docs: resolve ADR 0018 open question 5 -- one fold into sha256-canon-v1

Adds ADR 0018 section 15 and DECISIONS D25. The eight hash-affecting
manifest additions land in one pass, into v1, before any real package
is signed - not behind a v2.

Why v1: a hash scheme version exists to protect history, and there is
no history to protect. Minting a v2 to carry additions no v1 package
ever saw leaves a version boundary that records nothing and that every
future reader has to learn about.

D6 is amended, not reversed. Its own reasoning - that hash semantics
are hard to change once real records exist - argues for completing the
allowlist now, because the allowlist is exactly the thing that becomes
unchangeable. D6 conflated two separable questions: the canonical form
and manifest allowlist, which get strictly more expensive with delay
and are unfrozen here, and acceptance of ADR 0010 as a whole, which
stays blocked on gates this work does not touch - C4's not-a-qualified
-e-signature wording, required-role semantics, and the D12 contract
bump. ADR 0010 stays Proposed with a completed allowlist, which is a
coherent state: the bytes are settled, the legal and contract
questions are not.

Recorded as a real precondition rather than an assumption: the builder
and canonicalizer are already shipped and running, with a golden-vector
self-check on load, so this is a code change. Confirm no
turnover_packages record carrying real signatures exists on any live
instance before the fold ships. If one does the decision inverts and
the additions go behind v2 - a signed package that stops verifying is
the outcome this ADR exists to prevent.

Partial folds are forbidden: each addition alone changes the canonical
bytes, so piecemeal shipping means several silent breaks instead of one
deliberate one. The golden vector is regenerated as the acceptance test.

Also completes the turnover-additions list with the two decided since
it was written - active operating restrictions per subject (section 13)
and template_version on every included check (section 14) - and marks
signature-role QC unblocked in the conflicts table.

Author: mds08011

docs/DECISIONS.md

@@ -307,3 +307,31 @@ engine scope LoopCheck refuses to become.
 **Rejected.** Hard-blocking phase entry; a dedicated `gates` collection (a
 gate is a check).
 **Cross-ref.** ADR 0018 §12; ADR 0007.
+
+### D25 — D6 amended — the turnover manifest folds into `sha256-canon-v1` now
+**Decision.** ADR 0018's eight hash-affecting manifest additions land in **one
+pass, into `sha256-canon-v1`**, before any real package is signed — not behind a
+`sha256-canon-v2`. D6 is **amended, not reversed**: the canonical form and
+manifest allowlist are unfrozen for this fold, while ADR 0010's *acceptance*
+stays blocked on its own gates (the "not a qualified e-signature" wording C4,
+required-role semantics, and the D12 contract bump). ADR 0010 stays **Proposed**
+with a completed allowlist. Partial folds are forbidden — each addition alone
+changes the canonical bytes, so piecemeal shipping means several silent breaks
+instead of one deliberate one. The golden vector is regenerated as the
+acceptance test.
+**Precondition.** The builder and canonicalizer are already shipped and running,
+so this is a code change. **Confirm no `turnover_packages` record carrying real
+signatures exists on any live instance before the fold lands.** If one does, the
+decision inverts and the additions go behind `sha256-canon-v2`; a signed package
+that stops verifying is the outcome the ADR exists to prevent. Test packages are
+discarded, not migrated.
+**Rationale.** A hash version exists to protect history, and there is no history
+to protect. A v2 carrying additions no v1 package ever saw would leave a version
+boundary that records nothing. D6's own reasoning — that hash semantics are hard
+to change once real records exist — argues *for* completing the allowlist now,
+because the allowlist is exactly the thing that becomes unchangeable. D6
+conflated the canonical form with acceptance of the ADR; they are separable, and
+only one of them gets more expensive with delay.
+**Rejected.** Accepting ADR 0010 wholesale (its legal and contract gates are
+untouched by this work); minting `sha256-canon-v2` (no history to protect).
+**Cross-ref.** ADR 0018 §15 and open question 5; ADR 0010; D6, D12.

