@am_shork/attest 0.9.1 → 0.9.3

package/CHANGELOG.md

@@ -13,6 +13,276 @@ input, removes/renames a public API or `--json` field, or changes a default
 runtime behavior an existing invocation relies on — diagnostic message text is
 not API.
 
+## [0.9.3] - 2026-08-18
+
+### Added
+
+- **The archive is read back, as `inspectRedEvidence` on `@am_shork/attest/inspect`
+  (`ATX-80`).** `archive --apply` moves each merged change into
+  `archive/<date>-<name>/`, carrying `proposal.md`, the delta and the record of
+  how every one of its scenarios ended the *first* time it ran — and nothing
+  read any of it. The only store here that keeps a decision with its evidence
+  attached was write-only. It now answers, for each scenario a project declares,
+  which of `fail` / `pass` / `unobserved` / `unarchived` the archived records
+  place it in. Promoted from `Planned`, where the blockers were an archive
+  nobody had produced and an entry point nobody had chosen.
+
+  *The question the entry was promoted with was the wrong granularity, and
+  finding that is most of what this change is.* It asked which **requirements**
+  ever had a scenario observed failing. Under the gate as written that is true
+  by construction for every archived id — `neverRedIssues` walks *every*
+  scenario of every ADDED id and blocks on any one without a recorded red, so a
+  change that archived at all archived with the whole set proven. Where the gate
+  genuinely stops is one level down, and it leaks two ways: a scenario grown
+  onto a requirement after it archived can never acquire evidence, because
+  `never-red` fires only on ids a change is currently ADDing and an archived id
+  is ADDed by nothing again; and MODIFIED carries no such obligation at all, so
+  a requirement whose statement is later rewritten keeps evidence only for the
+  form it had when it archived. Both accumulate silently. The report is
+  therefore over `(reqId, file, name)`, which the record already keys by.
+
+  *Four states rather than two, and the two absences are the whole design.*
+  `unarchived` — the id is in no archived change at all — is a requirement
+  written straight into the registry, which is how existing behaviour is
+  described in a brownfield adoption and which design §6 gives no obligation to
+  have been red. `unobserved` — the id **is** archived and this scenario is not
+  in the record — is the drift above. Folding them together would report a
+  design working exactly as intended as though it were a backlog, and on a
+  first-day adoption that is every row. `pass` stays separate from both because
+  the gate cannot produce it, so an archived one means a hand-edited record or a
+  format that moved.
+
+  *Two things it deliberately does not do.* It does not judge: whether an
+  `unobserved` scenario matters is a judgement about that scenario, which is the
+  ground truth §0 refuses to compute for someone else. And it does not hand back
+  the records — the archive read returns rows, because the record is a nested map
+  keyed by ids, paths and scenario names read off disk, and exporting the
+  container would export the prototype hazard `red-record.ts` exists to hold.
+
+  *`proposal.md` is not read, and that is the blocker dissolving rather than
+  being cleared.* The prose half was filed as the one carrying the reasoning.
+  In this repository it carries a link: `CLAUDE.md` makes `CHANGELOG.md` the
+  single decision record, so a proposal restating an argument would be a second
+  store of it with nothing comparing the two. There is nothing in it for an
+  index to offer but its path.
+
+  *The three scan exclusions are untouched.* `locate.ts`, `runner.ts` and
+  `pipeline.ts` each still exclude `archive/`, and they are §7 and §8 — an
+  archived change's requirements and specs must not re-enter a normal run. The
+  new read walks the archive for facts *about* archived changes, never to fold
+  their contents back into a registry or a plan.
+
+  *Blocker **(2)** is settled against the fifth static command, on the roster's
+  own terms.* `ATX-16`'s subject is reading TypeScript *without evaluating it* —
+  its rationale is about a top-level `fetch` in a registry file reaching CI
+  secrets on a fork merge request. `first-run.json` is JSON; joining that roster
+  would quietly turn a security promise into a list of commands that do not run
+  the suite. The trial datum that seemed to point at a command measured demand
+  to read the archive **as prose**, which is a different question. And the
+  direction is reversible: adding a command later is additive, narrowing a
+  requirement's roster back is not. Two things measured while deciding —
+  `archive.ts`'s runtime closure names no `vite`/`vitest`, so `ATX-79`'s
+  peer-free promise holds over the new reachability; and `intent-quality.md`
+  already exists for findings of exactly this kind, where `cli-reference.md`
+  has no place to state one.
+
+  *What it cost elsewhere, because it is the part that does not announce
+  itself.* The fixture that exercises all four states adds a registry, and the
+  judgement tables in `tests/intent-rule-candidates.spec.ts` score the fixtures
+  too — so the corpus moved 87 → 90 and four measurements were re-read rather
+  than re-baselined. `ATX-80` is judged compound (2), and `compound-requirement`
+  flags it correctly; its quantifier ranges over values, the shape that table
+  prefers; `ATX-80.states` is an iterated domain and carries its pin. One new
+  divergence needed judging — `states:ATX-32,ATX-80` — and it is worth a line
+  because of how it arrived rather than how it reads: two reports each naming
+  their own closed set of labels, neither author aware of the other, which is a
+  second generic param name starting the climb `code` made to nineteen members.
+  The count of judgements a shippable `divergent-param` would demand grows with
+  the registry, from nothing anyone did wrong.
+
+  *Mutation-checked, and one assertion did not survive it.* Every new test was
+  run against a deliberately broken implementation. The one pinning archived
+  folder order passed with the sort deleted, because `readdir` returns names
+  already ordered on Windows — the fixture-with-no-separator shape from the
+  `Fixed` entry below, arriving in a new test on the day it was written. Fixed
+  by choosing names where the two orders differ, measured rather than assumed,
+  with the casing called out in the test so it is not tidied away.
+
+  *One more scenario, added before cutting a release, and writing it corrected
+  the reason it was added.* Every state above was read out of a hand-written
+  `first-run.json` at a folder this repository spelled, so the reader had never
+  met an archive the tool itself produced. `self/merge.spec.ts` now runs
+  `--apply` for real and joins the result: the folder is the one the run's own
+  date stamp named, and the report's paths are derived from whatever it picked.
+  Mutation-checked to be worth its runtime — an enumeration that finds nothing,
+  and the two absences folded into one, each fail it and no other scenario in
+  that file.
+
+  **The risk it was written to close turned out not to exist, which is the more
+  useful half.** The reason given for it was the proposed → merged rename: the
+  record is written while the spec is `*.proposed.spec.ts` and `--apply` renames
+  that file, so `fileKey` is what keeps the two meeting. Reading the code to
+  write the assertion showed the archive reader cannot exercise that at all.
+  `recordedOutcome` normalises the **ref**, and the record is keyed in merged
+  spelling from the start — so by the time a change is archived, every ref this
+  reader passes is already post-merge and `fileKey` is the identity on all of
+  them. The translation exists for the gate reading a record mid-flight, and the
+  archive reader is downstream of the point where it can matter. The scenario
+  stays, for what it does cover; the claim it was justified with is written out.
+
+  *A hazard found by running the mutations, worth recording because nothing
+  reports it.* Stubbing `mergedSpecPath` and running the suite **rewrote two
+  committed fixtures** — `fixtures/e2e-archive` and `fixtures/stdout-pollution`
+  each hold a `first-run.json` that a real archive run rewrites in place, so a
+  mutation run leaves the working tree dirty with plausible-looking changes to
+  files nobody edited. Caught by `git status`, not by any gate. It also settles
+  the write half by accident: those records really are produced through
+  `fileKey`, because under the stub they came out keyed by the proposed
+  spelling.
+
+- **The propose stage now asks three questions, where it previously said how to
+  write a delta and nothing about what to check you had thought about.** They sit
+  at the end of Stage 1, immediately before the instruction to present and stop:
+  what pins each expectation, does each statement carry one obligation, and was
+  any of this ever red. Promoted from `Planned`, where the blocker was the
+  selection rather than the idea — spec-kit's `clarify` carries nine generic
+  categories, and copying them wholesale was the specific thing to avoid, because
+  §10's economics put every line of that document into every adopting project's
+  agent context forever.
+
+  *The selection is by what this repository has actually been bitten by*, which
+  is a different list from a product-spec taxonomy. **(1)** is the measured one:
+  the mine-density band moved 3.3× with the whole suite green because the
+  assertion recomputed its expectation from the param the code under test
+  consumed — the entry still under `Under consideration`, whose *guidance* half
+  shipped in `[0.5.0]` as a statement in *The model*. What is new here is asking
+  it as a question at the moment the assertion is being authored, which is a
+  different mechanism from stating the rule 80 lines earlier in the same file.
+  **(2)** is measured too: 34 of this repository's requirements carry more than
+  one obligation, so the question is doing work no shipped diagnostic does — and
+  deliberately names no code, because none exists to name. **(3)** answers what
+  the archive gate structurally cannot ask: `never-red` demands a recorded
+  failing run only for the ids a change ADDs, so a requirement written for
+  behaviour already shipped never had a moment when it should have failed.
+
+  *Two more went to `CLAUDE.md` instead*, and that split is the finding the entry
+  did not anticipate — the checklist wanted two destinations, not one. Crossing a
+  platform boundary, and whether a change leaves `check`, `cover`, `render` and
+  `status` executing nothing, are about this engine's internals; shipping them
+  would have been the dead weight the cost argument was worried about without
+  being able to name.
+
+  *Re-measured before building, per the discipline that section runs on, and the
+  claim held exactly*: the document was 405 lines with Stage 1 at 87–255, still
+  exactly 169. **The cost claim did not hold, and the entry's own number was
+  wrong.** It priced this at "three lines rather than nine" by counting one line
+  per category, which is what nine generic categories would have cost as a bare
+  list. Three questions with the clause each needs to be answerable cost **eight**
+  lines: Stage 1 is now 177 and the document 413. Still under half of what the
+  nine would have been, so the argument survives its own number being off, but the
+  number is corrected here rather than quietly restated.
+
+  *And the question the entry left open is answered: no new `ATX-n`.* The
+  document's content is gated only by `ATX-57`, which asks that every diagnostic
+  code it names be one the engine can emit — and asking *what this makes
+  reachable for the first time* is what that check turned into here: the only
+  hyphenated code-voice token the three questions add is `never-red`, which the
+  document already named. What they earn instead is **one scenario on `ATX-27`**,
+  which already obliges the body to carry the workflow rather than a pointer to
+  it. A requirement of their own would make every rewording of three sentences a
+  registry change; no assertion at all would leave a checklist with no diagnostic
+  behind it able to be dropped in silence — the same decay shape as the fixture
+  assertion fixed below, which is what decided it.
+
+### Fixed
+
+- **The assertion guarding the one fixture that exercises a path separator
+  passed on a corpus with no separator in it.** `CLAUDE.md` says not to flatten
+  `fixtures/nested-spec/`, because its spec is the only one that sits below a
+  root and a relative spec path becomes the child run's `include` glob, where a
+  backslash is an escape character. What stood behind that instruction was
+  `tests/paths.spec.ts` scanning the fixture and asserting that no relative path
+  contains a backslash — and a flat filename contains no backslash either, so
+  flattening the fixture would have left the test green while removing the only
+  thing it was there to exercise. The rule with a written warning against silent
+  decay was guarded by an assertion that decayed silently.
+
+  Now a second assertion requires the scan to find a spec below the root, which
+  is the property the fixture exists for. Checked against a flattened copy
+  before being written: the predicate is true on the fixture as committed and
+  false on the same files laid flat.
+
+  *Found by the `CLAUDE.md` audit filed under `Considered and rejected`*, whose
+  answer to "which of these rules should become requirement ids" was none — this
+  is the one actionable thing it turned up, and it is a plain test rather than an
+  `ATX-n` because it is a property of this repository's fixture corpus and not a
+  promise Attest makes to anyone.
+
+## [0.9.2] - 2026-08-17
+
+### Added
+
+- **`@am_shork/attest/inspect`: read what a project declares, without executing
+  it and without acquiring the runner peer.** One function,
+  `inspectProject(root)`, answering the requirements a project declares, the
+  scenarios declared for each, and the issues that stopped a file being read.
+  Nothing about the quality of any of it — that is the ground truth this project
+  refuses to compute for someone else's requirements (design §0).
+
+  *Why it exists rather than what it does.* Everything this repository knows
+  about the quality of its own intent layer is a hand-judged table in
+  `tests/intent-rule-candidates.spec.ts`, and the check that keeps such a table
+  from rotting is that a scenario a row names is one a spec really declares. An
+  adopter could not write that check: the package exported the authoring API and
+  nothing else, so `parseSpecs` and the static registry read were internal and
+  **the scenario names of their own project were unreachable** — not
+  undocumented, unreachable. This is the enabling half of the judgement-table
+  proposal under *Under consideration*, and deliberately only that half: it
+  ships no schema and decides nothing, and it is the only thing that can produce
+  the second table that proposal is waiting for.
+
+  *One function, not the four internals it composes,* because `loadRegistry`
+  takes a reader and which of the two runs is a security property fixed by the
+  command, never chosen by a caller (design §5.1). The static reader is welded
+  in and no parameter can change it.
+
+  *And its import closure names neither runner peer,* so a consumer that only
+  analyses acquires neither `vite` nor `vitest` — the same argument `./define`
+  was added on (design §10). Measured on the built entry: ten modules, and the
+  only bare specifiers in the closure are `typescript`, `zod` and two node
+  builtins. That claim is gated over the **built** package rather than the
+  source, because `locate.ts` names `loader.ts` in a type-only import that the
+  emit erases: the two graphs differ by exactly that edge, and it is the edge
+  the promise is about. `tests/import-boundary.spec.ts` holds the source side,
+  where a type-only mention still counts as *naming* the runner, and its
+  reachability walk now follows runtime edges only for the same reason.
+
+  Additive: no command, flag, exit code or `--json` field changes, and nothing
+  that used to pass now fails.
+
+- **"Judging your own intent layer" (`docs/{en,zh}/intent-quality.md`): the four
+  things no gate is looking at, and a method for building your own
+  counter-pressure out of them.** For an existing adopter, on the back of the
+  export above.
+
+  *A method with no template, and the omission is the point.* The page states
+  the four **findings** — coverage is binary so lumping is free, a quantifier is
+  unread, an iterated `params` list is a run's domain, an assertion can echo
+  rather than pin — and the two **mechanical properties** that make a
+  hand-judged record a counter-pressure rather than a note: completeness
+  (something enumerable must force a row) and rot-binding (a scenario a row
+  names must be asserted to exist). Both generalise without assuming a single
+  column. What it withholds is this repository's own answer — the four tables
+  in `tests/intent-rule-candidates.spec.ts` — and it asks a reader to reach that
+  file only after doing the hand pass, saying why rather than hiding it: there
+  is one such table in existence and its author wrote both the schema and every
+  answer in it, so a second one built from someone else's corpus is evidence
+  while one built from ours is an echo. That is the fourth finding turned on the
+  question itself.
+  The worked example is deliberately **one column**, so the shape that comes
+  back is not a copy of the shape that went out, and the report the page asks
+  for names the thing worth most: *the column you needed that we do not have.*
+
 ## [0.9.1] - 2026-08-13
 
 ### Changed
