Skip to content

Make the outstanding-issues snapshot merge-safe (v2), and record the measured assessment of two other rows - #2735

Open
BigSimmo wants to merge 3 commits into
mainfrom
claude/busy-mayer-d5ljkv
Open

Make the outstanding-issues snapshot merge-safe (v2), and record the measured assessment of two other rows#2735
BigSimmo wants to merge 3 commits into
mainfrom
claude/busy-mayer-d5ljkv

Conversation

@BigSimmo

@BigSimmo BigSimmo commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Summary

Three ledger rows were re-assessed against origin/main 0177bed before any code was written. One needed a fix, and got one. Two did not, and are recorded rather than "fixed" into something they no longer are.

Row Verdict What happened
#Y090R5 sibling snapshot Real. Fixed here. Root cause proven with a merge simulation; the fix mirrors repo-awareness-snapshot-v3
#KHTTW4 Ward Flow Overtaken. The eight failures are gone; the blind spot is designed out and held inert behind one repository setting
#RA0QAH flaky specs Half closed by measurement, half unfixable without evidence The generic trap does not exist elsewhere; the remaining three specs were never named and the CI logs are gone

1. The one real defect: data/outstanding-issues-snapshot.json

The pending half of #Y090R5 was already fixed — the committed artefact carries an empty pending, and only prebuild asks for the live list. ledger_revision is what was left, and it is the only field here measured changing as a side effect of unrelated work: PR #2690 ("calculators: remove directive clinical copy") touches no ledger file and rewrote exactly those two lines and nothing else in this snapshot.

The churn is structural rather than occasional. A reconciliation regenerates the snapshot and then becomes the ledger's newest commit, so the value it just wrote is stale the instant it lands — which is why the gate excludes ledger_revision from comparison in the first place. Every later branch that regenerates (pre-commit doc sync, docs:update, next build) rewrites the field with whichever ledger commit its base carries. Excluding a field from the gate never stopped it conflicting in git, because the bytes still shipped.

Proven by simulating that exact sequence — a ledger commit, one branch cut before it and one after, each regenerating during its own unrelated commit:

BEFORE (v1: sha + timestamp): CONFLICT (content) in data/outstanding-issues-snapshot.json
AFTER  (v2: date only):       CLEAN MERGE

The sha goes because nothing reads it: resolveFreshness uses committed_at alone. The timestamp coarsens to a day, so two branches regenerating on the same day write identical bytes — and same-day is the measured case, the two commits behind #2690's rewrite being 35 minutes apart. Branches a day apart still differ, which is deliberate residue: freshness is the one value here a reader cannot recompute.

counts is deliberately NOT removed, unlike its repo-awareness sibling. It derives from the canonical ledger alone, and ledger edits are serial by policy, so it is not a contended surface — 9 commits in 60 days, all but one of them reconciliations. Removing it would be a larger change than the evidence asks for.

readCommittedRevision normalises a v1 revision found on disk, because the preserve-instead-of-read path is taken by the production image (no .git) and would otherwise write the conflicting v1 shape straight back into a v2 file. Pinned by a new test.

