@am_shork/attest 0.9.2 → 0.9.4

package/CHANGELOG.md

@@ -13,6 +13,443 @@ input, removes/renames a public API or `--json` field, or changes a default
 runtime behavior an existing invocation relies on — diagnostic message text is
 not API.
 
+## [0.9.4] - 2026-08-19
+
+### Added
+
+- **A requirement can say a value is not decided yet, as `open` (`ATX-81`,
+  `ATX-82`).** The registry had two states, schema-valid or an ERROR, and there
+  was no third — so an author who could not determine a value had nowhere to put
+  that fact. What they do instead is pick one, and a scenario written against an
+  invented number is drift no gate can see: the single source is perfectly
+  consistent and describes a promise nobody made, arriving through the mechanism
+  meant to stop it. `open` is a free-text list of what is still undecided about a
+  requirement, one entry per question. The static commands report each as a
+  `requirement-open` WARNING and keep their exit code; the archive gate refuses
+  with `open-unresolved` while any remains. Promoted from *Under consideration*,
+  where the blockers were an unmeasured frequency and the permanent surface a
+  schema field costs.
+
+  *The asymmetry is the design, and it is `never-red`'s.* A proposal may be
+  legitimately half-finished while it is being written, and the four static
+  commands are where an author works during that; failing there would push them
+  back to inventing a value, which is the behaviour being replaced. Archiving is
+  where "done" acquires a hard definition, and a registry carrying an unanswered
+  question is not done.
+
+  *Re-measuring the entry before implementing it corrected it in four places,
+  per this file's own discipline.* **(1)** The proposed "WARNING from `check`,
+  ERROR at the gate" cannot be one diagnostic at two levels: `evaluateGate`'s
+  structure step already filters `validateStructure` to ERROR, so every WARNING
+  is discarded there. It needs its own gate step, which is what `never-red`
+  being the stated precedent actually implies. **(2)** The scope is the whole
+  merged registry, not the ids the change ADDs — and that is where it parts
+  company with `never-red`, whose narrower scope exists because "was ever
+  observed failing" is a fact about history that cannot be demanded
+  retroactively. An open question is a claim about the present. **(3)** The
+  entry over-counted the static extractor, which reads any literal property and
+  needed nothing, and under-counted `render`: without a section there, `SPEC.md`
+  — the only human review surface a requirement has — would not show that a
+  shipped requirement is open.
+
+  ***(4)* is the one that had to ship in the same change, and it is the
+  question `Planned`'s preamble says to ask.** `splice.ts` carries the comment
+  *"Any other field is one the schema does not define, and not this module's to
+  rewrite or to remove"*, and that sentence is true **only while `open` is off
+  the schema**. Adding the field without adding the two writer branches would
+  mean a change that *answers* a question is approved by the gate against an end
+  state the registry on disk does not match — the merge commits a file still
+  carrying the closed question, with nothing anywhere comparing the two. Not a
+  path the entry's own reasoning could reach, because it reasons about the field
+  being added and this is about the field being removed.
+
+  *Cost, stated rather than hidden.* One unresolved question anywhere blocks
+  every unrelated change from archiving. That is the intended reading of a
+  registry that is not done, it is recoverable by answering the question, and it
+  is the same all-or-nothing shape `verify` already has. `SCHEMA_VERSION` is
+  unchanged: two new `code` values are additive to the `--json` envelope. The
+  type surface **does** move — `Requirement` gains a required `open`, so code
+  constructing one by hand rather than through `defineRequirements` needs the
+  field. In this repository that was 26 sites, every one of them a test literal
+  that already spelled `outOfScope: []`; no adopter reading requirements is
+  affected, and `defineRequirements` still takes it as optional.
+
+- **This repository ran its own `changes/` → `status` → `archive` workflow for
+  the first time, and the change above is what went through it.** Every one of
+  the 80 requirements before it was written straight into the registry, so
+  `archive/` did not exist and `inspectRedEvidence` — shipped in `[0.9.3]` to
+  read it — reported all 252 declared scenarios as `unarchived`. The export had
+  no consumer that was not a test of itself for the second release running, and
+  this time the reason was not that nothing had been built on it but that the
+  repository had never produced the input it reads.
+
+  **The gate's first run failed on two of the five scenarios, and it was right.**
+  Both were the negative half of a pair — "says nothing when the list is empty",
+  "lets the gate through once every question is closed" — and both passed on
+  their first run, because an engine that has never heard of the field satisfies
+  "stays silent" trivially. `never-red` named them individually. The repair is
+  one scenario asserting the *discrimination* rather than two asserting each
+  side, which fails now and still refuses an implementation that warns
+  unconditionally later. This is the mechanism catching the exact defect class
+  the tautology entry under *Under consideration* is about, on the first change
+  it was ever pointed at, in the author's own work.
+
+  *A second defect surfaced after `--apply` and is worth recording because
+  nothing catches it.* The proposed spec read its params through `delta.added`
+  rather than by id. A delta is *also* keyed by the ids it ADDs
+  (`withProposedRequirements`), which is what makes the import the only line the
+  merge has to change — reaching through `added` loads during stage 1 and throws
+  once the import is repointed at the registry. The gate cannot see it, because
+  the gate runs before the rename; `check` cannot, because it executes nothing.
+  It appeared at the next `verify` as `spec-load-failed`. The workflow document
+  already shows the by-id accessor; what it does not say is that the other one
+  works until it doesn't.
+
+  *What the archive now reports*, and it is the shape the design predicts rather
+  than a backlog: one archived change, 5 `fail` rows, 228 `unarchived`. The two
+  retired scenario names remain in `first-run.json` as `pass` and produce no
+  rows at all, which is `inspectRedEvidence`'s documented behaviour for a record
+  naming a scenario no spec declares any more — measured here for the first time
+  rather than reasoned about.
+
+### Changed
+
+- **The publish job publishes through `npm` and requests an npm OIDC token, so
+  trusted publishing becomes a setting rather than a rewrite.** The provenance
+  work in `[0.7.2]` signs the release but does not change what authorises it: a
+  long-lived automation token, masked and protected, that publishes as us to
+  anyone holding it. This is the half of removing it that lives in the
+  repository. Promoted from `Planned`; what remains there is narrowed to the two
+  npmjs.com settings that actually retire the credential.
+
+  *The one thing the entry was promoted with as unmeasured is now measured, and
+  it decides the rollout.* The question was whether a failed OIDC exchange falls
+  back to the `_authToken` already in `.npmrc` or fails the publish outright.
+  It falls back. Read off npm 11.10.1's `lib/utils/oidc.js` rather than inferred:
+  the function documents itself as intended never to throw, every failure path
+  logs at verbose and returns, the whole body sits inside a `try/catch` that also
+  returns, and `opts[authTokenKey]` is assigned only on success. So this lands
+  beside the existing token with nothing registered yet, and a failed exchange is
+  a quiet fall back rather than a failed release — which is what makes the first
+  tagged release a cheap test instead of an irreversible bet.
+
+  *`pnpm publish` was never going to work, and that is now an observation rather
+  than a strong inference.* The entry reasoned from `pnpm/pnpm#11526` that pnpm
+  gets out of the way and npm does the work. The call site confirms it:
+  `npm/lib/commands/publish.js` invokes `lib/utils/oidc.js`, so the exchange is
+  inside npm's publish command and no flag passed to pnpm reaches it. Hence the
+  client swap, which is a cost this file has already priced once in the other
+  direction.
+
+  *Two details the swap turned up that the entry had not counted.* `npm publish`
+  has no `--no-git-checks` — it warns *"Unknown cli config"* and does no git
+  checks at all — so the flag is dropped rather than translated. And the job now
+  runs `corepack enable pnpm` rather than the bare `corepack enable` plus the
+  `COREPACK_ENABLE_STRICT` override the entry expected to re-add: naming the shim
+  leaves the image's own npm alone for `npm i -g npm@^11.5.1` to upgrade, which
+  is the same outcome with one fewer environment variable and no refusal that can
+  be switched off by accident. `--provenance` stays explicit even though npm's
+  OIDC path can enable it by itself, because it only does so while `provenance`
+  is at its default — passing it keeps the setting this job's decision rather
+  than a side effect of whether the exchange succeeded.
+
+  *What is not claimed.* Nothing here has run. The job is exercised once per
+  release and cannot be tested any other way, which is why the fallback
+  measurement came first and why the token and its guard both stay. `NPM_TOKEN`
+  is still required and still what authorises the publish until a release is
+  observed going out without it.
+
+
+- **This repository's own judgement table now reads its scenario names through
+  `@am_shork/attest/inspect`, and what that measured is the point of the
+  change.** `intent-quality.md` names one read as the rot check every hand-judged
+  table needs — that a scenario a row claims is one a spec really declares — and
+  tells an adopter to get it from `inspectProject`. This repository's table got
+  it from `parseSpecs` and `findFiles` directly, because it was written while
+  both were internal. So the export shipped in `[0.9.2]` had **no consumer that
+  was not a test of itself**: `self/inspect.spec.ts` attests it, and nothing
+  built anything on it. Passing its own tests is not evidence that an export is
+  sufficient for the thing it was added for, and the only party who could have
+  found out otherwise was an adopter.
+
+  *Equivalence was measured rather than assumed, in both directions.*
+  `scanProject` sorts the same `findFiles` walk with the same `isSpecFile`
+  predicate, so the two reads should agree — and they do, compared as sorted
+  `(reqId, names)` pairs over the whole repo before the old call was deleted.
+  Then mutation-checked, because an assertion that still passes when the read
+  returns nothing is not reading anything: with the map stubbed empty the
+  rot-binding test fails and the other nine pass, which is the blast radius the
+  call actually has.
+
+  **What would not go through the export is the finding, and it is one thing.**
+  `Inspection.registry` is merged across registry files, so an id arrives with no
+  record of which file declared it. `corpus()` needs that — `source` is the scope
+  a cross-requirement rule sees, `divergentParam` keys on it, and the DOMAINS
+  completeness check uses it to hold the fixture registries out — and nothing in
+  the public export can reconstruct it. That half still deep-imports
+  `readRegistrySource`, with the reason written at the call site rather than left
+  as an unexplained inconsistency. It is filed as a measurement and **not** as a
+  decision to add a field: one caller wanting per-file attribution is one
+  adapter, and the entry under *Under consideration* about an outward-facing
+  judgement schema is waiting on exactly the second one.
+
+  *Cost.* `inspectProject` reads the registry as well, which this caller does not
+  need — one extra static read on a tree `corpus()` already walks once per call,
+  seven times per run. Paid deliberately: the alternative is deep-importing the
+  function whose reachability from outside the package is the thing being
+  demonstrated.
+
+### Documentation
+
+- **Design §11 now states that evidence outranks testimony, and that a
+  disagreement between them is a finding.** The registry and the gate's verdict
+  are evidence — machine-checked, recomputable, true of the tree as it stands. An
+  archived `proposal.md` is testimony: prose about a decision taken on one past
+  date that nothing has re-read since. A reader holding both holds claims in two
+  tenses with no stated order, and the order matters most exactly when they
+  conflict, because a stale proposal is more fluent than a registry and reads as
+  the more authoritative of the two. Decided from *Under consideration*, where it
+  had sat behind a blocker that was circular.
+
+  *The blocker was circular and naming the circle is what dissolved it.* The rule
+  was held back for describing a workflow the tool does not have — nothing read
+  the prose half — and the prose half was read by nothing **because no rule
+  existed for reading it**. Neither side moves on its own. The way out is the
+  split `[0.9.3]` already made for the propose-stage questions, where two of five
+  went to `CLAUDE.md` rather than into the document `init` writes: **this lands in
+  §11 only, and deliberately not in the instruction document.** §11 is a permanent
+  property of the design and its cost is paid once, here; the §10 document's cost
+  is paid in every adopting project's agent context forever, and that cost is what
+  the blocker was actually about. It is also the statement any later retrieval
+  surface would have to be built against, so writing it first is cheaper than
+  writing it after something depends on it.
+
+  *Re-measuring it before writing found the entry's own subject had stopped being
+  hypothetical, and falsified something this file recorded.* `[0.9.3]` states that
+  `proposal.md` in this repository "carries a link" — `CLAUDE.md` makes
+  `CHANGELOG.md` the single decision record, so a proposal restating an argument
+  would be a second store of it with nothing comparing the two — and concludes
+  there is nothing in it for an index to offer but its path. The very next change
+  to archive carries a proposal of **sixty-nine lines across five sections**, most
+  of its argument also present in the changelog entry. So the second store arrived
+  by ordinary means, in the first change that could produce one, written by an
+  author who knew the rule. The archived file is left as it is rather than trimmed
+  to a pointer: it is what the gate approved, and rewriting an archive to agree
+  with a claim about it is the failure this section is about, performed on itself.
+  §11 cites it as the measurement instead.
+
+  *What is deliberately not claimed.* The typed half cannot produce this conflict
+  — `first-run.json` is an `Outcome` in a schema-validated envelope, and a
+  scenario either is in the record or is not, so `inspectRedEvidence` reports an
+  absence rather than a contradiction. Nothing enforces the rule and nothing can:
+  reconciling prose against a registry is the ground truth §0 refuses to compute.
+  What §11 states is only the direction to reconcile in.
+
+## [0.9.3] - 2026-08-18
+
+### Added
+
+- **The archive is read back, as `inspectRedEvidence` on `@am_shork/attest/inspect`
+  (`ATX-80`).** `archive --apply` moves each merged change into
+  `archive/<date>-<name>/`, carrying `proposal.md`, the delta and the record of
+  how every one of its scenarios ended the *first* time it ran — and nothing
+  read any of it. The only store here that keeps a decision with its evidence
+  attached was write-only. It now answers, for each scenario a project declares,
+  which of `fail` / `pass` / `unobserved` / `unarchived` the archived records
+  place it in. Promoted from `Planned`, where the blockers were an archive
+  nobody had produced and an entry point nobody had chosen.
+
+  *The question the entry was promoted with was the wrong granularity, and
+  finding that is most of what this change is.* It asked which **requirements**
+  ever had a scenario observed failing. Under the gate as written that is true
+  by construction for every archived id — `neverRedIssues` walks *every*
+  scenario of every ADDED id and blocks on any one without a recorded red, so a
+  change that archived at all archived with the whole set proven. Where the gate
+  genuinely stops is one level down, and it leaks two ways: a scenario grown
+  onto a requirement after it archived can never acquire evidence, because
+  `never-red` fires only on ids a change is currently ADDing and an archived id
+  is ADDed by nothing again; and MODIFIED carries no such obligation at all, so
+  a requirement whose statement is later rewritten keeps evidence only for the
+  form it had when it archived. Both accumulate silently. The report is
+  therefore over `(reqId, file, name)`, which the record already keys by.
+
+  *Four states rather than two, and the two absences are the whole design.*
+  `unarchived` — the id is in no archived change at all — is a requirement
+  written straight into the registry, which is how existing behaviour is
+  described in a brownfield adoption and which design §6 gives no obligation to
+  have been red. `unobserved` — the id **is** archived and this scenario is not
+  in the record — is the drift above. Folding them together would report a
+  design working exactly as intended as though it were a backlog, and on a
+  first-day adoption that is every row. `pass` stays separate from both because
+  the gate cannot produce it, so an archived one means a hand-edited record or a
+  format that moved.
+
+  *Two things it deliberately does not do.* It does not judge: whether an
+  `unobserved` scenario matters is a judgement about that scenario, which is the
+  ground truth §0 refuses to compute for someone else. And it does not hand back
+  the records — the archive read returns rows, because the record is a nested map
+  keyed by ids, paths and scenario names read off disk, and exporting the
+  container would export the prototype hazard `red-record.ts` exists to hold.
+
+  *`proposal.md` is not read, and that is the blocker dissolving rather than
+  being cleared.* The prose half was filed as the one carrying the reasoning.
+  In this repository it carries a link: `CLAUDE.md` makes `CHANGELOG.md` the
+  single decision record, so a proposal restating an argument would be a second
+  store of it with nothing comparing the two. There is nothing in it for an
+  index to offer but its path.
+
+  *The three scan exclusions are untouched.* `locate.ts`, `runner.ts` and
+  `pipeline.ts` each still exclude `archive/`, and they are §7 and §8 — an
+  archived change's requirements and specs must not re-enter a normal run. The
+  new read walks the archive for facts *about* archived changes, never to fold
+  their contents back into a registry or a plan.
+
+  *Blocker **(2)** is settled against the fifth static command, on the roster's
+  own terms.* `ATX-16`'s subject is reading TypeScript *without evaluating it* —
+  its rationale is about a top-level `fetch` in a registry file reaching CI
+  secrets on a fork merge request. `first-run.json` is JSON; joining that roster
+  would quietly turn a security promise into a list of commands that do not run
+  the suite. The trial datum that seemed to point at a command measured demand
+  to read the archive **as prose**, which is a different question. And the
+  direction is reversible: adding a command later is additive, narrowing a
+  requirement's roster back is not. Two things measured while deciding —
+  `archive.ts`'s runtime closure names no `vite`/`vitest`, so `ATX-79`'s
+  peer-free promise holds over the new reachability; and `intent-quality.md`
+  already exists for findings of exactly this kind, where `cli-reference.md`
+  has no place to state one.
+
+  *What it cost elsewhere, because it is the part that does not announce
+  itself.* The fixture that exercises all four states adds a registry, and the
+  judgement tables in `tests/intent-rule-candidates.spec.ts` score the fixtures
+  too — so the corpus moved 87 → 90 and four measurements were re-read rather
+  than re-baselined. `ATX-80` is judged compound (2), and `compound-requirement`
+  flags it correctly; its quantifier ranges over values, the shape that table
+  prefers; `ATX-80.states` is an iterated domain and carries its pin. One new
+  divergence needed judging — `states:ATX-32,ATX-80` — and it is worth a line
+  because of how it arrived rather than how it reads: two reports each naming
+  their own closed set of labels, neither author aware of the other, which is a
+  second generic param name starting the climb `code` made to nineteen members.
+  The count of judgements a shippable `divergent-param` would demand grows with
+  the registry, from nothing anyone did wrong.
+
+  *Mutation-checked, and one assertion did not survive it.* Every new test was
+  run against a deliberately broken implementation. The one pinning archived
+  folder order passed with the sort deleted, because `readdir` returns names
+  already ordered on Windows — the fixture-with-no-separator shape from the
+  `Fixed` entry below, arriving in a new test on the day it was written. Fixed
+  by choosing names where the two orders differ, measured rather than assumed,
+  with the casing called out in the test so it is not tidied away.
+
+  *One more scenario, added before cutting a release, and writing it corrected
+  the reason it was added.* Every state above was read out of a hand-written
+  `first-run.json` at a folder this repository spelled, so the reader had never
+  met an archive the tool itself produced. `self/merge.spec.ts` now runs
+  `--apply` for real and joins the result: the folder is the one the run's own
+  date stamp named, and the report's paths are derived from whatever it picked.
+  Mutation-checked to be worth its runtime — an enumeration that finds nothing,
+  and the two absences folded into one, each fail it and no other scenario in
+  that file.
+
+  **The risk it was written to close turned out not to exist, which is the more
+  useful half.** The reason given for it was the proposed → merged rename: the
+  record is written while the spec is `*.proposed.spec.ts` and `--apply` renames
+  that file, so `fileKey` is what keeps the two meeting. Reading the code to
+  write the assertion showed the archive reader cannot exercise that at all.
+  `recordedOutcome` normalises the **ref**, and the record is keyed in merged
+  spelling from the start — so by the time a change is archived, every ref this
+  reader passes is already post-merge and `fileKey` is the identity on all of
+  them. The translation exists for the gate reading a record mid-flight, and the
+  archive reader is downstream of the point where it can matter. The scenario
+  stays, for what it does cover; the claim it was justified with is written out.
+
+  *A hazard found by running the mutations, worth recording because nothing
+  reports it.* Stubbing `mergedSpecPath` and running the suite **rewrote two
+  committed fixtures** — `fixtures/e2e-archive` and `fixtures/stdout-pollution`
+  each hold a `first-run.json` that a real archive run rewrites in place, so a
+  mutation run leaves the working tree dirty with plausible-looking changes to
+  files nobody edited. Caught by `git status`, not by any gate. It also settles
+  the write half by accident: those records really are produced through
+  `fileKey`, because under the stub they came out keyed by the proposed
+  spelling.
+
+- **The propose stage now asks three questions, where it previously said how to
+  write a delta and nothing about what to check you had thought about.** They sit
+  at the end of Stage 1, immediately before the instruction to present and stop:
+  what pins each expectation, does each statement carry one obligation, and was
+  any of this ever red. Promoted from `Planned`, where the blocker was the
+  selection rather than the idea — spec-kit's `clarify` carries nine generic
+  categories, and copying them wholesale was the specific thing to avoid, because
+  §10's economics put every line of that document into every adopting project's
+  agent context forever.
+
+  *The selection is by what this repository has actually been bitten by*, which
+  is a different list from a product-spec taxonomy. **(1)** is the measured one:
+  the mine-density band moved 3.3× with the whole suite green because the
+  assertion recomputed its expectation from the param the code under test
+  consumed — the entry still under `Under consideration`, whose *guidance* half
+  shipped in `[0.5.0]` as a statement in *The model*. What is new here is asking
+  it as a question at the moment the assertion is being authored, which is a
+  different mechanism from stating the rule 80 lines earlier in the same file.
+  **(2)** is measured too: 34 of this repository's requirements carry more than
+  one obligation, so the question is doing work no shipped diagnostic does — and
+  deliberately names no code, because none exists to name. **(3)** answers what
+  the archive gate structurally cannot ask: `never-red` demands a recorded
+  failing run only for the ids a change ADDs, so a requirement written for
+  behaviour already shipped never had a moment when it should have failed.
+
+  *Two more went to `CLAUDE.md` instead*, and that split is the finding the entry
+  did not anticipate — the checklist wanted two destinations, not one. Crossing a
+  platform boundary, and whether a change leaves `check`, `cover`, `render` and
+  `status` executing nothing, are about this engine's internals; shipping them
+  would have been the dead weight the cost argument was worried about without
+  being able to name.
+
+  *Re-measured before building, per the discipline that section runs on, and the
+  claim held exactly*: the document was 405 lines with Stage 1 at 87–255, still
+  exactly 169. **The cost claim did not hold, and the entry's own number was
+  wrong.** It priced this at "three lines rather than nine" by counting one line
+  per category, which is what nine generic categories would have cost as a bare
+  list. Three questions with the clause each needs to be answerable cost **eight**
+  lines: Stage 1 is now 177 and the document 413. Still under half of what the
+  nine would have been, so the argument survives its own number being off, but the
+  number is corrected here rather than quietly restated.
+
+  *And the question the entry left open is answered: no new `ATX-n`.* The
+  document's content is gated only by `ATX-57`, which asks that every diagnostic
+  code it names be one the engine can emit — and asking *what this makes
+  reachable for the first time* is what that check turned into here: the only
+  hyphenated code-voice token the three questions add is `never-red`, which the
+  document already named. What they earn instead is **one scenario on `ATX-27`**,
+  which already obliges the body to carry the workflow rather than a pointer to
+  it. A requirement of their own would make every rewording of three sentences a
+  registry change; no assertion at all would leave a checklist with no diagnostic
+  behind it able to be dropped in silence — the same decay shape as the fixture
+  assertion fixed below, which is what decided it.
+
+### Fixed
+
+- **The assertion guarding the one fixture that exercises a path separator
+  passed on a corpus with no separator in it.** `CLAUDE.md` says not to flatten
+  `fixtures/nested-spec/`, because its spec is the only one that sits below a
+  root and a relative spec path becomes the child run's `include` glob, where a
+  backslash is an escape character. What stood behind that instruction was
+  `tests/paths.spec.ts` scanning the fixture and asserting that no relative path
+  contains a backslash — and a flat filename contains no backslash either, so
+  flattening the fixture would have left the test green while removing the only
+  thing it was there to exercise. The rule with a written warning against silent
+  decay was guarded by an assertion that decayed silently.
+
+  Now a second assertion requires the scan to find a spec below the root, which
+  is the property the fixture exists for. Checked against a flattened copy
+  before being written: the predicate is true on the fixture as committed and
+  false on the same files laid flat.
+
+  *Found by the `CLAUDE.md` audit filed under `Considered and rejected`*, whose
+  answer to "which of these rules should become requirement ids" was none — this
+  is the one actionable thing it turned up, and it is a plain test rather than an
+  `ATX-n` because it is a property of this repository's fixture corpus and not a
+  promise Attest makes to anyone.
+
 ## [0.9.2] - 2026-08-17
 
 ### Added