@@ -5069,6 +5339,10 @@ have to gather again.
   **changing the value of an existing param goes through no gate at all.**
   `archive` gates a change; a param edit is not a change. That is a cleaner
   statement of the gap than "params can be tautological".
+  **That observation is now its own entry at the foot of this section**, split
+  out and measured on 2026-08-18, because it asks what happens when a value
+  moves rather than whether an assertion is a real comparison, and neither
+  answer settles the other. What stays here is the detector.
   *What blocks the decision — three things, all of them real.* **(1)** Every
   mutation above is synthetic. Across 8 commits touching `*.reqs.ts` in that
   repo, **no param value was ever modified** — every `params:` line in every diff
@@ -5082,7 +5356,21 @@ have to gather again.
   far past the two registry readers' current surface. **(3)** No mechanism is yet
   known that separates "the assertion pins this independently" from "the assertion
   echoes it" without executing the scenario twice under different values — which
-  is mutation testing, a much larger thing to own.
+  is mutation testing, a much larger thing to own. *One has since been built and
+  scored, and it does not lift this blocker.* The syntactic candidate — flag a
+  scenario whose expectation is derived from the param the code under test
+  consumed, decided inside one body without executing anything — flags 9 params
+  here, of which **4 are real echoes and 5 are pinned by something outside the
+  body it cannot see**. Under half precision, and the failure is the one
+  predicted above rather than a tuning problem: what pins a value is often a
+  fixture or a second derivation in another file, so a single-body detector is
+  looking in the wrong place by construction. The newest false positive is the
+  clearest instance — `ATX-79.subpath` is compared against `package.json`, which
+  is not the code under test and does not read the registry, so the independent
+  term is in another file entirely. Precision has fallen on every addition
+  measured so far, which is the direction that matters. The score is quoted from the
+  suite's snapshot and re-read with the judgement-table entry above, which is
+  where the same measurement is used for a different decision.
   **The guidance half has shipped; this entry is now only about the detector.**
   "Read the param inside the assertion" was insufficient and half-wrong as
   written, and `[0.5.0]` replaces it everywhere it appeared — README, the
