@am_shork/attest 0.7.2 → 0.7.4

package/CHANGELOG.md

@@ -13,6 +13,514 @@ 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.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
+
+- **A loader that never opened left its scratch directory behind — one per
+  `attest` invocation, i.e. one per CI build.** `createLoader` creates the
+  directory and writes the stub, and the only `rm` of it lives inside the `close`
+  of the object it returns — so nothing between those two points can be cleaned
+  up by anyone, because until the caller holds that object no `close` exists to
+  call. It is the exact leak the comment on `close` records as already fixed,
+  surviving on the other side of the same function. The window is now closed by
+  the function that opened it.
+  *Stated over the window rather than over `createServer`, which is where it was
+  found.* `writeFileSync` is inside it too, and a full disk or a temp directory
+  that turns read-only between the two calls reaches it with no project
+  involved — so scoping the repair to the call it was noticed at would have left
+  half of it.
+  *The trigger this was filed on does not reproduce, and that is the useful
+  half.* The entry proposed a malformed `package.json` at the root, on the
+  reasoning that `configFile: false` still leaves Vite reading it for `type`.
+  Measured: it starts a server cleanly, as do eight other shapes — a
+  `package.json` holding an array, one that is a directory, an unknown `type`, a
+  `node_modules` occupied by a file, a `node_modules/.vite` occupied by a file, a
+  `.env` that is a directory, a deleted root, and a well-formed control. Nine
+  candidates, zero throws. **`configFile: false` is why**, and it is worth
+  recording as a property rather than an accident: the option set chosen to stop
+  the loader reading a project's Vite config, and to stop it opening a socket,
+  also leaves almost no project I/O that can fail hard. The throw surface was
+  closed as a side effect of decisions taken for other reasons.
+  *So the repair is justified by ownership rather than by a symptom*, which is a
+  weaker case than this file usually accepts and is why the alternative was to
+  reject the entry outright. What decides it is the asymmetry of cost: the fan-out
+  entry below stays open because bounding concurrency changes how every run
+  behaves, whereas a `try` around a window nothing currently reaches changes
+  nothing observable on any path that exists. A resource whose ownership transfer
+  is conditional on nothing throwing is a shape, and the shape is what recurs.
+  *A cleanup that fails must not replace the error that caused it*, so the `rm`
+  swallows its own failure and the original throw propagates unchanged. The
+  regression test asserts the identity of what comes out, not its wording.
+  **`close` had the same hazard and now makes the same choice, which is a change
+  to an existing path rather than a new one.** Its `rm` runs in a `finally`, so a
+  failed cleanup replaced whatever `close` was doing — and all five callers in
+  `pipeline.ts` call `close` from a `finally` of their own, where the damage is
+  larger than symmetry: a real error on the way out is lost, and a *successful*
+  command becomes a crash about a temp directory. What that reader is handed is a
+  misdiagnosis pointing at their own correct files, which this project already
+  treats as worse than the gap it fills — the argument `ATX-49` records against
+  reporting a load failure as a wall of skipped scenarios, in a much smaller
+  place. Given up with it: the one signal a failed cleanup could have raised,
+  which no caller could have acted on.
+  *The test goes red without the fix, which is the only reason it is worth
+  having.* Verified by reverting `src/` and re-running: `expected [
+  'attest-loader-z7jhoK' ] to deeply equal []`, the leaked directory named in the
+  failure. It injects the throw at the module boundary — no project input could
+  produce one — and mocks `tmpdir` to a directory of its own, because on the
+  throwing path there is no loader to ask for its `scratchDir` and counting
+  `attest-loader-*` in the shared temp directory is the flake the lifecycle test
+  beside it already documents.
+  *It is its own file*, which is a rule this repo already wrote down and which
+  the first draft broke: `tests/locate-fanout.spec.ts` is separate because
+  `vi.mock` is file-scoped and it mocks a Node builtin, and the four lifecycle
+  tests boot the *real* Vite loader — sharing a module registry with a
+  `createServer` that throws is exactly what that convention exists to prevent.
+  The first attempt scoped the mocks with `doMock` and `resetModules` inside the
+  shared file instead, which is machinery bought to work around a constraint the
+  repo had already decided how to solve. Following it deleted the machinery.
+  *No new requirement, and the precedent cuts the other way, so it is worth
+  saying why.* `ATX-36` is the sibling property — what a live loader leaves on the
+  user's machine, stated as a count, with a scenario in `self/` — and "leaves no
+  scratch directory" is the same shape. What decides against filing one here is
+  that the success-path half has never had a requirement either, so a new one
+  covering only the throwing path would state half a contract and cost a
+  permanent scenario for the half nothing reaches. If it is ever filed it should
+  be filed whole, and that is a larger change than this fix.
+
+- **The `cmd.exe` guard in `tests/consumer.spec.ts` checked one character of a
+  class, and the comment above it claimed the quoting was doing work it cannot
+  do here.** `shellArg` asserted the argument held no `"` and then quoted only
+  when it held whitespace, so an argument with neither went to the shell bare
+  with `&`, `|`, `^`, `<`, `>`, `(` unexamined. Measured against the twelve
+  shapes: the old assertion let **11 of 12** through.
+  *What decided it, and it is the thing the entry this replaces did not have.*
+  That entry framed the choice as "widen the class, or fix the prose", and
+  argued that widening while leaving the prose is the change that looks like a
+  fix and settles nothing. Both halves turn on a fact neither named: **every
+  command this suite spawns is a `.cmd`**, which is the whole reason
+  `NEEDS_SHELL` exists, and a batch file expands `%*` into its own line *before*
+  anything parses it — so a metacharacter survives double quotes and is acted on
+  at the far end. That is the argument-injection hole Node closed in 22.x,
+  arrived at the long way round. So the quoting is not a defence that the
+  assertion merely backstops; **the assertion is the only defence**, and a
+  defence that covers one character of its class is the defect rather than the
+  prose being generous. Both are fixed together: the class is named, and the
+  comment now says the quotes do whitespace and nothing else.
+  *`%` and `!` are in the class for a different reason* — expansion rather than
+  syntax, and `!` only under delayed expansion, which the spawned shell does not
+  enable but a batch file can enable for itself. Neither costs anything to
+  refuse.
+  *The cost, which is real and is the right cost.* Windows permits `&`, `(` and
+  `%` in a user name, and `os.tmpdir()` sits under it — so on such a machine this
+  suite now stops with *"argument would need escaping, not quoting"* instead of
+  running. That is correct rather than a false red: through a batch target those
+  arguments genuinely are not safe, and the invariant the assertion guards is
+  that every argument is a literal flag or a path from `mkdtemp`. Stopping is
+  right even where quoting would have survived it, because the value is then not
+  the kind of value the helper accepts.
+  *What is measured, and what is not.* `pnpm test:consumer` was run on Windows,
+  where `NEEDS_SHELL` is true and the changed path actually executes: 11 tests
+  passed, none skipped — the distinction that matters, since the failure this
+  file's own comment records reported ten tests as *skipped* at zero run. CI is
+  Linux, where `shellArg` returns before the assertion, so the pipeline says
+  nothing about this either way. Not measured end to end: an argument carrying a
+  metacharacter actually reaching the guard, because no call site can produce
+  one — the class is verified as a predicate over the twelve shapes above and
+  the sixteen arguments the suite really passes, not by driving the suite red.
+
+- **A statement or rationale can no longer become HTML, or open a section of
+  its own.** `sanitised` is the entry §9.1 names and it strips control
+  characters and nothing else, so `statement` and `rationale` reached the
+  Markdown by concatenation exactly as written. Measured: a `rationale`
+  containing a newline and `## ATX-999` rendered a whole section — heading,
+  statement, `**Why:**` — for a requirement no registry holds, sitting between
+  two real ones and worded identically, with the overview table above it listing
+  three ids and the body carrying four sections. `<script>` and `<img onerror>`
+  survived the same way into a file that is committed and served. `check` and
+  `cover` saw nothing, because the id is in no registry, and `render --check`
+  could not object, because that *was* what the registry rendered to.
+  *Which of the three is intended, which is the part the fix had to decide.*
+  Marking prose up stays — `plain` escapes a param value precisely because the
+  value is data and the sentence around it is not — and that decision had never
+  been separated from allowing raw HTML or a heading. It is now a **fifth
+  obligation in design §9.1** rather than a patch at an emitter: prose may be
+  marked up, it may not become a tag, and it may not open a section. Stated as a
+  count over the document — one heading per requirement id — because what a
+  reader trusts is that a section means a requirement (`ATX-67`).
+  *Escaped rather than refused, on an asymmetry.* A rule that misses something
+  ships the document it ships today; a rule that fires wrongly makes a
+  legitimate rationale a hard error in the one command whose value is that it
+  always produces the document — the `ATX-29` argument about `--check` seen from
+  the other side. So there is no new diagnostic and no exit code moves.
+  *And escaped for the position, which is what keeps it lossless.* A code span
+  is literal text in every renderer, so `&lt;` written inside one is **visible**
+  — Markdown does not decode entities there, and this repository documents
+  `attest status <change>` in a statement. The scan therefore tracks spans and
+  leaves their contents alone, conservatively: a backtick run opens a span only
+  if a run of exactly that length closes it, and an unmatched run is text with
+  the defence still applied after it.
+  *One rendering change beyond the fix, and it is a repair.* A param
+  substituted inside the author's own code span was emitted as `**value**`,
+  which in a code span is two asterisks around the value; knowing the position
+  is what removes them. `SPEC.md` in this repository moves by 12 lines, all of
+  that shape — `` `**changes/<name>/first-run.json**` `` becomes
+  `` `changes/<name>/first-run.json` `` — and no `&lt;` appears anywhere in it,
+  which is the measurement that the span exception works on real prose.
+  *The defence had the defect it was written next to, and `ATX-59` gained a
+  third shape because of it.* The first code-span scan searched forward from
+  each backtick run for a run of the same length, so a rationale whose runs are
+  all of *different* lengths paid a scan to the end of the string for every one
+  of them: 500 KB cost 1.6 s and 2 MB cost 15 s, from `attest render` with no
+  flag, on text the registry chooses — the same "a registry must not decide what
+  rendering costs" defect the padded statement and the backtick-run param
+  already stand for. The runs are now read once and indexed by length, each
+  length holding a forward-only cursor, which is linear: 40 ms at 2 MB. It is
+  filed under `ATX-59` rather than here because the obligation is that one, and
+  it is worth saying where the site came from — the *defence another requirement
+  added*, which is the direction the next one will arrive from too.
+  *This leaves `Planned`.* The forged section was reproduced first, then the
+  four scenarios were run against the pre-fix renderer: three went red, and the
+  fourth — the setext underline, which heads the line *above* it — went green,
+  because counting `##` lines cannot see a heading that has no `##` in it. That
+  scenario was rewritten to assert the neutralised underline instead. A scenario
+  that cannot fail is the defect `archive` exists to catch, and it was caught
+  here only by running it against the old code.
+
+- **`attest init` no longer follows a symbolic link out of the project, and
+  refuses the whole run when a destination leads there.** `runInit` did
+  `join(root, target.file)`, `mkdir -p` and then the write, and nothing asked
+  whether the path was still under `root` once the filesystem had had its say.
+  A `.claude/skills/attest` planted in a repository as a link to anywhere the
+  user can write was followed by both: measured on Windows with a junction, a
+  file at the far end holding `USER OWNED FILE - DO NOT OVERWRITE` came back
+  holding the skill, and the report printed the relative path, so nothing on
+  screen said where it had gone. Every destination is now resolved segment by
+  segment before the first byte of any of them is written, and one that escapes
+  is an `unsafe-target-path` ERROR that writes nothing at all (`ATX-66`).
+  *What the exposure was, stated precisely, because two nearby things are not
+  it.* `writeAtomic`'s exclusive creation is not the gap and was never scoped to
+  be one: it defends the *temporary* path against a planted link, and it does
+  that perfectly in whichever directory the destination turns out to be. And
+  `workflowBody()` is a pure function of nothing, so no byte of the checked
+  project reaches the file — there is nothing to exfiltrate. What was exposed is
+  the **path**, which is `targets.ts`'s first scoping rule ("Attest owns the
+  path") having been an assumption rather than a check.
+  *Why the check is a resolution rather than a comparison.* `join` normalises
+  `..`, so a lexical containment test was already satisfied — the escape is a
+  segment that *is* a link, which only `realpath` can see. Containment itself
+  goes through `isInside` in `src/core/paths.ts`, asked as a relative path
+  rather than a string prefix: `/repo-backup` starts with `/repo`, and on
+  Windows a path on another drive has no relative spelling at all, so
+  `path.relative` answers with an absolute one instead of a chain of `..`. Both
+  read as contained under `startsWith`.
+  *The limit, recorded rather than papered over.* A link planted between the
+  resolution and the write is not caught, and no check outside the filesystem
+  can catch it. The exposure this closes is one committed to a repository, which
+  is the one a fresh clone and every merge-request checkout hands you.
+  *Behaviour change:* an `init` that used to write through such a link now
+  fails with exit 1. The only input that reaches it is a path that was already
+  leaving the project. The JSON surface is unchanged beyond one more `code`
+  value, which is additive — no `SCHEMA_VERSION` bump.
+  *This leaves `Planned`*, where it was filed with the measurement above; the
+  first act of building it was re-running that measurement, and it reproduced.
+
+### Changed
+
+- **The guidance now draws the line between a literal that is drift and a literal
+  that is a pin — the shipped text forbade the only defence against a shortened
+  domain.** `[0.7.2]` fixed the repo half: every param a scenario iterates gained
+  a literal pinning its extent, after three of that release's four green
+  mutations turned out to be a domain silently losing cases rather than the
+  tautology the experiment was looking for. The user-facing half was held back,
+  and it was not merely absent. The `init` skill's "Four things you must not do"
+  says **"Do not hardcode a value that lives in `params`"**, and the pin every one
+  of those fixes adds is, read literally, exactly that. An adopter who writes a
+  roster param — which the design actively pushes them toward, since a quantifier
+  a scenario can iterate is the shape `QUANTIFIED` recommends — was being handed
+  an instruction that forbids the only thing standing between them and a run that
+  covers less every time someone edits the list.
+  *The distinction is real and one sentence long*, and it is now drawn in all four
+  places the claim is made: the rule is about the **expectation** the system is
+  measured against, and the pin asserts what the **intent** is. A list a scenario
+  loops over is not a value under test — it is the set of cases the run covers,
+  so dropping a member removes a case while every assertion inside still passes,
+  with the expectation as independent as it ever was. That is why the `[0.5.0]`
+  rule (*the expectation must not be a function of the param the code under test
+  consumed*) does not reach it, and why a literal is the **only** independent term
+  available: anything derived from the list shrinks with it, so a length assertion
+  written as a function of the list is true at every length.
+  *Where it landed, and why it is four documents rather than one line appended.*
+  README §"killer move", the `init` skill (a sibling bullet in the model section
+  and a carve-out inside rule 3 itself, where the contradiction was), the
+  `possible-drift` troubleshooting section with a worked ✓/✗ pair, and design §11
+  as a residual weakness beside the tautology bullet it shares a gap with — both
+  languages. `[0.5.0]` records the reason this shape of change is done in one
+  deliberate pass rather than incrementally: it is the central claim of the tool
+  being reworded, and the last time it was split the halves disagreed.
+  *No engine change, and none is proposed here.* Nothing in this is detectable —
+  which surface a statement claims is prose judgement, the same judgement §11
+  already records as the reason obligation counting can never be an engine rule.
+  The counter-pressure that exists is a hand-judged table, and §11 now says so,
+  including what it cannot reach: a domain whose size is carried by a scalar.
+  *This leaves `Planned`*, where it was filed with the measurement above; the
+  measurement was already taken, and what it needed was the pass.
+
+- **The release publishes through `pnpm` again, and the check that read the
+  attestation back is gone.** Two corrections to the provenance job shipped in
+  `[0.7.2]`, both from what the first real tag pipeline showed.
+  *`pnpm publish --provenance` works on the pinned 10.28.0; the claim that it
+  did not was read off `pnpm publish --help`, where the flag is absent.* The
+  parser knows it — `--provenanceX` is rejected with *"Did you mean
+  'provenance'?"*, and `--provenance --dry-run` runs clean. A help text is a
+  document, not the interface; checking a flag means asking the parser. So the
+  job is pnpm like every other job here, `--no-git-checks` comes back with it
+  (pnpm inspects the branch, CI builds tags in detached HEAD), and
+  `COREPACK_ENABLE_STRICT=0` goes away, since it existed only so a bare `npm`
+  could run under a `packageManager` that pins pnpm.
+  *The post-publish check failed the 0.7.2 release, and the publish it failed
+  was correctly signed.* Six attempts over a minute all got a 404 from the
+  registry's attestation endpoint; the same endpoint now serves
+  `slsa.dev/provenance/v0.2` for `0.7.2`. Lengthening the budget was the wrong
+  repair, and the entry it replaces already contains the reason without drawing
+  the conclusion: the check runs *after* an irreversible step, so its red cannot
+  be cleared — the republish that would rerun it fails `EPUBLISHCONFLICT` on a
+  version that now exists. Every failure it can reach is therefore either a
+  false one or an unfixable one, on a job nobody can make green again, which
+  makes it a machine for teaching that red is routine — the exact habit the
+  `audit` job's comment refuses. A gate has to sit where the answer can still
+  change what happens. Verification moves to where it can: `npm audit
+  signatures` in an installing project, or the package page's Provenance panel.
+  *What is unchanged:* the attestation itself, the three preconditions, and the
+  fact that npm rejects the publish rather than degrading to an unsigned one if
+  any is missing. `0.7.2` is signed, and shipped signed, despite the red job.
+
 ## [0.7.2] - 2026-08-07
 
 ### Added
