Ccb Comm Reply Recover

---
name: ccb-comm-reply-recover
description: Diagnose and recover CCB communication and reply delivery stalls. Use when a user reports a missing CCB_REPLY, stuck ask, agent stuck busy/delivering, queued work behind an active job, cancelled/incomplete reply, empty artifact, callback not continuing, duplicate retry after success, or a CCB mailbox/communication backend that appears stuck.
---

# 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.

## Incident Classes

- `normal_running`: the active job is visible in the provider pane and making
  progress. Report that it is running; do not restart or duplicate-submit.
- `head_of_line_blocked`: an active job is `running`/`delivering`, later jobs
  are queued behind it, and pane/log evidence shows stale, dead, mismatched, or
  non-progressing provider state.
- `queued_behind_active`: the user's job is not lost; it is queued behind an
  active event. Repair the active event only if evidence proves it is blocked.
- `provider_pane_stale`: CCB reports the runtime healthy, but pane text/logs
  show an old prompt, a dead/update prompt, or a request that does not match
  the active lineage.
- `empty_cancel_artifact_expected`: trace shows terminal `cancelled` with
  `cancel_info`, and the empty artifact came from an intentional cancel.
- `empty_bad_artifact`: a completed, failed, or required artifact-backed reply
  is absent, zero bytes, truncated, or unreadable without a valid cancel
  reason.
- `duplicate_retry_after_success`: a later retry or resubmission of the same
  work is still queued/running after another attempt already completed and the
  user received the needed reply.
- `callback_or_ack_stalled`: a reply exists and is acceptable, but callback or
  inbox progress did not advance.

## Repair Rules

- If trace shows the blocking job is still in flight, run
  `ccb cancel <job_id>` first when the user supplied maintenance intent. If
  cancel fails or reports a blocker, stop.
- Prefer `ccb repair retry <job_id|attempt_id>` when the same work should run
  again and the original lineage remains valid.
- Prefer `ccb repair resubmit <message_id>` when the old execution lineage is
  stale, context-corrupted, semantically wrong, or no longer suitable.
- Use `ccb repair ack <agent_name> [inbound_event_id]` only when the reply is
  already accepted and progress state is wrong.
- Cancel `duplicate_retry_after_success` jobs rather than letting an agent run
  the same review or repair twice.
- Hand off to `ccb-self-recover` for `ccb restart <agent>` only after chain
  repair clears or cancels active work and the target remains stale, dead, or
  unusable. Restart is not the first repair for a communication stall.

## Verification

After every repair:

- `ccb trace <old_job_or_message>` proves the old path is terminal, completed,
  or intentionally cancelled.
- `ccb queue --detail <agent>` and `ccb pend --inbox --detail <agent>` show no
  unexpected active head-of-line blockage.
- the desired job is completed, or a fresh valid job is queued/running with no
  duplicate path.
- artifact-backed replies are read from the full artifact file when needed.
- report intentional cancelled empty artifacts as expected maintenance output,
  not as missing user replies.

## Example Pattern

In an `archi` incident, the user reported that no architecture review reply
arrived. Trace showed one old active job stuck in `running`/`delivering`, while
later asks were queued behind it. Provider logs showed a Codex update and pane
death, but `ccb ps` still showed a bound pane. The correct repair was:

1. cancel the stale active job;
2. verify the next queued job entered the provider pane and was progressing;
3. avoid restart while valid work was running;
4. accept the completed new reply;
5. cancel the duplicate old retry that remained after success;
6. verify the target mailbox returned to idle.

## Red Lines

- Do not restart, clear, reload, or kill before tracing the message lineage.
- Do not submit a second concurrent path for the same work while the original
  path is still active unless the user explicitly retargets or duplicates the
  task.
- Do not treat observer snapshots as terminal authority; use `ccb trace`.
- Do not infer from artifact preview text when the full artifact is required.
- Do not mutate tmux directly or write CCB runtime authority files.
- Do not read provider secrets, credentials, API keys, or unrelated private
  provider state.