@@ -5200,7 +5488,7 @@ have to gather again.
   pass and separating them is the finding.
 
 - **Whether a requirement can ever be retired, and what it costs that none can.**
-  The registry is at **69 requirements and 192 scenarios, 2.78 each**, and
+  The registry is at **79 requirements and 221 scenarios, 2.80 each**, and
   every one is a permanent obligation: `uncovered-requirement` is an ERROR, so a
   requirement without a scenario cannot exist, and nothing ever removes one.
   `delta.removed` exists and `applyDelta` applies it, but `--apply` refuses to
@@ -5245,6 +5533,19 @@ have to gather again.
   the ratio: 2.56 → 2.78. The cost of a requirement is not flat and it is not
   falling, which is the premise the whole entry rests on, and it is the first
   time this file has had two measurements of it to compare.
+  *A third measurement, on 2026-08-18, and it points the other way from the
+  second.* **79 requirements and 221 scenarios**, counted the way `verify self`
+  prints them, which is the control the 2026-08-08 restatement established. The
+  ratio runs 2.56 → 2.78 → **2.80**, so the step that carried the argument was
+  the first one and the second is **+0.015**, which is flat. The premise this
+  entry rests on now has one measurement for it and one against, and the honest
+  statement is the narrower one: per-requirement cost has held at about 2.8
+  scenarios across ten days and ten requirements. What is unchanged is the
+  absolute total, which only rises — that half of the argument is untouched, and
+  it was always the half about permanence rather than about acceleration. What is
+  no longer supported is the acceleration. **Reopening on cost needs the ratio to
+  move again**; reopening on the three meanings of "retire" needs none of these
+  figures, and that is still the part nobody has separated.
 
 - **Running `verify` over a subset of the scenarios, and what a partial run may
   be allowed to say.** `verify` is all-or-nothing and `check` executes nothing,
