Skip to content

ci: tiered PR checks — parallel ui-smoke job + required-check plan - #150

Merged
BigSimmo merged 1 commit into
mainfrom
claude/ci-tiered-pr-checks
Jul 2, 2026
Merged

ci: tiered PR checks — parallel ui-smoke job + required-check plan#150
BigSimmo merged 1 commit into
mainfrom
claude/ci-tiered-pr-checks

Conversation

@BigSimmo

Copy link
Copy Markdown
Owner

What

Splits the single serial ~6.5-minute verify CI job into two parallel PR jobs:

  • verify — runtime alignment, edge typecheck, CI-safe production readiness, lint, typecheck, unit tests (coverage gate), build. ~3 min.
  • ui-smoke — Chromium Playwright smoke (boots its own dev server, so no build step needed). ~4.5 min.

The deployment boot smoke stays inside verify gated to main/release/dispatch/schedule, and release-browser-matrix now needs both jobs (preserving the old "matrix only after smoke passed" semantics).

Why

Clinical governance preflight

No ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output changes — CI orchestration and process docs only.

🤖 Generated with Claude Code

Split the serial ~6.5-minute verify job into two parallel PR jobs:
verify (static checks, unit tests, build; ~3 min) and ui-smoke
(Chromium Playwright smoke; ~4.5 min). PR wall-clock drops to the
slower job and a smoke rerun no longer repeats lint/type/tests/build.
The check names verify, ui-smoke, and Gitleaks are intended as
required status checks on main; documented in process-hardening.md
alongside the existing required-check debt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@BigSimmo
BigSimmo merged commit 25df493 into mainJul 2, 2026
4 checks passed
@BigSimmo
BigSimmo deleted the claude/ci-tiered-pr-checks branch July 2, 2026 11:56
BigSimmo added a commit that referenced this pull request Jul 30, 2026
Main resolved#148 via #1491 and moved it to the archive table, so its side of
the open-items hunk was empty. Resolution keeps main's archival and re-adds only
#149, #150 and #151; the next-id marker stays at 152, which is the value this
branch allocated and is still above main's highest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BigSimmo pushed a commit that referenced this pull request Jul 30, 2026
Re-lands the rows that were reverted out of this PR earlier, now that
auto-merge is off and there is no merge race to lose them to. Recording them
here makes them durable: they were otherwise held only in an ephemeral
session and in pre-revert commits that the squash-merge would make
unreachable.
#149 task — adopt a consolidated answer-home notice block. The hero stacks
three notices in three type sizes with two opposing shield
icons, and the least important reads loudest. Adoption moves
PrivacyInputNotice, the single site-wide APP-5 line, across the
answer, documents and calculators composers, so it needs a full
clinical governance preflight rather than a design review.
#150 issue — answer mode ships no verify-before-use caveat while
differentials, prescribing, specifiers and calculators all do.
Stands independently of any redesign.
#151 issue — verify:pr-local exits 0 when guard-next-build refuses to run,
reporting green with the production build never executed.
Ids allocated above main's current highest (#148); the marker moves to 152.
The three cross-references between the rows were updated to match.
check:outstanding-issues: 149 rows (60 open, 89 archived), unique ids,
next-id=152 above the highest, no merge driver.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NPyFcMfn1jMmphr6AqiWBg
BigSimmo pushed a commit that referenced this pull request Jul 30, 2026
main landed its own #133 fix, which strips the Prettier column padding from
the issues ledger. That reformats every row, so the whole table conflicted
rather than just the rows anyone edited — the last and largest instance of
exactly the problem #133 exists to end.
Resolved by taking main's unpadded table wholesale and re-emitting this
branch's three captured rows in the same format (#149 adopt a consolidated
answer-home notice block, #150 answer mode ships no verify-before-use caveat,
#151 verify:pr-local exits 0 when its build step refuses to run). Taking one
side wholesale is safe here only because this branch's sole contribution to
the file is those three rows; main's own rows are unmodified.
check:outstanding-issues: 149 rows (59 open, 90 archived), unique ids,
next-id=152 above the highest, no merge driver, no ids deleted from base
00ddb22 — main's new #148 gate confirming nothing was dropped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NPyFcMfn1jMmphr6AqiWBg
BigSimmo added a commit that referenced this pull request Jul 30, 2026
#150 — the four at-risk worktrees were snapshotted onto their own already-merged
branches (748ef018f, 5dbd9f965, b7eae51a4, d949859c3), so the work survives a
worktree reclaim. All four are clean now. None is pushed or reviewed; the next
action is per-snapshot promote-or-reset.
#151 — the never-pushed branch is superseded rather than salvageable: its script
and hook reached main by other routes, so the fail-open guard was applied to
main's committed hook in PR #1494 instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BigSimmo added a commit that referenced this pull request Jul 30, 2026
 edits
