I read this as an advisory contract decision - I’ll trace the plan, consolidation, sealed-product evidence, and upgrade invariant, then issue one verdict with alternatives and safeguards.


I read this as a release-contract decision - the memo distinguishes canonical product derivation from incidental buildability.

# Decision memo

**Verdict: `A_VALID`**

## Decision

Todo 1 requires two reproducible executions of the **canonical split product derivation**, not a stable digest for every buildable source subtree.

The qualified v1.3.3 architecture is:

- Complete 998-input candidate root -> Hermes wheel `cf4ccf…`
- Exact 56-file sealed v1.3.2 profile snapshot -> profile wheel `a099b3…`
- Retained target profile source -> source/test lane only; `87 passed`

The direct target-profile wheels `09c5…` and `d302…` are therefore non-product diagnostics.

## Contract reading

“Two isolated pre-feature builds produce the exact four hashes above” names only:

1. Hermes wheel `cf4ccf…`
2. Profile wheel `a099b3…`
3. Telegram source `8b6c7b…`
4. Regression source, corrected by the retained erratum to `75ab5e…c4c73f…`

It cannot literally mean four build outputs because two are source-file hashes. In context, each isolated verification run must build the two named product wheels and verify the two named source identities. No fifth direct-profile wheel digest appears in the plan.

The upgrade skill’s two-build invariant applies to **wheels being sealed as products**. It does not promote every nested buildable tree into a release artifact. Todo 12 will make the v1.4.0 profile wheel a product; that future wheel must then reproduce identically twice.

## Alternatives and trade-offs

### A — Split product gate, direct build diagnostic

Matches the actual v1.3.3 candidate binding and rollback artifact pair. It keeps product provenance, source-test lineage, and incidental buildability separate. Its failure mode is misleading evidence that labels a diagnostic wheel as a product.

### B — Require one stable direct-profile digest

Provides a simpler one-root mental model, but requires reconstructing the retained profile tree and may invalidate the qualified source-test lineage. It adds coupling without strengthening the already complete 998/56 product derivation.

**Recommendation: A.** It is the smallest architecture matching the sealed product boundary.

## Effect on later gates

A does not weaken:

- **Candidate provenance:** Candidate identity remains bound to `cf4ccf… + a099b3…`, not either diagnostic wheel.
- **Migration/rollback:** These operate on sealed candidate/runtime/config/state identities; the diagnostic wheel is never installed.
- **Todo 12 reproducibility:** Todo 12 independently requires complete v1.4 source and wheel inventories, two identical product builds, installed-wheel Golden Path parity, and migration/rollback evidence.

Any retained-profile source byte that enters the v1.4 profile wheel must be declared as changed relative to `a099b3…`; it cannot be treated as an unchanged baseline member.

## Required evidence language

The authoritative receipt must state:

> The canonical pre-feature product derivation is split-source: two isolated runs built Hermes from the complete 998-input authority to `cf4ccf…` and the profile from the exact 56-file sealed v1.3.2 snapshot to `a099b3…`. The target `dualcoach/profile` direct build is not the sealed v1.3.3 profile product, is not a candidate-identity, deployment, migration, or rollback input, and has no expected digest. Observed `09c5…` and `d302…` values are retained diagnostic observations only. PASS does not claim reproducibility of that diagnostic build.

## Non-negotiable safeguards

- Supersede, rather than mutate, evidence that fixes `09c5…` while claiming overall PASS.
- Retain both diagnostic hashes and the `needs-fix` audit as history.
- Gate Todo 1 on two exact 998/56 split derivations, corrected source hashes, `87 passed`, and unchanged live candidate.
- Do not include a direct-profile diagnostic digest in candidate identity or rollback material.
- Todo 12 must close all actual v1.4 product inputs and reproduce both new product wheels twice.

No plan clause mandates B. B becomes mandatory only if the direct target profile tree is explicitly redefined as a canonical product derivation root.