@@ -4989,7 +5426,7 @@ time**.
 
 *The first time that question was asked in advance, it paid, and how it paid is
 worth a line because it is not what the two cases above would predict.* The
-`check` `empty-spec` entry — `[Unreleased]`, the third entry to reproduce exactly
+`check` `empty-spec` entry — `[0.9.0]`, the third entry to reproduce exactly
 on its reported half — was not wrong about its own repair. Asking the question
 anyway found the defect one step to the side: the fix it proposed was correct,
 and the *obvious implementation of it* — make `check` agree with `verify` —
@@ -5000,82 +5437,32 @@ path the repair makes reachable; it is about **everything the repair would make
 `check` agree with**, and an entry that names the right fix can still be
 implemented wrongly by copying the half nobody has audited.
 
-- **Trusted publishing, which would delete `NPM_TOKEN` rather than add to it.**
-  The provenance work in `[0.7.2]` signs the release but does not change
-  what authorises it: a long-lived automation token, masked and protected, that
-  publishes as us to anyone holding it. npm's trusted publishing exchanges the
-  same OIDC identity the attestation already uses for a short-lived credential,
-  which would remove the stored secret entirely and grant provenance as a
-  property of the flow rather than a flag on the command. The deletion test
-  points the right way for once: what it removes is the only long-lived
-  credential this repository has.
-  **The blocker this entry was filed with is retired, and it was the wrong
-  question** — checked against npm's documentation on 2026-08-08. It asked
-  whether npm's trusted publishers accept a **gitlab.com-hosted** project on the
-  plan this package publishes under, and both halves come back clean: GitLab
-  CI/CD is a first-class provider alongside GitHub Actions, and no plan
-  requirement is stated anywhere in the documentation. The four fields it wants
-  are `Pseudorca`, `attest`, the top-level CI file path (`.gitlab-ci.yml`, and it
-  must carry the extension) and the allowed actions; environment name is optional
-  and this project uses no GitLab environments. Shared runners are the only ones
-  supported and the publish job carries no `tags:`, so it is already on them. The
-  `repository.url` cross-check needs no separate verification — provenance
-  already passes it with the same identity.
-  Two things the entry did not anticipate, both of which change the shape of the
-  change rather than blocking it. **`SIGSTORE_ID_TOKEN` is not replaced**: the
-  documented GitLab snippet declares `NPM_ID_TOKEN` with
-  `aud: "npm:registry.npmjs.org"` *beside* it, so this is an addition to the
-  `id_tokens` block, not a swap. And **the YAML is not what deletes the
-  credential** — enabling a trusted publisher leaves the automation token just as
-  able to publish; what retires it is `Require two-factor authentication and
-  disallow tokens` on the package, which npm states does not affect trusted
-  publishers. That setting is the one that closes the loop this job's own comment
-  opens, where an automation token is used *because* a granular token fails
-  against 2FA on writes: trusted publishing does not bypass the prompt, it stops
-  being a token.
-  *What blocks the decision now is `pnpm`, and it is not a version to wait for.*
-  **pnpm does not implement the OIDC exchange at all.** `pnpm/pnpm#11526` — the
-  fix for the pnpm 11 regression that made this look like a supported path —
-  shows what its "OIDC support" is: `actions/setup-node` writes
-  `_authToken=${NODE_AUTH_TOKEN}` into `.npmrc`, pnpm used to pass the unresolved
-  placeholder through verbatim, and the fix treats it as empty so that **npm's**
-  credential exchange can be the sole auth source. pnpm gets out of the way; npm
-  does the work. That matches npm's own wording, which requires publishing
-  through npm directly or indirectly, and it matches the reports: every account
-  of pnpm publishing under OIDC is GitHub Actions, and there is **no record of
-  pnpm + GitLab + OIDC succeeding**. Stated at the strength the evidence carries:
-  this is a strong negative inference, not a documented refusal.
-  So the real cost is a tooling swap — `pnpm publish` back to `npm publish` in
-  this one job — and it is a swap this file has already priced once in the other
-  direction. The comment above records that moving to pnpm took
-  `COREPACK_ENABLE_STRICT` with it, that override having existed only so a bare
-  `npm` could run under a `packageManager` pinning pnpm; going back re-adds it.
-  It also needs npm ≥ 11.5.1 where `node:22-slim` ships 10.x, so the job gains an
-  npm upgrade step. None of that is prohibitive. It is simply a different
-  decision from the one this entry was filed as, which is why it stays here.
-  *One correction to the entry's own risk framing.* "It cannot be tested except
-  by publishing" is half wrong: registering a trusted publisher on npmjs.com is
-  free and reversible, and `NPM_TOKEN` can stay in place while it is tried. What
-  decides whether this can be rolled out incrementally is whether a failed OIDC
-  exchange falls back to the `_authToken` already in `.npmrc` or fails the
-  publish outright — unmeasured, and the thing to establish before touching the
-  job.
-  *Method note, because it is the reusable part.* The pinned pnpm bundle was the
-  obvious place to look and was the wrong one — `pnpm publish --help` on 10.28.0
-  omits the flags it accepts, exactly as this job's comment already records for
-  `--provenance`, so neither the help text nor the shipped bundle would have
-  answered it. The answer was in the upstream pull request.
-  **Promoted from `Under consideration` on 2026-08-08**, and what moved it is
-  that the question it was filed as is answered. It asked whether npm's trusted
-  publishers would accept this project at all; they will. What is left is a
-  known tooling swap with a priced cost, which is a decision to build rather
-  than a question — the preamble's own line, *a decision with an argument
-  attached*. One thing stays unmeasured and is the first act of building it, per
-  the discipline three paragraphs up: whether a failed OIDC exchange falls back
-  to the `_authToken` already in `.npmrc` or fails the publish outright. That
-  decides whether this rolls out incrementally beside the existing token or in
-  one cut, and it is cheap to establish because registering a trusted publisher
-  is free and reversible.
+- **Retiring `NPM_TOKEN`, which is now two settings on npmjs.com rather than
+  anything in this repository.** The mechanism landed under `[0.9.4]`: the
+  publish job requests an npm OIDC token and publishes through `npm`, which is
+  the only client that performs the exchange. What that did **not** do is remove
+  the credential, and the distinction is the point — enabling a trusted publisher
+  leaves an automation token just as able to publish. Two acts remain, neither of
+  them a commit:
+  **(1)** register the trusted publisher on the package — `Pseudorca`, `attest`,
+  `.gitlab-ci.yml` with the extension, the allowed actions; environment name is
+  optional and this project uses none, and shared runners are the only supported
+  kind, which the job already uses because it carries no `tags:`. Free and
+  reversible, and safe to do at any time: a failed exchange falls back to the
+  token rather than failing the publish (measured — see the `[0.9.4]`
+  entry). **(2)** set *Require two-factor authentication and disallow tokens* on
+  the package, which npm states does not affect trusted publishers. That is the
+  one that closes the loop the job's own comment opens, where an automation token
+  is used *because* a granular token fails against 2FA on writes: trusted
+  publishing does not bypass the prompt, it stops being a token.
+  *What is unmeasured, and it is not measurable from here.* Whether the exchange
+  actually succeeds against a gitlab.com project. Every documented ingredient
+  checks out and no plan requirement is stated anywhere, but there is no record
+  of anyone publishing from GitLab under OIDC — every account is GitHub Actions.
+  The first tagged release after the `[0.9.4]` change is the test, and the
+  fallback is what makes running it cheap: if the exchange fails, the release
+  still publishes and the job's verbose log says why. **Do not delete the token
+  before a release has been observed publishing without it.**
 
 ## Under consideration
 