Another session reconciled the same three rows while this one snapshotted the
worktrees. Resolution keeps this side for #149 and #150 (theirs carried no
snapshot SHAs) and unions #151: their PR #1442 provenance plus the correction
that the archived #143 row implied the fail-open was durable when only the hook
and script had landed, kept alongside this side's redirect to PR #1494.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BigSimmo pushed a commit that referenced this pull request Jul 30, 2026
The conflict was TWO lines — my side removed the open #130 row because it
moved to the archive table, main kept it. Taking my side; #130 remains a
single 5-cell archived row, #149 and #150 remain 7-cell open rows, and
main had claimed neither id (its marker was 149).
Worth recording the size: this same conflict before PR #1479 would have
been the whole 148-row table, because one row edit re-padded every row.
Un-padded it is 2 lines. That is the first conflict since #1479 landed and
it behaved exactly as the change predicted.
Verified: check:outstanding-issues 148 rows (57 open, 91 archived), unique
ids, next-id=151, no merge driver, no ids deleted from base; prettier clean;
no conflict markers remain.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ
BigSimmo added a commit that referenced this pull request Jul 30, 2026
…ge gaps (#1496)
* issues: close#130 by decision; capture the stale-install and reviewer gaps
#130 is archived because the owner decided not to pursue it, NOT because
the acceptance was run. The row says so in its first sentence, because a
"CLOSED" line is exactly the thing a future reader could mistake for
evidence: docs/phone-chrome-physical-acceptance.md on main is still the
blank template, and nothing in CI covers what it covers — headless Chromium
was explicitly stated as unable to certify Safari chrome-minimisation or
cold-launch PWA paint. Residual risk is unchanged and unmeasured, and the
row says to open a fresh one if phone-chrome misbehaves on a real device.
Two risks that surfaced during today's work were never written down, and
neither had an existing row (checked before adding, after creating a
duplicate earlier today by not checking):
#149 — the SessionStart hook reported "node_modules matches the lockfile"
while brace-expansion was installed at 1.1.16 against a lockfile pinning
1.1.18, the CVE-2026-14257 patch. Every local gate run in that window was
weaker than reported, including verify:cheap runs called green during
#1430/#1444. It surfaced only because installed-lock-parity asserts the
patched behaviour directly, and its failure was first misread as a
pre-existing repo defect because it also failed on clean main in the same
stale container. Notes that check:installed-lock-parity is only in
verify:ui, so the broad local gate cannot catch its own stale foundation.
#150 — CodeRabbit reviewed none of #1404, #1430, #1444, #1445 or #1479;
every comment was a spending-cap rate-limit notice that renders as ordinary
bot activity. Codex was the sole substantive reviewer and found three real
defects that survived local gates and self-review.
Fast checks run against this tree: check:runtime, check:installed-lock-parity
(now passing, confirming the drift is resolved), check:outstanding-issues,
check:branch-review-ledger and check:migration-role all PASS.
check:supabase-project and check:production-readiness fail only on absent
provider credentials, which AGENTS.md states is expected in demo mode.
Verified: check:outstanding-issues 148 rows (57 open, 91 archived), unique
ids, next-id=151, no merge driver, no ids deleted from base; docs:check-links
clean; whole-tree prettier clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ
* issues: correct #149 — parity check scope, not its placement
Codex review is right on both counts and this rewrites the row rather than
patching around it. The earlier text said check:installed-lock-parity lives
only in verify:ui and proposed adding it to verify:cheap; verify:cheap:internal
already runs it, so that follow-up was a no-op — and it ran green throughout
the stale window.
The real gap is scope. criticalInstalledPackages lists seven top-level names
(next, react, react-dom, eslint, playwright, typescript, vitest), so a stale
transitive dependency is invisible. Proved by faking node_modules/brace-expansion
back to 1.1.16 against the 1.1.18 lockfile pin: check:installed-lock-parity
exits 0. That also explains why both the hook and the gate reported parity
while the tree was stale — neither was looking at the package that drifted.
Next step is now to broaden the check (full tree, or a lockfile-hash install
stamp) rather than move it, and the row warns against reading a green parity
run as proof the install is current.
Verified: check:outstanding-issues 148 rows, unique ids, next-id=151, no ids
deleted from base; docs:check-links 1413 references; prettier clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ
---------
Co-authored-by: Claude <noreply@anthropic.com>
BigSimmo pushed a commit that referenced this pull request Jul 30, 2026
Fourth ledger id collision on this branch: main allocated #149
(check:installed-lock-parity only compares seven top-level packages) and #150
(CodeRabbit reviewed none of a full day's PRs) while this branch held
#149-#151 for the answer-home notice capture.
main's rows are kept and the incoming rows renumber per the ledger's own
rule: #151 adopt a consolidated answer-home notice block, #152 answer mode
ships no verify-before-use caveat, #153 verify:pr-local exits 0 when its
build step refuses to run. Their three cross-references and the marker (154)
follow.
check:outstanding-issues: 151 rows (58 open, 93 archived), unique ids,
next-id=154 above the highest, no ids deleted from base 4312a21.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NPyFcMfn1jMmphr6AqiWBg
BigSimmo added a commit that referenced this pull request Jul 30, 2026
…closed (#1508)
PR #1490 was closed unmerged, so none of its content reached main. Confirmed by
content rather than id: main's #149 and #150 are unrelated rows (installed-lock
parity and CodeRabbit rate limits) that happened to take those ids, so an
id-presence check reported them as landed when they were not.
- #151 corrects the earlier claim that CI is unreadable. The PAT lacks Checks:
read but has Actions: read, so workflow runs are queryable; the endpoint that
looked authoritative returns an empty result rather than an error, which is
what made it read as a hard wall.
- #152 re-lands the at-risk worktree inventory together with the four
preservation snapshots taken on 2026-07-31, which existed in no other record.
- #153 archives the pre-commit fail-open as resolved by PR #1494.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
BigSimmo added a commit that referenced this pull request Jul 31, 2026
* issues: capture the unreadable-CI token, at-risk worktree work, and the unpushed hook fix
Three findings from the 2026-07-30 organisation session that were recorded
nowhere durable:
- #149 the session GitHub PAT lacks Checks: Read, so no agent can confirm a PR
is green. The endpoint that does work returns an empty result rather than an
error, so it reads like an absence of checks rather than an absence of
permission.
- #150 four worktrees on already-merged branches hold uncommitted work that
exists in no branch and no PR, the largest being +395/-200 across 19 files
including CI config.
- #151 the pre-commit fail-open for #143 lives only on a never-pushed local
branch, which is also 17 behind main and conflicts on the file whose count
sentence main's new docs:update generator now owns.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(ledger): record the session-followup capture review for PR #1490
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(ledger): record #143/#151/#149 reconciliation for PR #1490
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs(ledger): supersede PR #1490 reconciliation after remote sync
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* issues: record the worktree snapshots and redirect #151 to PR #1494#150 — the four at-risk worktrees were snapshotted onto their own already-merged
branches (748ef018f, 5dbd9f965, b7eae51a4, d949859c3), so the work survives a
worktree reclaim. All four are clean now. None is pushed or reviewed; the next
action is per-snapshot promote-or-reset.
#151 — the never-pushed branch is superseded rather than salvageable: its script
and hook reached main by other routes, so the fail-open guard was applied to
main's committed hook in PR #1494 instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: remove credential metadata and correct audit dates
* docs: consolidate session follow-up findings
* docs: record consolidated follow-up review
* issues: record that #101 hydration shipped
PR #1463 merged as dba7356, so #86's "Next X3 unit — rag-hydration.ts" is
now stale. The row records the extraction as shipped and keeps the corrected
boundary: hydration re-homed only two of prepareCoverageGateResults's five
rag.ts-only dependencies, so it did not unblock that function — exactly as the
Codex review on PR #1461 predicted.
This row was deliberately dropped from #1463 itself (commit 6290d02) after
docs/outstanding-issues.md conflicted on five consecutive main syncs. Recording
it separately here is the same pattern used for #1454 via #1461.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GGEBHp4Seoh1jK1vGTNtYS
* docs(ledger): record the landed X3 hydration review
Appended with npm run ledger:append (never hand-written), keyed to the squash
commit dba7356 so ledger:lookup can resolve it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GGEBHp4Seoh1jK1vGTNtYS
* docs: fix the #101 mislabel and key the ledger row to a resolvable ref
Both defects were raised by Codex on PR #1495 and both are real; verified
against the files before accepting.
1. #101 is NOT this extraction. docs/outstanding-issues.md:138 shows #101 is
"Canary-gated retrieval parallelisation candidates" (P3, rec) — a separate,
still-open recommendation gated on a live canary pair. Calling the hydration
extraction "#101" marked that unrelated work as shipped and could have caused
the live-evaluation work to be skipped. The label came from the original task
brief and was propagated without checking it against the ledger. Both the
#86 row and the X3 work-order entry now identify the change as the X3
hydration unit (PR #1463) instead. #101's own row is untouched and still open.
2. The ledger row did not resolve. `npm run ledger:lookup --
dba7356` returned NOT REVIEWED, because the
ref cell held only the slash-form branch token and that branch no longer
resolves locally, so the throttling record could not prevent a repeat review.
Appended a superseding record keyed to the landed SHA; the same lookup now
returns ALREADY REVIEWED. The original row is retained, per the ledger's
append-only rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GGEBHp4Seoh1jK1vGTNtYS
* docs: record consolidated PR reviews
* docs: record ingestion recovery review
* docs(visual): document the platform-scoped baseline layout and how to seed it
`playwright.visual.config.ts` records snapshots under
`__screenshots__/{platform}/`, so a baseline taken on Windows lands in `win32/`
and is never consulted by the `ubuntu-24.04` CI job, which reads `linux/`.
Nothing said so, and committing `win32/` images looks like protection while
providing none.
Records the constraint, names the CI artifact as the supported recorder for
`linux/` baselines, and notes that comparison stays advisory until the jobs come
off `continue-on-error`. Also creates the tracked directory `.gitignore` already
claims exists, which sets `ui_changed=true` (`scripts/ci-change-scope.mjs`) so
the visual job can run and produce that first artifact.
No baselines are added here — they cannot be produced on this platform.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: correct visual baseline adoption steps
* docs: record visual baseline guidance review
* fix(ui): repair mockup accent token references
* docs: record token-reference repair review
* docs: archive advisory UI scoping task
* docs: record advisory UI closure review
* issues: archive #151 after #1494 and mark #143 fully resolved
PR #1494 landed the fail-open guard on main, so close the open salvage
row and update the #143 archive from PARTIAL to resolved across #1442
and #1494. Also carries the merge of origin/main that cleared the
GitHub DIRTY mergeability state.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs(ledger): record PR #1490 main-sync and #151 closeout
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs(ledger): record #1496 id-collision renumber for PR #1490
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* issues: record the withdrawn live-region finding as #151 so it is not re-filed
Archive-only row. There is no defect and no work to do — the row exists purely
as a guard rail against repeating a misreading that already happened once.
search-results-header-band.tsx sets aria-live={faulted ? "off" : "polite"} on
its count/status span, which reads like a silenced failure announcement. It is
not: the band mounts a separate fault panel with role="alert" carrying the
failure title, body and Retry, and the mute is deliberate so the two do not both
speak. The reasoning is in a comment directly above the attribute, and
tests/search-results-header-band.dom.test.tsx pins it with singular role queries
that throw on duplicates.
During session 2026-07-30 (PR #1481) this was filed as a real P2 defect on the
strength of the attribute alone, and the proposed fix — escalating the count span
to role="alert"/aria-live="assertive" — would have produced a duplicate
announcement and a red test, making it worse than no change. Codex caught it.
An earlier withdrawal row was then lost to the squash that merged #1481, which
is the row-deletion shape #148 now guards against.
Also records that the mockup's escalation is correct in the mockup and must not
be ported: search-refine-adaptive-mockups.tsx has no fault panel, so there the
count span is the only announcement channel.
#148 needed no work — the merge-base deletion check landed on main
independently, and its output now reports the base it compared against.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JdPa3mHCX5ZQZZvU5GHU3r
* docs(rag): record refuted lexical probe collapse (#98)
* issues: capture the residual id-allocation hazard as #151#133 is resolved: #1444 removed merge=union and #1479 excluded the ledger from
Prettier, which together fixed conflict frequency. Neither changes id
allocation, which is still read-modify-write against the next-id marker, so
concurrent branches still claim the same number.
Measured on PR #1451: one row was renumbered #135 -> #141 -> #145 -> #147 ->
#149 across four sync cycles. The sharper finding is that GitHub's Update-branch
button resolved one such collision into duplicate #141 rows with the marker left
below main's highest id — git reported success and only
check:outstanding-issues caught it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(issues): attribute the mobile CLS breach — a 128px reserve round trip
#147 asked which elements shift. Driving Chromium against the same
offline production build with a PerformanceObserver on layout-shift
(Lighthouse mobile emulation, reading entry.sources[].node) gives one
dominant cause on all four breaching routes: the entire main content
region moves down 128px and straight back up 128px within 15-60ms. Both
moves score, so it is pure cost with zero net movement — 100% of
/documents/search's 0.220 and about 75% of /dsm's.
The shifting element is the max-sm:pt-[var(--phone-overlay-chrome-h)]
wrapper around <main>. A MutationObserver timeline on the root style
attribute pins the mechanism rather than inferring it: the property goes
CSS seed -> 200px -> 72px, and the 200px is written when the header
stack ALREADY measures 72px (t=1552ms reserve=200px stack=72, corrected
at t=1612ms). usePhoneOverlayChromeReserve reads stack.offsetHeight
while the stack is transiently tall, publishes a value that is stale by
the time it lands, and its ResizeObserver then corrects it.
The CSS seed at globals.css:375 is correct for the settled stack, which
corrects the mechanism recorded on the now-archived #130 — that framed
the defect as the seed under-reserving by 0-8px. Measured, the driver is
a 128px transient over-reserve written by the hook, not the seed. / is
the control: it never writes the property and is the one clean route.
Variance is stated rather than smoothed: /dsm measured 0.363 and 0.219
across two runs, and this harness has no network throttling so /forms
and /therapy-compass run high locally. Only /dsm, /documents/search and
/ reproduced the live dispatch exactly.
Also recorded: attaching a MutationObserver to document.documentElement
inside a Playwright addInitScript throws before the document element
exists, silently killing the CLS observer and reporting a uniform
CLS=0.000 — a false clean bill that voided one run of this harness.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF
* docs(ledger): record the #151 capture review for PR #1506
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(review): clarify snapshot branch state
* docs(ledger): record PR #1490 main sync after snapshot wording
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs: archive rendered style contract task
* docs: record style contract closure review
* docs: record synced style contract review
* docs: record post-121 style closure review
* docs: normalize style review ledger after sync
* docs: record post-1490 style closure review
* docs: record consolidated PR 1490 review
* docs: record replacement consolidation review
* docs: record reconciled consolidation review
* docs: record post-1511 consolidation review
* docs: normalize PR 1510 ledger after main sync
* docs: record PR 1510 post-sync review
* docs: correct false #98 canary evidence and NOTES triage
Remove the incorrect probe-collapse canary attribution from #98 and
point the unread --med-accent-soft note at #157 without breaking the
seven-token TOKENS_MISSING accounting.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs(ledger): record PR #1510 evidence-correction review
Supersede the prior approve-with-no-findings row after correcting the
false #98 canary attribution and NOTES triage drift.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs: keep concurrency note inside issue table
* docs: record post-1513 consolidation review
* docs: address CodeRabbit notes on PR #1510
Fix the computed-value-time wording in design-sync notes, give #33 a
unique recommended-queue order, and drop the duplicated #98 Done block.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
* docs(ledger): record PR #1510 CodeRabbit fix review
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
BigSimmo pushed a commit that referenced this pull request Jul 31, 2026
Resolves the fifth conflict on docs/outstanding-issues.md by taking
main's side on both hunks, after verifying that was correct rather than
convenient: main renumbered the queue to fix a duplicate rank 18 this
branch introduced, and it archived #138 and #146 rather than dropping
them (confirmed present in the archive table). The resulting id set is
byte-identical to main's.
#150 escalated. That row records CodeRabbit reviewing none of a full
day's PRs and rests explicitly on the Codex connector being the
surviving reviewer that "found three real defects that had survived
local gates". On PR #1505 Codex posted its own usage-limit notice
alongside CodeRabbit's spending-cap notice, so that PR received zero
automated review and so will anything opened while both caps hold. This
is the same issue with its fallback removed, not a new one — which
matters because the single Codex finding on #1459 was correct and
caught a verification that had matched the wrong component, closing
#105 on bad evidence. Local gates did not catch it.
The attribution harness lands as scripts/measure-cls-attribution.mjs.
#147's next step needs a before/after CLS pair, and #118 will want
element attribution again; without this, both mean re-deriving it. Build
and serve mirror run-lighthouse-budget.mjs so the numbers sit beside the
Lighthouse reports. Two traps that cost real time are encoded rather
than left to be rediscovered: CHROME_PATH must be set where the browser
is outside a standard location, and an init script attaching a
MutationObserver to document.documentElement before <html> exists throws
and silently takes the CLS observer with it — so the script now fails
loudly on an all-zero result instead of reporting a false clean bill.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF
BigSimmo added a commit that referenced this pull request Jul 31, 2026
CopilotAI added a commit that referenced this pull request Aug 12, 2026
- Make #150 decision bot-agnostic: covers CodeRabbit spending-cap AND
Codex quota/limit notices; neither counts as reviewer coverage
- Extend #151 CI observation procedure to query job-level PR required
aggregate (GET /actions/runs/{id}/jobs) and require conclusion:success
on the PR required job, not just workflow-run conclusion
- Add CI observation fallback section to docs/codex-review-protocol.md
so the durable #151 rule lives in the required operational doc (#187)
- Update outstanding-issues.md #151 resolution to point to both docs"
Co-authored-by: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@BigSimmo