I read this as a read-only mapping task: inspect a sealed profile wheel plus provenance/source in a delivery bundle, determine exactly what source and build metadata it represents, and produce a STOP/PROCEED decision for a single-commit Hermes release. - Plan: locate all bundle files and provenance, inspect the wheel, diff against non-Git source, then report counts/mismatches and a recommendation.


The profile source tree is found in an external cache. Let me inspect its build metadata and locate the Hermes release worktree / any git repo


I have the full picture. Here is the mapping and verdict.

## Source identity represented by the profile wheel

The sealed wheel `physique_checkin_cli-0.1.0-py3-none-any.whl` (sha256 `a56da2417df0912f3fe407c0b78befd7362207d1c8a35271000af46701ba79d2`) was built by setuptools `bdist_wheel` (setuptools >= 68 backend) from a single source tree located at:

`/home/cube/.cache/task26-strict-successor-1786976146/src-p`

That tree (our only live copy) contains exactly the artifact-visible layout:

| Tree member | Role | Wheel mapping |
|---|---|---|
| `checkin_cli/` — 51 `.py` modules (incl. `__init__.py`) | runtime package | biject exactly to 51 wheel members under `checkin_cli/` |
| `checkin_cli/policies/__init__.py` + 2 JSON policy files | package data (`package-data = *.json`) | 3 wheel members |
| `tests/` — 33 files (`31 test_*.py`, `__init__.py`, `_support.py`) | 749-test qualification suite | NOT in wheel (source-input only) |
| `pyproject.toml` | build metadata | drives wheel name/metadata; not shipped verbatim (only its PKG-INFO projection) |
| `uv.lock` / `.venv` / `build/` / `egg-info/` / caches | dev env + generated dirs | excluded from wheel |

Wheel content = **54 runtime members** (51 `.py` + `policies/__init__.py` + 2 JSON) + 4 `dist-info` files (METADATA, WHEEL, top_level.txt, RECORD). The your-stated "54 runtime wheel members" matches the build log exactly. No generated code, no compiled artifacts — every runtime member is a pure-source text file, so source↔wheel is a clean bijection.

## Can this go in ONE commit in the Hermes release worktree?

**Yes — PROCEED**, but only as a *provenance snapshot* that reuses the existing sealed candidate. Do not build a new wheel, do not re-seal, do not derive a fresh `candidate_digest`. A single commit containing the source + metadata for the sealed profile wheel does **not** invent a new candidate, because candidate identity is the already-sealed bundle: `candidate_digest d1109d8f78…239112`, product binding `1b016220cbe3fd04…`, profile wheel `a56da2417df0…`, hermes wheel `f8b3c779c584…`. The commit must reference that frozen identity, not mint a new one.

### Mismatches / gaps to record in the commit message
1. **Evidence dir holds zero source bytes.** The delivered bundle's `source-provenance.json` pins *names + sha256 + sizes* of the 51 modules + tests, but no file content. The live bytes exist **only** at the non-Git cache `src-p` (no `.git`, not under the project, not under the evidence tree). The 54 runtime members have no matching file under `.omo/evidence`. Recovery is truthful **only** because (a) the binding field `profile_source_metadata_only` points to that exact `src-p` path and (b) the profile qualification (exit 0, 749 passed, Python 3.12.9, `source_tree_digest b34b2a12…` unchanged before/after) proves the `src-p` tree is byte-identical to what produced the sealed wheel. If `src-p` were wiped, exact source would be **unrecoverable** from evidence alone.
2. **`pyproject.toml` and `uv.lock` are unsealed.** The sealed tree digest and `source-provenance.json` inventory cover only `checkin_cli/` source + `tests/`; they do **not** include `pyproject.toml`/`uv.lock` ("metadata only"). The committed `pyproject.toml` is reproduced from `src-p` and byte-matches the historical snapshot `task26-owner-customer-v1-candidate-v3/snapshot/profile-package/pyproject.toml` (identical content) — truthful, but its hash is not independently pinned by the delivered bundle. Good enough to commit; note it.
3. `uv.lock` is optional — setuptools `bdist_wheel` never reads it. Commit it only if the intent is to reproduce the hermetic **test env** (749-suite), not the wheel. Skipping it changes wheel identity not at all.

## Bytes to freeze as ARTIFACT vs SOURCE

- **Frozen artifact bytes (never reconstructed):** the two wheels themselves — `physique_checkin_cli-0.1.0-py3-none-any.whl` (`a56da24…`), `hermes_agent-0.17.0-py3-none-any.whl` (`f8b3c77…`); plus the sealed candidate records: `candidate.json`, `outer-candidate-manifest.json` product binding (`1b016220…`), driver-inputs, SEAL, qualification receipt. These define the candidate and must be preserved as opaque byte objects.
- **Committed as source:** the 54 `checkin_cli/` runtime members, `tests/` (33 files), `pyproject.toml`; optionally `uv.lock`. Taken verbatim from `src-p`.
- **Excluded (generated):** `__pycache__/`, `.venv/`, `build/`, `physique_checkin_cli.egg-info/`, `.pytest_cache/`, `.ruff_cache/`. The `egg-info/PKG-INFO` is the derived projection of `pyproject.toml` and must not be committed as if source.

## Missing build inputs

None that block a truthful commit **if** `pyproject.toml` is included, because the hermetic toolchain is recorded in evidence: Python 3.12.9, pytest 9.1.1, ty 0.0.21 (binary `a7c67f97…`), ruff, in `outer-candidate-manifest.json` derivation inputs + qualification receipt. The one soft gap: the committed `pyproject.toml` only floors `setuptools>=68`; the exact setuptools version that produced the sealed wheel is **not** pinned there. Byte-exact wheel reproduction therefore depends on freezing the same setuptools/Python from the qualification seal — which is why the wheel is recommended as a frozen artifact rather than rebuilt. Recommend recording the build-env pin (setuptools version) in the release commit or alongside the artifact.

## Verdict

**PROCEED** with a single provenance/reproducibility commit: copy the 54 runtime members + `tests/` + `pyproject.toml` (optionally `uv.lock`) byte-identically from `src-p`; keep both already-sealed wheels and the `d1109d8f…` candidate binding as frozen artifacts; reference that candidate digest in the commit message; do **not** rebuild or re-seal. This commits the exact source behind the sealed wheel and creates no new candidate. The sole fragility is that live source bytes live only in the non-Git `src-p` cache — back them up as part of the commit, and keep the wheels as opaque artifacts since their contents are not independently extractable from the evidence bundle.