@@ -5134,6 +5521,10 @@ have to gather again.
   **changing the value of an existing param goes through no gate at all.**
   `archive` gates a change; a param edit is not a change. That is a cleaner
   statement of the gap than "params can be tautological".
+  **That observation is now its own entry at the foot of this section**, split
+  out and measured on 2026-08-18, because it asks what happens when a value
+  moves rather than whether an assertion is a real comparison, and neither
+  answer settles the other. What stays here is the detector.
   *What blocks the decision — three things, all of them real.* **(1)** Every
   mutation above is synthetic. Across 8 commits touching `*.reqs.ts` in that
   repo, **no param value was ever modified** — every `params:` line in every diff
@@ -5279,7 +5670,7 @@ have to gather again.
   pass and separating them is the finding.
 
 - **Whether a requirement can ever be retired, and what it costs that none can.**
-  The registry is at **69 requirements and 192 scenarios, 2.78 each**, and
+  The registry is at **79 requirements and 221 scenarios, 2.80 each**, and
   every one is a permanent obligation: `uncovered-requirement` is an ERROR, so a
   requirement without a scenario cannot exist, and nothing ever removes one.
   `delta.removed` exists and `applyDelta` applies it, but `--apply` refuses to
@@ -5324,6 +5715,19 @@ have to gather again.
   the ratio: 2.56 → 2.78. The cost of a requirement is not flat and it is not
   falling, which is the premise the whole entry rests on, and it is the first
   time this file has had two measurements of it to compare.
