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 by ccb ps, and only as evidence.
5. Classify the incident, choose the least disruptive repair, then re-run trace and queue checks.