2. Ward Flow (#KHTTW4) — do not fix, it is already fixed

npm run test:e2e:ward-journeys on a fresh origin/main worktree: 71 passed, 3 skipped, 0 failed. The eight failures are gone.

Two of the three skips are the ui-ward-morning pair, and that skip is an owner-approved decision rather than a silencing: MERGE 02 folded the morning board into CapacityScreen, MorningPage is unmounted, and morning-page.tsx's own comment forbids retargeting the spec or re-mounting the component pending the owner's ruling on spec D9. Component coverage continues in tests/ward-morning-page.dom.test.tsx (20 cases) and tests/ward-morning-print.test.ts.

The durable half — a path-scoped gate cannot report a break in code already broken on its base — is designed out: ui-ward-journeys now gates on needs.changes.outputs.ui_changed, not ward paths. It is held inert behind vars.WARD_JOURNEYS_BLOCKING, deliberately, so that turning it on is one act taken by somebody holding a green run. That precondition is now met, and the green run is recorded on the row. Setting that variable is a repository-settings change no pull request can make, so it is left to the owner.

3. Flaky Production UI specs (#RA0QAH) — one half closed, one half honestly left

That row's own text left a standing worry: the Next 16 prefetch-header trap is generic to any Playwright assertion trying to tell a prefetch from a navigation, and was worth grepping for. Grepped: two hits, both inside the already-fixed block. No second occurrence exists, so no further code fix follows.

The other three failures stay unfixed on purpose. The row never named the specs, the only pointers are CI runs past useful retention, and a fix without a reproduction is a guess — which is how a real failure gets quarantined by accident. Recorded as a watch item with the exact input to capture next time.

Verification

  • Merge simulation, before and after, quoted above — the decisive evidence
  • npm run test1269 files, 18067 passed, 2 expected fail, 3 skipped, exit 0
  • npx tsc -p tsconfig.json --noEmit exit 0
  • ESLint clean on every changed path
  • npm run format run whole-tree and committed
  • node scripts/check-outstanding-issues-snapshot.mjsin step with data/outstanding-issues-snapshot.json (121 open, 0 pending)
  • npm run test:e2e:ward-journeys — 71 passed, 3 skipped, 0 failed (the evidence behind §2)
  • npm run verify:pr-localVerification not run: deferred to CI. The full offline suite above is the widest gate this change can break.

No test was deleted, skipped or quarantined. Four fixtures moved to the v2 shape; one test added for the v1 normalisation path.

Risk and rollout

  • Risk: the snapshot is a developer-hub data file behind DeveloperAreaGate; no clinical, retrieval or patient-facing surface is touched. The version bump means a stale v1 snapshot fails loadLedgerSnapshot loudly rather than rendering an unexpected shape.
  • Rollback: revert the commit and regenerate.
  • Provider or production effects: None.
  • RAG impact: none.

Notes

  • The two ledger rows are updated through merge-safe inbox requests, not by editing the canonical ledger. Reconcile after this lands.
  • Historical plan and spec documents under docs/superpowers/ still name v1. They are a record of what was built then and are deliberately left alone.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KmcnnSgi8sxy7dQipsYCWG


Generated by Claude Code


Note

Low Risk
Changes affect developer-hub snapshot data and generation only; no patient-facing or auth paths, with a loud version mismatch if a stale v1 snapshot remains.

Overview
Outstanding-issues snapshot v2 removes the unused sha from ledger_revision and stores only a date (YYYY-MM-DD) for committed_at, matching the approach used for repo-awareness-snapshot-v3. The goal is to stop unrelated branches from merge-conflicting on regenerated snapshot bytes when they rebuild on the same day, while freshness still uses committed_at via resolveFreshness.

The generator adds toRevisionDate, reads git with date-only output, and normalizes v1 revisions on the production preserve path (no .git) so old sha+timestamp shapes are not written back into v2 files. Types, constants, committed data/outstanding-issues-snapshot.json, and tests are updated accordingly, including a new test for v1 normalization.

Two merge-safe inbox updates (not direct ledger edits) record reassessment of #KHTTW4 (ward journeys green; enable WARD_JOURNEYS_BLOCKING in repo settings) and #RA0QAH (prefetch grep clean; remaining flaky specs left as P3 watch without quarantine).

Reviewed by Cursor Bugbot for commit 274f2ac. Configure here.

… revision, drop the sha

Closes the second half of #Y090R5. The `pending` half was fixed already —
the committed artefact carries an empty `pending` and only `prebuild` asks
for the live list. `ledger_revision` is what was left, and it is the only
field in this file measured changing as a side effect of unrelated work:
PR #2690 ("calculators: remove directive clinical copy"), which touches no
ledger file, rewrote exactly those two lines and nothing else here.

The churn is structural, not occasional. A reconciliation regenerates the
snapshot and then becomes the ledger's newest commit, so the value it just
wrote is stale the instant it lands — which is why the gate excludes
`ledger_revision` from comparison in the first place. Every later branch
that regenerates (pre-commit doc sync, docs:update, next build) rewrites
the field with whichever ledger commit ITS base carries. Two branches cut
either side of a reconciliation write different values into adjacent lines
at the top of the file. Excluding a field from the gate never stopped it
conflicting in git, because the bytes still shipped.

Proven by simulating that exact sequence — a ledger commit, one branch cut
before it and one after, each regenerating during its own unrelated commit:

  BEFORE (v1: sha + timestamp): CONFLICT (content) in
                                data/outstanding-issues-snapshot.json
  AFTER  (v2: date only):       CLEAN MERGE

The sha goes because nothing reads it: `resolveFreshness` uses
`committed_at` alone. The timestamp coarsens to a day, so two branches
regenerating on the same day write identical bytes — and same-day is the
measured case, the two commits behind #2690's rewrite being 35 minutes
apart. Branches a day apart still differ, which is deliberate residue:
freshness is the one value here a reader cannot recompute.

`counts` is deliberately NOT removed, unlike its repo-awareness sibling.
It is derived from the canonical ledger alone, and ledger edits are serial
by policy (one reconciliation branch), so it is not a contended surface —
9 commits in 60 days, all but one of them reconciliations. Removing it
would be a larger change than the evidence asks for.

Same device and reasoning as `captured_revision` in
repo-awareness-snapshot-v3, which closed the identical defect in the
sibling file.

Version bumped to outstanding-issues-snapshot-v2 so a stale v1 snapshot
fails `loadLedgerSnapshot` loudly rather than rendering a shape the reader
no longer expects. `readCommittedRevision` normalises a v1 revision it
finds on disk, because the preserve-instead-of-read path is taken by the
production image (no `.git`) and would otherwise write the conflicting v1
shape straight back into a v2 file — pinned by a new test.

No test deleted, skipped or quarantined. Four fixtures moved to the v2
shape; one test added for the normalisation above.

Verification:
- npm run test: 1269 files, 18067 passed, exit 0
- npx tsc -p tsconfig.json --noEmit: exit 0
- eslint clean on every changed path; npm run format committed
- node scripts/check-outstanding-issues-snapshot.mjs: in step (121 open, 0 pending)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmcnnSgi8sxy7dQipsYCWG
…c rows

Two rows filed on 2026-09-06 were re-assessed against origin/main 0177bed
rather than fixed, because measurement showed neither needs the fix its
row implies.

#KHTTW4 (Ward Flow): the eight failures are gone — 71 passed, 3 skipped,
0 failed. The path-scoped blind spot the row exists for is designed out,
the lane now gating on ui_changed rather than ward paths, but it is held
inert behind vars.WARD_JOURNEYS_BLOCKING until somebody has a green run in
hand. That precondition is now met and the run is recorded, so the one
remaining action is a repository-settings toggle no PR can perform.

#RA0QAH (flaky Production UI specs): the standing worry its own text
raised — that the Next 16 prefetch-header trap might sit elsewhere — is
closed by a repository-wide grep returning only the already-fixed site.
The other three failures stay unexplained, and deliberately unfixed: the
row never named the specs, the CI runs are past useful retention, and a
fix without a reproduction is a guess that risks quarantining something
real.

Queued as merge-safe inbox requests; reconcile after this lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmcnnSgi8sxy7dQipsYCWG
@coderabbitai

coderabbitai Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Team

Run ID: adcdc632-eb27-4ee7-8072-603c8fadc685


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@supabase

supabase Bot commented Sep 7, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 7, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-07T11:58:51.597903Z 274f2ac PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@cursor

cursor Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_792c07c6-15a3-4628-9d37-2e4f66e1a9e3)

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 274f2ac96e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/generate-outstanding-issues-snapshot.mjs
…ock time and a false hour count

Codex review finding on this PR (P2), confirmed by reading the render path
rather than taken on trust — and it is worse than reported: the same defect
is already live on main for the repo-awareness snapshot, whose
`captured_revision` has been a date since v3. One fix in FreshnessStamp
covers both, because line 82 was the only snapshot-mode render of ageHours.

Two false claims, both from parsing a date as midnight UTC:

- `new Date("2026-09-07")` formatted with `timeStyle` in Australia/Perth
  renders "7 Sept 2026, 08:00 AWST". Nothing recorded 08:00. This component
  exists to stop confident-looking stamps carrying no information, so
  manufacturing one is squarely the failure it guards against.
- `ageHours` measured from that midnight is wrong by however far into the
  day the commit actually was, up to a full day, so a ledger update can read
  as "24 hours old" minutes after landing.

A date-only value now renders as a date, with no clock time and no zone,
and ages in whole days. A full timestamp keeps hour precision, pinned by a
test so this cannot quietly coarsen the live ingestion stamp.

The day arithmetic is UTC on both sides, and correcting that was a genuine
bug in my own first attempt, caught by the 23:59 test rather than by
reading. The stored date comes from a commit's `%cI`, so it is a UTC
calendar date; comparing it against the reader's Perth date mixes zones and
adds a further day of error on top of the day already lost to rounding —
23:59 UTC is 07:59 next morning in Perth, which called a just-landed commit
"1 day old". Rendering stays pinned to Perth like the rest of the
component, and midnight UTC falls on the same calendar date there anyway.

Four tests added: no fabricated clock time, the reported 23:59 case reading
"same day", singular "1 day old", and hour precision retained for a real
timestamp. No test deleted, skipped or quarantined.

Verification:
- npm run test: 1269 files, 18071 passed, exit 0
- npx tsc -p tsconfig.json --noEmit: exit 0
- eslint clean on both changed paths; npm run format committed

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KmcnnSgi8sxy7dQipsYCWG
Sign up for free to 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.

2 participants