+  *A third measurement, on 2026-08-18, and it points the other way from the
+  second.* **79 requirements and 221 scenarios**, counted the way `verify self`
+  prints them, which is the control the 2026-08-08 restatement established. The
+  ratio runs 2.56 → 2.78 → **2.80**, so the step that carried the argument was
+  the first one and the second is **+0.015**, which is flat. The premise this
+  entry rests on now has one measurement for it and one against, and the honest
+  statement is the narrower one: per-requirement cost has held at about 2.8
+  scenarios across ten days and ten requirements. What is unchanged is the
+  absolute total, which only rises — that half of the argument is untouched, and
+  it was always the half about permanence rather than about acceleration. What is
+  no longer supported is the acceleration. **Reopening on cost needs the ratio to
+  move again**; reopening on the three meanings of "retire" needs none of these
+  figures, and that is still the part nobody has separated.
 
 - **Running `verify` over a subset of the scenarios, and what a partial run may
   be allowed to say.** `verify` is all-or-nothing and `check` executes nothing,
@@ -5548,6 +5952,298 @@ have to gather again.
   design it. If it comes back the same shape, the seam is real and the schema
   follows; if it comes back different, `inspect` was the whole answer and the
   schema never needs to exist.
+  **Nothing currently makes that table arrive, which is a separate problem from
+  the three blockers and the one that gates all of them.** Raised in a product
+  review of `[0.9.1]`–`[0.9.3]` on 2026-08-19. The deciding evidence is an
+  artifact only an adopter can produce, and the path to producing it is: a row in
+  the README's document table, then a 214-line page, then a hand pass over four
+  questions, then writing the two mechanical properties from a prose
+  description, then choosing to report back. Five voluntary steps with no
+  scaffold at any of them, against a decision this entry has been waiting on
+  since `[0.9.2]`. An entry blocked on evidence that no shipped surface asks for
+  is blocked indefinitely, and the wait is not itself evidence of anything.
+  *The proposal is scaffolding the mechanism while still withholding the answer,*
+  which is the same split `[0.9.2]` already made and not a retreat from it: an
+  `examples/` directory holding the completeness and rot-binding assertions with
+  **no columns** — the enumeration that forces a row, and the check that a named
+  scenario is one `inspectProject` really declares — and the judgement columns
+  left for the adopter to add. What the page withholds is this repository's four
+  columns, and that stays withheld; what it currently also withholds is the two
+  properties it names as *mechanical*, and those are the half where a copy is not
+  an echo, because their content is fixed and the fourth finding does not apply
+  to them.
+  *What blocks it.* Whether a skeleton with no columns is still a shape that
+  comes back as a copy — the page's argument is that a template makes the answer
+  return its own question, and it is untested whether an adopter reads an empty
+  frame as an invitation or as a form to fill in. And it is a second artifact
+  claiming to be runnable consumer usage of the public API, which `pre-commit-check`
+  §6 already records as the category no gate reaches: the page's three samples
+  are unasserted today, and a fourth in a directory that looks executable would
+  be worse than a fenced block, not better, unless something runs it.
+
+- **Prefix ownership is inferred rather than declared, and the cost arrives only
+  when adoption succeeds.** Design §11 records that the id grammar has no level
+  above the requirement: the prefix is a convention, nothing allocates it, and
+  `duplicate-prefix` can only report a collision that already happened.
+  spec-kit's answer is a roadmap table — a stable id, an intent, a scope
+  boundary, dependencies — authored above the specs it decomposes into. That
+  comparison is stated here rather than referred to, because the entry that
+  introduced the spec-kit reading has since been built and now sits under
+  `[0.9.4]` as the `open` field: an entry whose evidence rests on a
+  neighbour is one a promotion silently empties.
+  *Two things have changed since that reading, and they point opposite ways.*
+  The proposal is **smaller** than it looked: the mechanism partly exists.
+  `loadRegistry` returns `prefixOwners` — first claim in sorted file order —
+  `merge.ts` uses it to decide which file an ADDED id belongs in, and
+  `apply-no-prefix-owner` already refuses a prefix nobody owns. So what is
+  proposed is declaration replacing inference, not a new layer. And it is
+  **weaker**: `/inspect` shipped in `[0.9.2]`, so the cross-repository half —
+  the one §11 says no command can see across — is now something an adopter
+  computes from two registries in about ten lines. Attest does not have to own
+  it to make it possible.
+  *What blocks the decision:* nobody has the problem. §11 states the cost
+  arrives "exactly when adoption succeeds: two teams sharing a registry have
+  someone owning prefix allocation by hand", and no such adoption has been
+  reported. Building the declared form now would be deciding prefix semantics
+  for everyone from one repository whose five prefixes — `ATX` and the four
+  fixture ones — are each declared by exactly one file, so the allocation
+  question this would answer has never been asked here.
+
+
+- **A merged requirement carries no trace of the change that produced it, and
+  the rename chain is the part actually lost.** `RequirementSchema` is
+  `statement`, `rationale`, `params`, `outOfScope`; the splice writes those and
+  nothing else, so after `--apply` no field and no sidecar records which change
+  introduced an id, which modified it, or that one id used to be another. The
+  delta that knew is in `archive/`, which nothing reads. Proposed from
+  OpenViking's `.relations.json`: links between memories live in a
+  directory-level sidecar, deliberately kept out of the content, and are
+  rendered on demand at retrieval time (`docs/design/memory-link-design.md`).
+  *The argument for the sidecar over a field is in their competitor analysis
+  rather than their design.* The same document reads GBrain, which writes links
+  into the page body, and records what that costs: rename a page and every
+  inbound link still points at the old slug, with fuzzy matching at the read end
+  as the only mitigation. A `supersedes:` or `introducedBy:` field on a
+  requirement would be that mistake in this repository's terms — the registry is
+  a literal and a single source (§2), and a field naming a folder that a later
+  rename can move is a second source with nothing comparing it against the
+  first. A derived index has no such copy to go stale: it is recomputed from the
+  archived deltas every time it is read.
+  *What blocks the decision, restated on 2026-08-19 because half of what was
+  filed here is no longer true.* This entry was blocked on the empty archive and
+  on the corpus being rename-free, and only the second still holds. `archive/`
+  now has a real change in it — the `open` field, put through the workflow the
+  same day — so the store this would index exists. Its delta carries `added` and
+  nothing else, measured rather than assumed, so a backlink index is still
+  testable only against fixtures for the operation it is actually about. Note
+  what that says about the odds of the blocker clearing on its own: `--apply`
+  refuses RENAMED outright, so no change this repository archives can ever
+  exercise a rename until that refusal is lifted, and lifting it is a separate
+  decision with its own reason (`splice.ts` — deleting an entry has no smaller
+  span to fall back to). The blocker is therefore not "waiting for a rename to
+  happen"; it is downstream of a refusal nobody has proposed removing. And one
+  question the OpenViking reading does not answer, which is whether the chain is
+  wanted at all. §7 applies
+  `RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
+  deliberately, as far as anything written says. The case for recovering it is an
+  external reference that outlives the rename, a ticket or a commit message
+  naming a retired id, and nobody has reported one.
+
+- **Changing the value of an existing param passes no gate, and for seven of
+  them there is no record either.** Split out of the tautology entry at the
+  head of this section on 2026-08-18, where it was one sentence inside the
+  reframing paragraph. It is a different question: that entry asks whether an
+  assertion is a real comparison, this one asks what happens when the number
+  itself moves, and neither answer settles the other. `archive` gates a
+  **change** — a delta, proposed specs, a recorded failing run — and a param edit
+  is none of those. It is one literal in a merged `*.reqs.ts`, and every gate
+  reads it as fine: `check` finds it schema-valid, because a param is any JSON
+  value; `possible-drift` is quiet by construction, since `ATX-8` makes it ask
+  whether *any* covering scenario reads the params at all rather than whether a
+  value moved; and `verify` stays green wherever the assertion derives its
+  expectation from the same param, which is the pair of green rows measured in
+  the entry this was split from.
+  *What is left is `render`, and it was measured here rather than assumed.*
+  Across **89 params on 59 of this repository's 79 requirements, 82 — 92.1% —
+  are interpolated into their own statement**, so editing one changes
+  `self/requirements/SPEC.md` and `render --check` fails until the document is
+  regenerated. That is a review surface and not a gate: the new value lands in a
+  committed generated file where a reader can see it, and nothing anywhere asks
+  whether the move was intended.
+  *The other seven leave no trace outside the line that was edited, and which
+  seven they are is the finding rather than the count.* Five are **structurally
+  uninterpolatable**: `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are
+  kind → payload tables, and `ATX-15.sortMethods`, `ATX-15.bannedApis` and
+  `ATX-72.quotes` are lists. A statement cannot carry any of them —
+  `non-scalar-interpolation` is the diagnostic that refuses it — so the params
+  with no record are disproportionately the shape §2 widened the params rule to
+  cover **precisely because lists and tables are the most drift-prone constants
+  there are**. The remaining two, `ATX-15.comparator` and `ATX-26.code`, are
+  scalars their author simply did not interpolate.
+  *What this is not.* It is not a re-proposal of the committed params snapshot
+  rejected below. That was rejected on the argument that the mechanism guarding a
+  param is a scenario reading it rather than a file recording it, and nothing
+  here disputes that or needs a second copy of the values. The observation is
+  narrower: the **edit** is unremarkable to every gate, which is a different
+  claim from the values being unguarded.
+  *What blocks the decision — and the first is the one that blocks the entry this
+  came from.* **(1)** Frequency is unmeasured, and the one corpus anybody has
+  looked at points at zero: across 8 commits touching `*.reqs.ts` in the
+  reporting repository, no param value was ever modified — every `params:` line
+  in every diff is an addition. A defect nobody has committed is a hazard rather
+  than a report. **(2)** No shape is obvious. A param edit is not a change, so
+  `archive` is the wrong place; making `check` notice one needs a previous value
+  to compare against, which is the rejected snapshot wearing a different hat. The
+  only mechanism needing no stored copy is review, and review already sees the
+  `SPEC.md` diff for 82 of the 89. **(3)** What is left after that is seven
+  params in one repository, and the right answer for the five that matter may be
+  nothing more than a line in `intent-quality.md` — the four things no gate is
+  looking at already being that page's subject, and this being a fifth of the
+  same kind.
+
+- **`/inspect` returns five exported shapes and the page telling people to build
+  on them says nothing about whether they move.** Filed 2026-08-19 from a product
+  review of `[0.9.1]`–`[0.9.3]`. `inspect.ts` exports `Inspection`,
+  `ScenarioEvidence`, `EvidenceRow`, `ArchivedChangeRef` and
+  `RedEvidenceInspection`, and `intent-quality.md` carries three samples
+  destructuring them. `SCHEMA_VERSION` governs the `--json` envelope and nothing
+  governs these.
+  *The policy is not missing — its statement is.* The Versioning section at the
+  head of this file already binds them: removing or renaming a public API bumps
+  the minor, and under 0.x that is the breaking bump. So a reader who finds that
+  section is already told what they need. The gap is that the reader this export
+  was written for arrives through `intent-quality.md`, which is a method page
+  reached from the README's document table, and nothing on the path between the
+  two states it.
+  *Why it is worth a decision rather than a one-line edit.* The two candidate
+  sentences say opposite things to the person this needs. Restating the existing
+  promise reads as a stability guarantee and is the honest summary of current
+  policy; saying the shape may move before 1.0 is the more useful warning and
+  discourages exactly the adopter whose table would decide the judgement-schema
+  entry above. Which one is right depends on the 1.0 entry below, which is why
+  this is filed rather than fixed.
+  *One thing already measured, in the other direction.* `pre-commit-check` §6
+  records that changing what `/inspect` returns breaks three usage samples that
+  no gate can see. The internal awareness of this surface's fragility therefore
+  exists and is written down; the outward-facing half is what does not.
+
+- **The store worth retrieving is this file, not `archive/`, and no shape has
+  been proposed for either.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`, and it is the OpenViking reading turned back on the
+  repository that did the reading. Everything that came out of it is about
+  `archive/`, and the entries are no longer counted here — the number was wrong
+  on the day it was written, was corrected on 2026-08-19, and was wrong again by
+  the next commit, when the precedence rule left for design §11. Three strikes on
+  one figure is the section's own preamble arriving in the first person: a count
+  kept in prose with nothing to check it goes wrong quietly, and the repair is to
+  stop keeping one rather than to keep fixing it. But `archive/` holds `first-run.json` — typed,
+  low-information, and now read — beside a `proposal.md` that in this repository
+  carries a link, for the reason `[0.9.3]` gives: `CLAUDE.md` makes this file the
+  single decision record. **So the store that actually holds decisions with their
+  evidence attached is `CHANGELOG.md`, at 7,100 lines with the three foot
+  sections past 1,700 of them,** and the property that makes it valuable — a
+  design evaluated, priced and killed, with the reasoning that killed it — is
+  exactly the property that makes it unreadable in one pass. It is append-only
+  with no retrieval, which is the shape the OpenViking reading was about.
+  *What an agent would actually consume is a composition, not a new store.*
+  Given an `ATX-n`: its statement and params, the scenarios covering it, the
+  first-run evidence for each, and the paths to the change that introduced it.
+  Four of the five are already computable — `inspectProject` answers two,
+  `inspectRedEvidence` the third and the archived refs the fourth — and the fifth,
+  the reasoning, is the one with no index and no key. That asymmetry is the
+  finding: the retrieval problem is not in the half that was just made readable.
+  *One thing to unmerge before deciding.* `[0.9.3]` settled a question against
+  the fifth static command, and it settled it correctly and on the right
+  grounds — `first-run.json` is JSON, and `ATX-16`'s subject is reading
+  TypeScript without evaluating it, so joining that roster would turn a security
+  promise into a list of commands that do not run the suite. But that is a
+  ruling about **roster membership**, and it is being carried as though it also
+  ruled on whether such a command should exist. Those are separate, and only the
+  first was argued.
+  *What blocks the decision, and what would cheaply unblock it.* No measurement
+  exists of whether a bundle like this changes what an agent does — the one datum
+  quoted in `[0.9.3]` measured demand to read the archive **as prose**, which is
+  a third question again. The proposal is therefore a probe and not a build,
+  per this section's own discipline of re-measuring before implementing: assemble
+  the bundle by hand for one requirement, run one real change against it, and
+  record whether it was used, ignored, or used wrongly. One session, and it
+  decides between a command, a skill surface, and nothing. Building any of the
+  three before that measurement is the order `divergent-param` was designed in
+  and the order this file has already paid for once.
+
+- **A stage-1 spec can read its params through `delta.added` instead of by id,
+  and the merge that repoints its import cannot repoint that.** Filed 2026-08-19
+  from the first change this repository put through its own `changes/` workflow,
+  where it was written by the author of the workflow's own tooling — which is
+  most of why it is worth an entry rather than a fix.
+  `delta()` returns the delta *and* the registry of what it adds
+  (`withProposedRequirements`), so `reqs['ATX-81'].params.field` reads a proposed
+  requirement before the merge and a merged one after it. That is the whole
+  reason merging a spec changes its import and nothing else. Reaching through
+  `added` — `d.added['ATX-81'].params.field` — is equally correct during stage 1
+  and throws the moment `--apply` repoints the specifier at the registry, because
+  a registry has no `added`.
+  **Nothing catches it, and the reason is structural rather than an oversight.**
+  The archive gate runs *before* the rename, so the spec it graded is not the
+  spec the merge commits; `check` executes nothing, so it never evaluates the
+  accessor; and the type checker is satisfied on both sides of the merge only
+  because it is run against whichever half is currently on disk. It surfaced at
+  the next `verify`, as `spec-load-failed` — a correct diagnosis of the symptom
+  that names the file and not the cause. The window between `--apply` and the
+  next `verify` is the whole exposure, and in a workflow that ends at `--apply`
+  it is unbounded.
+  **The guidance already exists and did not prevent it, which is the finding.**
+  `registry.ts`'s doc comment on `delta` states the intended expression and the
+  rejected one, in those terms, on the function itself; the document `init`
+  writes shows the by-id form in its worked example. So this is not a gap in what
+  is written. It is a case of the correct form and an incorrect one being
+  *indistinguishable at the moment of writing* — both compile, both pass, both go
+  red for the right reason — with the difference appearing one command later.
+  *Two shapes, and they point opposite ways, which is why this is filed rather
+  than fixed.* **(1)** A `check` diagnostic: `parser.ts` already walks property
+  accesses inside spec bodies to find `.params`, so finding `.added` on a binding
+  imported from a `requirements.delta` path is the same walk and the same file.
+  It has to be a WARNING, because enumerating what a change adds is a legitimate
+  thing for a spec to do, and a WARNING is exactly the strength that did not stop
+  the author here. **(2)** A type-level refusal: have `delta()` return a type
+  without `added`, so `typecheck:all` refuses it with no new diagnostic, no
+  roster entry and no runtime cost. `DefinedDelta<T> = T & ProposedRequirements<T>`
+  carries `added` because `T` does, so this means `Omit<T, 'added'>` — and that
+  breaks the evaluating loader, which hands the same default export to
+  `applyDelta` typed as `RegistryDelta`. Whether that break is real or just needs
+  the internal path to name a different type is **unmeasured, and is the first
+  thing to establish**; it decides between the two shapes rather than being a
+  detail of one.
+  *What blocks the decision:* frequency, and it is the same blocker the `open`
+  entry carried before it — one occurrence, in one repository, on the first
+  change ever run through the workflow. That is a report rather than a
+  hypothetical, which is more than most entries here start with, and it is still
+  n=1. What would settle it cheaply is the next change: if the by-id form is
+  written without prompting, the guidance is sufficient and this is an anecdote;
+  if the reach-through appears again, the two shapes above are worth pricing.
+
+- **Nothing is frozen, and the evidence this repository is waiting for requires
+  somebody to build on something.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`. Three releases in five days each added public surface, and
+  as of `[0.9.3]` the CLI, `./define`, `./inspect`, the archive layout, the
+  judgement schema and any retrieval surface are all simultaneously open. Every
+  entry in this section that is blocked on an adopter — the judgement table above
+  being the sharpest — is asking someone to invest in a surface that is
+  documented as movable. That is a coherent thing to ask under 0.x and it is also
+  the reason the ask may never be answered.
+  *The proposal is a line rather than a milestone:* 1.0 freezes the CLI, `./define`
+  and `./inspect`, and everything currently blocked on an adopter's evidence —
+  the judgement schema, the backlink index, any archive retrieval — is explicitly
+  1.x. What that buys is not a version number; it is the only condition under
+  which "build your own counter-pressure on our export" is a reasonable thing to
+  ask of somebody.
+  *What blocks it.* Freezing `./inspect` five days after shipping it is freezing
+  on one adapter, which is the objection this repository raises against every
+  other premature interface and does not get to waive for its own. And the
+  release-notes discipline cuts both ways here: a 1.0 is a claim about what the
+  cost of adoption will be, and `Planned`'s own preamble records that **what a
+  release costs its adopters is not known on the day it is cut**. There is no
+  measurement to date of anyone adopting either export.
 
 ## Considered and rejected
 
