feat(gates): make the second key real — lock the seal to a filled spec, and record it on every close

[bhyi4]

Yeoul and mirror-stack are meant to be two keys: yeoul decides the design, mirror-stack seals the kill-condition before compute. Measured 2026-08-26: one side had no lock, and the other had no record.

1. The lock was missing

arc-prereg attached a seal to an arc whose spec had every field blank — Goal, Success condition, Kill-condition, Constraints — with exit 0 and not a word printed:

$ arc-open emptyspec-probe --arcs-dir=$T/arcs      # spec: all fields blank
$ arc-prereg $ARC probe-claim-0001 $T/ledger.jsonl
🔒 prereg linked: arc … ← seal probe-claim-0001     ← rc=0, no warning

arc-prereg now refuses unless those four fields carry substance, judged by the same substance_check.py the close gate uses — with its positive control run first. An instrument is trusted because it just proved it can still say no, not because it printed green.

Two details decide whether the lock is real rather than decorative:

• Two spec shapes exist. - **Goal**: (arc-open) and - **Goal** — what do you want to learn / build (observable): (templates/spec.md). substance_check's extractor only strips the first, so feeding it a template line verbatim would hand the judge the prompt as if it were the answer — a lock that opens on a spec nobody filled. Normalised at this call site rather than by widening the shared extractor that ten correct callers depend on. DK-10 is that vacuity check.
• templates/spec.md's Kill-condition line had no colon — it ended ★No falsifier = untestable., so there was nowhere to write the one field the seal is about. DK-11 fails without the fix.

2. The record was missing on the half that matters

A KILL close wrote ⚠️ UNSEALED … into its _SUMMARY. A GO close wrote nothing about the seal at all:

grep -c 'UNSEALED\|prereg\|seal'  <GO close _SUMMARY>   →  0

The notice lived inside emit_kill_defense(), so it existed only on the path that says this failed — while GO is the label that opens the next step. A yeoul-only environment closed arcs that read identically to fully-locked ones.

• Every close now carries a harness-owned **Second key (pre-registration)** line. The 2nd run requires it verbatim, so "closed with one key" cannot be edited into "closed with two" (DK-08). It runs last of the gates on purpose: a summary damaged by an encoding fault must fail with the gate that names the real cause, not with a mismatch here that names the wrong one.
• The closing banner said blanks & KILL-defense checked as a fixed string on every successful close — including GO closes where no KILL-defense section was ever produced. It now names the gates that actually ran.
• The knowledge index printed its Sealed claim row only when a claim existed, so an unsealed close produced an entry with the promised column simply absent — indistinguishable from an old row or a failed write. It now says none (closed with one key only).

3. The guarantee: this must not make mirror-stack an install requirement

The lock lives only in arc-prereg, which is only ever called by someone who already has a ledger. Measured before and after — with no mirror-stack anywhere on PATH, every other command still runs:

yeoul-new · arc-open · arc-list · status · arc-roles · build-handoff · verify-gate · loop-guard · a full arc-close round trip → 9/9 rc=0

DK-09 pins it. Putting the same refusal in arc-close would have broken all nine and turned a lock into an installation prerequisite.

Tests

gates	72/72 (61 before)
revert-to-red	all four changed files reverted in turn → suite red for each
pre-publish guard	clean

Two pre-existing tests linked a seal to an arc whose spec was never written. That setup is no longer valid, so they fill the design first — the thing under test there is the seal link, not the spec.