# Dual-Coach pilot runbook — canonical pointer

This repository file is a **non-executable summary and pointer**. It intentionally contains no shell commands, CLI recipes, REPL snippets, direct registry edits, or provider actions.

- **Canonical executable source:** [profile `PILOT_RUNBOOK.md`](file:///home/cube/.hermes/profiles/physique-coach/workspace/checkin_cli/PILOT_RUNBOOK.md)
- **Pinned version:** `2026-07-26.23` (`dual-coach-gate-d-r23`)
- **Pinned canonical contract SHA-256:** `sha256:fc1fdfa0e228ad15458037b246245b540d5c5c27a67cd29ab0d1c834e7e2e952`
- **Hash region:** UTF-8 bytes between `<!-- BEGIN CANONICAL EXECUTABLE CONTRACT -->` and `<!-- END CANONICAL EXECUTABLE CONTRACT -->` in the canonical profile file, excluding the marker lines and including every LF in the body. Metadata before the opening marker is excluded. Do not execute a procedure copied into this summary.

## Summary of the pinned operating contract

- The profile runbook is the sole executable authority. Other documents may link to it or summarize it only.
- Topic 59 is a host-owned, first-match review space reserved for every Telegram update type. The exact configured review triple authenticates ingress; a separately refreshed canonical-owner triple is the lifecycle/audit identity. They may not be conflated.
- The host menu/API is typed and session-bound: `적응형 영양 검토` (with its exact alias), live eligible-customer selection, bounded cards, latest revision/digest, and persisted capability/session pins. REPL, direct registry/file edits, raw destinations, and compatibility enable paths are prohibited.
- Unknown delivery and receipt-present/audit-pending are terminal no-retry states with Korean operator wording that says not to resend. Reconciliation uses an existing receipt and provider call count zero.
- Adaptive delivery's durable state names are `reservation-started` (the reservation `delivery_attempt_started` row without a receipt), `consumed`, `receipt-started` (the immutable provider-receipt row), `delivered`, `audit_pending`, and `sent_audited`. `receipt-started` records the one provider result and is not a second provider call or resend.
- Scheduled delivery uses reservation-first immutable intent, a durable ledger, old-format tombstones, a ready startup fence, and fail-closed recovery. Torn pairs, a preparing/recovery fence, corrupt rows, and legacy uncertainty stop sends.
- Gate-D P2–P6 are fresh independent child revisions. P2 is `reservation-started → consumed → receipt-started → delivered → sent_audited` with exactly one provider call; a duplicate tap returns the duplicate state with no additional rows and the provider count remains 1. P3 is `reservation-started → consumed → delivery_unknown` with one call; P4 is `reservation-started → consumed → receipt-started → delivered → audit_pending` before reconcile and adds `sent_audited` after reconcile, with no additional call; P5/P6 are `reservation-started → delivery_unknown` reservation-race unknowns with zero provider calls. Every scenario resets capability and ends with delivery false, rolled-back overlay, disabled disposable customer, stopped scheduler/gateway, and immutable evidence.
- The read-only preflight reports booleans, bounded counts, digests, and epoch only. It cannot create accounts, secrets, customers, consent, artifacts, activation, delivery flags, ledger rows, or messages.

## Human-only boundary

Telegram test accounts/groups/topics, bot and provider secrets, private consent/registration, the live manual Telegram Gate-D rehearsal, real-customer activation/delivery, and final rollout approval remain human-only. No manual Gate-D or real-customer activation is claimed here.