@am_shork/attest 0.9.3 → 0.9.4

package/CHANGELOG.md

@@ -13,6 +13,238 @@ input, removes/renames a public API or `--json` field, or changes a default
 runtime behavior an existing invocation relies on — diagnostic message text is
 not API.
 
+## [0.9.4] - 2026-08-19
+
+### Added
+
+- **A requirement can say a value is not decided yet, as `open` (`ATX-81`,
+  `ATX-82`).** The registry had two states, schema-valid or an ERROR, and there
+  was no third — so an author who could not determine a value had nowhere to put
+  that fact. What they do instead is pick one, and a scenario written against an
+  invented number is drift no gate can see: the single source is perfectly
+  consistent and describes a promise nobody made, arriving through the mechanism
+  meant to stop it. `open` is a free-text list of what is still undecided about a
+  requirement, one entry per question. The static commands report each as a
+  `requirement-open` WARNING and keep their exit code; the archive gate refuses
+  with `open-unresolved` while any remains. Promoted from *Under consideration*,
+  where the blockers were an unmeasured frequency and the permanent surface a
+  schema field costs.
+
+  *The asymmetry is the design, and it is `never-red`'s.* A proposal may be
+  legitimately half-finished while it is being written, and the four static
+  commands are where an author works during that; failing there would push them
+  back to inventing a value, which is the behaviour being replaced. Archiving is
+  where "done" acquires a hard definition, and a registry carrying an unanswered
+  question is not done.
+
+  *Re-measuring the entry before implementing it corrected it in four places,
+  per this file's own discipline.* **(1)** The proposed "WARNING from `check`,
+  ERROR at the gate" cannot be one diagnostic at two levels: `evaluateGate`'s
+  structure step already filters `validateStructure` to ERROR, so every WARNING
+  is discarded there. It needs its own gate step, which is what `never-red`
+  being the stated precedent actually implies. **(2)** The scope is the whole
+  merged registry, not the ids the change ADDs — and that is where it parts
+  company with `never-red`, whose narrower scope exists because "was ever
+  observed failing" is a fact about history that cannot be demanded
+  retroactively. An open question is a claim about the present. **(3)** The
+  entry over-counted the static extractor, which reads any literal property and
+  needed nothing, and under-counted `render`: without a section there, `SPEC.md`
+  — the only human review surface a requirement has — would not show that a
+  shipped requirement is open.
+
+  ***(4)* is the one that had to ship in the same change, and it is the
+  question `Planned`'s preamble says to ask.** `splice.ts` carries the comment
+  *"Any other field is one the schema does not define, and not this module's to
+  rewrite or to remove"*, and that sentence is true **only while `open` is off
+  the schema**. Adding the field without adding the two writer branches would
+  mean a change that *answers* a question is approved by the gate against an end
+  state the registry on disk does not match — the merge commits a file still
+  carrying the closed question, with nothing anywhere comparing the two. Not a
+  path the entry's own reasoning could reach, because it reasons about the field
+  being added and this is about the field being removed.
+
+  *Cost, stated rather than hidden.* One unresolved question anywhere blocks
+  every unrelated change from archiving. That is the intended reading of a
+  registry that is not done, it is recoverable by answering the question, and it
+  is the same all-or-nothing shape `verify` already has. `SCHEMA_VERSION` is
+  unchanged: two new `code` values are additive to the `--json` envelope. The
+  type surface **does** move — `Requirement` gains a required `open`, so code
+  constructing one by hand rather than through `defineRequirements` needs the
+  field. In this repository that was 26 sites, every one of them a test literal
+  that already spelled `outOfScope: []`; no adopter reading requirements is
+  affected, and `defineRequirements` still takes it as optional.
+
+- **This repository ran its own `changes/` → `status` → `archive` workflow for
+  the first time, and the change above is what went through it.** Every one of
+  the 80 requirements before it was written straight into the registry, so
+  `archive/` did not exist and `inspectRedEvidence` — shipped in `[0.9.3]` to
+  read it — reported all 252 declared scenarios as `unarchived`. The export had
+  no consumer that was not a test of itself for the second release running, and
+  this time the reason was not that nothing had been built on it but that the
+  repository had never produced the input it reads.
+
+  **The gate's first run failed on two of the five scenarios, and it was right.**
+  Both were the negative half of a pair — "says nothing when the list is empty",
+  "lets the gate through once every question is closed" — and both passed on
+  their first run, because an engine that has never heard of the field satisfies
+  "stays silent" trivially. `never-red` named them individually. The repair is
+  one scenario asserting the *discrimination* rather than two asserting each
+  side, which fails now and still refuses an implementation that warns
+  unconditionally later. This is the mechanism catching the exact defect class
+  the tautology entry under *Under consideration* is about, on the first change
+  it was ever pointed at, in the author's own work.
+
+  *A second defect surfaced after `--apply` and is worth recording because
+  nothing catches it.* The proposed spec read its params through `delta.added`
+  rather than by id. A delta is *also* keyed by the ids it ADDs
+  (`withProposedRequirements`), which is what makes the import the only line the
+  merge has to change — reaching through `added` loads during stage 1 and throws
+  once the import is repointed at the registry. The gate cannot see it, because
+  the gate runs before the rename; `check` cannot, because it executes nothing.
+  It appeared at the next `verify` as `spec-load-failed`. The workflow document
+  already shows the by-id accessor; what it does not say is that the other one
+  works until it doesn't.
+
+  *What the archive now reports*, and it is the shape the design predicts rather
+  than a backlog: one archived change, 5 `fail` rows, 228 `unarchived`. The two
+  retired scenario names remain in `first-run.json` as `pass` and produce no
+  rows at all, which is `inspectRedEvidence`'s documented behaviour for a record
+  naming a scenario no spec declares any more — measured here for the first time
+  rather than reasoned about.
+
+### Changed
+
+- **The publish job publishes through `npm` and requests an npm OIDC token, so
+  trusted publishing becomes a setting rather than a rewrite.** The provenance
+  work in `[0.7.2]` signs the release but does not change what authorises it: a
+  long-lived automation token, masked and protected, that publishes as us to
+  anyone holding it. This is the half of removing it that lives in the
+  repository. Promoted from `Planned`; what remains there is narrowed to the two
+  npmjs.com settings that actually retire the credential.
+
+  *The one thing the entry was promoted with as unmeasured is now measured, and
+  it decides the rollout.* The question was whether a failed OIDC exchange falls
+  back to the `_authToken` already in `.npmrc` or fails the publish outright.
+  It falls back. Read off npm 11.10.1's `lib/utils/oidc.js` rather than inferred:
+  the function documents itself as intended never to throw, every failure path
+  logs at verbose and returns, the whole body sits inside a `try/catch` that also
+  returns, and `opts[authTokenKey]` is assigned only on success. So this lands
+  beside the existing token with nothing registered yet, and a failed exchange is
+  a quiet fall back rather than a failed release — which is what makes the first
+  tagged release a cheap test instead of an irreversible bet.
+
+  *`pnpm publish` was never going to work, and that is now an observation rather
+  than a strong inference.* The entry reasoned from `pnpm/pnpm#11526` that pnpm
+  gets out of the way and npm does the work. The call site confirms it:
+  `npm/lib/commands/publish.js` invokes `lib/utils/oidc.js`, so the exchange is
+  inside npm's publish command and no flag passed to pnpm reaches it. Hence the
+  client swap, which is a cost this file has already priced once in the other
+  direction.
+
+  *Two details the swap turned up that the entry had not counted.* `npm publish`
+  has no `--no-git-checks` — it warns *"Unknown cli config"* and does no git
+  checks at all — so the flag is dropped rather than translated. And the job now
+  runs `corepack enable pnpm` rather than the bare `corepack enable` plus the
+  `COREPACK_ENABLE_STRICT` override the entry expected to re-add: naming the shim
+  leaves the image's own npm alone for `npm i -g npm@^11.5.1` to upgrade, which
+  is the same outcome with one fewer environment variable and no refusal that can
+  be switched off by accident. `--provenance` stays explicit even though npm's
+  OIDC path can enable it by itself, because it only does so while `provenance`
+  is at its default — passing it keeps the setting this job's decision rather
+  than a side effect of whether the exchange succeeded.
+
+  *What is not claimed.* Nothing here has run. The job is exercised once per
+  release and cannot be tested any other way, which is why the fallback
+  measurement came first and why the token and its guard both stay. `NPM_TOKEN`
+  is still required and still what authorises the publish until a release is
+  observed going out without it.
+
+
+- **This repository's own judgement table now reads its scenario names through
+  `@am_shork/attest/inspect`, and what that measured is the point of the
+  change.** `intent-quality.md` names one read as the rot check every hand-judged
+  table needs — that a scenario a row claims is one a spec really declares — and
+  tells an adopter to get it from `inspectProject`. This repository's table got
+  it from `parseSpecs` and `findFiles` directly, because it was written while
+  both were internal. So the export shipped in `[0.9.2]` had **no consumer that
+  was not a test of itself**: `self/inspect.spec.ts` attests it, and nothing
+  built anything on it. Passing its own tests is not evidence that an export is
+  sufficient for the thing it was added for, and the only party who could have
+  found out otherwise was an adopter.
+
+  *Equivalence was measured rather than assumed, in both directions.*
+  `scanProject` sorts the same `findFiles` walk with the same `isSpecFile`
+  predicate, so the two reads should agree — and they do, compared as sorted
+  `(reqId, names)` pairs over the whole repo before the old call was deleted.
+  Then mutation-checked, because an assertion that still passes when the read
+  returns nothing is not reading anything: with the map stubbed empty the
+  rot-binding test fails and the other nine pass, which is the blast radius the
+  call actually has.
+
+  **What would not go through the export is the finding, and it is one thing.**
+  `Inspection.registry` is merged across registry files, so an id arrives with no
+  record of which file declared it. `corpus()` needs that — `source` is the scope
+  a cross-requirement rule sees, `divergentParam` keys on it, and the DOMAINS
+  completeness check uses it to hold the fixture registries out — and nothing in
+  the public export can reconstruct it. That half still deep-imports
+  `readRegistrySource`, with the reason written at the call site rather than left
+  as an unexplained inconsistency. It is filed as a measurement and **not** as a
+  decision to add a field: one caller wanting per-file attribution is one
+  adapter, and the entry under *Under consideration* about an outward-facing
+  judgement schema is waiting on exactly the second one.
+
+  *Cost.* `inspectProject` reads the registry as well, which this caller does not
+  need — one extra static read on a tree `corpus()` already walks once per call,
+  seven times per run. Paid deliberately: the alternative is deep-importing the
+  function whose reachability from outside the package is the thing being
+  demonstrated.
+
+### Documentation
+
+- **Design §11 now states that evidence outranks testimony, and that a
+  disagreement between them is a finding.** The registry and the gate's verdict
+  are evidence — machine-checked, recomputable, true of the tree as it stands. An
+  archived `proposal.md` is testimony: prose about a decision taken on one past
+  date that nothing has re-read since. A reader holding both holds claims in two
+  tenses with no stated order, and the order matters most exactly when they
+  conflict, because a stale proposal is more fluent than a registry and reads as
+  the more authoritative of the two. Decided from *Under consideration*, where it
+  had sat behind a blocker that was circular.
+
+  *The blocker was circular and naming the circle is what dissolved it.* The rule
+  was held back for describing a workflow the tool does not have — nothing read
+  the prose half — and the prose half was read by nothing **because no rule
+  existed for reading it**. Neither side moves on its own. The way out is the
+  split `[0.9.3]` already made for the propose-stage questions, where two of five
+  went to `CLAUDE.md` rather than into the document `init` writes: **this lands in
+  §11 only, and deliberately not in the instruction document.** §11 is a permanent
+  property of the design and its cost is paid once, here; the §10 document's cost
+  is paid in every adopting project's agent context forever, and that cost is what
+  the blocker was actually about. It is also the statement any later retrieval
+  surface would have to be built against, so writing it first is cheaper than
+  writing it after something depends on it.
+
+  *Re-measuring it before writing found the entry's own subject had stopped being
+  hypothetical, and falsified something this file recorded.* `[0.9.3]` states that
+  `proposal.md` in this repository "carries a link" — `CLAUDE.md` makes
+  `CHANGELOG.md` the single decision record, so a proposal restating an argument
+  would be a second store of it with nothing comparing the two — and concludes
+  there is nothing in it for an index to offer but its path. The very next change
+  to archive carries a proposal of **sixty-nine lines across five sections**, most
+  of its argument also present in the changelog entry. So the second store arrived
+  by ordinary means, in the first change that could produce one, written by an
+  author who knew the rule. The archived file is left as it is rather than trimmed
+  to a pointer: it is what the gate approved, and rewriting an archive to agree
+  with a claim about it is the failure this section is about, performed on itself.
+  §11 cites it as the measurement instead.
+
+  *What is deliberately not claimed.* The typed half cannot produce this conflict
+  — `first-run.json` is an `Outcome` in a schema-validated envelope, and a
+  scenario either is in the record or is not, so `inspectRedEvidence` reports an
+  absence rather than a contradiction. Nothing enforces the rule and nothing can:
+  reconciling prose against a registry is the ground truth §0 refuses to compute.
+  What §11 states is only the direction to reconcile in.
+
 ## [0.9.3] - 2026-08-18
 
 ### Added
