Skip to content

Rollback Protocol

HALT

When something goes wrong — regression, broken build, incorrect merge, unexpected behavior — the manager declares HALT.

Problem detected
    ↓
Manager declares HALT
    ↓
All agents STOP (no new work)
    ↓
Investigation phase (user + manager)
    ↓
Root cause identified
    ↓
Manager proposes recovery plan
    ↓
User approves plan
    ↓
Resume work

When to HALT

Trigger Who declares
QA reports CRITICAL regression Manager
Code-reviewer finds correctness bug post-merge Manager
Shadow reveals fundamental KB error Manager
Build breaks on main branch Manager
User detects any problem User directly

Investigation Phase

During HALT, the user and manager work together:

  1. Identify the problem. What broke? When? Which commit?
  2. Scope the damage. What's affected? Just one module or cascading?
  3. Find root cause. Why did it happen? What was missed?
  4. Assess options:
  5. Git revert: Undo the specific commit(s) that caused the problem.
  6. Fix forward: Write a targeted fix for the issue.
  7. Shadow block revert: If a shadow merge caused the issue, revert to the #else (original) side.
  8. Propose recovery plan. Manager drafts, user approves.
  9. Resume. Execute the plan, verify fix, then resume normal work.

Rules

No one works during HALT

Only the user and manager investigate. All other agents stop.

  • No shortcuts. Don't skip investigation to "just fix it."
  • Log the incident. After resolution, add a HALT entry to SYNCLOG:
## HALT --- YYYY-MM-DD

### Problem
{what went wrong}

### Root Cause
{why it happened}

### Resolution
{what was done to fix it}

### Lesson
{what to do differently — feeds back to docs/skills}
  • Update process if needed. If the HALT reveals a gap in the framework (missing review check, inadequate test coverage), the lesson becomes a teamdev-developer task.