loopx-self-repair

LoopX Self Repair

Use this skill to turn a surprising LoopX behavior into a durable fix, not only an apology or a one-off explanation.

Repair Loop

1. Pause delivery selection. Do not spend quota or continue adapter work until the control-plane facts explain why that work is valid.

2. Build a compact evidence packet. Prefer structured surfaces:

   git status --short --branch
   loopx --format json diagnose --goal-id <goal-id>
   loopx --format json status --goal-id <goal-id> --limit 20
   loopx --format json quota should-run --goal-id <goal-id> [--agent-id <agent-id>]
   loopx --format json history --goal-id <goal-id> --limit 5
   

   status defaults to the registry/dashboard view, but accepts --goal-id when the repair needs one goal-focused projection. Use diagnose --goal-id for the richer goal-specific agent reasoning packet. Also inspect the project-local registry and the registry-declared active state file when relevant. Use the shared global registry for heartbeat/quota truth.

3. Classify the failure. Read references/repair-patterns.md and match the symptoms to a known pattern. If no pattern fits, add one after the fix.

4. Assign the responsible layer. Separate:

   • agent behavior mistake;
   • state projection or quota payload bug;
   • active-state authoring gap;
   • benchmark harness mismatch;
   • docs/process hygiene gap.

5. Repair at the lowest durable layer.

   • If it is a one-off agent mistake, write back the correct state/todo and continue with a larger bounded batch.
   • If the machine projection misled the agent, fix CLI/status/quota projection and add a focused smoke.
   • If the user correction changes the goal acceptance, says the agent missed the intended loop, or exposes a product bottleneck that is not visible in quota/status, write a bounded goal_vision_replan_contract_v0 packet with replan_trigger_summary through normal loopx refresh-state --vision-* fields, using the same --agent-id as the current lane, or --agent-vision-json for generated multi-field patches, before returning to delivery. If the next executable step is already known, also add or link the concrete successor todo; do not leave the correction only in chat or an incident note.
   • If a design rule is missing, update the interaction model or todo list before implementing broad behavior.
   • If benchmark evidence is not attributable, add posthoc trace/parity checks before claiming uplift or regression.

6. Validate before resuming. Run the smallest smoke or CLI check that would have caught the issue, plus loopx check on changed public surfaces when docs/contracts changed.

7. Write back the lesson. Update active goal state, docs, contributor tasks, or this skill so the same failure mode is visible next time.