@@ -5194,7 +5426,7 @@ time**.
 
 *The first time that question was asked in advance, it paid, and how it paid is
 worth a line because it is not what the two cases above would predict.* The
-`check` `empty-spec` entry — `[Unreleased]`, the third entry to reproduce exactly
+`check` `empty-spec` entry — `[0.9.0]`, the third entry to reproduce exactly
 on its reported half — was not wrong about its own repair. Asking the question
 anyway found the defect one step to the side: the fix it proposed was correct,
 and the *obvious implementation of it* — make `check` agree with `verify` —
@@ -5205,82 +5437,32 @@ path the repair makes reachable; it is about **everything the repair would make
 `check` agree with**, and an entry that names the right fix can still be
 implemented wrongly by copying the half nobody has audited.
 
-- **Trusted publishing, which would delete `NPM_TOKEN` rather than add to it.**
-  The provenance work in `[0.7.2]` signs the release but does not change
-  what authorises it: a long-lived automation token, masked and protected, that
-  publishes as us to anyone holding it. npm's trusted publishing exchanges the
-  same OIDC identity the attestation already uses for a short-lived credential,
-  which would remove the stored secret entirely and grant provenance as a
-  property of the flow rather than a flag on the command. The deletion test
-  points the right way for once: what it removes is the only long-lived
-  credential this repository has.
-  **The blocker this entry was filed with is retired, and it was the wrong
-  question** — checked against npm's documentation on 2026-08-08. It asked
-  whether npm's trusted publishers accept a **gitlab.com-hosted** project on the
-  plan this package publishes under, and both halves come back clean: GitLab
-  CI/CD is a first-class provider alongside GitHub Actions, and no plan
-  requirement is stated anywhere in the documentation. The four fields it wants
-  are `Pseudorca`, `attest`, the top-level CI file path (`.gitlab-ci.yml`, and it
-  must carry the extension) and the allowed actions; environment name is optional
-  and this project uses no GitLab environments. Shared runners are the only ones
-  supported and the publish job carries no `tags:`, so it is already on them. The
-  `repository.url` cross-check needs no separate verification — provenance
-  already passes it with the same identity.
-  Two things the entry did not anticipate, both of which change the shape of the
-  change rather than blocking it. **`SIGSTORE_ID_TOKEN` is not replaced**: the
-  documented GitLab snippet declares `NPM_ID_TOKEN` with
-  `aud: "npm:registry.npmjs.org"` *beside* it, so this is an addition to the
-  `id_tokens` block, not a swap. And **the YAML is not what deletes the
-  credential** — enabling a trusted publisher leaves the automation token just as
-  able to publish; what retires it is `Require two-factor authentication and
-  disallow tokens` on the package, which npm states does not affect trusted
-  publishers. That setting is the one that closes the loop this job's own comment
-  opens, where an automation token is used *because* a granular token fails
-  against 2FA on writes: trusted publishing does not bypass the prompt, it stops
-  being a token.
-  *What blocks the decision now is `pnpm`, and it is not a version to wait for.*
-  **pnpm does not implement the OIDC exchange at all.** `pnpm/pnpm#11526` — the
-  fix for the pnpm 11 regression that made this look like a supported path —
-  shows what its "OIDC support" is: `actions/setup-node` writes
-  `_authToken=${NODE_AUTH_TOKEN}` into `.npmrc`, pnpm used to pass the unresolved
-  placeholder through verbatim, and the fix treats it as empty so that **npm's**
-  credential exchange can be the sole auth source. pnpm gets out of the way; npm
-  does the work. That matches npm's own wording, which requires publishing
-  through npm directly or indirectly, and it matches the reports: every account
-  of pnpm publishing under OIDC is GitHub Actions, and there is **no record of
-  pnpm + GitLab + OIDC succeeding**. Stated at the strength the evidence carries:
-  this is a strong negative inference, not a documented refusal.
-  So the real cost is a tooling swap — `pnpm publish` back to `npm publish` in
-  this one job — and it is a swap this file has already priced once in the other
-  direction. The comment above records that moving to pnpm took
-  `COREPACK_ENABLE_STRICT` with it, that override having existed only so a bare
-  `npm` could run under a `packageManager` pinning pnpm; going back re-adds it.
-  It also needs npm ≥ 11.5.1 where `node:22-slim` ships 10.x, so the job gains an
-  npm upgrade step. None of that is prohibitive. It is simply a different
-  decision from the one this entry was filed as, which is why it stays here.
-  *One correction to the entry's own risk framing.* "It cannot be tested except
-  by publishing" is half wrong: registering a trusted publisher on npmjs.com is
-  free and reversible, and `NPM_TOKEN` can stay in place while it is tried. What
-  decides whether this can be rolled out incrementally is whether a failed OIDC
-  exchange falls back to the `_authToken` already in `.npmrc` or fails the
-  publish outright — unmeasured, and the thing to establish before touching the
-  job.
-  *Method note, because it is the reusable part.* The pinned pnpm bundle was the
-  obvious place to look and was the wrong one — `pnpm publish --help` on 10.28.0
-  omits the flags it accepts, exactly as this job's comment already records for
-  `--provenance`, so neither the help text nor the shipped bundle would have
-  answered it. The answer was in the upstream pull request.
-  **Promoted from `Under consideration` on 2026-08-08**, and what moved it is
-  that the question it was filed as is answered. It asked whether npm's trusted
-  publishers would accept this project at all; they will. What is left is a
-  known tooling swap with a priced cost, which is a decision to build rather
-  than a question — the preamble's own line, *a decision with an argument
-  attached*. One thing stays unmeasured and is the first act of building it, per
-  the discipline three paragraphs up: whether a failed OIDC exchange falls back
-  to the `_authToken` already in `.npmrc` or fails the publish outright. That
-  decides whether this rolls out incrementally beside the existing token or in
-  one cut, and it is cheap to establish because registering a trusted publisher
-  is free and reversible.
+- **Retiring `NPM_TOKEN`, which is now two settings on npmjs.com rather than
+  anything in this repository.** The mechanism landed under `[0.9.4]`: the
+  publish job requests an npm OIDC token and publishes through `npm`, which is
+  the only client that performs the exchange. What that did **not** do is remove
+  the credential, and the distinction is the point — enabling a trusted publisher
+  leaves an automation token just as able to publish. Two acts remain, neither of
+  them a commit:
+  **(1)** register the trusted publisher on the package — `Pseudorca`, `attest`,
+  `.gitlab-ci.yml` with the extension, the allowed actions; environment name is
+  optional and this project uses none, and shared runners are the only supported
+  kind, which the job already uses because it carries no `tags:`. Free and
+  reversible, and safe to do at any time: a failed exchange falls back to the
+  token rather than failing the publish (measured — see the `[0.9.4]`
+  entry). **(2)** set *Require two-factor authentication and disallow tokens* on
+  the package, which npm states does not affect trusted publishers. That is the
+  one that closes the loop the job's own comment opens, where an automation token
+  is used *because* a granular token fails against 2FA on writes: trusted
+  publishing does not bypass the prompt, it stops being a token.
+  *What is unmeasured, and it is not measurable from here.* Whether the exchange
+  actually succeeds against a gitlab.com project. Every documented ingredient
+  checks out and no plan requirement is stated anywhere, but there is no record
+  of anyone publishing from GitLab under OIDC — every account is GitHub Actions.
+  The first tagged release after the `[0.9.4]` change is the test, and the
+  fallback is what makes running it cheap: if the exchange fails, the release
+  still publishes and the job's verbose log says why. **Do not delete the token
+  before a release has been observed publishing without it.**
 
 ## Under consideration
 
