[IanFrelinger]

SPEC-006 S-7: a signed gate record now belongs to one store, and says which inside its signed bytes

The residual this closes, in SPEC-006's own words:

A signed gate record carries no store identity until S-7. One copied from a sibling store under the
same operator key verifies, pins, anchors the store it was copied into — creating an expectation
where there was none, against which every other record there is then judged — and counts toward that
store's self-extension budget. The file-name rule does not catch it: the copy keeps its own
{id}.json name.

GateSigningActivation mints a StoreId (32 lowercase hex over 128 bits from
RandomNumberGenerator), inside the marker's signed bytes, only where a marker is minted. GateRecord
gains a nullable StoreId. WriteAsync strips it with the signature fields so it is never inherited
from incoming bytes, then re-applies the identity taken from the honoured marker before computing
the signature, so the field is under the signature and cannot be relabelled.
GateSignatureExpectation gains a fifth refusal leg inside the present-signature arm, after the
trusted-signer pin, so every pre-existing refusal message stays byte-identical.

Minted, never derived, and the threat model is the reason. Not from the store's path — a path-keyed
identity is lost by a clone, a remount or a move, so it would refuse every record in a relocated store,
including one delivered by an ordinary checkout. Not from the store's contents — every input such a
derivation could reach is a file in the directory being attacked, so an actor who can write the state
root must not be able to compute the victim's identity. It lives in the marker because that is the one
artefact in the state root the operator's key signs.

Backward compatibility is normative, not an afterthought. CanonicalJson omits nulls, so a record
signed before StoreId existed has no such field in the bytes its signature covers. No existing
canonical hash moved, so no grandfather inventory entry was invalidated. A record carrying no identity
keeps verifying in any store and is not a mismatch — the spec requires exactly that, because a record
signed without the field cannot be distinguished from one written under any store.

What two rounds of adversarial review changed, which is most of why this is worth reading

A regression the first pass introduced and did not disclose. Binding the identity from a marker a
keyless reader merely "corroborates" — where corroboration is a record signed under the marker's own
key, both halves of which an actor who can write the state root supplies themselves — made the store
refuse its own genuine records, with a message accusing them of being copies. Those same three files
read fine before the change. It also violated, verbatim, the rule the same method already states for the
pinning set: key material only — deriving it from the records would accept whatever key an attacker
re-signed them all with. The identity is now bound only when _trustedSigners.Count > 0, and a fact
asserts a keyless reader still reads its own records under a planted marker and corroborating record.

The rule the whole feature rests on had no test. A reviewer hoisted the identity read out of
if (honoured) and let the unvouched replacement inherit an identity, ran it, and got 56/56 —
byte-identical to baseline. Every marker plant in the suite passed storeId: null, so nothing
exercised an unvouched marker that declares an identity. Both halves now have facts.

A non-vacuity guard that was itself vacuous. The narrowed residual asserted
carried.StoreId.Should().Be(<A's identity>) to prove a copied record names its origin — but in a build
minting no identity at all, both sides are null and Be(null) passes. Fixed with NotBeNull() first;
the mutation now reddens ten facts instead of sailing through.

Three sentences this branch made inaccurate, corrected rather than softened. A SPEC-006 mitigation
sentence was false in both halves (contradicted by an existing passing conformance fact); a comment
reasoned "a store with no identity has no honoured marker to attest one", which the keyless fix made
false; and the operator-facing refusal claimed the copy came "from another store under the same operator
key" while the leg compares no keys — after a rotation the record and marker are legitimately signed
by two different vouched-for keys. The message now states only what the leg established.

What this does NOT close, said plainly

• A whole-store copy — records and marker together — remains indistinguishable from the original.
  The spec says so and this branch claims nothing more. The identity travels with the marker.
• A keyless consumer gets no S-7 protection, because the identity is bound only where key material
  vouches for the marker. This is now a disclosed residual with its own inverted fact and a row in
  GateSignatureResidualTests.Residuals. It deliberately does not reuse the keyless fact above: that
  one asserts the store still works, which would stay green on the day the protection is regained.
• Records signed before StoreId existed stay transplantable for their lifetime. Normative.
• Forward compatibility, newly disclosed: a pre-S-7 binary drops StoreId on deserialize and
  recomputes different bytes, so it reports a post-S-7 store's records as not verifying. Recorded so
  nobody diagnoses a mixed-version lane as a forgery.

The one decision left open

How a store adopts an identity on the pre-S-7 upgrade path. Today one file planted in gates/,
signed under any key the machine vouches for, decides what the operator's own
ashlar gates sign-activate --repair signs — no marker deletion, no disagreement. A store whose marker
predates S-7 has zero identity-bearing records of its own, so the only verifying record that can name
an identity is a copied one, and the vote is first-non-null-unopposed.

The disclosure is restated to what it actually takes, and the disagreement rule SPEC-006 states as a
MUST is now pinned by a fact, so a refactor to "majority" or "first wins" cannot widen it silently. No
mechanism was implemented.

Options, costed: unanimity-plus-a-count-floor is the cheap one and buys almost nothing here, since
the stores it protects are the ones already safe. An explicit operator adopt step that prints the
candidate identity and which files name it is the one that actually closes it — it puts a human between
a planted file and a signed adoption, matching the shape this repo already trusts for the grandfather
inventory — and it needs CLI surface in application/, which layer-boundary gives no legal base to
combine with src/. Recommendation: ship the disclosure now, do the adopt step as a follow-up PR.
If that is taken, Two_disagreeing_store_identities_carry_forward_neither_on_a_repair is the fact whose
assertion moves, and its first-wins mutation is the one to re-run.

Verification

Linux devtest container, never the host.

• cert-gate: 1224/1224 passed, 0 warnings.
• Full Ashlar.sln build succeeded (2 warnings, neither a warning CS — the harness's own SourceLink
  pair, which its header documents as absent in CI).
• Every fact mutation-checked, each mutation reddening its own fact and nothing else, and the
  load-bearing ones independently re-proven by reviewers running their own mutations rather than
  reading the author's numbers. All four original blocking findings confirmed resolved in the committed
  code, not in the report about it.

One measurement worth recording so nobody misreads it later: a reviewer saw
RollbackGateExemptionTests.A_second_breach_at_the_default_retention_window_is_still_contained fail
once and pass on re-run at the same tree. That was at the pre-rebase base, which predated the stepping
clock that fixed it (#656). This branch is rebased past that fix, and the failure has not recurred.

🤖 Generated with Claude Code