docs: narrow the v0.5 Layer B gate and accept the attestation cost

[vunm-dev]

PDN-0004, S7 scoping. This is a design-only change for the owner to decide on before S7 is built. Design: §20.2 release gate, §26.2 S7. Issue #12.

Proposal

1. Narrow the Layer B release gate from 13 scenarios (F1, F2, F4, F8, F10–F15, F18, F27) to 6, one per invariant (F14 added back in review):

   • F1: a worker does not accept its own work (I-1);
   • F2: pickup does not trust a forged accepted line after a crash;
   • F11: an interrupted launch window is never "not launched";
   • F14: a crash between verdict and projection is repaired only after the §13.3 re-checks (changed task, changed artifact);
   • F18: a surviving descendant blocks a stop and a second writer;
   • F27: routing respects an owner-mandated executor.

   Layer A already runs all of them in CI against the reference host. Layer B only has to show that a real host follows the prose. The rest become post-release evidence.

2. Accept owner attestation as the v0.5 cost. The S6 measurements (feat: measured executor cards for kiro-cli, claude and codex #21) show that no shipped executor gives safe machine stop evidence on macOS: Claude Code and Codex tool shells survive SIGKILL, and kiro-cli could detach through a trusted shell. So every delegated attempt ends with a person confirming no process remains. v0.5 documents this in the README and release notes instead of weakening §8.3. Lowering it is v0.6 work (a macOS containment scope, or measured normal-exit behavior).

3. In Layer B the owner attests by hand. The harness never records owner-attested itself.

Why now

v0.5 has grown to roughly 50k lines. About 40k of those are fixtures, recorded evidence and byte-identical copies of the helper; about 8.5k are hand-written. The full 13-scenario Layer B gate, with a person attesting every attempt, would make S7 the largest slice.

Tests

tests/docs.sh: 32 (design text only).

🤖 Generated with Claude Code

[vunm-dev]

One release-gate coverage issue needs adjustment. Keeping explicit human stop attestation and documenting the limitations of historical evidence is consistent with the existing protocol. Validation: all 32 documentation checks passed, the diff has no whitespace errors, and GitHub CI is green. Recommendation: narrow the gate to six scenarios, retaining F14 alongside the proposed five.

[vunm-dev]

[P2] Keep F14 in the real-host release gate

C6 recovery relies on host behavior that the helper does not enforce: projected checks the persisted accepted verdict, checkbox and attempt line, but does not recompute the task/artifact digests or rerun verification. If the task or working tree changes after a crash between verdict and projection, a real host that skips the prose's rechecks can still project the historical verdict and mark the task complete. None of F1, F2, F11, F18 or F27 exercises this recovery branch; Layer A only proves that the reference host performs the rechecks. Retain F14 in the gate, including changed-task and changed-artifact cases after the verdict, so the narrower gate still tests this distinct false-acceptance path.

[vunm-dev]

Agreed; fixed in ef0bd54. I confirmed on the helper that cmd_projected checks only the persisted verdict, the checkbox and the Dispatched: … attempt: line. It neither recomputes the digests nor reruns a check, so the §13.3 re-checks are host prose that only a real host can be shown to follow.

• F14 is back in the gate, which now has six scenarios: F1, F2, F11, F14, F18, F27.
• The real-host run covers both the changed-task case (the verdict stays historical) and the changed-artifact case (digest mismatch), as the reference host already does in F14b and F14c.
• The post-release list is now F4, F8, F10, F12, F13, F15.

A deterministic alternative would be for projected to recompute both digests itself. That would move this guard out of prose, but it is a helper change, so I would take it as a separate follow-up only if you want it.