I read this as a read-only final compliance audit of Task26 v19 candidate `b347…61ff` - I’ll locate the plan, ledger entries 163–164, source, and frozen artifacts, then trace every listed blocker to concrete evidence without performing live actions.


I read this as the final read-only GO/CONSTRAINT audit for v19 - I traced each blocker through the sealed artifacts and frozen production paths.

## Bottom line

**FAIL** for candidate `b347efcd931f8590e08faffd23ff70070d34b6fd48dcc2363cea9e91c33661ff`. The immutable bundle is internally consistent and closes the Ty, RECORD, lifecycle, transport-revocation, and cleanup blockers, but current-authority enforcement is not mandatory at production service start or production CLI capability issuance.

## Evidence

- Candidate derivation recomputes exactly to `b347…61ff`; product binding recomputes to `94f9ff46…9c03`.
- Frozen wheels hash correctly:
  - Hermes: `62a09f9a…b3c7`
  - Profile: `62c508d3…4121`
  - Corrected Ty: `932d4552…e4c`
- Ty provenance is hermetic: sealed ELF member/executable `a7c67f97…8d16`, 810 raw diagnostics at `f4a22651…e86a`, zero diagnostics in capability spans, no ambient Ty accepted.
- Ledger line 164 correctly repairs line 163’s truncated installed-driver hash to `6aaf1367…357bb`; the receipt matches.
- External authority is enforced for:
  - customer activation through `dualcoach_admin` and `activate_customer_cutover`;
  - internal `NutritionCoachingCoordinator.issue_delivery_capability`;
  - Telegram provider I/O through `authorize_delivery_provider_transport`, with shared authority lock and zero sender calls after revocation.
- Portable RECORD projections match across rehydration; differing raw installer RECORD hashes are explicitly retained and equality is not claimed.
- Seven hash-linked clauses prove all 22 Korean answers, deterministic clarification/revision, preview isolation, projection failure, unknown-outcome no-retry, one `sent_audited` delivery, duplicate rejection, and resumed terminal cleanup.
- Bundle/postfreeze seals match `0bef0efe…2599` and `9e7da340…6f84`.
- Ledger ends at line 164 with `task26_complete:false`, `task27_started:false`, and `release_authorized:false`.

## Blocking findings

1. **Production capability issuance bypasses current authority.**
   The packaged `dualcoach_tasks21_25_controller issue-delivery-capability` directly rewrites `draft-deliveries.json`. Its issuance block contains no `FileCandidateAuthoritySource`, `authorize(..., "capability_issue")`, or revocation check. It also omits `runtime_authority_snapshot`, `hermes_wheel_sha256`, `profile_wheel_sha256`, and `candidate_product_binding_sha256`. The Golden Path instead calls the protected coordinator method directly, so its PASS does not prove the mandatory production CLI path.

2. **Service-start authority is controller-conventional, not runtime-mandatory.**
   `launch_controller(..., start_service=True)` checks authority while starting the dedicated service, but normal packaged service entrypoints contain no Task26 enforcement, and `TelegramAdapter.connect()` does not load current authority. It only becomes mandatory when `_get_nutrition_coaching()` is later invoked. Therefore service activation can occur outside the authority-checked controller path.

## Action plan

1. Route CLI capability issuance through the coordinator’s lock-held `capability_issue` authorization and require all canonical product/wheel/snapshot bindings.
2. Enforce current external authority inside service startup, not only in the optional launch controller.
3. Add revoke-before-issue and direct-service-start negatives, reseal a new candidate, and rerun all Task26 lanes. **Effort: Medium.**
4. Keep Task27 and release blocked.

## Residual risks

- 810 Ty diagnostics remain outside the scoped capability spans; no whole-file-clean claim is made.
- Current worktree status has drifted since freeze, although the six relevant production modules remain byte-identical to the sealed Hermes wheel.
- Evidence remains unsigned and bounded by the declared operator/admin trust model.