ccb-comm-reply-recover

# CCB Comm Reply Recover ## Overview Use this skill for user-visible "I did not receive the reply" incidents. It combines message lineage repair with mailbox and provider-pane evidence, then hands off to runtime recovery only when the chain evidence proves the provider process or pane must be replaced. Mutations must go through CCB control-plane commands. Do not directly edit mailbox, lifecycle, lease, runtime, provider-session, artifact, or tmux authority files. ## Core Workflow 1. Identify the target from the user's evidence: - `job_id`, `message_id`, `attempt_id`, `reply_id`, inbound event id, or artifact path when provided. - agent name when the user only says a target is stuck. - `ccb queue --detail all` when neither id nor agent is clear. 2. Trace lineage first: - `ccb trace <id>` - record message, attempt, reply, event, callback, and job states. - read the full artifact file before acting when a request or reply is artifact-backed. 3. Inspect mailbox head-of-line state: - `ccb queue --detail <agent>` - `ccb pend --inbox --detail <agent>` - if the requested job is queued behind an active event, trace the active job before touching the queued job. 4. Cross-check runtime evidence when a job is `running` or `delivering` longer than expected: - `ccb ps` - `ccb ping <agent>` - `ccb doctor logs <agent>` when provider/pane failure is plausible. - read-only tmux pane capture only from the socket and pane id reported ...