@@ -5770,55 +5952,45 @@ have to gather again.
   design it. If it comes back the same shape, the seam is real and the schema
   follows; if it comes back different, `inspect` was the whole answer and the
   schema never needs to exist.
-
-- **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.
+  **Nothing currently makes that table arrive, which is a separate problem from
+  the three blockers and the one that gates all of them.** Raised in a product
+  review of `[0.9.1]`–`[0.9.3]` on 2026-08-19. The deciding evidence is an
+  artifact only an adopter can produce, and the path to producing it is: a row in
+  the README's document table, then a 214-line page, then a hand pass over four
+  questions, then writing the two mechanical properties from a prose
+  description, then choosing to report back. Five voluntary steps with no
+  scaffold at any of them, against a decision this entry has been waiting on
+  since `[0.9.2]`. An entry blocked on evidence that no shipped surface asks for
+  is blocked indefinitely, and the wait is not itself evidence of anything.
+  *The proposal is scaffolding the mechanism while still withholding the answer,*
+  which is the same split `[0.9.2]` already made and not a retreat from it: an
+  `examples/` directory holding the completeness and rot-binding assertions with
+  **no columns** — the enumeration that forces a row, and the check that a named
+  scenario is one `inspectProject` really declares — and the judgement columns
+  left for the adopter to add. What the page withholds is this repository's four
+  columns, and that stays withheld; what it currently also withholds is the two
+  properties it names as *mechanical*, and those are the half where a copy is not
+  an echo, because their content is fixed and the fourth finding does not apply
+  to them.
+  *What blocks it.* Whether a skeleton with no columns is still a shape that
+  comes back as a copy — the page's argument is that a template makes the answer
+  return its own question, and it is untested whether an adopter reads an empty
+  frame as an invitation or as a form to fill in. And it is a second artifact
+  claiming to be runnable consumer usage of the public API, which `pre-commit-check`
+  §6 already records as the category no gate reaches: the page's three samples
+  are unasserted today, and a fourth in a directory that looks executable would
+  be worse than a fenced block, not better, unless something runs it.
 
 - **Prefix ownership is inferred rather than declared, and the cost arrives only
   when adoption succeeds.** Design §11 records that the id grammar has no level
   above the requirement: the prefix is a convention, nothing allocates it, and
   `duplicate-prefix` can only report a collision that already happened.
   spec-kit's answer is a roadmap table — a stable id, an intent, a scope
