I read this as a read-only closure integrity audit - I’ll trace the candidate, preseal, controller-source copy, source, and package hashes/import closure, then return an evidence-backed PASS/FAIL without modifying anything.


I’ve located the authoritative live target paths referenced by the r5 package; I’m now comparing the immutable preseal/controller-source surfaces against the candidate and wheel contents, then tracing every local import used by the controller and verifiers.


I read this as a final read-only integrity verdict - the r5 candidate fails closure integrity despite valid hashes and manifests.

# FAIL

Passing evidence:

- Candidate digest recomputes exactly to `232725f01e3cdfe7acd4a8927bd0ce46d22438d4c424165de6d83c068a41f628`.
- Package payload recomputes exactly to `fa58fc80a38ca4f4d58db84db9db46ba48b842e2d12b983f4f7eee236cabd147`.
- Candidate inventory: 324 expected/actual files, zero missing, extra, or hash mismatches.
- Controller-source: 318 manifest/physical files, zero mismatches; all files mode `0444`.
- Preseal package: 326 entries plus self-excluded manifest, zero hash/mode/inventory errors; all 327 files mode `0444`.
- Candidate and copied controller-source trees are byte-identical for all 312 source entries.
- Both build pairs are reproducible. Physical wheels are regular, single-link `0444` files with expected hashes:
  - Hermes: `7769edae...11825`
  - Profile: `ca187949...a55b`
- Wheel RECORDs fully validate, including every member hash and size:
  - Hermes RECORD: `bec67407...121e`
  - Profile RECORD: `59f9aa73...6407`
- Static transitive analysis resolved 101 first-party modules: 17 controller-source, 6 Hermes-wheel, 78 profile-wheel; no missing first-party import.

Blocking failures:

1. **Runtime/verifier closure is not sealed or complete.**
   `nutricoach_v150_runtime_ops.py:163-191` creates the successor with `venv --system-site-packages`, then installs only the two wheels using `--no-deps`. The 101-module closure imports unsealed external modules including `pydantic`, `yaml`, `anyio`, and `typing_extensions`. They resolve from `/home/cube/miniconda3/lib/python3.12/site-packages`, outside every RECORD and closure manifest, and are owner-writable mode `0664`. The actual Pydantic is 2.12.5 while the Hermes wheel declares exact `pydantic==2.13.4`.

2. **Mutable worktree verification escape.**
   `verify_nutricoach_v150_preseal_v14.py:23-33,210` reads `_BASE_MANIFEST` directly from `/home/cube/projects/richard/.worktrees/nutricoach-v150-combined/...`, rather than the frozen candidate/preseal copy. Thus authorization-time verification depends on a mutable worktree surface.

3. **Wheel-first import order is later overridden.**
   The detached bootstrap initially constructs `PYTHONPATH` as Hermes wheel, profile wheel, controller-source. However:
   - `verify_nutricoach_v150_preseal_v14.py:13`
   - `verify_nutricoach_v150_candidate.py:23`

   both execute `sys.path.insert(0, controller-source)`. This puts copied source ahead of wheels for subsequent imports, permitting mixed source/wheel resolution and defeating the bootstrap’s stated wheel-first rule.

4. **Additional mutable binding surfaces.**
   The permission package and candidate manifest used during verification are owner-writable mode `0664`; `snapshot-before.json` is `0600`. Hash checks are present, but these are not immutable closure members and remain raceable between separate hash/read operations.

No files were modified and no live, network, service, or authorization action was invoked.