@@ -5378,6 +5679,283 @@ have to gather again.
   and the second report of the same shape, which this measurement does not
   supply and does not replace.
 
+- **An outward-facing form of the judgement tables, so an adopter can run this
+  counter-pressure on their own registry.**
+  `tests/intent-rule-candidates.spec.ts` maintains four hand-judged tables over
+  this repo's registry and enforces their completeness. Design §11 records the
+  properties they defend and that nothing enforces any of them; what the tables
+  add is a counter-pressure holding for **one** registry whose authors agreed to
+  maintain it. An adopter got none of it, and the reason was sharper
+  than "nobody wrote it for them": the package exported `requirement`,
+  `scenario`, `defineRequirements`, `delta` and types, and nothing else.
+  `parseSpecs`, `findFiles` and `readRegistrySource` were internal, so an
+  adopter **could not enumerate their own scenario names** — the table's central
+  rot check, that a claimed scenario is one a spec really declares, was not
+  merely unwritten downstream but unreachable. **That half shipped under
+  `[0.9.2]` as `@am_shork/attest/inspect`** and is recorded at the foot of
+  this entry; what stays here is the schema built on top of it, and the three
+  blockers below are untouched by the export.
+  *The shape that makes it shippable at all is a split, not a feature.* The
+  engine can compute which ids exist, which statements match the universal
+  quantifier regex, which params are list-valued, and whether a named scenario
+  is declared — all four already, all statically. It cannot compute how many
+  obligations a requirement carries, what a quantifier ranges over, or whether a
+  scenario iterates a param. So the shippable object is **the enforcement, never
+  the judgement**: an opt-in `*.judge.ts` read by the same static reader and
+  under the same literal-only rule the registry is (it is metadata about
+  requirements under review, so `check` must execute nothing to read it), whose
+  contents are entirely the adopter's. Opting in is creating the file; once it
+  exists, `requirement-unjudged`, `orphan-judgement`, `unbound-site` and
+  `quantifier-unjudged` make it complete and keep it from rotting. The
+  asymmetry is the only way this can exist without Attest asserting a ground
+  truth it refuses to compute (§0), and it is the same asymmetry `never-red`
+  already runs on: the archive gate would owe judgement only for ids a change
+  ADDs, so a brownfield adoption is not blocked wholesale.
+  *One part of the existing table cannot ship in any form.* `DOMAINS.pin` comes
+  in two kinds — a scenario name, checkable against the AST, and a **source-text
+  fragment** grepped out of the spec file. The second is asserting on the
+  wording of somebody's test, which is the `Issue.message` category error under
+  another name. Only the scenario-name kind is exportable, and what that costs
+  is real: the grep is what caught a deleted pin that `toContain` had passed.
+  *Why no detector ships with it, and this is the part that is already
+  measured.* Three rule families were built and scored against the whole corpus
+  (86 entries, counting a fixture id once per registry file) before any was
+  written into the engine, which is the order `divergent-param` was originally
+  designed in the wrong way round. Every figure below is a quotation of the
+  suite's inline snapshots; the snapshot is the fresh copy, and this paragraph
+  is only ever as fresh as its last edit.
+  **(1) `compound-requirement`** — 34 requirements carry more than one
+  obligation, it flags 16, is **wrong about none**, and misses 18. Never wrong
+  and nearly blind, and the 18 are the form the coverage incentive actually
+  rewards: extra clauses under a single keyword. **(2) The widened variant** —
+  29 correct, but 14 wrong and still 5 missed, and it is silenced by deleting an
+  "and". A rule whose cheapest fix degrades the artifact it protects does not
+  ship, and its precision falls as the registry grows. **(3) `divergent-param`**
+  — 5 divergences on this repo, **all 5 judged wrong**, zero true positives ever
+  recorded. The `code` group now spans 19 ids, and the failure is structural
+  rather than a matter of naming: the key is built by discarding the evidence of
+  relatedness, so the one genuinely paired divergence in the group is the one it
+  cannot show, and the key has churned three times under `flag` on additions
+  that changed no verdict. A fourth candidate — the echo detector, scored at
+  half precision — belongs to the tautology entry above and is not re-quoted
+  here, because a figure stated in two places goes stale in one. Taken together
+  these are the measured range of what a token or single-body detector over
+  prose can do here, and they are why the proposal is enforcement-only.
+  *What blocks the decision — three things.* **(1) One adapter.** This
+  repository's table is the only one that exists, and its author wrote both the
+  schema and every answer in it. By this project's own rule a second table is
+  what makes the seam real, and freezing a `Judgement` type now is deciding for
+  everyone from 34 requirements written by one person. **(2) The breaking form
+  of this was already rejected** — see *Countable obligations* below — and one
+  of its three reasons survives the separate-file shape intact: **nothing can
+  force the count to be true.** The other two do not survive, which is what is
+  new here: a separate artifact touches no `--json` field, no delta apply and no
+  `render` output, and completeness *across ids* is computable in a way
+  completeness *within* an obligation array never was. So this is a re-proposal
+  with one of three objections answered and the sharpest one standing.
+  **(3) `quantifier-unjudged` reuses a rejected detector as its trigger.**
+  Firing on the quantifier token was rejected below at 43% reach and 70% wrong;
+  the claim here is that the same regex is acceptable when it asks a question an
+  author discharges in one line (`over: 'values'`) rather than issuing a
+  verdict. That claim is untested on anyone who did not also write the regex.
+  *The half that is not blocked has shipped, under `[0.9.2]`.*
+  `@am_shork/attest/inspect` is one function answering what a project declares —
+  AST-only, no runner peer, landing on the existing static/executing boundary.
+  It ships no schema and decides nothing, which is why it could go ahead of the
+  three blockers rather than waiting on them. What it changes about this entry
+  is the *kind* of thing that is now missing: the mechanism is no longer
+  unreachable, only unwritten, so a second table is something an adopter can
+  build rather than something only this repository could.
+  *What would decide it:* one judgement table maintained by someone who did not
+  design it. If it comes back the same shape, the seam is real and the schema
+  follows; if it comes back different, `inspect` was the whole answer and the
+  schema never needs to exist.
+
+- **A registry cannot say a value is deliberately undecided, and an agent that
+  cannot determine one will invent it.** From a read of GitHub's spec-kit
+  against this design — the first time another SDD toolkit has been compared
+  here rather than OpenSpec, and the source of this entry and the three that
+  followed it — of which two have since been decided: the audit of this
+  repository's own rules is rejected below, and the propose-stage coverage scan
+  shipped under `[0.9.3]`, as three questions rather than nine categories.
+  spec-kit marks an unresolved decision inline as `[NEEDS CLARIFICATION: …]`,
+  greppable, with a command whose whole job is converging them. Attest's
+  registry has two states: schema-valid, or an ERROR. There is no third.
+  *Why that matters here specifically, rather than as a general nicety.* The
+  workflow is written for an agent to follow — that is what `init` writes — and
+  an agent drafting a delta that cannot determine a timeout does not leave the
+  field out, because the schema will not let it. It picks a number. A fabricated
+  `params` value, then pinned by a scenario written to match it, is exactly the
+  drift this project exists to prevent, arriving through the mechanism meant to
+  stop it: the single source is perfectly consistent and describes a promise
+  nobody made.
+  *A precedent that is not one, recorded because it reads like one.*
+  `rationale-placeholder` already warns about authoring sloppiness in a prose
+  field, and the `init` document already teaches it — but it is about
+  interpolation syntax written into the wrong field, not about a value nobody
+  has decided. The engine's willingness to warn on prose is the precedent; the
+  diagnostic is not the feature.
+  *The gap is narrower than "the registry cannot express doubt".* `changes/` is
+  already the place where a whole proposal is undecided, and the archive gate is
+  what settles it. What has no expression is **one field** of an otherwise
+  well-formed requirement.
+  *Shape, if it is built:* an additive `open?: string[]`, naming the fields or
+  questions still unresolved; a WARNING from `check`, so a proposal may be
+  legitimately half-finished, and an ERROR at the archive gate, so "done" is not
+  diluted. The same asymmetry `never-red` already runs on.
+  *What blocks the decision — three things.* **(1)** The frequency is entirely
+  unmeasured. No adoption report has recorded an agent inventing a param; the
+  argument above is structural, and this project has twice been wrong about a
+  hazard it reasoned to rather than measured. **(2)** The cheap half already
+  works: writing the uncertainty into `rationale` as prose costs nothing, and
+  the propose stage is human-reviewed regardless. What that does not buy is a
+  gate, which is the whole question. **(3)** It is permanent surface — a schema
+  field, a code, two troubleshooting sections, a History row, an `ATX-n` and its
+  scenarios forever — for a hazard nobody has yet reported.
+
+- **Prefix ownership is inferred rather than declared, and the cost arrives only
+  when adoption succeeds.** Design §11 records that the id grammar has no level
+  above the requirement: the prefix is a convention, nothing allocates it, and
+  `duplicate-prefix` can only report a collision that already happened.
+  spec-kit's answer is a roadmap table — a stable id, an intent, a scope
+  boundary, dependencies — authored above the specs it decomposes into.
+  *Two things have changed since that reading, and they point opposite ways.*
+  The proposal is **smaller** than it looked: the mechanism partly exists.
+  `loadRegistry` returns `prefixOwners` — first claim in sorted file order —
+  `merge.ts` uses it to decide which file an ADDED id belongs in, and
+  `apply-no-prefix-owner` already refuses a prefix nobody owns. So what is
+  proposed is declaration replacing inference, not a new layer. And it is
+  **weaker**: `/inspect` shipped in `[0.9.2]`, so the cross-repository half —
+  the one §11 says no command can see across — is now something an adopter
+  computes from two registries in about ten lines. Attest does not have to own
+  it to make it possible.
+  *What blocks the decision:* nobody has the problem. §11 states the cost
+  arrives "exactly when adoption succeeds: two teams sharing a registry have
+  someone owning prefix allocation by hand", and no such adoption has been
+  reported. Building the declared form now would be deciding prefix semantics
+  for everyone from one repository whose five prefixes — `ATX` and the four
+  fixture ones — are each declared by exactly one file, so the allocation
+  question this would answer has never been asked here.
+
+
+- **A merged requirement carries no trace of the change that produced it, and
+  the rename chain is the part actually lost.** `RequirementSchema` is
+  `statement`, `rationale`, `params`, `outOfScope`; the splice writes those and
+  nothing else, so after `--apply` no field and no sidecar records which change
+  introduced an id, which modified it, or that one id used to be another. The
+  delta that knew is in `archive/`, which nothing reads. Proposed from
+  OpenViking's `.relations.json`: links between memories live in a
+  directory-level sidecar, deliberately kept out of the content, and are
+  rendered on demand at retrieval time (`docs/design/memory-link-design.md`).
+  *The argument for the sidecar over a field is in their competitor analysis
+  rather than their design.* The same document reads GBrain, which writes links
+  into the page body, and records what that costs: rename a page and every
+  inbound link still points at the old slug, with fuzzy matching at the read end
+  as the only mitigation. A `supersedes:` or `introducedBy:` field on a
+  requirement would be that mistake in this repository's terms — the registry is
+  a literal and a single source (§2), and a field naming a folder that a later
+  rename can move is a second source with nothing comparing it against the
+  first. A derived index has no such copy to go stale: it is recomputed from the
+  archived deltas every time it is read.
+  *What blocks the decision:* the empty archive — the subject of the entry that
+  shipped under `[0.9.3]`, whose promotion this one does **not** inherit,
+  because the two changes that produced that corpus were ADDED-only and
+  exercised no rename at all — which makes a backlink index testable only
+  against fixtures; and one question the OpenViking reading
+  does not answer, which is whether the chain is wanted at all. §7 applies
+  `RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
+  deliberately, as far as anything written says. The case for recovering it is an
+  external reference that outlives the rename, a ticket or a commit message
+  naming a retired id, and nobody has reported one.
+
+- **The instruction document says how to write intent and nothing about how to
+  read the record back.** §10's one-document-many-targets file is entirely about
+  authoring, and the moment anything reads `archive/` — the entry above, and the
+  one that shipped under `[0.9.3]` — an
+  agent is holding prose from a proposal agreed on some past date against a
+  registry that is current, with no stated order between them. OpenViking states
+  one for its own store in the skill it ships to coding agents
+  (`agent-plugins/skills/openviking-memory/SKILL.md`): retrieved memory is
+  advisory, and the order is system and developer instructions, then the current
+  request, then current environment and tool evidence, then memory — with "prior
+  success never authorizes a destructive action now", and "store conclusions,
+  not scrollback".
+  *Here the same rule has a harder form, because the authoritative half is
+  machine-checked.* The registry and the gate's verdict are evidence; an
+  archived proposal is testimony about a decision taken once. Where they
+  disagree, the disagreement is a finding — the exact thing this tool exists to
+  report — and not something for a reader to reconcile quietly in favour of
+  whichever it read last. That is a property of the design rather than of a
+  file, so if it is taken it lands in design §11 first and in the instruction
+  document second.
+  *What blocks the decision:* it is a rule for reading a store nothing reads yet,
+  so on its own it would document a hazard that cannot currently arise. It is the
+  cheapest of the three and could ship first, at the price of being the only
+  paragraph in that file describing a workflow the tool does not have — and §10's
+  economics make that price the same in every adopter's agent instructions at
+  once.
+  **That blocker is retired, and what replaced it is narrower than the entry
+  assumed.** Something reads `archive/` as of `[0.9.3]`, so the hazard can
+  now arise. But what shipped reads the **typed** half — `first-run.json`, whose
+  every value is an `Outcome` in a schema-validated envelope — and evidence that
+  parses cannot disagree with the registry in the way testimony can: a scenario
+  either is in the record or is not. The rule this entry wants is about the prose
+  half, and the prose half is still read by nothing. So the store is no longer
+  write-only and the entry's own subject is still hypothetical, which is a
+  different blocker from the one it was filed with rather than none.
+
+- **Changing the value of an existing param passes no gate, and for seven of
+  them there is no record either.** Split out of the tautology entry at the
+  head of this section on 2026-08-18, where it was one sentence inside the
+  reframing paragraph. It is a different question: that entry asks whether an
+  assertion is a real comparison, this one asks what happens when the number
+  itself moves, and neither answer settles the other. `archive` gates a
+  **change** — a delta, proposed specs, a recorded failing run — and a param edit
+  is none of those. It is one literal in a merged `*.reqs.ts`, and every gate
+  reads it as fine: `check` finds it schema-valid, because a param is any JSON
+  value; `possible-drift` is quiet by construction, since `ATX-8` makes it ask
+  whether *any* covering scenario reads the params at all rather than whether a
+  value moved; and `verify` stays green wherever the assertion derives its
+  expectation from the same param, which is the pair of green rows measured in
+  the entry this was split from.
+  *What is left is `render`, and it was measured here rather than assumed.*
+  Across **89 params on 59 of this repository's 79 requirements, 82 — 92.1% —
+  are interpolated into their own statement**, so editing one changes
+  `self/requirements/SPEC.md` and `render --check` fails until the document is
+  regenerated. That is a review surface and not a gate: the new value lands in a
+  committed generated file where a reader can see it, and nothing anywhere asks
+  whether the move was intended.
+  *The other seven leave no trace outside the line that was edited, and which
+  seven they are is the finding rather than the count.* Five are **structurally
+  uninterpolatable**: `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are
+  kind → payload tables, and `ATX-15.sortMethods`, `ATX-15.bannedApis` and
+  `ATX-72.quotes` are lists. A statement cannot carry any of them —
+  `non-scalar-interpolation` is the diagnostic that refuses it — so the params
+  with no record are disproportionately the shape §2 widened the params rule to
+  cover **precisely because lists and tables are the most drift-prone constants
+  there are**. The remaining two, `ATX-15.comparator` and `ATX-26.code`, are
+  scalars their author simply did not interpolate.
+  *What this is not.* It is not a re-proposal of the committed params snapshot
+  rejected below. That was rejected on the argument that the mechanism guarding a
+  param is a scenario reading it rather than a file recording it, and nothing
+  here disputes that or needs a second copy of the values. The observation is
+  narrower: the **edit** is unremarkable to every gate, which is a different
+  claim from the values being unguarded.
+  *What blocks the decision — and the first is the one that blocks the entry this
+  came from.* **(1)** Frequency is unmeasured, and the one corpus anybody has
+  looked at points at zero: across 8 commits touching `*.reqs.ts` in the
+  reporting repository, no param value was ever modified — every `params:` line
+  in every diff is an addition. A defect nobody has committed is a hazard rather
+  than a report. **(2)** No shape is obvious. A param edit is not a change, so
+  `archive` is the wrong place; making `check` notice one needs a previous value
+  to compare against, which is the rejected snapshot wearing a different hat. The
+  only mechanism needing no stored copy is review, and review already sees the
+  `SPEC.md` diff for 82 of the 89. **(3)** What is left after that is seven
+  params in one repository, and the right answer for the five that matter may be
+  nothing more than a line in `intent-quality.md` — the four things no gate is
+  looking at already being that page's subject, and this being a fifth of the
+  same kind.
+
 ## Considered and rejected
 
 Decisions **not** to build something, kept where they can be found before the
