I read this as a read-only v1.1 release-architecture review - I’ll survey the tagged baseline and feature worktree end to end, compare viable candidate-boundary designs, and return exact gates, provenance rules, acceptance criteria, and stop conditions without modifying anything.


message: WebSocket error

stop_reason: error


I read this as a release-boundary decision under the new build evidence - I’ll verify the new wheel/candidate facts and decide which v1 evidence can be inherited versus which v1.1 claims require fresh receipts.


I read this as a release-boundary decision under the new build evidence - define whether inheritance from v1 is truthful and what must still be regenerated.

## Decision

**Yes. A semver v1.1 delta-qualified candidate is truthful. Every v38 receipt does not need to be regenerated.**

Use:

- Product candidate: `0e383539aea1b83205771772f1e8b417840defe60f5ea6ce184f80e3af8d25f9`
- Product binding: `178ce0ce9a2ea0b76af8e5ef7fcba2340c4a266388a23da5769642bc550f97f2`
- Hermes wheel: `ec160d3d0e29bc747f463923d31bfe736aefb5840a3d32fcb04842aa5139ddb0`
- Profile wheel: unchanged `a56da2417df0912f3fe407c0b78befd7362207d1c8a35271000af46701ba79d2`

Call the **qualification model** delta-based, not the product identity. The candidate digest still describes the complete composed product.

Do not claim:

- full v38 requalification;
- that old candidate-bound receipts apply directly to `0e383...`;
- exact-candidate external Telegram execution.

## Designs considered

### A. Delta qualification over immutable v1 - recommended

Reference `dualcoach-v1.0.0`, prove that the new Hermes wheel differs only at the TTL seam, inherit unchanged claims by byte identity, and generate a small fresh qualification envelope.

Trade-offs:

- Lowest migration and execution cost.
- Highly testable with one stdlib-only verifier.
- Couples v1.1 verification to the immutable v1 tag and its recorded hashes.
- Fails closed if the base tag, base artifacts, or inheritance receipts are absent.
- Requires precise wording around inherited real-surface evidence.

### B. Reconstruct and replay all v38 qualification

Rebuild both products and regenerate all candidate, Golden Path, expected-state, authority, postfreeze, review, and Task27 receipts.

Trade-offs:

- Self-contained and avoids inherited claims.
- Expensive and operationally risky because the original orchestration was transient.
- Reconstructing the old harness introduces more failure and nondeterminism than this two-byte semantic change warrants.
- Provides little additional assurance once wheel-level byte equivalence is established.

### Rejected hybrid

Do not substitute the new wheel into the v1 delivered bundle and update selected hashes. Candidate identity propagates through authority, parity, expected-state, Golden Path, seals, and Task27 receipts; partial rebinding would be false.

## Why delta qualification is sufficient

I verified that the old and new Hermes wheels both contain 992 members, with exactly two changed member payloads:

1. `gateway/platforms/telegram_customer_bootstrap.py`
2. `hermes_agent-0.17.0.dist-info/RECORD`

There are no added or removed members. All other 990 members, including console entry points and qualification tools, are byte-identical.

The verifier must additionally prove the source member contains exactly one semantic replacement:

```text
timedelta(minutes=30) -> timedelta(hours=24)
```

This makes unchanged v1 claims inheritable by byte identity rather than assumption.

## Immutable v1 inputs that may be reused

Reference these without rewriting or relabeling them:

- Tag commit `d7425705ee403b543f203668eef751c060e2c89d`
- Tag tree `062d2dadc3755df6de72efdfaeb8fd57d6c92568`
- Base candidate `d1109d8f...39112`
- Base Hermes wheel `f8b3c779...60b1`
- Profile wheel `a56da241...79d2`
- Profile source digest `b34b2a12...3747`
- Profile qualification: 749 tests and its immutable receipt
- Wheelhouse: 107 entries, inventory `b7cab3f2...13f4`
- Corrected Ty wheel `932d4552...fe4c`
- Trust-boundary digest `1273abc2...10c6`
- Unchanged qualification-tool hashes
- v1 Task27 consolidated receipt `4f578c47...a2a4`
- v1 final report `31d7daa6...a76`
- v1 Task27 manifest `50eb92a4...ed9d`
- Historical Task24 real-surface and Task25 cleanup evidence

These remain **base evidence**, not v1.1 receipts.

## Fresh v1.1 gates required

1. **Source-boundary gate**
   - Exact source diff classification.
   - Changed-file diagnostics, Ruff, and compile.
   - New 24-hour boundary tests.
   - Existing v1 bootstrap regression tests, using hash-pinned retained test sources if necessary.
   - No generated `build/` content in the release commit.

