The Hotfix Protocol

Our strictly governed Code-Run-Read lifecycle—where a PM writes a spec, a Coder executes it, and a QA agent verifies it—is brilliant for long-term project stability. It prevents hallucinations and enforces testing.

But what happens when the orchestrator.py daemon crashes in production at 2 AM because of a Telegram API timeout?

The Cost of Bureaucracy

We realized that when a P0 production incident occurs, the normal agent pipeline is far too slow and methodical. By the time Henry (The PM) finishes drafting a beautifully formatted 150-line Markdown blueprint in tasks/backlog/, your users have already been disconnected from the IPTV proxy for three minutes.

You cannot put a live fire through a multi-stage QA staging environment. You need a fire extinguisher.

The Emergency Bypass path: tasks/hotfix/

To solve this, we introduced the Hotfix Protocol. It completely bypasses the standard /active/ and /review/ physical pipeline.

When the Human Architect detects a crash, they create a tiny markdown file (e.g. HOTFIX-telegram-crash.md) directly inside the tasks/hotfix/ directory. The orchestrator immediately detects it, skips all normal routing rules, and summons a specialized CLI agent armed with a completely different bootloader instruction set.

The Hotfix Agent is instructed to do three things:

1. Prioritize speed over elegance. No refactoring allowed.
2. Contain the error (e.g., wrap it in a try-catch block).
3. Record its manual verification steps directly into the tracker and stop.

It never pushes the file to tasks/review/ for QA validation. It leaves the file exactly where it is in the hotfix/ folder, allowing the Human Architect to instantly verify the uncommitted fix and push it to production.