-  boundary, dependencies — authored above the specs it decomposes into.
+  boundary, dependencies — authored above the specs it decomposes into. That
+  comparison is stated here rather than referred to, because the entry that
+  introduced the spec-kit reading has since been built and now sits under
+  `[0.9.4]` as the `open` field: an entry whose evidence rests on a
+  neighbour is one a promotion silently empties.
   *Two things have changed since that reading, and they point opposite ways.*
   The proposal is **smaller** than it looked: the mechanism partly exists.
   `loadRegistry` returns `prefixOwners` — first claim in sorted file order —
@@ -5857,53 +6029,26 @@ have to gather again.
   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
+  *What blocks the decision, restated on 2026-08-19 because half of what was
+  filed here is no longer true.* This entry was blocked on the empty archive and
+  on the corpus being rename-free, and only the second still holds. `archive/`
+  now has a real change in it — the `open` field, put through the workflow the
+  same day — so the store this would index exists. Its delta carries `added` and
+  nothing else, measured rather than assumed, so a backlink index is still
+  testable only against fixtures for the operation it is actually about. Note
+  what that says about the odds of the blocker clearing on its own: `--apply`
+  refuses RENAMED outright, so no change this repository archives can ever
+  exercise a rename until that refusal is lifted, and lifting it is a separate
+  decision with its own reason (`splice.ts` — deleting an entry has no smaller
+  span to fall back to). The blocker is therefore not "waiting for a rename to
+  happen"; it is downstream of a refusal nobody has proposed removing. And one
+  question the OpenViking reading does not answer, which is whether the chain is
+  wanted at all. §7 applies
   `RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
   deliberately, as far as anything written says. The case for recovering it is an
   external reference that outlives the rename, a ticket or a commit message
   naming a retired id, and nobody has reported one.
 
-- **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
@@ -5956,6 +6101,150 @@ have to gather again.
   looking at already being that page's subject, and this being a fifth of the
   same kind.
 
+- **`/inspect` returns five exported shapes and the page telling people to build
+  on them says nothing about whether they move.** Filed 2026-08-19 from a product
+  review of `[0.9.1]`–`[0.9.3]`. `inspect.ts` exports `Inspection`,
+  `ScenarioEvidence`, `EvidenceRow`, `ArchivedChangeRef` and
+  `RedEvidenceInspection`, and `intent-quality.md` carries three samples
+  destructuring them. `SCHEMA_VERSION` governs the `--json` envelope and nothing
+  governs these.
+  *The policy is not missing — its statement is.* The Versioning section at the
+  head of this file already binds them: removing or renaming a public API bumps
+  the minor, and under 0.x that is the breaking bump. So a reader who finds that
+  section is already told what they need. The gap is that the reader this export
+  was written for arrives through `intent-quality.md`, which is a method page
+  reached from the README's document table, and nothing on the path between the
+  two states it.
+  *Why it is worth a decision rather than a one-line edit.* The two candidate
+  sentences say opposite things to the person this needs. Restating the existing
+  promise reads as a stability guarantee and is the honest summary of current
+  policy; saying the shape may move before 1.0 is the more useful warning and
+  discourages exactly the adopter whose table would decide the judgement-schema
+  entry above. Which one is right depends on the 1.0 entry below, which is why
+  this is filed rather than fixed.
+  *One thing already measured, in the other direction.* `pre-commit-check` §6
+  records that changing what `/inspect` returns breaks three usage samples that
+  no gate can see. The internal awareness of this surface's fragility therefore
+  exists and is written down; the outward-facing half is what does not.
+
+- **The store worth retrieving is this file, not `archive/`, and no shape has
+  been proposed for either.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`, and it is the OpenViking reading turned back on the
+  repository that did the reading. Everything that came out of it is about
+  `archive/`, and the entries are no longer counted here — the number was wrong
+  on the day it was written, was corrected on 2026-08-19, and was wrong again by
+  the next commit, when the precedence rule left for design §11. Three strikes on
+  one figure is the section's own preamble arriving in the first person: a count
+  kept in prose with nothing to check it goes wrong quietly, and the repair is to
+  stop keeping one rather than to keep fixing it. But `archive/` holds `first-run.json` — typed,
+  low-information, and now read — beside a `proposal.md` that in this repository
+  carries a link, for the reason `[0.9.3]` gives: `CLAUDE.md` makes this file the
+  single decision record. **So the store that actually holds decisions with their
+  evidence attached is `CHANGELOG.md`, at 7,100 lines with the three foot
+  sections past 1,700 of them,** and the property that makes it valuable — a
+  design evaluated, priced and killed, with the reasoning that killed it — is
+  exactly the property that makes it unreadable in one pass. It is append-only
+  with no retrieval, which is the shape the OpenViking reading was about.
+  *What an agent would actually consume is a composition, not a new store.*
+  Given an `ATX-n`: its statement and params, the scenarios covering it, the
+  first-run evidence for each, and the paths to the change that introduced it.
+  Four of the five are already computable — `inspectProject` answers two,
+  `inspectRedEvidence` the third and the archived refs the fourth — and the fifth,
+  the reasoning, is the one with no index and no key. That asymmetry is the
+  finding: the retrieval problem is not in the half that was just made readable.
+  *One thing to unmerge before deciding.* `[0.9.3]` settled a question against
+  the fifth static command, and it settled it correctly and on the right
+  grounds — `first-run.json` is JSON, and `ATX-16`'s subject is reading
+  TypeScript without evaluating it, so joining that roster would turn a security
+  promise into a list of commands that do not run the suite. But that is a
+  ruling about **roster membership**, and it is being carried as though it also
+  ruled on whether such a command should exist. Those are separate, and only the
+  first was argued.
+  *What blocks the decision, and what would cheaply unblock it.* No measurement
+  exists of whether a bundle like this changes what an agent does — the one datum
+  quoted in `[0.9.3]` measured demand to read the archive **as prose**, which is
+  a third question again. The proposal is therefore a probe and not a build,
+  per this section's own discipline of re-measuring before implementing: assemble
+  the bundle by hand for one requirement, run one real change against it, and
+  record whether it was used, ignored, or used wrongly. One session, and it
+  decides between a command, a skill surface, and nothing. Building any of the
+  three before that measurement is the order `divergent-param` was designed in
+  and the order this file has already paid for once.
+
+- **A stage-1 spec can read its params through `delta.added` instead of by id,
+  and the merge that repoints its import cannot repoint that.** Filed 2026-08-19
+  from the first change this repository put through its own `changes/` workflow,
+  where it was written by the author of the workflow's own tooling — which is
+  most of why it is worth an entry rather than a fix.
+  `delta()` returns the delta *and* the registry of what it adds
+  (`withProposedRequirements`), so `reqs['ATX-81'].params.field` reads a proposed
+  requirement before the merge and a merged one after it. That is the whole
+  reason merging a spec changes its import and nothing else. Reaching through
+  `added` — `d.added['ATX-81'].params.field` — is equally correct during stage 1
+  and throws the moment `--apply` repoints the specifier at the registry, because
+  a registry has no `added`.
+  **Nothing catches it, and the reason is structural rather than an oversight.**
+  The archive gate runs *before* the rename, so the spec it graded is not the
+  spec the merge commits; `check` executes nothing, so it never evaluates the
+  accessor; and the type checker is satisfied on both sides of the merge only
+  because it is run against whichever half is currently on disk. It surfaced at
+  the next `verify`, as `spec-load-failed` — a correct diagnosis of the symptom
+  that names the file and not the cause. The window between `--apply` and the
+  next `verify` is the whole exposure, and in a workflow that ends at `--apply`
+  it is unbounded.
+  **The guidance already exists and did not prevent it, which is the finding.**
+  `registry.ts`'s doc comment on `delta` states the intended expression and the
+  rejected one, in those terms, on the function itself; the document `init`
+  writes shows the by-id form in its worked example. So this is not a gap in what
+  is written. It is a case of the correct form and an incorrect one being
+  *indistinguishable at the moment of writing* — both compile, both pass, both go
+  red for the right reason — with the difference appearing one command later.
+  *Two shapes, and they point opposite ways, which is why this is filed rather
+  than fixed.* **(1)** A `check` diagnostic: `parser.ts` already walks property
+  accesses inside spec bodies to find `.params`, so finding `.added` on a binding
+  imported from a `requirements.delta` path is the same walk and the same file.
+  It has to be a WARNING, because enumerating what a change adds is a legitimate
+  thing for a spec to do, and a WARNING is exactly the strength that did not stop
+  the author here. **(2)** A type-level refusal: have `delta()` return a type
+  without `added`, so `typecheck:all` refuses it with no new diagnostic, no
+  roster entry and no runtime cost. `DefinedDelta<T> = T & ProposedRequirements<T>`
+  carries `added` because `T` does, so this means `Omit<T, 'added'>` — and that
+  breaks the evaluating loader, which hands the same default export to
+  `applyDelta` typed as `RegistryDelta`. Whether that break is real or just needs
+  the internal path to name a different type is **unmeasured, and is the first
+  thing to establish**; it decides between the two shapes rather than being a
+  detail of one.
+  *What blocks the decision:* frequency, and it is the same blocker the `open`
+  entry carried before it — one occurrence, in one repository, on the first
+  change ever run through the workflow. That is a report rather than a
+  hypothetical, which is more than most entries here start with, and it is still
+  n=1. What would settle it cheaply is the next change: if the by-id form is
+  written without prompting, the guidance is sufficient and this is an anecdote;
+  if the reach-through appears again, the two shapes above are worth pricing.
+
+- **Nothing is frozen, and the evidence this repository is waiting for requires
+  somebody to build on something.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`. Three releases in five days each added public surface, and
+  as of `[0.9.3]` the CLI, `./define`, `./inspect`, the archive layout, the
+  judgement schema and any retrieval surface are all simultaneously open. Every
+  entry in this section that is blocked on an adopter — the judgement table above
+  being the sharpest — is asking someone to invest in a surface that is
+  documented as movable. That is a coherent thing to ask under 0.x and it is also
+  the reason the ask may never be answered.
+  *The proposal is a line rather than a milestone:* 1.0 freezes the CLI, `./define`
+  and `./inspect`, and everything currently blocked on an adopter's evidence —
+  the judgement schema, the backlink index, any archive retrieval — is explicitly
+  1.x. What that buys is not a version number; it is the only condition under
+  which "build your own counter-pressure on our export" is a reasonable thing to
+  ask of somebody.
+  *What blocks it.* Freezing `./inspect` five days after shipping it is freezing
+  on one adapter, which is the objection this repository raises against every
+  other premature interface and does not get to waive for its own. And the
+  release-notes discipline cuts both ways here: a 1.0 is a claim about what the
+  cost of adoption will be, and `Planned`'s own preamble records that **what a
+  release costs its adopters is not known on the day it is cut**. There is no
+  measurement to date of anyone adopting either export.
+
 ## Considered and rejected
 
 Decisions **not** to build something, kept where they can be found before the
@@ -6138,7 +6427,7 @@ weaker signal "some registry file failed to load, so suppress all
 `orphan-test`" is the other candidate and is a strictly worse `check` on a
 multi-file registry, where the other files are fine and their orphans are real.
 **The wrong *advice* was separated out and fixed in `[0.7.0]`; the noise is
-fixed under `[Unreleased]`, and the blocker above was the wrong question.**
+fixed under `[0.7.4]`, and the blocker above was the wrong question.**
 The mapping this entry called for could not be recovered, and did not have to
 be: what a suppression needs is not the broken file's *prefix* but the ids it
 declares, and those are written in its source. Reading them back is a source
@@ -6164,7 +6453,7 @@ breadth argument recorded above, which points the other way for both commands.
 *What rejected it is that the argument for it was entirely the noise, and the
 noise is gone.* Refusing was never justified by the load failure itself — it was
 justified by the wall of derived findings burying it, and the collapse under
-`[Unreleased]` removed the wall without touching either command's breadth. What
+`[0.7.4]` removed the wall without touching either command's breadth. What
 is left on the table is the breadth argument alone, and it points the other way
 for both: `check` is the command a pipeline runs first, its contract is seeing
 everything it can still see, and answering with three findings instead of nine
@@ -6265,7 +6554,7 @@ measurement** saying parsing costs anything here — this reader is
 `createSourceFile` per file with no type checking, which is the cheap half of
 what arktype pays for, and the fan-out measurement — filed as an entry in
 `Under consideration`, and now shipped as the two concurrency bounds in
-`[0.7.0]` and `[Unreleased]` — clocked `attest check` over 6000 spec files at
+`[0.7.0]` and `[0.9.0]` — clocked `attest check` over 6000 spec files at
 1.99 s total. Worse, a cache is a correctness hazard
 of precisely the kind this tool exists to detect: a stale analysis makes a
 **drift detector** report drift that has already been fixed, or miss drift
@@ -6287,7 +6576,7 @@ to be stronger than an mtime before the trade is even worth pricing.
 
 ### Zod Mini (`zod/v4-mini`) for the registry schema
 
-Evaluated alongside v4 (which shipped under `[Unreleased]`), on the same
+Evaluated alongside v4 (which shipped under `[0.8.0]`), on the same
 schema and the same 69-requirement registry, and it wins both numbers it is
 supposed to win:
 **0.249 ms** per parse against v3's 3.47 ms, and — the one v4 does not deliver —
@@ -6569,7 +6858,7 @@ current.
 
 The mechanism `ATX-37` sat under `Under consideration` waiting for, kept there
 on cost, and killed by measuring that cost rather than by paying it. The three
-sites it was aimed at are closed under `[Unreleased]` by hand-written scenarios;
+sites it was aimed at are closed under `[0.7.4]` by hand-written scenarios;
 what is rejected is the roster, and the argument is that **`src/cli/report.ts`'s
 exports are the wrong roster in both directions at once.**
 
@@ -6860,6 +7149,7 @@ rather than a scorer, which ranks.
 
 ## Releases
 
+[0.9.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.4
 [0.9.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.3
 [0.9.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.2
 [0.9.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.1

package/README.md

@@ -167,7 +167,7 @@ Every diagnostic carries a `code`, and every code has a section in
 ```
 ERROR   registry-not-static (requirements/upload.reqs.ts:5)
     Value is not a literal.