@@ -3365,91 +3873,17 @@ 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; twice correcting an entry's own numbers before a line of it was written —
+a call-site count that a regex had inflated, and a cost filed as "a fixture per
+diagnostic" that the corpus put at one fixture. **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.
 
-- **Telling adopters about the domain trap, which the shipped guidance
-  currently walks them into.** The repo half landed under `[Unreleased]`; the
-  user-facing half has not, and it is not merely absent. `skill.ts`'s "Four
-  things you must not do" says **"Do not hardcode a value that lives in
-  `params`"**, and the pin every fix in that entry adds is, read literally,
-  exactly that. An adopter who writes a roster param — which the design
-  actively pushes them toward, since a quantifier a scenario can iterate is the
-  shape `QUANTIFIED` recommends — gets an instruction that forbids the only
-  defence against shortening it. The distinction is real and one sentence long:
-  the rule is about the **expectation** the system is measured against, and the
-  pin asserts what the **intent** is. Nothing shipped draws it.
-  *Why it is filed rather than done in the same pass.* It reaches README §"killer
-  move", the `init` skill, `possible-drift`'s troubleshooting section and design
-  §11, in both languages — the same surface `[0.5.0]` rewrote, and that entry
-  records the lesson: rewording the central claim of the tool is not a line
-  appended, and it was held back once precisely so it could be done deliberately
-  and in one pass. The measurement it needs is already taken; what it needs next
-  is the pass. *Not* a `possible-drift` change: nothing here is detectable by
-  the engine, for the reason the entry below gives about prose judgement.
-
-- **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.
-
-- **`render`'s document can carry raw HTML and a forged requirement section.**
-  `sanitised` is the entry §9.1 names and it strips control characters and
-  nothing else, so `statement` and `rationale` reach the Markdown by
-  concatenation exactly as written. Measured: a `rationale` containing newlines
-  and `## ATX-999` renders a whole section — heading, statement, `**Why:**` —
-  for a requirement no registry holds, sitting between two real ones and worded
-  identically; `<script>` and `<img onerror>` survive the same way. `check` and
-  `cover` see only the real id, and `render --check` cannot object, because that
-  *is* what the registry renders to now.
-  *Not an accepted risk, which is the part worth pinning.* §9.1 and the
-  reference both scope their guarantee to control characters, and the
-  reference's heading over that paragraph is "Safe to read, and safe to keep",
-  with "a site generator" named in the threat it describes. What *is* a decision
-  is that prose may be marked up — `plain()` escapes a param value precisely
-  because it is data while the statement around it is not — and that decision
-  has never been separated from allowing raw HTML or a heading. So the entry is
-  as much about stating which of the three is intended as about the escaping,
-  and if the answer is that Markdown stays and HTML and headings go, that is a
-  fourth obligation in §9.1 rather than a patch at an emitter.
-
-- **`attest init` follows a symlink out of the project root.** `runInit` does
-  `mkdir(dirname(dest), { recursive: true })` and then `writeAtomic`, and
-  neither asks whether `dest` is still under `root`. A `.claude/skills/attest`
-  planted in the repository as a link to anywhere the user can write is followed
-  by both: measured on Windows with a junction, a file at the target holding
-  `USER OWNED FILE - DO NOT OVERWRITE` came back holding the skill. The report
-  prints the relative path, so nothing on screen says where it went.
-  *`write.ts` is not the gap and neither is `targets.ts`'s content.* The `wx`
-  flag defends the *temporary* path against a planted link and does exactly
-  that; the destination's directory was never in its scope. And `workflowBody()`
-  is a pure function of nothing, so no byte of the checked project reaches the
-  file — the exposure is the path, not the content, which is `targets.ts`'s
-  first rule ("Attest owns the path") being an assumption rather than a check.
-  The check belongs beside `resolveTargets`, which is already all-or-nothing for
-  the same reason: a name known to be unwritable must not leave half a set
-  behind.
-
 ## Under consideration
 
 Candidates with **no decision yet**, between the two sections either side of it
