@am_shork/attest 0.7.3 → 0.8.0

package/CHANGELOG.md

@@ -13,6 +13,648 @@ 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.8.0] - 2026-08-09
+
+### Security
+
+- **The `--json` document escaped every C0 control and no C1, while every other
+  surface stripped both.** `control()` (`core/terminal.ts`) covers
+  `\x00-\x1f`, DEL and `\x80-\x9f`, the last of those held deliberately for
+  8-bit CSI; the machine path rested on `JSON.stringify`, and the claim written
+  above it — that serialising to JSON escapes the same characters — is true of
+  C0 and of nothing else. Re-measured before a line was written, as this file's
+  discipline asks: `U+009B` and `U+007F` both leave `renderJson` verbatim.
+  Reachable from every `--json` command including `check --json`, which executes
+  nothing and still quotes scenario names, file paths and reqIds out of the
+  repository being checked; under `verify` and `archive` a thrown message joins
+  them.
+  **Filed at the strength the evidence carries, and that has not changed.**
+  Exploiting it needs a terminal that treats UTF-8-decoded C1 as control —
+  believed to split VTE from xterm's default, still **not measured on either** —
+  and a reader looking at the JSON rather than parsing it. What makes it worth
+  closing is not the size of that window but the asymmetry: design §9.1 is
+  stated as a property of every artifact Attest writes, and one emitter opting
+  out through a true-but-narrower guarantee is exactly how two `catch` blocks
+  came to print a raw stack beside sanitised diagnostics once already.
+  **Re-measuring moved where the fix goes.** The entry proposed a map over
+  `issues`, on the `withDocs` model. Walking the report showed that is the wrong
+  half: `change`, `outFile`, `outFiles` and — two levels down — a status row's
+  scenario name and file all carry text from the project under test, and none of
+  them passes through the envelope. Enumerating them is the arrangement §9.1
+  already names as the cause of the defect, so the rule sits at serialisation
+  instead, which is the *document* arrangement the section describes — one point
+  of assembly, before any of it is seen, covering a field nobody has added yet.
+  `outFiles` and `docsUrl` were both added after the envelope and would each
+  have needed remembering. `reqId` needed none of this and is worth recording as
+  the case that is safe by construction: `RegistryIdSchema` holds every id to
+  `^[A-Z]+-\d+$` on both readers, which is the same argument `render` uses for
+  not sanitising ids.
+  No `SCHEMA_VERSION` bump: the shape is unchanged, and the field values a
+  consumer parses differ only where they previously carried a control character.
+  Attested as `ATX-74` rather than by widening `ATX-37`, which claimed this
+  surface was exempt — the two are separately falsifiable in the direction that
+  matters, since `ATX-37` holds at every print site today while this one failed.
+  That rationale, and the same claim in `core/terminal.ts`, are corrected in
+  place.
+
+- **`render --out` wrote through a committed symlink, because the per-segment
+  resolution `init` performs had exactly one caller.** `resolveDest` resolves
+  every segment of an `init` destination and refuses with `unsafe-target-path`;
+  the `--out` path was `resolve(cwd, opts.out)` and went straight to
+  `writeAtomic`. Measured before a line was written, as this file's discipline
+  asks, and the filed claim held: with `docs` committed as a symlink to a
+  sibling directory, `attest render <dir> --out <dir>/docs/SPEC.md` reported
+  `✓ Wrote …` and the document appeared outside the root. The victim's `--out`
+  is the one their own README or CI documents, and the content redirected is the
+  rendered document — the statements and rationales their repository wrote.
+  **The leaf was already safe, which is why the gap was exactly the directory
+  segments.** `writeAtomic` lands by `rename`, which replaces a symlink instead
+  of following it — measured: a `SPEC.md` symlinked at a file outside the root
+  left that file's bytes untouched. `wx` does not reach this either and was
+  never scoped to: it guards the temporary path, and the temporary path is
+  `dirname(dest)`, i.e. already inside whatever directory the link chose. So
+  both held perfectly while the whole write happened somewhere it should not.
+  **The scope is the part that is not inherited from `init`.** `init` owns its
+  destinations, so containment there is unconditional; `--out` is an argument,
+  and `--out ../site/SPEC.md` is a destination the caller can see they chose.
+  Refusing it would be refusing the flag. The check therefore applies exactly
+  where the argument stops being evidence of where the file goes: a path that
+  reads as staying inside the project. It is asked against the root in both
+  spellings, lexical and resolved, because they differ whenever the project
+  itself sits under a link — testing only the resolved one would skip the check
+  for every such checkout, failing open on precisely the layout that has links
+  in it.
+  **`--check` goes through the same resolution**, which the filed entry did not
+  cover. It reads the destination rather than writing it, and a freshness gate
+  comparing a fresh document against a file outside the project answers about
+  the wrong document — quietly, since both verdicts it can reach are ones it
+  reports normally.
+  So this is `resolveDest` gaining its second caller rather than a new
+  indirection; by this repository's own rule it was a hypothetical seam with one
+  adapter and is now a real one. `changes/<name>/` remains the candidate third
+  and stays unmeasured.
+  **The repair moved the write, not just the check, and the reason is the shape
+  of the defect rather than tidiness.** `render`'s `writeAtomic` was the only
+  call to it outside `core/` — `runInit` writes in the pipeline, `merge.ts`
+  writes in the pipeline, and this one write sat in the CLI, which is exactly
+  how it reached the filesystem without the resolution `runInit` had performed
+  since `[0.7.3]`. Guarding it in the shell would have left that intact: the
+  obligation to call the check would still belong to a caller who can forget it,
+  which is the situation `pipeline.spec.ts`'s compiler-guard gate already exists
+  to catch elsewhere ("delete the line and every scenario stays green"). So
+  `runRender` takes the destination and owns the write, `runRenderCheck`
+  resolves the path it reads, and the resolution is **private to the module** —
+  there is no longer an entry point that writes a document without resolving
+  where it goes. The CLI lost its `writeAtomic` import, and with it the last
+  policy decision it was making; `hasError` before the write is now what stops a
+  broken registry overwriting a good committed document, stated where the write
+  is. No existing test changed: `runRenderCheck` keeps its signature, because
+  `target` already carried the spelling a diagnostic echoes and asking a caller
+  for it twice is a clump waiting to disagree with itself.
+  Two things the move surfaced that a guard bolted onto the shell would have
+  hidden. **The compiler guard has to stay the first statement**, which
+  delegation gave `runRenderCheck` for free and a resolution placed above it
+  quietly took away — an unsupported TypeScript would have come back as a path
+  refusal. Both entry points call `compilerIssue` first now, and
+  `runRenderCheck` leaves the exemption table in `tests/pipeline.spec.ts`, which
+  is what that table is for: a list of exemptions exists to be decided about
+  rather than to drift. And **"never overwrite a good document with the output
+  of a broken registry" was a comment with nothing behind it** — the write lived
+  in the CLI, where no test could reach it. It is asserted now, where the write
+  is, and is red without the guard: a half-loaded registry renders a document
+  that silently omits requirements, so overwriting the committed one destroys
+  the only correct copy and the next `--check` passes against the damage. The ATX-73 scenarios drive
+  the binary, so they are what proves the move changed no behaviour, and three
+  mutants confirm they still bite: writing without resolving, refusing every
+  path that leaves the root, and `--check` skipping the resolution are each red.
+  Stated as `ATX-73` with three scenarios: the write path and the `--check` path
+  both driven through the real CLI against a project carrying a planted link —
+  spawned rather than called, because the defect was never in the resolution but
+  in the write not going through one, so a scenario calling `resolveOutFile`
+  directly would have passed against the broken build — and a third holding the
+  scope, that a destination spelled outside the project is still written where
+  it says. All three are red against the previous build.
+  One further behaviour change falls out of resolving rather than checking, and
+  it is a repair rather than a cost: a link *inside* the project is now
+  **followed** instead of replaced. `rename` used to overwrite `docs/SPEC.md ->
+  build/SPEC.md` with a regular file while `--check` read straight through it,
+  so the two halves of the gate disagreed about which file the document was;
+  measured, the link now survives and `build/SPEC.md` receives the bytes.
+  **This turns a passing run red for anyone whose `--out` currently resolves
+  through a link out of the project**, which is the behaviour change that
+  matters and is the point of it. No
+  `SCHEMA_VERSION` bump: `unsafe-target-path` is an existing code reported by an
+  additional command, `src/cli/json.ts` is untouched, and no field moves.
+
+- **`--apply` wrote the registry's own file name into a spec's import as text
+  rather than as a string, so a registry whose name carried a quote closed the
+  literal and everything after it became code.** `splice.ts` states that every
+  generated byte is escaped — `tsString` for statement, rationale and
+  `outOfScope`, `keySource` for param keys, a `throw` rather than a guess for
+  `__proto__` — and `repointImport` was the one site that interpolated instead.
+  What it interpolated is the value the *checked repository* names: `to` is the
+  registry file `--apply` decided the ids belong in, and `isReqsFile` tests only
+  the suffix.
+  **The deletion test says what this was worth, and it is not execution.**
+  `archive --apply` runs the suite in the same invocation, so the attacker
+  already executes there. What the injection added is **persistence**: the
+  payload lands in a `*.spec.ts` that the merge then commits, and runs on every
+  later clone and CI job, inside a diff `--apply` advertises as a rename plus one
+  specifier. **Not platform-scoped** — Windows rejects `\ / : * ? " < > |` in a
+  file name and neither `'` nor `;` is among them.
+  Re-measured before a line was written, as this file's discipline asks, and the
+  filed claim held with one correction it did not have: the payload must carry
+  **the file's own quote character**, so the double-quoted spec survives a `'`
+  and vice versa. That is why the repair is not "escape `'`". `tsString` splits
+  into a `tsStringBody(value, quote)` that is *told* which quote it writes
+  between, and the specifier edit passes the quote already in the file — the
+  file's quote style stays exactly as it was, which is the property that ruled
+  out `JSON.stringify` here in the first place. No refusal path was needed:
+  escaping has an answer for every name, since a specifier is a string and
+  `tsStringBody` can spell any string as one, so `repointImport` still cannot
+  throw and `merge.ts` keeps the one `UnwritableValue` site it had.
+  The regression is asserted as a **round-trip** rather than against escaped
+  bytes — the file still parses, carries its original four statements, and the
+  specifier reads back as the path — under both quote styles, because escaping
+  the wrong quote is as wrong as escaping neither. Both cases are red against
+  the previous emitter.
+  Stated as `ATX-72` with a scenario per quote style, driving the real
+  `--apply` over a project whose registry file is named with the payload. Its
+  first draft is worth recording because a gate caught it and not a reviewer:
+  written as a quantifier over every value the emitter writes, the `sites` table
+  in `tests/intent-rule-candidates.spec.ts` demanded a scenario per site and
+  found three the sentence claimed which no `self/` scenario reaches. The hole
+  was in the *statement*, not the coverage — the other three sites are attested
+  in `tests/splice.spec.ts` and were never part of this change — so the repair
+  was to narrow the sentence to the one value the checked repository names.
+  §7 gains the general form, since it already carried the emitter's rule ("it
+  may emit no text whose evaluation differs from the value it was handed") and
+  carried it as a rule about the *registry*: `--apply` writes a second file, and
+  a file name is not something a tool is in a position to restrict, so it is
+  something the writer is obliged to escape.
+  No `SCHEMA_VERSION` bump: `src/cli/json.ts` is untouched, no code or field
+  moves, and no valid input changes behaviour — for any registry not named to
+  attack, the bytes `--apply` writes are the bytes it wrote before.
+
+- **A registry file that swaps its prototype was read as the requirements the
+  prototype carried, under the reader that evaluates.** `{ '__proto__': { … } }`
+  written as a literal is a swap, not a key: the object has **no own keys at
+  all**, so what the loader reported never depended on the swap but on what
+  happened to be behind it. The static reader refuses such a source outright as
+  `registry-not-static` and always did — the two readers agreeing is a security
+  property, not a convenience — so this was the two of them disagreeing about
+  whether a file is a registry at all.
+  **A fixture for exactly this existed and was passing for the wrong reason.**
+  `tests/static-registry.spec.ts` put *malformed* ids on the prototype, and zod
+  v3's record enumerates with `for…in`, which walks the chain — so those
+  inherited keys were tested against the id grammar and failed it. The red was
+  incidental to the swap, and the whole guarantee rested on it.
+  Put a **well-formed** id on the prototype instead and the same shape is
+  **accepted**, with the entire registry built out of a prototype the source
+  does not declare. That is measured on the zod this release ships with, not
+  inferred: the new differential case is red without the guard and the old
+  fixture stays green beside it, which is the defect and its camouflage in one
+  run. Found while evaluating the move to zod v4 — which enumerates own keys
+  only, so the swapped object is simply empty and even the malformed fixture
+  goes green — but the acceptance is reachable today and is fixed here, ahead of
+  that port and independently of it.
+  Refused now by the `isPlainObject` guard `params` has carried since a param
+  became any JSON value, applied one level up to the registry itself — **stated
+  over the shape rather than over the name `__proto__`**, because a blocklist of
+  names is a second answer to "is this data" and the guard is already the first.
+  A class instance and a `Date` fail it for the same reason. `registry-invalid`
+  rather than a code of its own: the obligation is identical to every other way
+  the schema refuses a registry, and so is the reader's situation.
+  Stated as `ATX-70` with three scenarios, and the fixture the suite was missing
+  — the well-formed-id swap — is now the one the differential suite runs.
+
+### Changed
+
+- **The guidance now says which quantifier to write, where before it only said
+  what a scenario must read.** `[0.7.0]` added the `QUANTIFIED` table after
+  `ATX-37` — "**everything** the CLI writes to a terminal MUST replace every
+  control character" — was found to have scenarios for the two formatters that
+  existed the day it was written, while `render` built a document by
+  concatenation that never went past the sanitiser. What the table taught was
+  never written down anywhere an author would meet it, and it is the more useful
+  half of that work: **which surface a quantifier ranges over decides whether
+  scenarios can keep up with it**, and there are three, not the two the original
+  proposal assumed. Over *values* one site processes, representative inputs
+  settle it. Over a *roster* the code enumerates, a scenario looping that roster
+  covers a new member by construction. Over *sites* in the implementation, each
+  needing a hand-written scenario, a new site is a new obligation and nothing
+  enumerates them — the only one of the three that can silently stop being true,
+  and what `ATX-37` was. So the rule is *prefer a quantifier a scenario can
+  iterate*.
+  *Where it landed.* Design §11 as a residual weakness, beside the two `params`
+  bullets it completes — those say what an assertion must do with a value it
+  read; this says what the statement above them should quantify over in the first
+  place. The `init` skill gets the adopter-facing form in the same model section
+  as those two rules, so a project adopting Attest is told before it writes the
+  statement rather than after the gap is found by reading. Both languages, one
+  commit, per the reason `[0.5.0]` records for doing this shape of change in one
+  pass.
+  *No engine change, and the entry stays open for the one that is still not
+  proposed.* Which surface a sentence names is prose judgement — the ground truth
+  §0 refuses to compute for someone else's requirements — and the detector that
+  exists flags the quantifier only, missing the article form ("A registry that
+  cannot be read MUST …"). What ships here is counter-pressure, which is what §11
+  now says: a hand-judged table for this registry, plus a rule an author can
+  follow. The carve-out is carried with it, because it is the failure mode of any
+  such table: rewriting a statement to name its surfaces takes it back out of the
+  flagged set, so the table admits rows for ids nothing flags.
+
+- **Zod moves from v3 to v4 (`zod@^3.23.0` → `^4.4.3`).** The reason is supply,
+  not speed: v3 is in maintenance, so fixes land on v4. The port of the schema as
+  it stood was the **one API change** the plan predicted — `errorMap` → `error` —
+  with `z.custom().pipe()`, `z.record`, `z.lazy` and the recursive `paramValue`
+  all carrying over unedited, and `red-record.ts`'s `z.ZodType` untouched. A
+  `as z.ZodType<ParamValue>` on `paramValue` became unnecessary and is gone. The
+  count is one *for the schema the plan measured*: the prototype guard added in
+  the commit before this one brought a second options bag with it, so the port
+  actually touched two — which is the ordinary way a plan's cost estimate goes
+  stale, by the code moving under it rather than by the estimate being wrong.
+  **The plan's "no `package.json` change" framing was about the evaluation, and
+  taking it as the destination would have shipped a broken package.** It rested
+  on `zod@3.25.76` exporting a `./v4` subpath — true of the *installed* version
+  and not of the *declared range*: `zod@3.23.8` is inside `^3.23.0` and exports
+  no `./v4` at all, so importing `zod/v4` while keeping that range yields a
+  package that fails to resolve on a legitimate install of its own dependency.
+  It is a real bump or it is nothing.
+  *Re-measured here, and the entry's central type claim does not survive.* The
+  plan recorded instantiations as **unchanged** (27,681 → 27,671). On this
+  codebase they go **36,211 → 89,831**, about 2.5×, with build check time
+  0.58 s → 0.71 s. Controlled for the prototype guard, which accounts for 292 of
+  that — the growth is the port. The consumer-side `.d.ts` footprint is worse
+  than predicted too: **14 files / 68 KiB → 80 files / 217 KiB** (the plan said
+  66 / 181 KiB), and a consumer's own instantiations 71,935 → 131,044. Runtime
+  goes the other way and by less than advertised: parsing this registry is
+  **0.873 ms → 0.143 ms**, 6.1× rather than 13×, and worth ~0.7 ms against the
+  hundreds `attest check self` takes. None of it blocks a migration whose reason
+  is supply, and all of it is recorded because "v4 is also faster to typecheck"
+  is the sentence that would otherwise reach the commit message — and on this
+  schema it is false in a way the plan did not have: the plan called the type
+  side neutral, and it is a cost.
+  *One diagnosis regression, found and repaired.* A v4 record reports a bad key
+  as "Invalid key in record" and does not surface the key schema's own message,
+  so a mistyped requirement id — the commonest way to fail this schema — stopped
+  being told the grammar it had missed. The record now carries an explicit
+  `error`, which restores it.
+
+- **`RegistryValidationError.issues` has a shape of this project's own, and no
+  longer exposes `z.ZodIssue`.** Zod was otherwise fully absorbed — `Requirement`
+  and `Registry` are `z.infer` aliases, so a consumer resolves them to plain
+  object types and never names the library. This field was the single exception,
+  and it was the load-bearing one: it is reached through the `./define` subpath
+  that `defineRequirements` is imported from, and `ZodIssue` is a discriminated
+  union zod reshaped between v3 and v4. So a dependency bump this project should
+  have been free to make was a **breaking change for anyone who had destructured
+  the field**. The element type is now `RegistryValidationIssue` — `path:
+  PropertyKey[]` and `message: string`, exported from the same subpath — which is
+  the same boundary `Issue.message` already holds, with the difference that
+  `Issue` was designed with the boundary and this was not.
+  **Breaking, for the narrow surface that read past those two fields**, which is
+  why it is a minor under 0.x. Nothing in this repository was in that surface:
+  re-measured before a line was written, the only two readers are `formatIssues`
+  in `registry.ts` and `firstMessage` in `apply.ts`, and **nothing anywhere reads
+  `code`, `expected`, `received` or `fatal`** — which is what made this a rename
+  rather than a redesign. A consumer that only formats what it is given, as both
+  of those do, sees no change at all.
+  *`path` is `PropertyKey[]` rather than `(string | number)[]` deliberately.* It
+  is the wider of the two spellings zod has used, so a validator failure assigns
+  to it under either — which is the whole point, since the release that moves
+  that type is the one this change exists for.
+  *One thing the plan glossed, found by doing it.* The two formatters were said
+  to read the same two fields, and they did — but not the same way: `apply.ts`
+  spelled the path `.map(String).join('.')` and `registry.ts` spelled it
+  `.join('.')`. Under `(string | number)[]` those are identical; under
+  `PropertyKey[]` the second **throws** on a symbol key, because `join` cannot
+  convert one. The shared formatter uses the safe spelling. `ATX-44` is what made
+  the rest checkable rather than hopeful: the `a.b.c` path spelling is a stated
+  requirement with a scenario on it, so the property that had to survive already
+  had something asserting it.
+
+- **`changes/<name>/first-run.json` moves to `version: 2`, and a version-1 file
+  is discarded whole.** The record now nests the scenario name under the spec
+  file, so the old shape cannot be read as the new one. Discarding is the safe
+  direction — an empty record makes every obligation "never observed", which the
+  gate blocks on — and the cost is one stage-1 run to re-observe, for a change
+  in flight across this upgrade only. The version is *checked* rather than
+  inferred from the old shape failing the schema: it would fail it anyway, but
+  "discarded because the format moved" and "discarded because the file is
+  corrupt" are different facts, and reading one as the other is how a format
+  change happens without anyone deciding to make it. Unrelated to the report
+  `schemaVersion`, which does not move — `src/cli/json.ts` is untouched, and no
+  envelope, field or `code` changed.
+
+### Fixed
+
+- **A scenario that never ran was reported as attested, when another spec file
+  declared a scenario of the same name under the same `requirement()`.** Runtime
+  coverage was keyed `(reqId, scenario name)` with no file, so two spec files
+  declaring `scenario('x')` under `requirement('APP-1')` were one entry, and
+  whichever of them executed vouched for both. `declared-not-run` — the check
+  whose whole job is to catch a declared scenario that did not execute — was
+  answering about the wrong scenario, and answering "fine".
+  Reproduced on 2026-08-09 with no flag, no `--eval` and default configuration:
+  a `real.spec.ts` whose `scenario('x')` runs beside a `ghost.spec.ts` whose
+  `scenario('x')` sits in a branch that never registers gives
+  `✓ No issues. — 1 requirement / 2 scenarios`. Renaming the ghost to `'y'`
+  produces the `declared-not-run` naming it, so the collision was the whole of
+  the difference — the check was present and was looking at the wrong key.
+  **This is the failure this tool exists to refuse**, which is what put it ahead
+  of everything else in flight: a report that says a scenario attested a
+  requirement when the scenario did not execute.
+  **The same key reached the first-run record, and there it is worse.** The
+  record is monotonic toward `fail`, so two scenarios of one added requirement
+  sharing a name meant one going red satisfied the other's `never-red`
+  obligation — mechanism 2 certifying a discrimination that never happened.
+  That half was inferred from the shared key when this was filed and is measured
+  here: both halves go red independently under control, which is why `ATX-71` is
+  two obligations rather than one.
+  Fixed by carrying the file into the key rather than by adding a check. `walk`
+  already descends from the file task, which is the only level holding a path,
+  and `ParsedScenario` has carried `file` since it existed — so both sides of
+  design §5.4's one cross-process channel had the field and only the maps
+  forgot it. It goes through `relativePath` for the reason `unloadedFiles` does:
+  the key is compared against a plan built on POSIX paths, and a native
+  separator on Windows would turn this false green into a false red.
+  Nested (`reqId -> file -> name`) rather than a composite key string, at both
+  ends: no separator has to be chosen that a path or a scenario name could
+  contain, and `first-run.json` stays a file a reviewer reads.
+  **What the fix cost, and the alternative that was rejected.** Keyed by the
+  name on disk, the record broke `--apply`'s resume: step 2 renames
+  `x.proposed.spec.ts` to `x.spec.ts`, so a resume after that rename looked up a
+  key written under the proposed name, found nothing, and blocked a change whose
+  scenarios *had* been observed red — the gate refusing its own evidence, caught
+  by `ATX-53`'s two resume scenarios. Rewriting the record beside the rename was
+  the obvious repair and is worse: two files that must move together, in a
+  design whose entire resume story is that each step is separately idempotent.
+  So the record keys by the **merged** spelling from the start, which the rename
+  cannot move. It still separates two spec files, which is the collapse the key
+  exists to prevent; what it deliberately does not separate is a file from its
+  own proposed name, because those are the same file.
+  Not claimed: that a scenario name is unique within one file. It need not be,
+  and this key does not make two same-named scenarios in one file
+  distinguishable. What it closes is the cross-*file* case, which is the one
+  reachable by ordinary means — two authors adding a scenario to the same
+  requirement from two files is how a requirement grows, while a duplicate name
+  inside one file is visible in the file being read.
+  Measured on Linux; **Windows is unmeasured**, and the path-shaped half of the
+  fix is exactly what differs there.
+
+- **An error class was being used as a formatter, at two sites that never threw
+  it.** `locate.ts` and `static-registry.ts` each constructed a
+  `RegistryValidationError` purely to borrow its `.message`, because both report
+  the same `registry-invalid` as the throwing path and the message has to be
+  identical rather than merely similar. The formatter is what those sites wanted
+  and it is now the thing they can ask for — `registryValidationMessage` in the
+  new `core/registry-issues.ts`, which all three sites share. That sharing is
+  what makes the messages structurally identical instead of a coincidence
+  maintained by hand.
+  The module is separate from `registry.ts` rather than added to it because
+  `./define` maps to the whole of `registry.ts`, so everything that file exports
+  is a public contract. The issue *type* has to be public; the formatter does
+  not, and both of its callers are internal.
+
+### Added
+
+- **`tests/registry-error-types.spec-d.ts` pins the shape that was just
+  narrowed.** The property is entirely type-level — it has no runtime footprint,
+  and the engine reads registries from the AST — so a `.spec-d.ts` is the only
+  thing that can catch a regression in it, and a green suite would otherwise
+  carry one through to users untouched. It pins both halves: that the element
+  type is exactly the two fields (`toEqualTypeOf`, so a future edit widening it
+  back to a union fails), and that a real parse failure still assigns to it with
+  no cast. Confirmed to go red on the exact regression it exists to catch by
+  reverting the field to `z.ZodIssue[]` and re-running it.
+
+## [0.7.4] - 2026-08-08
+
+### Added
+
+- **`ATX-37`'s three unattested sites are closed, and the sweep that was going
+  to close them is rejected instead.** The requirement says *everything* the CLI
+  writes to a terminal replaces the control characters in text it quotes from
+  the project under test, and the `QUANTIFIED` table had carried four `null`
+  rows against it since `[0.7.0]`: the status rows, the coverage table, the
+  archive verdict, and the path `--out` echoes. Three of those are formatters
+  interpolating a reqId, a change name or a written path — correct by reading,
+  attested by nothing, which is the state a `sites` quantifier is the only kind
+  able to reach in silence. Three scenarios now drive them with hostile input,
+  covering six interpolations, and each was **proven able to go red by injection
+  before being believed**: `inline` removed from the status row's id, from the
+  merged path, from the archive verdict's change name, and from the coverage
+  row's id — four defects, each failing exactly one scenario and no other. The
+  fourth `null` stays: `--out` needs a filename holding a control character,
+  which NTFS refuses and Linux permits, and an unmeasured half is what a `null`
+  records.
+  **A fifth injection is why the archive verdict is asserted three times.**
+  Reading the diff caught what the site list does not resolve to: `change` is
+  interpolated by three separate expressions in that one function — merged,
+  archivable, and gate-failed — and the first draft covered two of them, leaving
+  `inline` deletable from the third with the whole suite green. A `sites` row
+  names sites at the granularity a sentence uses, and a branch is finer than
+  that; the injection is what tells the two apart.
+  **Re-measuring the proposal before building it is what split it in two**, and
+  the figures moved in both directions. `src/cli/report.ts` has 8 exports of
+  which **7** are `format*` — the eighth is `summarize`, so the entry's "eight
+  formatters" was already one off its own wording. The "eight fixtures, one per
+  signature" was worse: there are 7 distinct parameter types, `Issue[]` is
+  shared by three functions, and the honest cost of the fix turned out to be two
+  fixtures extending ones `self/report.spec.ts` already builds. And the entry
+  **undercounted its own benefit** — "three currently-correct sites" is three
+  *formatters* carrying six interpolations.
+
+- **The `✗` samples are bound to a fixture whose rejection the suite asserts.**
+  A page showing input the engine must *reject* was the one kind of sample
+  nothing could see going stale: it carries no version, names no `src/` symbol,
+  and keeps its page's structure perfectly, so every gate in
+  `tests/docs-consistency.spec.ts` passed while the claim underneath it aged.
+  The failure that mattered is asymmetric — a stale runnable sample stops
+  working when a reader pastes it, while a stale counterexample is a reader
+  taught a rule that is no longer a rule, which is worse than teaching nothing.
+  A `✗` annotated with a code the engine can emit is now bound to a fixture,
+  byte-equal the way `fixtures/consumer/` is bound to the README, and the
+  fixture is **run through the reader the documented command uses** — the code
+  and the line it produces are compared with the code and the line the page
+  shows. The line is the half that catches the shape a code-only assertion would
+  not: a fixture still rejected, for a different reason, having quietly stopped
+  demonstrating what it is quoted for.
+  **Re-measuring the entry before building it moved its cost by a factor.** It
+  was filed as the expensive half, "a fixture per diagnostic". Of the 33 fenced
+  `ts` blocks in the README and `docs/en/**`, 8 carry a `✗`, 3 name a code the
+  engine can emit, and 1 of those 3 is elided (`duplicate-prefix`, taught as two
+  one-line registries whose bodies are `{ /* … */ }`) — leaving one sample,
+  quoted on two pages, bound to one fixture. The count was never the reason it
+  sat: what it was really waiting for is the thing that makes the roster hold,
+  which is that the binding is a **sweep** rather than a list. A new `✗ code`
+  block on any English page is bound to a fixture or fails as `unbound`, so the
+  next diagnostic pays a fixture because it is obliged to, not because someone
+  remembered the roster existed.
+  **Proven able to go red before being believed**, since a gate over samples
+  that are all currently correct has never failed and cannot be trusted until it
+  does: four mutations, one per way the binding can rot — the page edited away
+  from the fixture, the fixture made static so the engine accepts it, a `✗`
+  sample added bound to nothing, and the defect moved to a line the annotation
+  does not mark. Each was reported naming the page or the fixture.
+  *Two limits, both structural.* **English only**: `docs/zh/**` matches
+  `docs/en/**` down to the comments inside its samples, so byte-equality is a
+  claim only one side can carry, and what covers the Chinese side is the parity
+  gate from `[0.4.3]` holding the code-sample sequences equal — structure, not
+  meaning. And an **elided block is excluded by rule**, not by omission from the
+  roster: `{ /* … */ }` is what makes that sample readable and also what makes it
+  unrunnable. The residual risk recorded in `[0.4.3]` does *not* apply here —
+  the byte gate and the run proving the fixture still fails are in the same
+  file, so a fixture that stopped being rejected cannot pass by living in a
+  suite nobody connected to the page.
+
+- **`ATX-15` is swept over `src/` from the AST, rather than attested one site at
+  a time.** The requirement quantifies over *sites* — every ordering committed to
+  disk or compared for equality — and `sites` is the one shape the quantifier
+  table records as able to stop being true in silence: a new site is a new
+  obligation and nothing enumerates them. Two of its five sites were `null`:
+  `red-record.ts` sorts ids and scenario names into `first-run.json`, and
+  `splice.ts` sorts ids and param keys into the registry file `--apply` writes.
+  Both are committed to disk, both were correct, and neither had a scenario. A
+  scenario per site would have closed those two and left the shape untouched,
+  because site six would have been unattested the day it was added. The sweep
+  instead makes the roster one the **code** owns — every `.sort`/`.toSorted` in
+  `src/` is a member — so a new ordering site is covered by construction. The
+  sanctioned comparator, the sort methods and the banned APIs are `ATX-15`
+  params, read by the scenario, pinned against literals for the reason the
+  domain table states: shrinking a list a scenario iterates removes a case and
+  everything left still passes.
+  **Stated narrowly enough to be true: it constrains how a site orders, not that
+  it orders.** A `red-record.ts` that stopped sorting altogether is still green
+  here, and the three hand-written scenarios are what speak to the result. That
+  is the honest limit of what a sweep can prove, and the table records it rather
+  than letting the row read as fully discharged.
+  **It was proven able to go red against the real corpus before being believed** —
+  three injected defects, one per shape the rule admits: a `localeCompare`
+  comparator in `red-record.ts`, a bare `.sort()` in `splice.ts`, and a
+  hand-rolled comparator in `merge.ts` that never reaches `byCodeUnit`. Each was
+  reported with its file, line and offending source. A gate asserting a property
+  that already holds everywhere has never been red and cannot become so until it
+  fires, so a negative control is not optional for it; a second scenario keeps
+  one in the suite permanently, including the case a line-wise scan gets wrong.
+  **Re-measuring the proposal's figures before building it changed two of
+  them**, which is the section's own rule and the reason it is worth restating:
+  the entry claimed 21 `.sort` call sites (there are **20** — the 21st was a
+  comment, which a regex counts and an AST does not), and two exceptions to
+  "names `byCodeUnit` on the call line" (there are **six**: one delegating to a
+  local `compareIds`, five inline arrows). The exception count being 3× what was
+  written is what made following local delegation part of the rule rather than a
+  footnote. The `localeCompare` figure moved the same way and in the direction
+  that matters most: **both occurrences in `src/` are comments explaining why it
+  is not used**, so a line-wise regex would have opened at 100% false positives.
+  Reading from the AST was the entry's own recommendation; it turns out to have
+  been the difference between a gate and a nuisance.
+  One shape the rule admits was not in the proposal and is worth naming:
+  `report.ts` sorts by `b.count - a.count || byCodeUnit(…)`. A numeric term is
+  legitimate, so the rule is "every comparator **reaches** the sanctioned one",
+  never "sorts only by code unit" — a stricter rule would have been red on
+  correct code the day it was written.
+
+### Fixed
+
+- **`attest check` answered `✓ No issues.` for a `*.reqs.ts` that does not
+  compile.** TypeScript's parser is error-tolerant by design: handed a file
+  truncated before its closing `});` it recovers the object literal and returns a
+  tree anyway, so the static reader read it as a *complete* registry and reported
+  nothing at all — while `--eval` on the same bytes said `registry-invalid`. Two
+  readers of one file disagreeing about whether it is even a file is the
+  condition the differential suite exists to prevent, and that suite could not
+  have caught it: it runs over registries that all compile. Nothing was looking
+  at `parseDiagnostics`, which is the one field that says so.
+  **The reach is three readers, not one**, because the tolerance belongs to the
+  compiler rather than to any reader: `parser.ts`, `static-registry.ts` and
+  `splice.ts` all open with the same `createSourceFile` call. The same half-saved
+  file was also a spec whose scenarios above the break still counted as coverage,
+  a delta whose ids `status` still reported, and — the site that writes rather
+  than reports — an insertion offset `attest apply` would have spliced a new
+  requirement into. All four now refuse it: the three readers as
+  `unreadable-file`, and the insertion point by returning the `undefined` it
+  already documents as its refusal to guess, because a write path that throws
+  mid-merge is worse than one that declines.
+  The diagnostic carries the **line** the syntax error is on, through both
+  shapes of refusal — the readers return it, and the spec parser carries it
+  through the throw its guard already catches. Without that second half the same
+  code would have had a line for a registry and none for a spec, for one
+  condition.
+  `unreadable-file` rather than a new code: `ATX-65` already states this
+  obligation for a file the parser cannot read, and the reader's situation is
+  identical — nothing in the file was checked, everything else in the run still
+  was. What `ATX-65` did not state is the *detection*, which is the whole of what
+  was missing; it was written for a parser that throws, and a parser that quietly
+  succeeds needs a different question asked of it.
+  **Syntactic only, and that is what makes it safe rather than merely narrow.**
+  `parseDiagnostics` is the parser's own list, so a type error, an unresolved
+  import and a name that does not exist are all absent from it — Attest does not
+  typecheck an adopter's project and this does not start. Measured over the 129
+  TypeScript files in this repository with every fixture included: zero carry a
+  parse diagnostic, so nothing valid today starts failing. The one reader left
+  deliberately tolerant is the id recovery added above, which runs only on files
+  a reader has already refused.
+
+- **Two scenarios named by a template literal were invisible to the static
+  plan.** `self/half-loaded.spec.ts` generated one scenario per command, and the
+  parser reads names from the AST — so `cover` counted one scenario where two
+  ran, and `archive`'s never-red gate could never have seen the second. Found
+  while binding the new requirement's roster to a scenario the plan declares.
+  Both are now one scenario looping the roster, which is the shape `ATX-64`
+  already used; the label on each `expect` is what the generated name was buying,
+  and it survives a failure. **The engine is not changed**: a name a static
+  reader cannot resolve is not a defect in the reader, and the failure it
+  produces on a requirement covered *only* that way is `uncovered-requirement`,
+  which is loud.
+
+### Changed
+
+- **One unreadable `*.reqs.ts` reported a finding per scenario that attested it,
+  and the finding was about the file.** The ids that file declares are missing
+  from the run, so every scenario covering one of them was an `orphan-test` —
+  measured on a registry of three requirements: six ERRORs, of which one was the
+  cause and five were its shadow, with the true finding at the top where the wall
+  of red pushes it out of view. Those scenarios are now reported once per
+  registry file as `orphan-from-failed-registry` (WARNING), naming the file, the
+  count and the ids; the same case is now two ERRORs and one WARNING. A WARNING
+  because the load failure is already an ERROR and is present whenever this is,
+  so no verdict moves and this cannot make a broken registry pass.
+  **What unblocked it was that the question was framed wrongly**, and the entry
+  under `Under consideration` had carried that framing for two releases: it asked
+  for a prefix→file mapping, which is exactly what a file that never parsed
+  cannot give — and could only have been recovered from the file *name*, which
+  this repository is its own counterexample to (`attest.reqs.ts` holds `ATX-*`,
+  the evidence that killed the prefix-matches-filename rule). The **ids** are
+  written in the source, and reading them back needs no naming convention that
+  nothing enforces. It is also strictly more precise than the prefix would have
+  been: a genuine typo sharing a prefix with the broken file stays reported.
+  Recall is partial and the direction of the miss is why that is acceptable — an
+  id not recovered keeps its `orphan-test`, so the report stays noisy and never
+  wrong. Measured over the ways a registry fails: a truncated file, a missing
+  default export, a non-literal value, a schema-invalid entry, a module that
+  throws at import and a spread from another module all yield their ids; only a
+  registry the file *computes* yields none, and that source contains no id to
+  find. The recovery is a source read that returns ids and nothing else — it
+  builds no registry, so it is not a second reader and cannot become the
+  evaluation fallback `registry-not-static` refuses.
+  Stated as a replacement rather than a suppression for the reason `ATX-62`
+  records about `spec-load-failed`: suppressing with nothing in its place trades
+  a wrong message for silence, and a wrong message beats silence.
+
+- **The hedged `orphan-test` advice added in `[0.7.0]` was applied to every
+  orphan in the report, including the ones it does not describe.** Any registry
+  file failing to load switched *all* of them to "a registry file failed to load
+  — fix that first, and add this id only if it is still unknown afterwards",
+  so a genuine typo was told to wait for work that has nothing to do with it.
+  The hedge now fires only where the uncertainty is real: when a failed file's
+  ids could not be recovered. When they all could, an orphan none of them claims
+  is genuinely unknown and gets the plain advice back.
+
+`SCHEMA_VERSION` is unchanged: a new `code` value is additive, and no envelope
+field moved.
+
 ## [0.7.3] - 2026-08-07
 
 ### Fixed
@@ -3647,33 +4289,116 @@ about itself, which is three things.
 **An entry can sit here for releases on the strength of a figure nobody has
 checked.** The discipline aims at keeping the *argument*, not at re-testing the
 evidence under it, so the first act of building one is re-measuring what it
-claims rather than implementing what it proposes. That has paid twice: once
-killing an entry outright, when the spans it rested on turned out not to be
-spans; once correcting an entry's headline number before a line of it was
-written. **What a release costs its adopters is not known on the day it is cut**
+claims rather than implementing what it proposes. That has paid three times:
+once killing an entry outright, when the spans it rested on turned out not to be
+spans; four times correcting an entry's own numbers or scope before a line of it
+was written — a call-site count that a regex had inflated, a cost filed as "a
+fixture per diagnostic" that the corpus put at one fixture, an injection whose
+payload turned out to need the target file's *own* quote character, which is the
+difference between escaping one quote and escaping the right one, and a fix
+filed as a map over `issues` that the report's own shape moved to the
+serialiser, four fields and one nesting level further out. **What a release costs its adopters is not known on the day it is cut**
 — several entries arrived from one adoption report, about shapes the tool made
 someone work around without ever erroring. And **the fixes with no observable
 symptom are worth batching**: individually none justifies a commit, together they
 cost about an hour, and they are the group no gate could have found, since having
 no symptom is the definition of what a gate cannot see.
 
-- **Binding the `✗` samples to fixtures whose rejection is asserted.** A sample
-  showing input the engine must *reject* can be bound the way a runnable one is,
-  to a fixture whose rejection is the thing under test — which is what
-  `fixtures/eval-invalid-registry` already is. This is the more valuable half of
-  what was once one entry with the region-marking below, because a counterexample
-  that quietly stopped being a counterexample is the one kind of stale sample
-  that actively teaches the wrong thing: a reader shown "this fails" about input
-  the engine now accepts is worse off than one shown nothing. It is also the
-  expensive half, needing a fixture per diagnostic, which is why it was never the
-  free part of that entry and is now the only part left in it.
-  *The mirror rule caps what can be claimed on the Chinese side.* `docs/zh/**`
-  matches `docs/en/**` down to the comments inside its code samples, so
-  byte-equality holds on one side only and the zh blocks stay translated prose
-  around the same code — the parity gate in `[0.4.3]` covers them, and it covers
-  structure, not meaning. The residual risk recorded with the whole-file half in
-  `[0.4.3]` — that the gate and the run proving the fixture still works live in
-  different suites — applies here identically.
+*The five entries this section carried before the one below* were built and are
+recorded under `[Unreleased]`. The second is where this preamble's own
+discipline paid again: it went in on an entry whose headline type
+measurement — instantiations unchanged — was false on re-measure, and the
+re-measure is the only reason the release notes do not repeat it. The fourth is
+the other outcome the discipline has, and worth a line because the first three
+were all corrections: the `render --out` symlink measurement reproduced exactly
+as filed, down to the leaf being safe for the reason given. What re-measuring
+added was not a correction but a **surface the entry had not counted** —
+`--check` reads the same destination, so the same link makes a freshness gate
+date a document outside the project. Re-measuring an entry is therefore not only
+a test of the number it quotes; walking the code the claim is about is what
+shows the claim's own edges. The fifth is that lesson arriving where an entry
+had already named its own fix: the C1 measurement reproduced exactly, and the
+repair it proposed — a map over `issues` — was still the wrong half, because
+four more fields and a nested scenario name carry the same untrusted text and
+never pass the envelope. An entry that ends with a fix is the one least likely
+to have its fix re-examined, which is the case worth naming.
+
+- **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.
 
 ## Under consideration
 
@@ -3687,60 +4412,6 @@ deletion. What each entry has to carry is the evidence currently blocking the
 decision, because that is what a re-proposal a year from now would otherwise
 have to gather again.
 
-- **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.
-  *What blocks the decision, and it is evidence rather than principle.* Whether
-  npm's trusted publishers accept a **gitlab.com-hosted** project on the plan
-  this package publishes under has not been verified against this project — it
-  was not checked when the provenance job was written, and an entry claiming it
-  works would be exactly the unverified confidence the rest of this file avoids.
-  It also cannot be tested except by publishing: as with provenance, there is no
-  dry run, so a failed experiment is a release. The cheap next step is reading
-  npm's current trusted-publisher documentation for GitLab support before
-  writing any YAML.
-
-- **A static sweep for the two properties claimed over the whole of `src/`.**
-  The quantifier table's first strict read left three rows wanting the same
-  thing, and the repo already owns the idiom: `tests/import-boundary.spec.ts` is
-  a sweep over the import graph asserting a cross-cutting property no runtime
-  test can see, written for the same reason — "only the graph shows it".
-  *The two candidates, and they are not equally shippable.* `ATX-15` is the easy
-  one: **no `.sort` outside `byCodeUnit`, and no `localeCompare`.** Measured over
-  `src/` today — 21 `.sort` call sites, every one reaching `byCodeUnit`, but only
-  19 naming it on the call line: `render.ts` goes through its own `compareIds`,
-  and `merge.ts` through a comparator that spans two lines. The only four
-  occurrences of `localeCompare` are comments explaining why it is not used. A sweep would have **zero false positives on the current corpus**,
-  which is the bar `divergent-param` failed and `compound-requirement` cleared —
-  and those two exceptions are already the warning that this needs the AST rather
-  than a line-wise regex, plus a rule for a comparator that delegates. `ATX-37` is the hard one: what it needs is "every project-derived
-  string interpolated into a terminal line goes through `inline`", and that is
-  not a token scan. The shape that would work is a scenario driving every
-  exported `format*` in `src/cli/report.ts` with hostile input — a real roster,
-  since the module's exports are what a new formatter joins — but each takes a
-  different argument type, so it needs a hostile fixture per signature rather
-  than one loop.
-  *What blocks the decision.* Two things, one per candidate. The `ATX-15` sweep
-  is cheap and precise and would be **the first rule in this repository that
-  polices how `src/` is written rather than what it does** — a lint rule wearing
-  a scenario's clothes, and the question is whether that belongs in `self/` (as
-  an obligation `ATX-15` already carries) or in `tests/` beside the import
-  boundary. Filing it under `ATX-15` makes it a permanent obligation with a
-  scenario; filing it in `tests/` makes it deletable in a green diff, which
-  `ATX-57`'s rationale argues against in as many words. The `ATX-37` roster is
-  blocked on cost rather than principle: eight formatters, eight fixtures, and
-  the honest count of what it buys is three currently-correct sites.
-  *Why neither is urgent.* Both properties hold everywhere today, verified by
-  reading. What is missing is not correctness but the thing that keeps it — and
-  the measurement above is what a re-proposal would otherwise have to gather
-  again.
-
 - **Bounding the fan-out in `findFiles` and `parseSpecs`.** Both walk the
   project with no concurrency limit: `findFiles` recurses through
   `Promise.all(subdirs.map(walk))`, so every directory in the tree is opened at