-    → https://gitlab.com/Pseudorca/attest/-/blob/v0.9.3/docs/en/troubleshooting.md#registry-not-static
+    → https://gitlab.com/Pseudorca/attest/-/blob/v0.9.4/docs/en/troubleshooting.md#registry-not-static
 ```
 
 The anchor **is** the code, so the link cannot point somewhere the section

package/dist/core/apply.js

@@ -97,6 +97,10 @@ export function applyDelta(base, d) {
             ...patch,
             params: { ...existing.params, ...(patch.params ?? {}) },
             outOfScope: patch.outOfScope ?? existing.outOfScope,
+            // Replaced wholesale rather than merged, exactly as `outOfScope` is: a
+            // patch that closes a question says so by writing the list that remains,
+            // and a union would make closing the last one impossible to express.
+            open: patch.open ?? existing.open,
         };
         const parsed = RequirementSchema.safeParse(merged);
         if (!parsed.success) {
@@ -209,6 +213,7 @@ function canonical(req) {
         // against itself. Code-unit order throughout, and `sortDeep` says why.
         params: sortDeep(req.params),
         outOfScope: [...req.outOfScope],
+        open: [...req.open],
     });
 }
 //# sourceMappingURL=apply.js.map

package/dist/core/docs.d.ts

@@ -8,7 +8,7 @@
  * and the `##` headings of both language documents, so landing here cannot
  * produce a dead link.
  */
