2026-08-19 — Design review of the candidate record extensions (scope

2026-08-19 — Design review of the candidate record extensions (scope conditions on intents, selection grounds at plan time and capture triage, per-record provenance of contributed material, a knowledge record, a framing passage in the brief) and of the cold-reading build path: one independent adversarial pass over the plan plus two SOTA surveys, written up as the two dated research notes 2026-08-19-*-sota.md. Six decisions. (1) No never-bluffs principle is minted — the brief's marking discipline is loud-staging applied to prose, and a framing passage cites loud-staging directly; the sensemaking entry's one-principle precedent (no near-copies) applies. (2) itd-60 is not a prerequisite for brief rewrites — the rewrite is existing human practice at ship time; itd-60 stays an unplanned ambition. (3) Nothing in itd-87 must be settled before itd-86 builds: capture carries no semantic dedup (id-collision guards only), so there is no store for a re-raising detector to fight; recurrence handling stays deferred to itd-87. (4) Promise-questioning — "delivered as promised, but the promise itself is in question" — if ever built, is its own surface with its own ADR extending adr-40's closed bucket list; it is never a slot inside the intent-fidelity verdict, whose one act is reality-vs-commitment. Nearest published vocabulary is Lean's hypothesis-invalidated / pivot; no surveyed practice has a machine-readable verdict separating built-wrong from wrongly-specified. (5) itd-86 is not plannable until its isolation mechanism is named in scope: no allowlist invocation surface exists, installed agents read the whole tree, and host subagents inherit project-context files by default — the blindness contract's mechanical half is a build item, and whatever remains disciplinary is reported as such per loud-staging. (6) The record extensions land as hand-run conventions before any automation, per script-first-mvp; the ideate rejected-alternatives shape and the wontfix_reason invariants are the two in-repo patterns they extend (one-canonical-primitive). Grounds and sources in the two SOTA notes.