2. **Artifact gate**
   - Two independent Hermes builds both produce `ec160d...ddb0`.
   - Validate both wheel RECORDs.
   - Verify the exact 992-member old/new comparison above.
   - Verify the copied profile wheel and profile source provenance remain unchanged.

3. **Golden Path**
   - Seal the reported fresh source Golden Path result to candidate `0e383...`.
   - **Run a fresh installed Golden Path** from the new Hermes wheel and unchanged profile wheel in an isolated Python 3.12 environment using only the sealed wheelhouse.
   - Require installed module-origin proof, candidate/binding equality, local-loopback Telegram transcript, terminal cleanup, and no external traffic.

4. **Authority**
   - Copy the verified v1 authority chain as an immutable prefix.
   - Append one `qualify` event for `0e383...`, bound to the fresh delta-qualification receipt.
   - Do **not** revoke v1 merely because it is superseded; it remains a valid rollback candidate.
   - Require current authority to resolve uniquely to `0e383...`.

5. **Evidence seal**
   - Canonical inventory of all v1.1 artifacts and fresh receipts.
   - Bind base tag/commit/tree, base receipts, new wheel, profile wheel, candidate, binding, verifier hash, authority heads, and F1-F5.
   - Materialized seal may use 0400/0500 modes; Git must again be described only as an exact content mirror.

6. **Fresh F1-F5**
   - F1: TTL objective and inherited v1 invariants are fully mapped.
   - F2: privacy and role-authority implementation is byte-identical outside the TTL seam.
   - F3: exact boundary, single-use behavior, installed lifecycle, and inherited exactly-once logic pass.
   - F4: `PASS_PRESERVED_BASE_REAL_SURFACE_PLUS_V1_1_OFFLINE_PARITY`; explicitly state that no v1.1 external Telegram run occurred.
   - F5: new provenance/seal/authority pass, plus read-only confirmation that the prior disabled and cleaned terminal state has not drifted.

Generate a new consolidated receipt and v1.1 report. Never reuse the old `PASS_ALL_F1_F2_F3_F4_F5` receipt as the v1.1 verdict.

## Standalone verifier boundary

A small stdlib-only verifier is enough if it:

- verifies the v1 tag commit/tree and recorded base hashes;
- content-verifies the v1 delivered mirror while acknowledging Git mode loss;
- validates both canonical product bindings;
- requires every derivation input except the Hermes wheel hash to be equal;
- validates both wheel RECORDs and the exact two-member wheel delta;
- validates the exact TTL textual/semantic replacement;
- validates the unchanged profile, wheelhouse, Ty, trust boundary, and tool hashes;
- validates fresh source and installed Golden Path receipts;
- verifies the authority chain and current candidate;
- verifies the v1.1 evidence inventory and F1-F5 receipts;
- performs no network, service, provider, Telegram, customer, or live-profile action.

Bind the verifier hash in the v1.1 qualification receipt and final seal. It need not alter the already-derived product candidate.

## Source/tag boundary

Prefer two local commits:

1. Source commit: TTL change, tests, and only necessary packaging/test metadata.
2. Evidence-freeze commit: v1.1 candidate artifacts, verifier, receipts, and seal.

Build from commit 1. Tag commit 2 as `dualcoach-v1.1.0`, recording both commit identities and proving that commit 2 changes no packaged source.

The two restored DualCoach console entry points are acceptable because they preserve the v1 wheel surface. The pytest asyncio defaults are separate test-harness changes and should be excluded unless independently required and explicitly classified.

## Stop conditions

Stop with no v1.1 release verdict if:

- installed Golden Path is absent or fails;
- the wheel delta contains anything beyond the TTL module and RECORD;
- any inherited profile/tool/wheelhouse/trust hash differs;
- any old receipt is relabeled as candidate `0e383...`;
- F4 requires exact-candidate external Telegram execution rather than preserved evidence;
- authority does not resolve uniquely to `0e383...`;
- filename/version-only installation is allowed without enforcing the new wheel hash;
- unclassified `pyproject.toml` or generated `build/` changes enter the source commit;
- any F1-F5 lane is missing, inconclusive, or fails;
- the final evidence seal or local tag binding does not verify.

Current state: `0e383...` is a valid derived product identity with a reproducible wheel and reported source Golden Path, but it is not yet a release candidate until installed Golden Path, delta verification, authority, sealing, and fresh F1-F5 complete.