@@ -5864,24 +6442,27 @@ quotation of that snapshot and is only ever as fresh as the last edit here —
 read the snapshot when the number is what matters. *`compound-requirement`
 (WARNING) — rejected.* More than one RFC-2119 keyword in one `statement` is
 objectively more than one obligation. Measured (figures re-read from the suite,
-which is the only place they are not prose): of the 8 requirements in the corpus
-carrying more than one, it flags 3 (`ATX-10`, `ATX-21`, `ATX-26`) and misses
-`ATX-5`, `ATX-9`, `ATX-13`, `ATX-14`, `ATX-17` — every one that packs clauses
-under a single keyword, which is the form the coverage incentive actually
-rewards. A wider variant (keyword plus a coordinating `and`/`while`/`;`) reaches
-7 of 8, at 3 wrong hits (`ATX-6`, `ATX-22`, `ATX-23`) rather than the 1 recorded
-when it was first scored — so reach is not the deciding argument, and the
-precision it trades away grows with the registry. This is: both variants are
+which is the only place they are not prose): of the 34 requirements in the
+corpus carrying more than one, it flags 16 and misses 18 — every one of those 18
+packs clauses under a single keyword, which is the form the coverage incentive
+actually rewards. A wider variant (keyword plus a coordinating `and`/`while`/`;`)
+reaches 29 of 34, at 14 wrong hits rather than the 3 quoted here when the corpus
+was half this size and the 1 recorded when it was first scored — so reach is not
+the deciding argument, and the precision it trades away grows with the registry,
+which three successive re-readings of this paragraph have now measured rather
+than predicted. This is: both variants are
 silenced by deleting the word that triggered them, and neither can tell that
 deletion from a real split. `SHALL do A and MUST do B` clears the warning as
 `SHALL do A and do B` — same two obligations, one fewer normative keyword. A
 rule whose cheapest fix degrades the artifact it protects does not ship.
 *`divergent-param` (WARNING) — rejected.* One param name declared with different