@@ -3942,100 +4613,8 @@ have to gather again.
   out below* — the entry is kept whole here because the two were measured in one
   pass and separating them is the finding.
 
-- **Whether `check` and `verify` should refuse a half-loaded registry the way
-  `cover` and `render` do.** Those two return early on `hasError(loadIssues)`,
-  and the argument is recorded at both call sites: a report computed from a
-  half-loaded registry is a lie, and a lie that reads as a pass is the worst
-  shape it can take — `cover` in particular used to answer `ok: true` on a repo
-  whose intent layer had stopped being readable, because an empty registry is
-  fully covered. `check` and `verify` carry on regardless.
-  *What that produces, measured* on a project with one unreadable `*.reqs.ts`:
-  a `registry-invalid`, then an `orphan-test` for **every** scenario belonging to
-  that file's requirements, plus `empty-spec`, `tests-red` and a
-  `declared-not-run` per scenario — six derived findings from one cause. Worse,
-  `orphan-test`'s fix hint ("Add it to the registry, or fix the id") is *wrong*
-  for an id already sitting in the registry that failed to load, so the loudest
-  advice in the report points at work that must not be done. In a multi-file
-  registry it scales with the broken file's scenario count, and the one true
-  finding is at the top where a wall of red pushes it out of view.
-  *Why it is not simply the same call as `cover` and `render`.* Each of those
-  produces exactly **one** artifact, and refusing to produce it is the whole of
-  the decision. `check` is the command a pipeline runs first and its contract is
-  breadth — returning three findings instead of nine because one of the nine was
-  a load failure makes it quieter about problems it can still see perfectly well,
-  which is the opposite of what it is for. `verify` has the same shape with a run
-  attached.
-  *What blocks the decision.* The narrower move — keep reporting everything
-  except the findings **derived from** the missing registry, i.e. suppress
-  `orphan-test` for ids whose prefix belongs to a file that failed to load —
-  needs a prefix→file mapping for a file that never parsed, and that is exactly
-  the file `loadRegistry` has no ids from. Recovering the mapping means reading
-  the prefix out of something other than the registry's own keys (the file name,
-  or a partial AST read that survives the failure), and whether either is
-  trustworthy enough to gate a suppression on is unmeasured. Suppressing on the
-  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* has been separated out and fixed; the noise has not.**
-  `[0.7.0]` changes `orphan-test`'s fix hint when any registry file failed
-  to load, so the loudest line in that report stops telling the reader to add an
-  id that already exists. That needed no mapping, because it claims nothing about
-  *which* orphans came from the broken file — only that the command cannot tell,
-  and what order to work in. It is worth separating because the two halves were
-  filed as one problem and are not: **being wrong** was fixable today at the cost
-  of a sentence, and **being loud** is the part still blocked on the mapping
-  above. The entry stays open on exactly that, with one blocker retired: the
-  measured six derived findings from one cause are still six, and only one of
-  them has stopped pointing at work that must not be done.
-
-- **A statement that quantifies over a surface, with scenarios covering only the
-  part that existed when it was written.** Found by reading, and it had already
-  cost something: `ATX-37` says "**everything** the CLI writes to a terminal —
-  a report, and the stack of a crash — MUST replace every control character",
-  and `self/report.spec.ts` covers `formatIssues` and `formatCrash`. Those were
-  the two functions that existed when it was written. `render` builds a document
-  by concatenation that never went past the sanitiser, and a registry could drive
-  the reviewer's terminal from `attest render` with no flag at all — shipped
-  under `[0.7.0]` as the fix, but the *shape* is not fixed and is not
-  specific to that requirement.
-  The shape: a universal quantifier in the statement, a finite set of scenarios,
-  and nothing anywhere that holds the two together. It reads as covered — the id
-  has scenarios, `cover` is green, `check` is green — and the quantifier is the
-  part no gate is looking at. Every one of the three mechanisms this project
-  sells operates *below* it: coverage asks whether an id has a scenario,
-  never-red asks whether that scenario discriminated, drift asks whether it reads
-  the params. None asks whether the scenarios span what the sentence claims.
-  *What blocks the decision.* Detecting it means knowing which surface a
-  statement names, which is prose judgement — the same judgement
-  `tests/intent-rule-candidates.spec.ts` records as the reason obligation
-  counting can never be an engine rule ("asserting a ground truth Attest cannot
-  compute for someone else's requirements, which is exactly what §0 refuses").
-  So the shippable form may not exist.
-  **The repo half has shipped, and this entry is now only about the engine
-  half.** `[0.7.0]` adds the `QUANTIFIED` table it described — hand-judged,
-  a row per flagged statement, every named scenario asserted to exist — and it
-  closed the way an entry built from a strict read is supposed to: it found a
-  live hole on `ATX-62`, the one requirement written specifically to avoid this
-  shape, where the archive gate path was claimed by the statement and asserted by
-  nothing. Two things came back that the entry did not predict. The useful one is
-  that "names a surface" splits three ways rather than two — `values`, `roster`,
-  `sites` — and only `sites` carries the risk, because a `roster` scenario
-  iterates the set the code owns and grows with it. That is a sharper statement
-  of the defect than "the scenarios do not span the sentence", and it is a rule
-  an author can act on: **prefer a quantifier a scenario can iterate.** The other
-  is that the remedy — rewriting the statement to name its surfaces, as `ATX-62`
-  did — takes it out of the flagged set, so the table has to allow rows for ids
-  the detector does not flag or it loses the binding exactly when the author does
-  the right thing.
-  *What stays open is the engine half, and nothing above touches it.* The three
-  kinds are prose judgement, the detector misses the article form ("A registry
-  that cannot be read MUST …") which is a universal too, and no rule can tell
-  which surface a sentence claims without being told. The repo half is a
-  counter-pressure, not a detector, and it holds for one registry whose authors
-  agreed to maintain it.
-
 - **Whether a requirement can ever be retired, and what it costs that none can.**
-  The registry is at 62 requirements and 160 scenarios, roughly 2.6 each, and
+  The registry is at **69 requirements and 192 scenarios, 2.78 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
@@ -4057,10 +4636,53 @@ have to gather again.
   requirement, where the scenario should move rather than go. Only the second is
   really about cost, and it is the one where deleting the intent to save the
   scenario inverts what the whole tool claims — that intent outlives its tests.
-  Nothing here is urgent while the number is 61. It is filed now because the
-  moment to write the argument down is while the reasoning is available, and
-  because a project whose requirement count only rises should have decided in
-  advance what would make one leave.
+  Nothing here is urgent at 69. It is filed now because the moment to write the
+  argument down is while the reasoning is available, and because a project whose
+  requirement count only rises should have decided in advance what would make
+  one leave.
+  *The figures above were restated on 2026-08-08, and how they were wrong is
+  itself the section's own warning happening.* As filed on 2026-08-03 this entry
+  said "62 requirements and 160 scenarios, roughly 2.6 each" while closing on
+  "the number is 61" — an inconsistency inside one entry, and the closing half
+  was the right one. Re-measured at the entry's own commit with the current
+  parser: **61 requirements, 156 scenarios**, so both opening figures were wrong
+  on the day they were written, and only the ratio survived. Measured the same
+  way today it is 69 and 192, and the method is the same one `verify self`
+  prints — the control is that today's `self/` counted this way returns exactly
+  what the runner does, which is what makes the 2026-08-03 number trustworthy. The
+  cheap way — `grep -c 'scenario('` — answers 211 against today's true 192, and
+  is what would have been reached for: comments and prose count, which is the
+  `ATX-15` error again.
+  **What moved in five days sharpens the argument rather than dating it.** +8
+  requirements and +36 scenarios, concentrated in three sessions rather than
+  accrued at a rate, so nothing here is a trend line. The part worth keeping is
+  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.
+
+- **Whether `isSafeChangeName` is wide enough on Windows, where the filesystem
+  strips trailing dots and spaces from a path component.** The guard's stated
+  test is path safety rather than a character whitelist, and it refuses `''`,
+  `'.'`, `'..'`, both separators and NUL. Win32 normalises `'.. '` to `'..'`
+  below the API, so a name that passes every one of those clauses could still
+  name the parent — and under `--eval` or `archive` the name reaches a module
+  path that is then executed.
+  **What is not known is whether that reproduces at all**, and it is the reason
+  this is here rather than in `Planned`. `path.win32.join` was checked on Linux
+  on 2026-08-09 and does *not* normalise it — `join('C:\\r\\changes', '.. ')`
+  keeps the space — so the whole question is what the Win32 layer does with the
+  resulting path, which no Linux measurement can answer. The repository's own
+  rule applies: say which half is unmeasured rather than describing it as
+  covered.
+  **Even granting it, the reach is one level.** `changes/<name>/…` with the name
+  eaten gives the project root, and going above it needs a second `..`, which
+  needs a separator the guard already refuses. So the outcome is executing a
+  file at another path *inside* the project, not an escape from it — which is
+  what keeps this an open question about the guard's completeness rather than a
+  filed defect. If it reproduces, the fix is one more clause of the same kind:
+  refuse a name that is empty, `.` or `..` after trailing dots and spaces are
+  trimmed. If it does not, the finding to keep is that the guard's clauses are
+  the POSIX spelling of path safety and the file should say so.
 
 ## Considered and rejected
 
@@ -4072,6 +4694,223 @@ it sat between 0.2.0 and 0.1.7 for two releases, where standing still meant
 sinking one version deeper each time a release was cut above it, and a rejection
 filed under a version reads as belonging to it.
 
+### Refusing a half-loaded registry in `check` and `verify`, the way `cover` and `render` do
+
+`cover` and `render` return early on `hasError(loadIssues)`,
+and the argument is recorded at both call sites: a report computed from a
+half-loaded registry is a lie, and a lie that reads as a pass is the worst
+shape it can take — `cover` in particular used to answer `ok: true` on a repo
+whose intent layer had stopped being readable, because an empty registry is
+fully covered. `check` and `verify` carry on regardless.
+*What that produces, measured* on a project with one unreadable `*.reqs.ts`:
+a `registry-invalid`, then an `orphan-test` for **every** scenario belonging to
+that file's requirements, plus `empty-spec`, `tests-red` and a
+`declared-not-run` per scenario — six derived findings from one cause. Worse,
+`orphan-test`'s fix hint ("Add it to the registry, or fix the id") is *wrong*
+for an id already sitting in the registry that failed to load, so the loudest
+advice in the report points at work that must not be done. In a multi-file
+registry it scales with the broken file's scenario count, and the one true
+finding is at the top where a wall of red pushes it out of view.
+*Why it is not simply the same call as `cover` and `render`.* Each of those
+produces exactly **one** artifact, and refusing to produce it is the whole of
+the decision. `check` is the command a pipeline runs first and its contract is
+breadth — returning three findings instead of nine because one of the nine was
+a load failure makes it quieter about problems it can still see perfectly well,
+which is the opposite of what it is for. `verify` has the same shape with a run
+attached.
+*What blocks the decision.* The narrower move — keep reporting everything
+except the findings **derived from** the missing registry, i.e. suppress
+`orphan-test` for ids whose prefix belongs to a file that failed to load —
+needs a prefix→file mapping for a file that never parsed, and that is exactly
+the file `loadRegistry` has no ids from. Recovering the mapping means reading
+the prefix out of something other than the registry's own keys (the file name,
+or a partial AST read that survives the failure), and whether either is
+trustworthy enough to gate a suppression on is unmeasured. Suppressing on the
+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.**
+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
+read that returns ids and builds nothing, so the failure modes that matter —
+a truncated file, a missing default export, a non-literal value, a
+schema-invalid entry, a module that throws at import — all give them up. The
+six derived findings from one cause are now two ERRORs and one WARNING, and
+the collapse is per id rather than per prefix, which is strictly more precise
+than what was blocked: a genuine typo sharing a prefix with the broken file
+stays reported. **The lesson is the entry, not the fix.** It sat here for two
+releases behind a blocker stated as "the mapping is unavailable", which was
+true and was about a mapping nothing needed; the evidence it carried was about
+the right problem and the mechanism it proposed was not, and nothing rereads a
+blocker that has already been written down. That is the same failure the
+section's own preamble records about a figure nobody re-checks, one level up:
+the *shape* of the proposal goes stale as quietly as its numbers do.
+*What is left of this entry is only the original question* — whether `check`
+and `verify` should refuse a half-loaded registry outright, the way `cover`
+and `render` do — **and the evidence that motivated it has been spent.** The
+argument for refusing was never the load failure itself; it was the wall of
+derived findings burying it, and that wall is gone. What remains is the
+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
+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
+because one of the nine was a load failure makes it quieter about problems it
+diagnoses perfectly well. `verify` is the same shape with a run attached.
+
+*What would reopen it*, stated because a rejection whose condition is unwritten
+gets re-proposed on a hunch: another finding found to scale with a **broken
+registry** rather than with the number of real problems. That is the shape that
+justified this once and could again; a merely noisy report is not.
+
+### An engine rule for a statement whose scenarios do not span its quantifier
+
+The shape was found by reading, and it had already
+cost something: `ATX-37` says "**everything** the CLI writes to a terminal —
+a report, and the stack of a crash — MUST replace every control character",
+and `self/report.spec.ts` covers `formatIssues` and `formatCrash`. Those were
+the two functions that existed when it was written. `render` builds a document
+by concatenation that never went past the sanitiser, and a registry could drive
+the reviewer's terminal from `attest render` with no flag at all — shipped
+under `[0.7.0]` as the fix, but the *shape* is not fixed and is not
+specific to that requirement.
+The shape: a universal quantifier in the statement, a finite set of scenarios,
+and nothing anywhere that holds the two together. It reads as covered — the id
+has scenarios, `cover` is green, `check` is green — and the quantifier is the
+part no gate is looking at. Every one of the three mechanisms this project
+sells operates *below* it: coverage asks whether an id has a scenario,
+never-red asks whether that scenario discriminated, drift asks whether it reads
+the params. None asks whether the scenarios span what the sentence claims.
+**Everything this entry established about the shape has left it, and the two
+halves left by different doors.** The repo half shipped in `[0.7.0]` as the
+`QUANTIFIED` table it described — hand-judged, a row per flagged statement,
+every named scenario asserted to exist — and it closed the way an entry built
+from a strict read is supposed to: it found a live hole on `ATX-62`, the one
+requirement written specifically to avoid this shape, where the archive gate
+path was claimed by the statement and asserted by nothing. What that table
+taught is now **design §11**, both languages, because it is a permanent
+property of the design rather than a candidate: which surface a quantifier
+ranges over — `values`, `roster`, `sites` — decides whether scenarios can keep
+up with it, only `sites` can silently stop being true, and the rule an author
+can act on is *prefer a quantifier a scenario can iterate*. The adopter-facing
+half of that rule is in the `init` skill beside the two `params` rules it
+completes. Neither was predicted here: the entry proposed a detector and
+expected a two-way split, and what came back was a three-way one and an
+authoring rule, which is the more useful object and needed no engine at all.
+The table's own trap is recorded with it — the remedy of rewriting a statement
+to name its surfaces takes it out of the flagged set, so the table must admit
+rows for ids nothing flags, or it loses the binding exactly when the author
+does the right thing.
+*What stays here is the engine half alone, and it is undecided rather than
+blocked-with-evidence.* Detecting this means knowing which surface a statement
+names, which is prose judgement — the same judgement
+`tests/intent-rule-candidates.spec.ts` records as the reason obligation
+counting can never be an engine rule ("asserting a ground truth Attest cannot
+compute for someone else's requirements, which is exactly what §0 refuses").
+The detector that exists flags the quantifier and nothing more, and it misses
+the article form ("A registry that cannot be read MUST …") which is a universal
+too. So the shippable form may not exist, and what §11 ships instead is a
+counter-pressure that holds for one registry whose authors agreed to maintain
+it. *What rejected it is a measurement that was already in the repository when this
+entry was trimmed, and went unread.* The inline snapshot in
+`tests/intent-rule-candidates.spec.ts` scores the detector against the real
+corpus: it flags **30 of 70** requirements, and of those 30, **21 are `values`
+or `roster`** — correct by construction, nothing for an author to do. A shipped
+WARNING would therefore fire on 43% of this registry and be wrong about 70% of
+what it fired on, with no way for the author to discharge it except by rewording
+the statement.
+
+*And rewording is both the evasion and the legitimate fix*, which is what makes
+the precision figure fatal rather than merely bad. `ATX-62` was improved by
+being rewritten to name its surfaces, and that rewrite takes it out of the
+flagged set by exactly the same mechanism a lazy reword would. The detector
+cannot tell them apart, so it grades the wording rather than the coverage. That
+is the failure design §11 records for every intent-layer detector tried — each
+"either saw almost nothing, or was cleared by deleting the word that triggered
+it" — and this one is squarely the second: `compound-requirement` sits
+at the other pole, never wrong and nearly blind, and the two together are the
+measured range of what a token detector over prose can do here.
+
+*What survives is not this proposal.* The three-way classification and the
+authoring rule are design §11, the adopter-facing form is in the `init` skill,
+and the hand-judged table is the counter-pressure that did survive measurement.
+Reopening this needs a signal that is not the quantifier token — the reach limit
+is the detector's input, not its threshold, so tuning it is the measurement
+bending to the corpus.
+
+### A precomputed analysis written to disk for the child run to read
+
+`@ark/attest` analyses the whole project once, writes it to
+`.attest/assertions/*.json`, and has the test process do position lookups
+against that file instead of a compiler — because its assertions need a full
+`ts.Program`, which cannot be afforded per test. The shape maps onto `verify`
+exactly: the parent parses registries and specs, then `runAndCollect` spawns a
+Vitest run that currently shares nothing with that work.
+*What rejected it is that the case for it was never made and the case against it
+is structural.* There is **no
+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 entry above measured `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
+that has just appeared, and it would do so silently. Any version of this needs
+an invalidation story stronger than a mtime before it is worth the seconds it
+saves, and the repo already has one cautionary precedent in the same
+direction — `bin/attest.js` loading `dist/` rather than `src/` is a cache with
+no invalidation at all, and it is in `CLAUDE.md`'s Gotchas because of how
+quietly it misleads. Note also what arktype gets wrong in the same file and
+what not to copy with it: the assertion cache and the queue of pending
+snapshot writes share one JSON document, so two things with unrelated
+lifetimes are invalidated together.
+
+*What would reopen it* is a measurement, and the entry names which one: a
+parse cost large enough to be worth a cache, on a real project rather than a
+synthetic tree. Until that exists this is a correctness hazard bought with
+seconds nobody has shown are being spent, and the invalidation story would have
+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
+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 —
+type instantiations down from **27,681 to 6,581**, check time 0.25 s → 0.14 s.
+
+*What rejected it is that both winners are collected by the wrong party.* Mini
+exists for tree-shaken bundle size in a browser. This ships as a Node CLI loaded
+from `dist/`, where bundle size is not a constraint on anything — apply the
+deletion test to mini's benefit and nothing in this repository changes. The
+instantiation saving is real but it is paid to **this project's own
+`pnpm typecheck`**, not to any adopter, and it is 0.11 s off a build already
+measured in seconds. The runtime saving is 3.2 ms against a 390 ms command.
+
+*And the cost lands on the file least able to afford it.* Mini's API is
+functional rather than chained:
+
+```ts
+params: z.record(z.string(), paramValue).default({})     // v3 / v4
+params: z._default(z.record(z.string(), paramValue), {}) // mini
+```
+
+`src/core/schema.ts` describes itself as the single source of truth for the
+shape of the intent layer, and it is written as one — the comments on
+`isPlainObject` and on the `params` union are longer than the code they sit
+over, because the file is read as a document by anyone deciding what a
+requirement may contain. Trading its legibility, and accepting an
+underscore-prefixed `_default` in it, buys 3 ms on a command nobody is waiting
+for.
+
+This reopens only if something makes bundle size a constraint here — a browser
+or edge build of the registry reader, which nothing currently proposes — and not
+on a faster benchmark, since the benchmark was never what was in doubt.
+
 ### Region-marked samples, so a partial quote could be bound too
 
 Decided **yes** and filed under `Planned`, then killed by building the count it
@@ -4302,6 +5141,46 @@ skill file. A pointer is cheap enough to be resident, it is their edit in their
 file, and it cannot go stale — the file it names is the one `init` keeps
 current.
 
+### A sweep driving every exported `format*` with hostile input
+
+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;
+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.**
+
+*Too wide.* Three of the eight exports cannot carry project-derived text at all:
+`summarize` and `formatScope` take `VerifyCounts`, which is four numbers, and
+`formatRepeats` prints a count, a `Level` and an `IssueCode` — both fixed
+rosters. A hostile fixture for those has nothing hostile to put in it, so a loop
+over the exports either forces three members that **cannot go red**, which is
+the defect this project ships a gate against, or carries an exclusion list —
+and an exclusion list is precisely what `ATX-15`'s sweep avoided by making the
+roster one the code owns.
+
+*Too narrow.* The statement is over everything the CLI writes to a terminal, and
+every site that has escaped it so far was outside this module: the `status`
+header was built and printed in `cli/index.ts`, the loader's writes are in
+`core/loader.ts`, and the `render` document that `ATX-58` was carved out for is
+in `core/render.ts`. A roster of formatters is neither necessary nor sufficient
+for the sentence, and the reading that made it look sufficient — that the
+formatters are the whole surface — is the exact assumption the `status` header
+falsified when it was found.
+
+*And the general form is the §0 wall.* "Every project-derived string
+interpolated into a terminal line goes through `inline`" needs to know which
+values are project-derived, which is prose judgement over a data flow. That is
+the ground truth `tests/intent-rule-candidates.spec.ts` records as the reason
+none of this can ever be an engine rule, and it does not become computable by
+being asked about this repository instead of someone else's.
+
+*What keeps the property instead* is the `QUANTIFIED` row itself — hand-judged,
+one entry per site, every named scenario asserted to exist. That is a
+counter-pressure rather than a detector, it holds for one registry whose authors
+agreed to maintain it, and after this change exactly one of its `ATX-37` sites
+is open. This reopens only if a site escapes that a roster of formatters would
+have caught, which none of the four so far would have been.
+
 ### A Codex target for `attest init`
 
 Evaluated when `init` grew `--target` and shipped for Claude Code, Cursor and
@@ -4386,6 +5265,8 @@ 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.
 
+[0.8.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.8.0
+[0.7.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.4
 [0.7.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.3
 [0.7.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.2
 [0.7.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.1