CCB Self Chain

CCB Self Chain

Use this skill for message and work-lineage recovery. Do not restart or clear a pane as the first repair for a lineage problem.

Core Workflow

1. Identify the lineage id: job_id, message_id, attempt_id, reply_id, inbound event id, or artifact path.
2. Run ccb trace <id> and record message, attempt, reply, event, callback, and job state.
3. Inspect observer state as supplementary evidence:
   • ccb queue --detail <agent|all>
   • ccb pend --inbox --detail <agent>
4. If a reply or request is artifact-backed, read the full artifact file before acting. If the file is absent, expired, truncated, or unreadable, report a blocker and do not act from preview text.
5. Classify the repair:
   • retry: same job or attempt should be retried because the attempt is failed, incomplete, or retryable and the original lineage remains valid.
   • resubmit: original message should be submitted as fresh work because the old lineage is no longer appropriate.
   • ack: acknowledgement or inbox progress is wrong, but the reply is otherwise accepted.
6. If trace shows a job still running or in flight, run ccb cancel <job_id> first when the user intended repair, then re-run trace before choosing retry or resubmit. If cancel fails or reports a blocking state, stop and report the blocker; do not retry, resubmit, or create a second concurrent path for the same work.
7. Execute a repair command only when trace evidence supports it and the user supplied maintenance intent:
   • ccb repair retry <job_id|attempt_id>
   • ccb repair resubmit <message_id>
   • ccb repair ack <agent_name> [inbound_event_id]
8. After repair, re-run trace and queue/inbox checks. Success means the new or repaired lineage is queued/running/completed as intended, the old duplicate path is cancelled or terminal, and no unexpected pending reply remains. Hand work back to the original target agent unless the user explicitly retargets it.