docs(issues): close #TK9GH7 as a duplicate of #1M0J6D

[BigSimmo]

Summary

• One defect currently occupies two rows in the canonical ledger. Two sessions hit the shallow-clone failure independently and each filed an add request: 4478f605 → #TK9GH7 (P3) and b11bdfdd → #1M0J6D (P2). Verified as 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.
• Nothing prevented it. add requests carry no baseRowFingerprint, so they cannot conflict with each other, and no row existed for either to look like a duplicate of. Both landed.
• This closes the P3 and keeps the P2, which carries the fuller reproduction and the more accurate severity. One new file, eleven lines.

The closure is explicit that a duplicate record is being retired, not a defect fixed. Web-container sessions still start on a shallow clone and still see two spurious test failures; that stays open and tracked under #1M0J6D. Getting this wrong would read as "the bug is fixed" when it is not, which is why the outcome text says so in terms.

Why a done and not the cancel that #2575 tried

#2575 queued a cancel against 4478f605. That could not work, and the tooling says so itself. An intervening reconciliation had already applied that request, and planRequestBatch (scripts/ledger-inbox.mjs, the ineffective path) classifies a cancel whose target is already applied as recorded but changing nothing, warning:

cancel request … did not take effect — its target … was already applied by an earlier reconciliation. The cancellation is recorded but changed nothing; correct the affected row with a new update request.

Once the row exists, only a done or update retires it. #2575 was closed unmerged, so the inert file never landed — this PR is the correction, not a second attempt alongside it.

Raised by Codex review on #2575 and verified independently: every claim in that review checked out against the tree.

Verification

• npm run verify:pr-local — 13 gates completed, failed: (none), not reached: (none). Build correctly skipped: Skipping build: no build-affecting source, config, package, or container changes detected.
• npm run check:ledger-write-discipline — Ledger write discipline passed for 4995b79942e7..HEAD. Run after committing; it compares two committed refs, so a pass beforehand would have meant nothing.
• node scripts/ledger-inbox.mjs check — Ledger inbox check passed: 32 pending request(s), 944 applied.
• npm run check:outstanding-issues — [snapshot] in step with data/outstanding-issues-snapshot.json (73 open, 0 pending). The committed snapshot is untouched, which is the point: a queued request must not reach the committed artefact.
• Request shape checked directly: action: done | id: #TK9GH7 | baseRowFingerprint: present — the fingerprint pins it to the row's current content, so it is rejected rather than misapplied if that row changes before reconciliation.
• Confirmed on origin/main before queueing: both rows still present and open, and no pending request targets either one.
• npm run format (whole tree), committed
• UI verification not run: no UI, routing, styling or browser surface is touched.
• Not run, deliberately: no provider-backed gate (OpenAI, Supabase, eval:*, verify:release) — nothing here reaches a provider.

Risk and rollout

• Risk: very low and reversible. One additive file in the append-only inbox; no source, schema, workflow, or canonical ledger row edited directly. The ledger changes only when someone later runs issues:reconcile, and the request is reviewable before then.
• Rollback: revert the commit, which removes the queued request. Nothing downstream has consumed it.
• Provider or production effects: None.
• RAG impact: none.

Notes

• Branch restarted from origin/main at 4995b7994. The previous branch was deleted when docs(issues): cancel the duplicate shallow-clone request before it becomes a second row #2575 closed, so this is fresh work rather than a continuation.
• Auto-merge deliberately not enabled.
• Still outstanding for whoever reconciles next: 32 pending requests, and a check for an open reconcile branch before starting — two reconciliations opened 54 seconds apart already cost two PRs this week.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_014Mn8yfo1bQzk4kDEiG1TEn

---

Generated by Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[supabase]

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 ↗︎.

[BigSimmo]

Closing: this duplicates a done request that is already on main

Withdrawing this PR. The fix it carries already exists.

docs/outstanding-issues-inbox/4b9739a8-83c8-4260-9178-cfb75a5c650b.json reached main when #2575 merged, and it is the same request in every respect that matters:

	Already on main (4b9739a8)	This PR (61fdc9a1)
action	done	done
target	#TK9GH7	#TK9GH7
baseRowFingerprint	present	present
reasoning	duplicate of #1M0J6D, same two specs, same two truncated-history commits	identical

Landing both would put two pending done mutations on one row — which is the exact hazard this whole line of work has been about, and which the reconciler refuses outright (it did so earlier in this sequence on #XHADPV). Merging this would recreate the problem it was written to fix.

How this PR came to be opened, stated plainly rather than glossed. I checked main for an existing fix before queueing, and found none — but I checked against 4995b7994, and #2575's merge had not yet propagated into what I fetched. So the check was real but the base was stale, and I queued a second request for work already done. The lesson is the one already recorded on #2560: re-fetch immediately before queueing a ledger request, because this inbox changes under you in minutes.

Nothing is lost by closing. 4b9739a8 is pending on main and the next reconciliation will apply it, closing #TK9GH7 as a duplicate of #1M0J6D.

Still true and still open: the underlying defect is not fixed. Web-container sessions start on a shallow clone and see two spurious failures in tests/clinical-hazard-controls.test.ts and tests/rag-plan-package-parity.test.ts. That remains tracked under #1M0J6D — only the duplicate record is being retired.

---

Generated by Claude Code