From 50b905cd087654942e9d50907c64f6b727fdba0c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 2 Sep 2026 21:18:30 +0000 Subject: [PATCH 1/3] docs(issues): cancel the duplicate shallow-clone request before it becomes a second row MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two sessions independently hit the same defect and each filed an `add` request for it, and both are still pending: - `b11bdfdd` (P2) "Web-container sessions start on a shallow clone, so two committed specs fail with messages that read as content errors" - `4478f605` (P3) "Two tests fail on a shallow clone as ordinary assertion failures rather than refusing…" They are the same defect, not merely adjacent: both name `tests/clinical-hazard-controls.test.ts` and `tests/rag-plan-package-parity.test.ts`, and both name commits `883f1007` and `f3d1a3cc` as the truncated-history cause. `add` requests carry no `baseRowFingerprint`, so nothing makes them conflict. Left alone, the next reconciliation files two ledger rows for one defect — and there is no row yet, so neither would look like a duplicate of anything already recorded. This cancels the P3 and keeps the P2, which carries the fuller reproduction and the more accurate severity. Queued as an immutable cancel request rather than by deleting the P3, per the clause `check:ledger-write-discipline` cites when it rejects a partial batch: "use an immutable cancel request for each rejected mutation". The request is additive and reconciles nothing, so it does not trip the concurrent-reconciliation guard (`#EH9VA6`) while `claude/issues-reconcile-2526` is still unmerged. Raised by Codex review on PR #2530's successor #2560 and verified there. That PR was closed as a duplicate of #2559; the finding was not specific to it, so it is carried here rather than lost with the closure. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_014Mn8yfo1bQzk4kDEiG1TEn --- .../01961e5e-2e72-4a3e-a1d7-d7e1c485a37e.json | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 docs/outstanding-issues-inbox/01961e5e-2e72-4a3e-a1d7-d7e1c485a37e.json diff --git a/docs/outstanding-issues-inbox/01961e5e-2e72-4a3e-a1d7-d7e1c485a37e.json b/docs/outstanding-issues-inbox/01961e5e-2e72-4a3e-a1d7-d7e1c485a37e.json new file mode 100644 index 0000000000..ab4449d5b2 --- /dev/null +++ b/docs/outstanding-issues-inbox/01961e5e-2e72-4a3e-a1d7-d7e1c485a37e.json @@ -0,0 +1,10 @@ +{ + "version": 2, + "id": "01961e5e-2e72-4a3e-a1d7-d7e1c485a37e", + "createdOn": "2026-09-02", + "action": "cancel", + "payload": { + "requestId": "4478f605-1e05-4a8e-addd-32cf70e5d155", + "reason": "Superseded by pending add b11bdfdd-70eb-4bf9-9384-4d30af2a6ad2, which records the same defect at P2. Both are add requests filed independently by two sessions that each hit it, and both name the same two specs (tests/clinical-hazard-controls.test.ts, tests/rag-plan-package-parity.test.ts) and the same two commit shas (883f1007, f3d1a3cc) as the truncated-history cause. add requests carry no baseRowFingerprint, so nothing makes them conflict: left alone, the next reconciliation files two ledger rows for one defect. Cancelling this P3 keeps the P2, which carries the fuller reproduction and the more accurate severity. Raised by Codex review on PR #2560 (discussion_r3913118402), verified there, and queued separately because the finding is not specific to that PR and outlived its closure." + } +} From 2b2127adb4109331e8a42d1d2742f1cfc5e5e443 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 3 Sep 2026 18:27:32 +0000 Subject: [PATCH 2/3] issues: queue a done request for the already-materialized duplicate row Codex review on this PR (discussion_r3919851568) found that reconciliation 090347a3 already applied the P3 add request (4478f605) this PR's cancel targets, materializing both duplicate rows (#TK9GH7, #1M0J6D) in the canonical ledger before this branch was rebased onto that history. The existing cancel request is therefore a no-op on the next reconciliation (planRequestBatch treats an already-applied target as ineffective and leaves both rows unchanged). Queue an additive `done` request for #TK9GH7 instead, so the next reconciliation actually removes the duplicate and keeps #1M0J6D, the fuller P2 record of the same shallow-clone defect. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_0137etKe6X2p9HkXsXoYY8TA --- .../4b9739a8-83c8-4260-9178-cfb75a5c650b.json | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 docs/outstanding-issues-inbox/4b9739a8-83c8-4260-9178-cfb75a5c650b.json diff --git a/docs/outstanding-issues-inbox/4b9739a8-83c8-4260-9178-cfb75a5c650b.json b/docs/outstanding-issues-inbox/4b9739a8-83c8-4260-9178-cfb75a5c650b.json new file mode 100644 index 0000000000..aa35178545 --- /dev/null +++ b/docs/outstanding-issues-inbox/4b9739a8-83c8-4260-9178-cfb75a5c650b.json @@ -0,0 +1,11 @@ +{ + "version": 2, + "id": "4b9739a8-83c8-4260-9178-cfb75a5c650b", + "createdOn": "2026-09-03", + "action": "done", + "payload": { + "id": "#TK9GH7", + "outcome": "Duplicate of #1M0J6D. Both rows were materialized by reconciliation 090347a3 from two independent add requests (b11bdfdd P2, 4478f605 P3) describing the identical shallow-clone defect (same two specs, same two truncated commits). This PR's original cancel request targeted the already-applied 4478f605, which is now a no-op per planRequestBatch; this done request removes the resulting duplicate row directly instead. Flagged by Codex review (discussion_r3919851568) on PR #2575.", + "baseRowFingerprint": "34bcd4274dda7d262874445480ad86d370e06e5ba03c47879925d39b0c9d43ae" + } +} From f7117041772ad4d3f4ced2d239cfd63c5e7e097c Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 3 Sep 2026 18:29:48 +0000 Subject: [PATCH 3/3] docs(ledger): record Run PR sweep review of PR #2575 Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_0137etKe6X2p9HkXsXoYY8TA --- ...c2ae6a82f1b256ed2358dd3db62918db93e7c2893a968f82729.record.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 docs/branch-review-records/e6295edf2c91cc2ae6a82f1b256ed2358dd3db62918db93e7c2893a968f82729.record.md diff --git a/docs/branch-review-records/e6295edf2c91cc2ae6a82f1b256ed2358dd3db62918db93e7c2893a968f82729.record.md b/docs/branch-review-records/e6295edf2c91cc2ae6a82f1b256ed2358dd3db62918db93e7c2893a968f82729.record.md new file mode 100644 index 0000000000..49c47fb80e --- /dev/null +++ b/docs/branch-review-records/e6295edf2c91cc2ae6a82f1b256ed2358dd3db62918db93e7c2893a968f82729.record.md @@ -0,0 +1 @@ +| 2026-09-03 | claude/snapshot-conflicts-3w455k (PR #2575) | 666f88d81a91a5d996f666fbfe17f9a46f36a629 | Run PR sweep: CI fix + threads + drift | Before: mergeable_state behind main (stale snapshot said blocked), 0 CI checks reported, 1 unresolved review thread (Codex P2: cancel request targets an already-applied duplicate request, so it is a no-op). After: merged origin/main (1 unrelated docs-ledger commit, clean), queued an additive done request for #TK9GH7 marking it duplicate of #1M0J6D so reconciliation actually drops the row, thread replied to and resolved. No CI checks were reported against this head either before or after (repo's checks job scope did not select for a docs-only inbox change). | npm run check:outstanding-issues (pass, both pre- and post-merge), npm run check:ledger-write-discipline (pass, both pre- and post-merge), node scripts/ledger-inbox.mjs check (pass, 33 pending / 944 applied); no provider-backed checks run |