@@ -5731,7 +6427,7 @@ weaker signal "some registry file failed to load, so suppress all
 `orphan-test`" is the other candidate and is a strictly worse `check` on a
 multi-file registry, where the other files are fine and their orphans are real.
 **The wrong *advice* was separated out and fixed in `[0.7.0]`; the noise is
-fixed under `[Unreleased]`, and the blocker above was the wrong question.**
+fixed under `[0.7.4]`, and the blocker above was the wrong question.**
 The mapping this entry called for could not be recovered, and did not have to
 be: what a suppression needs is not the broken file's *prefix* but the ids it
 declares, and those are written in its source. Reading them back is a source
@@ -5757,7 +6453,7 @@ breadth argument recorded above, which points the other way for both commands.
 *What rejected it is that the argument for it was entirely the noise, and the
 noise is gone.* Refusing was never justified by the load failure itself — it was
 justified by the wall of derived findings burying it, and the collapse under
-`[Unreleased]` removed the wall without touching either command's breadth. What
+`[0.7.4]` removed the wall without touching either command's breadth. What
 is left on the table is the breadth argument alone, and it points the other way
 for both: `check` is the command a pipeline runs first, its contract is seeing
 everything it can still see, and answering with three findings instead of nine
@@ -5858,7 +6554,7 @@ measurement** saying parsing costs anything here — this reader is
 `createSourceFile` per file with no type checking, which is the cheap half of
 what arktype pays for, and the fan-out measurement — filed as an entry in
 `Under consideration`, and now shipped as the two concurrency bounds in
