docs(issues): capture the H5a residual and the ledger id-scheme test gap

docs/branch-review-records/f76cd75e2ad4d6a67dd26e562753ca92c3cd2b63e321bef0fd8f7c226ee31714.record.md

@@ -0,0 +1 @@
+| 2026-08-18 | claude/issues-capture-h5a-residual-ulid-lookup | 5c9b69a7e6bd2a3f2a1f5abac1a19a71a1cd153b | two immutable outstanding-issues inbox requests (P3 issue: H5a residual after G1; P3 rec: ledger writer id-scheme test gap) — no product code | approved — inbox-request files only; canonical ledger untouched, applied later by issues:reconcile | verify:pr-local light docs scope, all 11 selected stages green (format:changed, docs link/index/inventory/scripts, branch-review-ledger, outstanding-issues, ledger-write-discipline); build/test correctly skipped as non-build-affecting; request JSON content verified incl. escaping |

docs/outstanding-issues-inbox/7c1f5850-ddcd-47da-89ad-99314d0040fe.json

@@ -0,0 +1,14 @@
+{
+  "version": 2,
+  "id": "7c1f5850-ddcd-47da-89ad-99314d0040fe",
+  "createdOn": "2026-08-18",
+  "action": "add",
+  "payload": {
+    "pri": "P3",
+    "type": "issue",
+    "summary": "H5a residual: whether a constant similarity of 1 may contribute to a confidence label is still open, and after G1 it lives only in the hazard doc",
+    "detail": "Packet G1 (PR #2053, merged 2026-08-17) implemented owner decision Option B: buildDocumentSummaryResults now stamps similarity_origin \"document_context\" on document-summary rows, deriveConfidence is unchanged, and document summaries still reach \"high\". That closed the LEGIBILITY half of the H5a live residual -- the fabricated 1.0 is no longer indistinguishable from a perfect cosine at any surface that reads a row. It did NOT answer the underlying governance question: may a score nobody measured contribute to the confidence label a clinician reads at all? Option B was chosen because tagging has no measured safety cost while Option A (tag as synthetic_text, capping summaries at \"medium\") is a label downgrade without measured gain -- so the question was deferred deliberately, not resolved. The paired question row #J912J9 is being closed by G1, so once that closure reconciles this knowledge survives only in docs/clinical-hazard-analysis.md H5a and not in the queue anyone reads. NEXT: no action required unless a measured signal appears; if it does, the tag is what makes the fix cheap -- any future gate can now discriminate the document-summary route without re-deriving provenance. Guard rails already in place: tests/rag-score.test.ts pins the discriminating pair (two document_context citations >= 0.82 -> \"high\"; the identical scores tagged synthetic_text -> \"medium\"), so a silent change in either direction goes red.",
+    "source": "Packet G1 session 2026-08-17 (PR #2053); docs/clinical-hazard-analysis.md H5a; closes-with #J912J9",
+    "issueUlid": "01M09A824C1PN5BM56CHVH0WKM"
+  }
+}

docs/outstanding-issues-inbox/f6798c46-7f43-4481-8e02-bcac1bf9b262.json

@@ -0,0 +1,14 @@
+{
+  "version": 2,
+  "id": "f6798c46-7f43-4481-8e02-bcac1bf9b262",
+  "createdOn": "2026-08-18",
+  "action": "add",
+  "payload": {
+    "pri": "P3",
+    "type": "rec",
+    "summary": "Ledger writer self-tests use only legacy numeric ids, which is why a Crockford-id lookup bug survived the ULID migration unnoticed",
+    "detail": "Fixed in PR #2053: issueRowFingerprint (scripts/check-outstanding-issues.mjs) matched only /^#(\\d+)$/ and keyed on entry.number, which is null on ULID-backed rows, so it returned null for every Crockford display locator -- and ledger-inbox.mjs reads a null fingerprint as \"no such row\" and refuses. npm run issues:done and issues:update were therefore unusable for EVERY row minted since the ULID migration, failing with \"#J912J9 is not in Open items\" about a row plainly in Open items. It surfaced only because a session happened to need to close two Crockford-id rows. ROOT CAUSE OF THE SURVIVAL, not of the bug: the self-tests and fixtures in scripts/outstanding-issues.mjs and tests/outstanding-issues-writer.test.ts exercise the writer almost entirely with legacy #005/#006/#013-style ids, so no test ever drove a Crockford id through the fingerprint path. A second, subtler trap sits in the same area and is now pinned but not generally guarded: Crockford's alphabet includes 0-9, so a ULID-derived locator can be ENTIRELY digits (the writer test's own id is #041061) and is indistinguishable from a legacy id by pattern -- branching on id shape rather than resolving against the table silently misses exactly those rows, which is how the first attempt at the fix still returned null. NEXT: add a fixture row with a ULID/Crockford id (ideally an all-digit one) to the shared ledger test fixtures and drive every writer entry point -- addIssue, resolveIssue, updateIssue, issueRowFingerprint, and the ledger-inbox done/update/reconcile paths -- through both id generations, so the next lookup left behind by an id-scheme change fails a test instead of a user's command.",
+    "source": "Packet G1 session 2026-08-17 (PR #2053), discovered while queueing the G1 closures",
+    "issueUlid": "01M09A9WXBDREDWA7KN2EB1JRA"
+  }
+}