-export declare const ISSUE_CODES: readonly ["add-conflict", "add-invalid", "added-id-unmerged", "apply-no-prefix-owner", "apply-unsupported-delta", "change-not-found", "compiler-unsupported", "declared-not-run", "duplicate-prefix", "duplicate-requirement", "empty-spec", "internal-error", "invalid-change-name", "missing-spec-doc", "modify-invalid", "modify-missing", "never-red", "non-scalar-interpolation", "orphan-from-failed-registry", "orphan-test", "possible-drift", "proposed-spec-name-taken", "proposed-spec-unclaimed", "rationale-placeholder", "registry-invalid", "registry-no-default", "registry-not-static", "rename-source-missing", "rename-target-exists", "rename-target-invalid", "spec-in-change-dir", "spec-load-failed", "stale-spec-doc", "tests-red", "unbound-param", "uncovered-requirement", "unknown-target", "unreadable-file", "unsafe-target-path"];
+export declare const ISSUE_CODES: readonly ["add-conflict", "add-invalid", "added-id-unmerged", "apply-no-prefix-owner", "apply-unsupported-delta", "change-not-found", "compiler-unsupported", "declared-not-run", "duplicate-prefix", "duplicate-requirement", "empty-spec", "internal-error", "invalid-change-name", "missing-spec-doc", "modify-invalid", "modify-missing", "never-red", "non-scalar-interpolation", "open-unresolved", "orphan-from-failed-registry", "orphan-test", "possible-drift", "proposed-spec-name-taken", "proposed-spec-unclaimed", "rationale-placeholder", "registry-invalid", "registry-no-default", "registry-not-static", "rename-source-missing", "rename-target-exists", "rename-target-invalid", "requirement-open", "spec-in-change-dir", "spec-load-failed", "stale-spec-doc", "tests-red", "unbound-param", "uncovered-requirement", "unknown-target", "unreadable-file", "unsafe-target-path"];
 export type IssueCode = (typeof ISSUE_CODES)[number];
 /**
  * The page explaining `code`, or `undefined` when nothing explains it.

package/dist/core/docs.js

@@ -37,6 +37,7 @@ export const ISSUE_CODES = [
     'modify-missing',
     'never-red',
     'non-scalar-interpolation',
+    'open-unresolved',
     'orphan-from-failed-registry',
     'orphan-test',
     'possible-drift',
@@ -49,6 +50,7 @@ export const ISSUE_CODES = [
     'rename-source-missing',
     'rename-target-exists',
     'rename-target-invalid',
+    'requirement-open',
     'spec-in-change-dir',
     'spec-load-failed',
     'stale-spec-doc',

package/dist/core/gate.d.ts

@@ -120,6 +120,14 @@ export declare function notRunIssues(plan: AttestPlan, run: RunResult, specific?
  * never a moment when its scenario was supposed to fail.
  */
 export declare function neverRedIssues(plan: AttestPlan, addedIds: readonly string[], firstRun: RedRecord): Issue[];
+/**
+ * Every requirement that still declares an open question.
+ *
+ * Exported for the same reason `neverRedIssues` is: it is one of the gate's
+ * obligations, and a caller projecting the gate's verdict has to reach the same
+ * answer from the same function rather than re-deriving it.
+ */
+export declare function openIssues(registry: Registry): Issue[];
 /**
  * Decide whether a change may be archived. Returns the blocking issues; an
  * empty array means the gate passes (design §8). Checks, in order:

package/dist/core/gate.js

@@ -171,6 +171,27 @@ export function neverRedIssues(plan, addedIds, firstRun) {
     }
     return issues;
 }
+/**
+ * Every requirement that still declares an open question.
+ *
+ * Exported for the same reason `neverRedIssues` is: it is one of the gate's
+ * obligations, and a caller projecting the gate's verdict has to reach the same
+ * answer from the same function rather than re-deriving it.
+ */
+export function openIssues(registry) {
+    const out = [];
+    for (const [id, req] of Object.entries(registry)) {
+        for (const question of req.open) {
+            out.push({
+                level: 'ERROR',
+                code: 'open-unresolved',
+                reqId: id,
+                message: `Requirement "${id}" still declares an open question, so the registry is not done: ${question} Answer it and remove the entry from open, then run the gate again.`,
+            });
+        }
+    }
+    return out;
+}
 /**
  * Decide whether a change may be archived. Returns the blocking issues; an
  * empty array means the gate passes (design §8). Checks, in order:
@@ -209,6 +230,23 @@ export function evaluateGate({ registry, plan, run, addedIds, unmergedAddedIds,
     if (addedIds && addedIds.length > 0) {
         blocking.push(...neverRedIssues(plan, addedIds, firstRun ?? {}));
     }
+    // 6) Open questions: nothing in the end-state registry may still be undecided.
+    //
+    // **Over the whole registry rather than the ids this change adds**, which is
+    // where it parts company with step 5 above. `never-red` is scoped to added ids
+    // because "was ever observed failing" is a fact about history and cannot be
+    // demanded retroactively of a requirement written straight into the base
+    // registry. An open field is not a historical fact; it is a claim that is true
+    // right now, so step 1's whole-registry re-validation is the precedent this
+    // belongs to. The scoping is also what closes the path the narrow form would
+    // open: `applyDelta` merges a MODIFIED patch field-wise, so an id that
+    // archived long ago can acquire `open` from a later change, and an
+    // added-ids-only gate would never look at it.
+    //
+    // The cost is deliberate: one unresolved question anywhere blocks every
+    // unrelated change from archiving. That is the intended reading of a registry
+    // that is not done, and it is recoverable by answering the question.
+    blocking.push(...openIssues(registry));
     return blocking;
 }
 //# sourceMappingURL=gate.js.map

package/dist/core/render.js

@@ -83,6 +83,7 @@ function sanitised(registry) {
             rationale: control(req.rationale),
             params: Object.fromEntries(Object.entries(req.params).map(([k, v]) => [control(k), sanitisedValue(v)])),
             outOfScope: req.outOfScope.map(control),
+            open: req.open.map(control),
         };
     }
     return out;
@@ -231,6 +232,13 @@ function section(id, req) {
     if (req.outOfScope.length > 0) {
         out.push('', '**Out of scope**', '', ...req.outOfScope.map((s) => `- ${prose(s)}`));
     }
+    // Last, and rendered at all because this document is the only human review
+    // surface a requirement has: a reader who is told what a requirement promises
+    // without being told what about it is still undecided has been told the
+    // stronger half of a claim on its own.
+    if (req.open.length > 0) {
+        out.push('', '**Open**', '', ...req.open.map((s) => `- ${prose(s)}`));
+    }
     return out;
 }
 /** The statement as the document says it, with its params in place. */