@@ -3463,7 +3897,7 @@ 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 `[Unreleased]` signs the release but does not change
+  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,
@@ -3481,41 +3915,6 @@ have to gather again.
   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
@@ -3751,17 +4150,34 @@ have to gather again.
   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.
+  **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.
+  It stays here rather than moving down because "the reason to do it was
+  removed" is not the same as "it was decided against", and the case would come
+  back the moment another finding is found to scale with a broken registry
+  rather than with the number of problems.
 
 - **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
@@ -3810,7 +4226,7 @@ have to gather again.
   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
@@ -3832,45 +4248,29 @@ 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.
-
-- **The `cmd.exe` quoting in `tests/consumer.spec.ts` guards one character of
-  several.** `shellArg` asserts the argument holds no `"` and then quotes only
-  when it holds whitespace, so an argument with none goes to the shell bare —
-  and `&`, `|`, `^`, `<`, `>`, `(` are metacharacters there that the assertion
-  does not name. The fix is one character class, which is why the entry is not
-  about the fix.
-  *What blocks the decision is that no input reaches it.* Both arguments are
-  either a literal flag or a path from `mkdtemp`, `NEEDS_SHELL` is win32 only
-  and CI is Linux, and the one path an attacker could plausibly influence — the
-  checkout directory on a fork MR pipeline — comes from a GitLab project path,
-  whose character set excludes every metacharacter above. So this is an
-  observation with no attack path, and the honest question is not whether to
-  widen the class but whether the comment above it should stop claiming more
-  than the assertion covers: it says "the assertion keeps that true" about
-  arguments generally, where what it checks is one character. Widening the class
-  and leaving the prose is the change that would look like a fix and settle
-  nothing.
-
-- **A loader that fails to start leaves its scratch directory behind.**
-  `createLoader` calls `mkdtempSync` and writes the stub *before* `createServer`,
-  and the only `rm` of that directory is inside the `close` of the object
-  `createServer` returns — so a throw from it leaks one `attest-loader-*` per
-  invocation, which on a CI runner is one per build. That is the exact failure
-  shape the comment on `close` records as already fixed, surviving on the other
-  path.
-  *What blocks it is that nothing has been made to throw there.* With
-  `configFile: false` Vite still reads the `package.json` at the root to decide
-  `type`, so a malformed one in the checked project is the obvious candidate and
-  it is the project's to write — but it was not tried, and an entry claiming a
-  trigger it has not seen is the thing this section exists to not accumulate.
-  The repair is three lines (a `try` around the two calls that `rm`s and
-  rethrows) and is not what the decision turns on; measuring whether the throw
-  is reachable at all is, because if it is not, this is a leak with no input
-  that produces it.
+  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.
 
 ## Considered and rejected
 
@@ -4112,6 +4512,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
@@ -4196,6 +4636,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.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
 [0.7.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.0