-values in two requirements sharing an id prefix. Measured: it fires twice on
-this repo and both firings are wrong — `idleTimeoutMin` (`15` in `ATX-3`, `30`
-in `ATX-10`), unrelated illustrative fixtures, and `code` (`registry-not-static`
-in `ATX-17`, `empty-spec` in `ATX-18`, `rationale-placeholder` in `ATX-21`),
-diagnostics that could not possibly agree. The second arrived on its own when
+values in two requirements sharing an id prefix. Measured: it fires 5 times on
+this repo and **every firing is judged wrong** — `idleTimeoutMin` (`15` in
+`ATX-3`, `30` in `ATX-10`), unrelated illustrative fixtures, and `code`
+(`registry-not-static` in `ATX-17`, `empty-spec` in `ATX-18`,
+`rationale-placeholder` in `ATX-21`), diagnostics that could not possibly agree.
+That second group has since grown to span **19 ids**, and two more param names
+have joined it on the same structure (`flag`, `payloadKinds`). The second arrived on its own when
 `ATX-18` was added and grew a third member on its own again when `ATX-21` was,
 then `ATX-25`, then `ATX-26`, which is the more damning half: a generic param
 name collides more often as a registry grows, so the false-positive rate rises
@@ -5898,8 +6479,19 @@ firing. Until it appeared, every false positive had been on the single name
 workaround and therefore left the rule arguably salvageable. It is not the word:
 two requirements owning unrelated constants of the same *kind* is the structure,
 and any registry large enough to be worth linting has it. Still zero true