docs/adr/0010-signatures-and-turnover-package.md

@@ -2,6 +2,23 @@
 
 **Status:** proposed · **Date:** 2026-07-10
 
+> **The manifest allowlist and canonical form are unfrozen for one fold**
+> (2026-08-04, DECISIONS **D25** amending D6). ADR 0018 adds eight
+> hash-affecting entries to the manifest, and they land **together, in
+> `sha256-canon-v1`** — not a v2 — because no real package has been signed, and
+> a version boundary that protects no history is worse than none. See
+> [ADR 0018 §15](0018-multi-vendor-startup-evidence-model.md) for the decision
+> and the enumerated additions.
+>
+> **Precondition before the fold ships:** confirm no `turnover_packages` record
+> carrying real signatures exists on any live instance. If one does, the
+> additions go behind `sha256-canon-v2` instead. The golden vector is
+> regenerated as the acceptance test; **partial folds are forbidden**, since
+> each addition alone changes the canonical bytes.
+>
+> **This does not accept ADR 0010.** C4's on-page wording, required-role
+> semantics, and the D12 contract bump still gate acceptance.
+
 **Implementation status (committed + review-hardened, 2026-07-12):** the
 migration (`turnover_packages` + `signatures`, `1789000026`), the server
 builder/canonicalizer (`pb_hooks/turnover.pb.js` + `turnover_canon.js`, with a

docs/adr/0018-multi-vendor-startup-evidence-model.md

@@ -627,6 +627,56 @@ manifest additions in the single fold that open question 5 recommends —
 real package is signed and v1 is simply defined to include it. **Decide and land
 this together with open question 5, not after it.**
 
+### 15. One fold into `sha256-canon-v1`, before any package is signed
+
+**Decided by the maintainer 2026-08-04, resolving open question 5.**
+
+Every manifest addition in this ADR is hash-affecting. The choice was to absorb
+them all into `sha256-canon-v1` now, or accept ADR 0010 as it stands and retire
+v1 into a `v2` later. **The fold happens now, in one pass, into v1.**
+
+**Why v1 rather than v2.** A hash scheme version exists to protect *history* —
+it lets old packages keep verifying under the rules they were sealed with. There
+is no history to protect: **no real package has been signed.** Minting a v2 to
+carry additions that no v1 package ever saw would leave a version boundary that
+records nothing, and every future reader would have to learn a distinction that
+never mattered. The cheap moment is the one where the cost is zero, and it does
+not come back.
+
+**Precondition, and it is a real one.** ADR 0010's builder and canonicalizer are
+**already shipped and running** (`pb_hooks/turnover.pb.js`,
+`turnover_canon.js`, with a golden-vector self-check on load). So this is a code
+change, not a documentation change. Before the fold lands, **confirm no
+`turnover_packages` record carrying real signatures exists on any live
+instance.** If one does, this decision inverts on the spot and the additions go
+behind `sha256-canon-v2` — a signed package that stops verifying is the one
+outcome this whole ADR exists to prevent. Test packages are discarded, not
+migrated.
+
+**Scope of the fold** — the eight additions listed above, landing together, with
+the **golden vector regenerated** as the acceptance test. Partial folds are
+forbidden: each one alone would change the canonical bytes, so shipping them
+piecemeal means several silent breaks instead of one deliberate one.
+
+**This does not accept ADR 0010, and D6 is amended rather than reversed**
+(DECISIONS D25). D6 froze ADR 0010 on the reasoning that "accepting it now
+hardens hash/attestation semantics that are hard to change once real records
+exist." That reasoning **argues for this fold, not against it** — the allowlist
+is precisely the thing that becomes unchangeable, so it is the thing to get
+complete while it is still free. D6 conflated two separable questions:
+
+- **the canonical form and manifest allowlist** — unfrozen by this decision,
+  because delay makes it strictly more expensive and never cheaper;
+- **acceptance of ADR 0010 as a whole** — still blocked, on gates this ADR does
+  not touch: the "not a qualified e-signature" wording (C4), required-role
+  semantics, and the API v1 contract bump (D12).
+
+So ADR 0010 stays **Proposed** with a completed allowlist. That is a coherent
+state: the bytes are settled, the legal and contract questions are not.
+
+**Unblocks §9.** The Conflicts table below recorded signature-role QC as
+"blocks on open question #5." It no longer does.
+
 ## What all of this adds to the frozen turnover package
 
 ADR 0010's manifest gains, per scope:
@@ -645,11 +695,17 @@ ADR 0010's manifest gains, per scope:
    ADR.
 6. **As-left conditions and scope-gap punch items** rendered as their own
    sections rather than buried in the punch list (§6).
+7. **Active operating restrictions, per subject** (§13) — the limit as data with
+   its cause and provenance. The one section whose primary reader is the
+   operator years later rather than the GC at turnover.
+8. **`template_version` on every included check** (§14) — the index that says
+   which revision of the questions a frozen answer set was complete for.
 
 Each addition is an allowlisted set of immutable fields entering the
 `sha256-canon-v1` canonical bytes, so **every one of them is a hash-affecting
 change** and must land before the first real package is signed, or behind a
-`sha256-canon-v2`. That is the sharpest sequencing constraint in this ADR.
+`sha256-canon-v2`. That is the sharpest sequencing constraint in this ADR, and
+it is resolved by open question 5 below: **one fold, now, into v1.**
 
 ## Alternatives rejected
 
@@ -747,7 +803,7 @@ change** and must land before the first real package is signed, or behind a
 | Configurable phases (§1) | ARCHITECTURE §7 rejects stored required-phase maps | Global vocabulary + template-library configuration; no per-project map |
 | No ambiguous blanks (§4) | ARCHITECTURE §6 deliberately records unanswered lines | Blank stays legal at capture; illegal at sign/freeze |
 | Typed values (§7) | CLAUDE.md constraint #5: exactly four response types | Limits are metadata on `value`; no fifth type |
-| Signature QC (§9) | DECISIONS D6 freezes ADR 0010 | **Blocks on open question #5** — ADR 0010 must be unfrozen first |
+| Signature QC (§9) | DECISIONS D6 freezes ADR 0010 | ~~Blocks on open question #5~~ **Unblocked 2026-08-04 (§15):** D6 is amended by D25 — the manifest allowlist and canonical form are unfrozen for one fold; ADR 0010's *acceptance* stays blocked on its own gates |
 | Vendor evidence UI (§5) | DECISIONS D7 parks the ADR 0017 UI | D7's trigger condition met; D7 amended by D21 |
 | Continuation UI (§10) | DECISIONS D8 parks the open→resolve UI | Same; D8 amended by D21 |
 | Punch party vocabulary (§6) | `docs/API.md` publishes `assigned_party` as v1 | Breaking; requires the D12 version bump — sequenced post-M3 |
@@ -777,10 +833,9 @@ change** and must land before the first real package is signed, or behind a
 4. **Asset/position split** — worth doing at all, or is the re-verification
    prompt achievable with a simpler "nameplate changed on this tag" event?
    (Open question #12.)
-5. **Hash versioning.** Accept ADR 0010 *after* folding these manifest
-   additions in (one canonical scheme), or accept it now and plan
-   `sha256-canon-v2`? Recommendation: fold first — no real packages are signed
-   yet, so the cheap moment is now.
+5. ~~**Hash versioning.**~~ **RESOLVED by the maintainer, 2026-08-04: fold
+   first, into `sha256-canon-v1`, before any real package is signed.** See
+   §15.
 
 *Questions 6–8 were raised by the source reading, not the summary. Full
 reasoning in [`0018-review-notes.md`](0018-review-notes.md) R3–R5.*