I read this as an independent, read-only acceptance audit of the exact Task26 trainer-free lifecycle and cleanup - I’ll trace the bound candidate and seals across source, live state, archives, Telegram surfaces, authority ledgers, and evidence, then return PASS only if every clause is positively evidenced.


The sealed summaries establish candidate/lifecycle/cleanup bindings, but they do not by themselves prove the membership-isolation clause. I’m now tracing the actual archived routing and authority rows, including invite/claim provenance and every participant identity, rather than treating “no trainer artifacts” as sufficient.


I found the active Task26 plan and the lifecycle observer corpus; I’m now matching its exact isolation clauses against what was actually observed.


The decisive gap is now concrete: the final activation used `dualcoach_admin customer activate`, whose production path never consumed a Telegram staff-membership receipt. I’m checking whether any independent Task26-bound observation closes that gap before issuing the verdict.


I read this as a read-only final Task26 trainer-free audit - report the evidence-bound verdict, blockers, and remediation without mutating anything.

# Verdict: FAIL / NOT PROVEN

Candidate `4a6c7ee54cf9526a30de8bb576c1d71b411938beba33a04914738f6e1b6ed1cb` cannot receive a trainer-free v1 PASS.

## Decisive blockers

1. **Customer absence from the staff chat is not lifecycle-proven**
   - Scoped staff chat: `-1004484458766`.
   - Customer: `8527916639`.
   - `TFV1-ROUTE-001` explicitly requires a provider membership receipt.
   - No Task26 activation, lifecycle, cleanup, or candidate-bound artifact records `telegram.getChatMember` for this customer/chat.
   - The real-ID observation reports `left`, but was captured on `2026-08-12T16:43:17Z`, before the final Task26 lifecycle.
   - The Task23 receipt uses synthetic IDs and is not applicable.
   - Therefore customer-free staff membership and complete DM isolation are **not proven**. This is not evidence that the customer was a member; it is missing mandatory positive evidence.

2. **A legacy trainer-era callback namespace remains in the production candidate**
   - Candidate wheel SHA-256: `9d22e89a0b1a14d4eb7f1c2005fc01860bec5f3b4eda6e01bb1390542a90b875`.
   - `gateway/platforms/telegram.py:11313` explicitly dispatches both:
     ```python
     if str(data).startswith(("non1:", "non2:")):
     ```
   - The same file bytes are present in the candidate wheel; file SHA-256 is `5d3103b744b6e92ddbc576a77df433c2127d6df17260a3c78d2000d7b90d2f97`.
   - `non1:` is identified by the tests as the historical namespace. Explicitly registering it violates the acceptance requirement that no historical trainer callback namespace remain configured, even though downstream decoding rejects it.

3. **Cleanup is not process-free**
   - At audit time, PID `591348` remained:
     ```text
     journalctl --user -fu hermes-gateway-dualcoachtest.service --since now -o cat
     ```
   - It started at `2026-08-17 14:10:38 +0900`, before both lifecycle sealing and cleanup sealing, and is a child of the current session.
   - The plan requires “no orphan log followers or session-owned monitors remain.”
   - The cleanup verifier missed it because `profile_processes()` checks only for a matching `HERMES_HOME` environment variable; this journal follower has no such variable.
   - The service itself is correctly `inactive/dead`, `MainPID=0`.

## Positive final-lifecycle evidence

- Requested seals authenticate:
  - Lifecycle seal SHA-256: `50e7556e58a876d8136fbfb2023ede8bcb46ac816d97d4b85e1d0559f463d008`.
  - Cleanup seal SHA-256: `84d937ef67c1517bfdbca4cabce9fb4bfbe39aa1165458bb3aedd14decc4bff0`.
  - Lifecycle root: `fdcfb1efd1f2d4a2b95f22f7311827d197898a6d480cb572956e87bd66d20361`.
  - Cleanup archive root: `9f5d72840b4cc1fcb57720a61ebc53529fa00202d9201615e4ebdbb3e047a635`.
- Current Task26 application records contain only customer and owner authority:
  - 28 onboarding publications to customer DM `8527916639`, topic `0`.
  - 2 owner publications to owner DM `8693203710`, topic `0`.
  - Owner approval callback was by `8693203710`.
  - Review card `231` went to owner DM.
  - Delivery `232` went to customer DM and is `sent_audited`.
- No Task26 trainer role, claim, invite, card, route, delivery, or authority record was found.
- Current cleanup payload has zero trainer-bearing data. Registry/customer state is removed, future jobs/publications are zero, and post-disable deliveries are zero.

## Historical findings

Older owner-only rehearsal archives contain trainer-era material in 39 files, including an August 10 Task22 trainer invite/claim and three `trainer_handoff` draft fields. Three retained logs also contain older `trainer_review` or rejected `/pilot_trainer` lines.

These records do **not** establish trainer involvement in the final Task26 lifecycle, but they must remain explicitly classified as quarantined historical evidence rather than represented as zero historical trainer data.

## Required remediation

1. Remove `non1:` from production dispatch and rebuild/rebind a new immutable candidate; historical rejection fixtures may remain under tests only.
2. Gate activation on fresh `telegram.getChatMember` observations for the customer against every configured staff chat, requiring `left` or `kicked`.
3. Bind membership evidence to candidate, wheel, customer, complete staff-chat inventory, observation time, activation journal, and lifecycle seal. Capture start/end observations and membership-change events for lifecycle-wide proof.
4. Terminate the session-owned journal follower and broaden cleanup verification to detect service-name log followers and session-owned monitors, not only `HERMES_HOME` processes.
5. Explicitly inventory and seal trainer-bearing rehearsal archives/logs as owner-only historical data, or purge them under separately authorized retention procedures.
6. Run a fresh lifecycle, cleanup, and independent trainer-free audit and issue new seals.

No files, services, Telegram state, provider state, or delivery state were mutated during this audit.