package/dist/core/schema.d.ts

@@ -11,6 +11,7 @@ export declare const RequirementSchema: z.ZodObject<{
     rationale: z.ZodString;
     params: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodType<ParamValue, unknown, z.core.$ZodTypeInternals<ParamValue, unknown>>>>;
     outOfScope: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    open: z.ZodDefault<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>;
 /**
  * The id grammar, on its own.
@@ -45,16 +46,19 @@ export declare const RegistrySchema: z.ZodPipe<z.ZodCustom<Record<string, {
     rationale: string;
     params?: Record<string, unknown> | undefined;
     outOfScope?: string[] | undefined;
+    open?: string[] | undefined;
 }>, Record<string, {
     statement: string;
     rationale: string;
     params?: Record<string, unknown> | undefined;
     outOfScope?: string[] | undefined;
+    open?: string[] | undefined;
 }>>, z.ZodRecord<z.ZodString, z.ZodObject<{
     statement: z.ZodString;
     rationale: z.ZodString;
     params: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodType<ParamValue, unknown, z.core.$ZodTypeInternals<ParamValue, unknown>>>>;
     outOfScope: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    open: z.ZodDefault<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>>>;
 /** Parsed (output) shapes — defaults applied. */
 export type Requirement = z.infer<typeof RequirementSchema>;

package/dist/core/schema.js

@@ -63,6 +63,17 @@ export const RequirementSchema = z.object({
     // instance.
     params: z.record(z.string(), paramValue).default({}),
     outOfScope: z.array(z.string()).default([]),
+    // What is still undecided about this requirement, in free text, one entry per
+    // question. Shaped as `outOfScope` rather than as a new kind of thing: every
+    // place that has to learn about it — the patch merge, both splice writers, the
+    // renderer — already carries that field's branch to copy, and a defaulted
+    // array means an empty list and an absent field are the same state, so no
+    // caller has to distinguish "closed" from "never opened".
+    //
+    // No grammar is imposed on an entry. A greppable free-text line is what
+    // spec-kit's `[NEEDS CLARIFICATION: …]` is, and constraining it here would be
+    // deciding for every adopter what counts as a question.
+    open: z.array(z.string()).default([]),
 });
 /**
  * The id grammar, on its own.

package/dist/core/skill.js

@@ -132,6 +132,30 @@ promises is a two-stage workflow, and the stages are separate on purpose.
   or it is an \`unbound-param\` ERROR. A \`{placeholder}\` written into a
   *rationale* is a \`rationale-placeholder\` WARNING — rationales are not
   interpolated, so it would reach the rendered document with its braces intact.
+- **If you cannot determine a value, say so — do not pick one.** \`open\` is a
+  list of what is still undecided about the requirement, in free text, one entry
+  per question. Each is a \`requirement-open\` WARNING from the static commands,
+  which does not fail them, so a proposal may be legitimately half-finished
+  while you are still writing it. The archive gate is where it stops: it blocks
+  with \`open-unresolved\` while any requirement in the merged registry still
+  carries one, so "done" is never diluted.
+
+  \`\`\`ts
+  'AUTH-7': {
+    statement: 'The system MUST require a TOTP code within {totpWindowSec} seconds.',
+    rationale: 'A password alone no longer meets the account-takeover risk we accept.',
+    params: { totpWindowSec: 30 },
+    open: ['is 30 seconds right, or does the authenticator app dictate it?'],
+  },
+  \`\`\`
+
+  This matters more for you than for a human author, and the reason is worth
+  stating plainly: the schema will not let you leave the field out, so an agent
+  that cannot determine a number picks one. A scenario is then written against
+  the invented value, and the result is a single source that is perfectly
+  consistent and describes a promise nobody made — the exact drift this workflow
+  exists to prevent, arriving through the mechanism meant to stop it. Writing
+  the question down costs nothing and blocks nothing until archive time.
 - **A registry is a literal, and so is a delta.** Every value is written in the
   file: no imported constant (\`params: { maxMb: MAX_MB }\`), no computed value,
   no \`Date.now()\`. \`check\`, \`cover\` and \`render\` read \`*.reqs.ts\` with the
@@ -348,6 +372,7 @@ once. Branch on \`issues[].code\`, never on \`message\`:
 | --- | --- |
 | \`tests-red\` | a test is failing — the normal state until you are finished |
 | \`never-red\` | an added requirement's scenario has no recorded failing run |
+| \`open-unresolved\` | a requirement anywhere in the merged registry still declares an \`open\` question |
 | \`uncovered-requirement\` | a requirement in the applied registry has no scenario |
 | \`declared-not-run\` | a scenario was declared but never executed (\`skip\` / \`only\`?) — withdrawn when one of the two rows below already explains its file, so it never stands in for a load failure |
 | \`spec-load-failed\` | a spec file could not be imported, so nothing in it ran. The run output carries the import error itself; this names which file it stopped |

package/dist/core/splice.d.ts

@@ -18,11 +18,11 @@ export declare class UnwritableValue extends Error {
  * body needs one after, and putting that decision here would mean this function
  * had to be told which case it was in anyway.
  *
- * `params` and `outOfScope` are omitted when empty rather than written as `{}`
- * and `[]`. The schema defaults both, so the two spellings mean the same thing,
- * and the shorter one is what a person writing this entry by hand would have
- * produced — which is the standard for a file `--apply` is merging into rather
- * than generating.
+ * `params`, `outOfScope` and `open` are omitted when empty rather than written
+ * as `{}` and `[]`. The schema defaults all three, so the two spellings mean the
+ * same thing, and the shorter one is what a person writing this entry by hand
+ * would have produced — which is the standard for a file `--apply` is merging
+ * into rather than generating.
  */
 export declare function requirementSource(id: string, req: Requirement, indent: string): string;
 /**

package/dist/core/splice.js

@@ -148,11 +148,11 @@ function paramSource(value) {
  * body needs one after, and putting that decision here would mean this function
  * had to be told which case it was in anyway.
  *
- * `params` and `outOfScope` are omitted when empty rather than written as `{}`
- * and `[]`. The schema defaults both, so the two spellings mean the same thing,
- * and the shorter one is what a person writing this entry by hand would have
- * produced — which is the standard for a file `--apply` is merging into rather
- * than generating.
+ * `params`, `outOfScope` and `open` are omitted when empty rather than written
+ * as `{}` and `[]`. The schema defaults all three, so the two spellings mean the
+ * same thing, and the shorter one is what a person writing this entry by hand
+ * would have produced — which is the standard for a file `--apply` is merging
+ * into rather than generating.
  */
 export function requirementSource(id, req, indent) {
     const inner = `${indent}  `;
@@ -172,13 +172,28 @@ export function requirementSource(id, req, indent) {
         lines.push(`${inner}params: { ${body} },`);
     }
     if (req.outOfScope.length > 0) {
-        lines.push(`${inner}outOfScope: ${outOfScopeSource(req.outOfScope)},`);
+        lines.push(`${inner}outOfScope: ${stringListSource(req.outOfScope)},`);
+    }
+    // Reachable only through a delta the gate never approves — `open-unresolved`
+    // blocks any end state that still carries one, so an ADDED entry written here
+    // has an empty list. Emitted anyway rather than left out: this function's
+    // contract is to write the requirement it is given, and a writer silently
+    // shorter than the schema is exactly the divergence the MODIFIED half below
+    // was found to have.
+    if (req.open.length > 0) {
+        lines.push(`${inner}open: ${stringListSource(req.open)},`);
     }
     lines.push(`${indent}}`);
     return lines.join('\n');
 }
-/** One `outOfScope` list as source. Shared with the modification writer below. */
-function outOfScopeSource(entries) {
+/**
+ * One list-of-strings field as source — `outOfScope` or `open`.
+ *
+ * One function for both, and named for the shape rather than for either field,
+ * so a third such field does not arrive with a third spelling of the same
+ * emitter. Shared with the modification writer below.
+ */
+function stringListSource(entries) {
     return `[${entries.map((s) => tsString(s)).join(', ')}]`;
 }
 /** One `params` key as source, at the key order the emitter writes everywhere. */
@@ -290,14 +305,24 @@ export function spliceModifications(file, source, changes) {
             }
             else if (name === 'outOfScope') {
                 if (!sameValue(before.outOfScope, after.outOfScope)) {
-                    out.at(name, span, outOfScopeSource(after.outOfScope));
+                    out.at(name, span, stringListSource(after.outOfScope));
+                }
+            }
+            else if (name === 'open') {
+                if (!sameValue(before.open, after.open)) {
+                    out.at(name, span, stringListSource(after.open));
                 }
             }
             else if (name === 'params') {
                 editParams(layout, before, after, out);
             }
             // Any other field is one the schema does not define, and not this
-            // module's to rewrite or to remove.
+            // module's to rewrite or to remove. `open` is above rather than here for
+            // exactly that reason: adding it to the schema without adding it to this
+            // loop would let the gate approve an end state where a question is closed
+            // while the file on disk still carries it — a divergence between the
+            // registry the verdict was reached on and the registry the merge commits,
+            // with nothing anywhere comparing the two.
         }
         if (!layout.fields.has('statement') && before.statement !== after.statement) {
             openField('statement', tsString(after.statement));
@@ -311,7 +336,10 @@ export function spliceModifications(file, source, changes) {
                 openField('params', `{ ${fresh.join(', ')} }`);
         }
         if (!layout.fields.has('outOfScope') && !sameValue(before.outOfScope, after.outOfScope)) {
-            openField('outOfScope', outOfScopeSource(after.outOfScope));
+            openField('outOfScope', stringListSource(after.outOfScope));
+        }
+        if (!layout.fields.has('open') && !sameValue(before.open, after.open)) {
+            openField('open', stringListSource(after.open));
         }
         if (opened.length > 0) {
             const point = layout.fieldInsertion;

package/dist/core/validator.d.ts

@@ -19,8 +19,9 @@ export declare function uncoveredIssues(registry: Registry, plan: AttestPlan): I
  * - unbound-param: a statement placeholder has no matching param
  * - non-scalar-interpolation: a statement placeholder names a structured param
  *
- * and one WARNING:
+ * and two WARNINGs:
  * - rationale-placeholder: a `{name}` in a rationale, which is never interpolated
+ * - requirement-open: the requirement names something still undecided about it
  *
  * and one more WARNING, which exists only when a registry file failed to load:
  * - orphan-from-failed-registry: the scenarios attesting ids that file declares

package/dist/core/validator.js

@@ -34,8 +34,9 @@ export function uncoveredIssues(registry, plan) {
  * - unbound-param: a statement placeholder has no matching param
  * - non-scalar-interpolation: a statement placeholder names a structured param
  *
- * and one WARNING:
+ * and two WARNINGs:
  * - rationale-placeholder: a `{name}` in a rationale, which is never interpolated
+ * - requirement-open: the requirement names something still undecided about it
  *
  * and one more WARNING, which exists only when a registry file failed to load:
  * - orphan-from-failed-registry: the scenarios attesting ids that file declares
@@ -208,6 +209,24 @@ export function validateStructure(registry, plan, unreadable = []) {
             });
         }
     }
+    // requirement-open: the requirement says what is still undecided about it.
+    // WARNING and not an ERROR, because the four static commands are where an
+    // author works while a proposal legitimately still has questions in it —
+    // failing here would push them back to inventing a value, which is the
+    // behaviour the field exists to replace. What refuses to call such a registry
+    // done is the archive gate (`open-unresolved`), the same asymmetry `never-red`
+    // runs on. One issue per question rather than one per requirement: each is a
+    // separate thing to answer, and a reader resolving them wants them listed.
+    for (const [id, req] of Object.entries(registry)) {
+        for (const question of req.open) {
+            issues.push({
+                level: 'WARNING',
+                code: 'requirement-open',
+                reqId: id,
+                message: `Requirement "${id}" is still open: ${question} Answer it and remove the entry from open — the archive gate refuses a registry that still carries one.`,
+            });
+        }
+    }
     return issues;
 }
 /**

package/package.json

@@ -1,8 +1,9 @@
 {
   "name": "@am_shork/attest",
-  "version": "0.9.3",
+  "version": "0.9.4",
   "description": "TDD-native spec framework: tests are the source of truth for verification, ID-bound requirements the source of truth for intent.",
   "type": "module",
+  "packageManager": "pnpm@10.28.0",
   "engines": {
     "node": ">=20.19"
   },
@@ -41,6 +42,24 @@
   "publishConfig": {
     "access": "public"
   },
+  "scripts": {
+    "clean": "node -e \"require('fs').rmSync('dist', {recursive: true, force: true})\"",
+    "build": "pnpm run clean && tsc -p tsconfig.json",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "typecheck:all": "tsc -p tsconfig.typecheck.json",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:consumer": "pnpm run build && vitest run --config vitest.consumer.config.ts",
+    "lint": "eslint .",
+    "prepack": "pnpm run build",
+    "prepublishOnly": "pnpm run test:consumer",
+    "attest": "node bin/attest.js",
+    "check:self": "node bin/attest.js check self",
+    "verify:self": "node bin/attest.js verify self",
+    "cover:self": "node bin/attest.js cover self",
+    "render:self": "node bin/attest.js render self --out self/requirements/SPEC.md",
+    "render:self:check": "node bin/attest.js render self --out self/requirements/SPEC.md --check"
+  },
   "keywords": [
     "tdd",
     "spec",
@@ -67,20 +86,15 @@
     "vite": "^8.1.5",
     "vitest": "^4.1.10"
   },
-  "scripts": {
-    "clean": "node -e \"require('fs').rmSync('dist', {recursive: true, force: true})\"",
-    "build": "pnpm run clean && tsc -p tsconfig.json",
-    "typecheck": "tsc -p tsconfig.json --noEmit",
-    "typecheck:all": "tsc -p tsconfig.typecheck.json",
-    "test": "vitest run",
-    "test:watch": "vitest",
-    "test:consumer": "pnpm run build && vitest run --config vitest.consumer.config.ts",
-    "lint": "eslint .",
-    "attest": "node bin/attest.js",
-    "check:self": "node bin/attest.js check self",
-    "verify:self": "node bin/attest.js verify self",
-    "cover:self": "node bin/attest.js cover self",
-    "render:self": "node bin/attest.js render self --out self/requirements/SPEC.md",
-    "render:self:check": "node bin/attest.js render self --out self/requirements/SPEC.md --check"
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "esbuild"
+    ],
+    "overrides": {
+      "brace-expansion@<5.0.9": ">=5.0.9",
+      "js-yaml@<4.3.1": ">=4.3.1",
+      "nanoid@<3.3.17": ">=3.3.17",
+      "postcss@<8.5.23": ">=8.5.23"
+    }
   }
-}
+}