-`[0.7.0]` and `[Unreleased]` — clocked `attest check` over 6000 spec files at
+`[0.7.0]` and `[0.9.0]` — clocked `attest check` over 6000 spec files at
 1.99 s total. Worse, a cache is a correctness hazard
 of precisely the kind this tool exists to detect: a stale analysis makes a
 **drift detector** report drift that has already been fixed, or miss drift
@@ -5880,7 +6576,7 @@ to be stronger than an mtime before the trade is even worth pricing.
 
 ### Zod Mini (`zod/v4-mini`) for the registry schema
 
-Evaluated alongside v4 (which shipped under `[Unreleased]`), on the same
+Evaluated alongside v4 (which shipped under `[0.8.0]`), on the same
 schema and the same 69-requirement registry, and it wins both numbers it is
 supposed to win:
 **0.249 ms** per parse against v3's 3.47 ms, and — the one v4 does not deliver —
@@ -6162,7 +6858,7 @@ current.
 
 The mechanism `ATX-37` sat under `Under consideration` waiting for, kept there
 on cost, and killed by measuring that cost rather than by paying it. The three
-sites it was aimed at are closed under `[Unreleased]` by hand-written scenarios;
+sites it was aimed at are closed under `[0.7.4]` by hand-written scenarios;
 what is rejected is the roster, and the argument is that **`src/cli/report.ts`'s
 exports are the wrong roster in both directions at once.**
 