-positives, now across a 34-entry corpus (the `corpus` figure in the suite's
+positives, now across an 86-entry corpus (the `corpus` figure in the suite's
 snapshot, which counts a fixture id once per registry file that declares it).
+**Two failure modes have been measured since, and both are about the key rather
+than the threshold.** The grouping keeps one id per distinct value, so two
+requirements naming the *same* constant — the case a reader would most want
+compared — are the pair the key deduplicates away; that has now happened twice,
+most sharply on `ATX-18`/`ATX-77`, a pair split deliberately because each is
+falsifiable in a direction the other is blind to. And the key's *identity*
+moves when a requirement agreeing with an existing member is added, so a finding
+has to be re-judged by hand while nothing about it changed — three re-keyings
+across three releases under `flag` alone, none of which moved a verdict. A rule
+whose output churns on additions that agree with it is one whose maintenance
+cost is a function of registry growth, on top of the zero precision above.
 The escape hatch it was blocked on has since been designed and does not rescue
 it: with no config file the only workable shape is an additive
 `independentParams?: string[]` on the requirement (a CLI flag is per-invocation
@@ -6097,6 +6689,180 @@ requirement, and human review at propose is still the whole answer. What is
 rejected is grouping as a way to assist it, and this reopens only on a
 contradiction that grouping would have caught.
 
+### An append-only writer for `status`, following spec-kit's `converge`
+
+spec-kit's `converge` assesses the codebase against a feature's artifacts and
+appends the remaining work as new tasks, under a strict contract: its only write
+is a new section at the foot of `tasks.md`, and it may not rewrite, renumber,
+reorder or delete anything already there. Proposed here as the shape `status`
+would need if it ever produced todos rather than a report, on the grounds that
+append-only is the safe way to write into a file a human owns.
+
+*Rejected because this repository already has a strictly finer instrument, and
+the first reading missed it by comparing the wrong pair.* `ATX-76`: with
+`--apply`, a MODIFIED requirement is written back by replacing the source span
+of **each value that changed** — never the entry holding them — and the whole
+merge is refused, with nothing written, when a span it would overwrite carries a
+comment. That is a smaller unit than "append at the foot", and it solves the
+harder problem: editing in place without destroying what a person wrote around
+it. Append-only avoids the question by never touching existing text; `--apply`
+answers it. The comparison that produced the proposal was `converge` against
+`status`, and it never looked at what the command that actually writes already
+does.
+
+*And the premise is unbuilt anyway.* `status` is a report, deliberately — it
+answers what the gate still wants, from the delta, the specs and the record,
+running nothing. No adoption report, and nobody here, has asked it to become a
+writer. A write discipline for a command that does not write is a solution
+looking for its problem, which is what `Speculative Generality` names.
+
+*Reopening this needs `status` to have a reason to write at all* — and if that
+ever happens, the discipline to reach for is `ATX-76`'s, not this one.
+
+### A Sync Impact Report at the head of a governance document
+
+spec-kit's `constitution.md` opens with a comment block recording what a change
+to it touched: the version bump and its rationale, the principles defined, and a
+checklist of every downstream template reviewed for alignment, each carrying a
+note on what was checked. Proposed here as a general form of the rule that a `docs/en` change
+carries its `docs/zh` counterpart in the same commit — a persisted record, per
+change, of what was checked downstream.
+
+*Rejected because `pre-commit-check` already produces exactly that, per commit,
+and produces it where it is useful.* The skill's opening instruction is to
+report which items applied and which did not, saying plainly when something was
+skipped and why, because "a silent omission is the failure mode this exists to
+prevent". That output is a Sync Impact Report under another name, produced at
+the moment of the change rather than pinned to the head of a file, and it covers
+more than one document's downstream — packaging, the `Issue` code contract,
+`SCHEMA_VERSION`, both language trees.
+
+*What persisting a second copy would cost is the thing this project has been
+most consistent about avoiding:* it splits a store deliberately kept single. The
+same argument keeps decisions in this file rather than an ADR directory, and it
+applies with more force here, because the two copies would disagree the first
+time a commit's report says something the header block does not.
+
+*The other half of the constitution reading* — that this repository's
+load-bearing rules have no ids and nothing reads them — survived the rejection of
+the document that carried it and was filed under `Under consideration`. Its audit
+was done on 2026-08-18 and it is now rejected too, in the section directly below
+this one, on an argument neither half of the reading predicted.
+
+### Promoting this repository's own rules in `CLAUDE.md` to requirement ids
+
+The audit this entry was filed for was done on 2026-08-18 and its answer is
+**none**. The entry named its own first step — an audit whose primary output is a
+rejection list — and asked which `CLAUDE.md` rules should become ids, on the
+observation that rules whose violation has already produced silent defects are
+gated by nothing.
+
+*Three were already ids, which the entry knew.* `ATX-28` is the path-spelling
+rule, `ATX-29` the line-endings rule in the form that matters (the freshness
+check compares the document rather than its bytes), and `ATX-16` with `ATX-17`
+the two-readers rule: the four-command static roster, and the refusal to fall
+back to evaluating a registry that will not read.
+
+*One is already gated and the entry did not know it.* `docs/zh/**` mirroring
+`docs/en/**` one-for-one is asserted twice in `tests/docs-consistency.spec.ts` —
+every English page has exactly one Chinese counterpart, and each pair shares a
+heading tree and a code-sample sequence. What has no gate is whether the two
+still *say* the same thing, which is what `CLAUDE.md` and `pre-commit-check` §6
+both mean by "checked by eye only": the structural half is held, the semantic
+half cannot be.
+
+*The rest fall into three groups and none of them wants an id.* **Six are
+working habits** — `vitest run` does not run `self/`; it also runs the type
+tests; `bin/attest.js` loads `dist/`; some fixtures fail on purpose; a scenario
+starting a child run needs an explicit timeout; a package manager is spawned only
+through the one helper in `tests/consumer.spec.ts`. Each is about how to work in
+this repository rather than what Attest promises anyone, and §1 is decisive:
+a requirement costs a mandatory scenario forever, so these would be six scenarios
+asserting facts about a maintainer's habits. **Two are the design vocabulary and
+the filing rule**, which are definitions and a destination — there is nothing to
+assert. **And one constrains a consumer rather than the engine**, which is the
+finding worth keeping.
+
+*`Issue.message` is prose, never API — the most load-bearing ungated rule in the
+file, and no id can hold it.* The promise is that a consumer may branch on `code`
+and `reqId` and must not branch on wording, so the obligation falls on the
+consumer's tests and not on any behaviour a run of this engine can exhibit. The
+checkable half is already structural: `code` is typed to the roster in
+`src/core/docs.ts`, and `ATX-40` obliges every code to carry a troubleshooting
+section in both languages. A requirement stating the rest would either restate a
+type or assert something no run can observe. **This is the audit's general
+result rather than one rule's exception** — the file is mostly a working
+agreement with this repository's maintainers, and the three rules in it that were
+contracts Attest owes an adopter had all been promoted before the question was
+asked.
+
+*The same argument retires the entry's own sharpener.* `[0.9.2]` edited
+`.claude/skills/pre-commit-check/SKILL.md` with no gate having an opinion about
+its contents, and that is true — but measured, the machine-checkable surface of
+that document is **one token**: it names exactly one issue code,
+`spec-load-failed`, and that code exists. An `ATX-57` analogue over it would gate
+a roster of one. Everything else in the document is judgement, which is both what
+a gate cannot hold and the reason the document is prose.
+
+*One actionable finding survives, and it is not an id.* `CLAUDE.md` says not to
+flatten `fixtures/nested-spec/`, because its spec is the only one below a root
+and therefore the only thing exercising a separator. The guard is
+`tests/paths.spec.ts`, which scans that fixture and asserts that no relative path
+contains a backslash — **and that assertion passes on a flattened corpus**,
+because a flat filename contains no backslash either. The rule carrying a written
+warning against silent decay is guarded by an assertion that decays silently. The
+fix is one line in that test, requiring at least one scanned path to sit below the
+root, and it is a plain test rather than a requirement for the same reason as
+everything else here: it is a property of this repository's fixture corpus, not a
+promise about Attest's behaviour. **Done under `[0.9.3]`**, and the guard
+was checked against a flattened copy of the fixture before it was written — the
+predicate reads true on `fixtures/nested-spec/` and false on the same files laid
+flat, which is the difference the old assertion could not see.
+
+*Worth reopening only for a rule that is a contract* — one Attest owes an
+adopter, added to that file later. It belongs in the registry when it is written,
+not in a second sweep of prose.
+
+### Semantic retrieval over the intent layer
+
+Priced on 2026-08-18 while reading OpenViking (volcengine/OpenViking, AGPL-3.0,
+at `87d5142e`) for what a context database for agents has that this repository
+does not. The proposal was its retrieval path
+(`docs/en/concepts/07-retrieval.md`): embed requirements, specs and archived
+proposals, then answer a question with an LLM intent analysis that emits zero to
+five typed queries, a priority-queue recursion down the directory tree with
+score propagation, and a rerank pass over the survivors.
+
+Rejected on what that machinery is *for*. Every part of it is a way to find
+things in a corpus that has lost its structure — free text, no ids, no grammar,
+tens of thousands of entries. This one has 79 requirements in a single file,
+each with an id matching `/^[A-Z]+-\d+$/`, grouped by a prefix, carrying a
+statement written to contain SHALL or MUST. Lookup by id is exact and free;
+`grep` over the statements answers the rest. Ranking is what you reach for when
+you cannot address; addressing is the thing this design already has, and §5.4
+extends it to evidence by keying the red record on requirement id, spec file and
+scenario name.
+
+The second reason is the one that would survive a bigger corpus. A retriever of
+that shape puts a non-deterministic, network-dependent, unfalsifiable scorer
+beside four commands whose defining property is that they execute nothing and
+whose output is a verdict a reader has to be able to reproduce. Their own
+document specifies the degradation frankly — "if rerank returns an invalid
+result or the API call fails, retrieval falls back to vector scores" — and a
+silent fallback to a weaker mechanism is precisely what §5.1 refuses when it
+makes a non-static registry a `registry-not-static` ERROR rather than a
+fallback to evaluation. The same answer applies here for the same reason.
+
+Worth reopening if an adopter's registry reaches a size where prefix grouping
+and `grep` genuinely stop working — but the first thing to try then is the
+declared prefix ownership already under consideration above, which addresses,
+rather than a scorer, which ranks.
+
+## Releases
+
+[0.9.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.3
+[0.9.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.2
+[0.9.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.1
 [0.9.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.0
 [0.8.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.8.0
 [0.7.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.4