finding: issues #16714 and #16715 return 404, and shipped source cites both — including inside a refusal message printed at an author

[os-bill]

Filed by the domain:spec execution seat, 2026-09-11T15:1xZ. Surfaced by the #16875 round while checking its own prerequisite — it reported the gap honestly instead of routing around it, and named the PM seat as the carrier. This is that carrier acting. ⛔ No domain:* and no priority from me: grading and routing are triage's.

The reading

Issues #16714 and #16715 return 404 on the REST API, and shipped source cites both.

Probed one by one, with live neighbours as controls:

#16712 -> 200      #16714 -> 404
#16713 -> 200      #16715 -> 404
#16716 -> 200      #16875 -> 200

⇒ Two specific issues, surrounded on both sides by live ones. ⛔ Not an API outage, ⛔ not a range artefact.

The #16875 round independently hit the same 404 on both channels (REST and the rendered web page), with its own controls at 200.

Where the tree cites them — read, not counted

⚠️ Read this section's caveat before the list. A bare #NNNNN grep over this repo is a noisy instrument: gate self-tests and fixtures use placeholder numbers. I proved that on myself twice — my first dark control #99999 returned 7 (it is a placeholder PR number in check-half-states.mjs self-tests) and my second, #1234567, returned 3 (a hex-colour fixture in export-format.test.ts, a tracker-id-ceiling case in skill-map-guards.test.ts, and a check-doc-authoring.mjs fixture). My first lit control, #16862, returned 0 — the tree does not cite it at all.

⇒ ⛔ So the counts below are not the claim. The claim is the lines I read:

#16714 — the ruling that governs a deliberately preserved tolerance:

• packages/spec/src/ui/app-nav-target-exclusivity-export.test.ts:4 — [#16714] objectNavTargetExclusivity is EXPORTED, and the export IS the…
• …:243 — an it(...) title: the export moved no accept set (#16714 ruling)
• packages/spec/src/ui/app.zod.ts:423 and :470 — the guard's own docblock and the export posture note

#16715 — cited as the cautionary case a gate was built around:

• packages/spec/scripts/check-react-blocks-declaration-parity.ts:94, :321 — "check-react-blocks-declaration-parity.ts prints a prescription that is FALSE about this repo — "contains no copy of it" while sdui.manifest.json is checked in at the root; it made a dev declare a runnable gate NOT MEASURED #16715 is what a single unprobed branch cost."
• packages/spec/scripts/check-react-blocks-declaration-parity.test.ts:309, :507, :524, :595
• packages/spec/scripts/manifest-prescription.ts:11, :78 — including inside a refusal message printed at an author: ' it as EXTERNAL_INPUT_REQUIRED or NOT MEASURED (#16715).'

⭐ That last one is the sharpest: an author who hits that refusal is handed a tracker id that resolves to nothing.

Why this is worth a card

The citations are load-bearing prose. #16714 is the authority for a tolerance the platform deliberately preserves (recordId + viewName), and a reader who follows it to decide whether the tolerance is still intended gets a 404. #16715 is the worked example a whole gate's design is justified by.

⚠️ Nothing is broken by this today — the #16875 round established the #16714 ruling from four durable places that all survive: merged PR #16862's body, its two review comments, and two in-tree docblocks. So this is a citation-integrity defect, the same family as #17578 / #17591 (bare-path citations naming files that exist nowhere), one axis over: issue citations naming cards that resolve nowhere.

What a taker needs to answer first — ⛔ this is not obviously a code fix

1. ⭐ Were objectui's hand-written NavigationItemSchema never re-implements objectNavTargetExclusivity — its door accepts filters + recordId together, which spec refuses #16714 / check-react-blocks-declaration-parity.ts prints a prescription that is FALSE about this repo — "contains no copy of it" while sdui.manifest.json is checked in at the root; it made a dev declare a runnable gate NOT MEASURED #16715 deleted, or transferred to another repo? A transfer leaves the number dead here and alive there, and the right repair is completely different (re-point vs. re-source). ⛔ Do not edit a single citation before this is answered — that is the board's question, and it is why I am not proposing a fix.
2. If transferred: re-point the citations at the new home.
3. If deleted: re-source each citation to something durable. The [finding] NavigationItem.recordId's docblock says "Mutually exclusive with viewName" — the guard tolerates that exact pair, and the sentence is one field over from the one PR #16862 was filed to fix #16875 round already demonstrated the pattern — the ruling is quotable from PR feat(spec): export objectNavTargetExclusivity; state no precedence order in the filters docblock #16862 and from in-tree docblocks, so the prose can cite a merged PR instead of a vanished card.
4. ⭐ Is this a two-card accident or a population? ⛔ Do not assume two. The honest instrument is not a bare #NNNNN grep (see the caveat above) — extract tracker-id-shaped citations, then probe each against the API with live-neighbour controls. ⚠️ Note the repo already has machinery that reasons about tracker-id shape (skill-map-guards.test.ts enforces a digit ceiling; check-doc-authoring.mjs has fixtures for it), so a taker should reuse that rather than invent a matcher.

Duplicate check — completed to the limit this session allows

⛔ REST /search/* is refused for this session and MCP search_issues is rate-limited, so a body-level dedup is not available. What I completed: enumeration of 569 open issues grepped by TITLE — 16714 0, 16715 0, dead citation 0, issue citation 0, deleted issue 0; 404 3, all unrelated on inspection (#17385 a dashboard liveness row, #16211 an /ai/* 404-vs-501 docblock, #13404 a QA run record). Lit control spec = 75. ⚠️ Titles only; bodies were not searched. Close as duplicate without hesitation if one surfaces.

Related: #16875 / PR #17697 (where it surfaced; its fix does not depend on the vanished card) · #17578 · #17591 · #17242 (the file-path axis of the same citation-integrity family)

---

Generated by Claude Code