@@ -6282,6 +6978,181 @@ requirement, and human review at propose is still the whole answer. What is
 rejected is grouping as a way to assist it, and this reopens only on a
 contradiction that grouping would have caught.
 
+### An append-only writer for `status`, following spec-kit's `converge`
+
+spec-kit's `converge` assesses the codebase against a feature's artifacts and
+appends the remaining work as new tasks, under a strict contract: its only write
+is a new section at the foot of `tasks.md`, and it may not rewrite, renumber,
+reorder or delete anything already there. Proposed here as the shape `status`
+would need if it ever produced todos rather than a report, on the grounds that
+append-only is the safe way to write into a file a human owns.
+
+*Rejected because this repository already has a strictly finer instrument, and
+the first reading missed it by comparing the wrong pair.* `ATX-76`: with
+`--apply`, a MODIFIED requirement is written back by replacing the source span
+of **each value that changed** — never the entry holding them — and the whole
+merge is refused, with nothing written, when a span it would overwrite carries a
+comment. That is a smaller unit than "append at the foot", and it solves the
+harder problem: editing in place without destroying what a person wrote around
+it. Append-only avoids the question by never touching existing text; `--apply`
+answers it. The comparison that produced the proposal was `converge` against
+`status`, and it never looked at what the command that actually writes already
+does.
+
+*And the premise is unbuilt anyway.* `status` is a report, deliberately — it
+answers what the gate still wants, from the delta, the specs and the record,
+running nothing. No adoption report, and nobody here, has asked it to become a
+writer. A write discipline for a command that does not write is a solution
+looking for its problem, which is what `Speculative Generality` names.
+
+*Reopening this needs `status` to have a reason to write at all* — and if that
+ever happens, the discipline to reach for is `ATX-76`'s, not this one.
+
+### A Sync Impact Report at the head of a governance document
+
+spec-kit's `constitution.md` opens with a comment block recording what a change
+to it touched: the version bump and its rationale, the principles defined, and a
+checklist of every downstream template reviewed for alignment, each carrying a
+note on what was checked. Proposed here as a general form of the rule that a `docs/en` change
+carries its `docs/zh` counterpart in the same commit — a persisted record, per
+change, of what was checked downstream.
+
+*Rejected because `pre-commit-check` already produces exactly that, per commit,
+and produces it where it is useful.* The skill's opening instruction is to
+report which items applied and which did not, saying plainly when something was
+skipped and why, because "a silent omission is the failure mode this exists to
+prevent". That output is a Sync Impact Report under another name, produced at
+the moment of the change rather than pinned to the head of a file, and it covers
+more than one document's downstream — packaging, the `Issue` code contract,
+`SCHEMA_VERSION`, both language trees.
+
+*What persisting a second copy would cost is the thing this project has been
+most consistent about avoiding:* it splits a store deliberately kept single. The
+same argument keeps decisions in this file rather than an ADR directory, and it
+applies with more force here, because the two copies would disagree the first
+time a commit's report says something the header block does not.
+
+*The other half of the constitution reading* — that this repository's
+load-bearing rules have no ids and nothing reads them — survived the rejection of
+the document that carried it and was filed under `Under consideration`. Its audit
+was done on 2026-08-18 and it is now rejected too, in the section directly below
+this one, on an argument neither half of the reading predicted.
+
+### Promoting this repository's own rules in `CLAUDE.md` to requirement ids
+
+The audit this entry was filed for was done on 2026-08-18 and its answer is
+**none**. The entry named its own first step — an audit whose primary output is a
+rejection list — and asked which `CLAUDE.md` rules should become ids, on the
+observation that rules whose violation has already produced silent defects are
+gated by nothing.
+
+*Three were already ids, which the entry knew.* `ATX-28` is the path-spelling
+rule, `ATX-29` the line-endings rule in the form that matters (the freshness
+check compares the document rather than its bytes), and `ATX-16` with `ATX-17`
+the two-readers rule: the four-command static roster, and the refusal to fall
+back to evaluating a registry that will not read.
+
+*One is already gated and the entry did not know it.* `docs/zh/**` mirroring
+`docs/en/**` one-for-one is asserted twice in `tests/docs-consistency.spec.ts` —
+every English page has exactly one Chinese counterpart, and each pair shares a
+heading tree and a code-sample sequence. What has no gate is whether the two
+still *say* the same thing, which is what `CLAUDE.md` and `pre-commit-check` §6
+both mean by "checked by eye only": the structural half is held, the semantic
+half cannot be.
+
+*The rest fall into three groups and none of them wants an id.* **Six are
+working habits** — `vitest run` does not run `self/`; it also runs the type
+tests; `bin/attest.js` loads `dist/`; some fixtures fail on purpose; a scenario
+starting a child run needs an explicit timeout; a package manager is spawned only
+through the one helper in `tests/consumer.spec.ts`. Each is about how to work in
+this repository rather than what Attest promises anyone, and §1 is decisive:
+a requirement costs a mandatory scenario forever, so these would be six scenarios
+asserting facts about a maintainer's habits. **Two are the design vocabulary and
+the filing rule**, which are definitions and a destination — there is nothing to
+assert. **And one constrains a consumer rather than the engine**, which is the
+finding worth keeping.
+
+*`Issue.message` is prose, never API — the most load-bearing ungated rule in the
+file, and no id can hold it.* The promise is that a consumer may branch on `code`
+and `reqId` and must not branch on wording, so the obligation falls on the
+consumer's tests and not on any behaviour a run of this engine can exhibit. The
+checkable half is already structural: `code` is typed to the roster in
+`src/core/docs.ts`, and `ATX-40` obliges every code to carry a troubleshooting
+section in both languages. A requirement stating the rest would either restate a
+type or assert something no run can observe. **This is the audit's general
+result rather than one rule's exception** — the file is mostly a working
+agreement with this repository's maintainers, and the three rules in it that were
+contracts Attest owes an adopter had all been promoted before the question was
+asked.
+
+*The same argument retires the entry's own sharpener.* `[0.9.2]` edited
+`.claude/skills/pre-commit-check/SKILL.md` with no gate having an opinion about
+its contents, and that is true — but measured, the machine-checkable surface of
+that document is **one token**: it names exactly one issue code,
+`spec-load-failed`, and that code exists. An `ATX-57` analogue over it would gate
+a roster of one. Everything else in the document is judgement, which is both what
+a gate cannot hold and the reason the document is prose.
+
+*One actionable finding survives, and it is not an id.* `CLAUDE.md` says not to
+flatten `fixtures/nested-spec/`, because its spec is the only one below a root
+and therefore the only thing exercising a separator. The guard is
+`tests/paths.spec.ts`, which scans that fixture and asserts that no relative path
+contains a backslash — **and that assertion passes on a flattened corpus**,
+because a flat filename contains no backslash either. The rule carrying a written
+warning against silent decay is guarded by an assertion that decays silently. The
+fix is one line in that test, requiring at least one scanned path to sit below the
+root, and it is a plain test rather than a requirement for the same reason as
+everything else here: it is a property of this repository's fixture corpus, not a
+promise about Attest's behaviour. **Done under `[0.9.3]`**, and the guard
+was checked against a flattened copy of the fixture before it was written — the
+predicate reads true on `fixtures/nested-spec/` and false on the same files laid
+flat, which is the difference the old assertion could not see.
+
+*Worth reopening only for a rule that is a contract* — one Attest owes an
+adopter, added to that file later. It belongs in the registry when it is written,
+not in a second sweep of prose.
+
+### Semantic retrieval over the intent layer
+
+Priced on 2026-08-18 while reading OpenViking (volcengine/OpenViking, AGPL-3.0,
+at `87d5142e`) for what a context database for agents has that this repository
+does not. The proposal was its retrieval path
+(`docs/en/concepts/07-retrieval.md`): embed requirements, specs and archived
+proposals, then answer a question with an LLM intent analysis that emits zero to
+five typed queries, a priority-queue recursion down the directory tree with
+score propagation, and a rerank pass over the survivors.
+
+Rejected on what that machinery is *for*. Every part of it is a way to find
+things in a corpus that has lost its structure — free text, no ids, no grammar,
+tens of thousands of entries. This one has 79 requirements in a single file,
+each with an id matching `/^[A-Z]+-\d+$/`, grouped by a prefix, carrying a
+statement written to contain SHALL or MUST. Lookup by id is exact and free;
+`grep` over the statements answers the rest. Ranking is what you reach for when
+you cannot address; addressing is the thing this design already has, and §5.4
+extends it to evidence by keying the red record on requirement id, spec file and
+scenario name.
+
+The second reason is the one that would survive a bigger corpus. A retriever of
+that shape puts a non-deterministic, network-dependent, unfalsifiable scorer
+beside four commands whose defining property is that they execute nothing and
+whose output is a verdict a reader has to be able to reproduce. Their own
+document specifies the degradation frankly — "if rerank returns an invalid
+result or the API call fails, retrieval falls back to vector scores" — and a
+silent fallback to a weaker mechanism is precisely what §5.1 refuses when it
+makes a non-static registry a `registry-not-static` ERROR rather than a
+fallback to evaluation. The same answer applies here for the same reason.
+
+Worth reopening if an adopter's registry reaches a size where prefix grouping
+and `grep` genuinely stop working — but the first thing to try then is the
+declared prefix ownership already under consideration above, which addresses,
+rather than a scorer, which ranks.
+
+## Releases
+
+[0.9.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.4
+[0.9.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.3
+[0.9.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.2
+[0.9.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.1
 [0.9.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.0
 [0.8.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.8.0
 [0.7.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.4