Phase 5 / Ep 26: Unified Bug Fix Format bug-fix.md

Everything in the T-Block system is in place, but software can never remain flawless forever. Suppose this afternoon you suddenly receive user feedback: "When I clicked and dragged the Google Calendar, it froze and flashed randomly for a second, then threw an error and crashed to a white screen."

An ordinary LLM user would immediately yell at the AI: "Quick, go check why the frontend drag-and-drop code is throwing an error and fix it!!" However, this easily leads to the code becoming increasingly messy.

We need to defeat this chaos with magic. Create a dedicated workflow .agents/workflows/bug-fix.md:

1. The Ultimate Bug-Fixing Pipeline Mechanism

# Standardized Targeted Bug-Fixing Protocol

Whenever you receive a prompt implying a "Bug Fix":
You are strictly forbidden from immediately making blind guesses and modifying the code logic in production functions to submit for testing.
You must follow these steps:
1. **Reproduce the Environment (Apply TDD)**: Upon hearing the user's description, your very first action must be to write an [automated test case that exactly reproduces the identical red error text].
2. Only when you see that specific "error text" in the terminal are you allowed to start modifying the core files.
3. If your modifications merely mask the error or cause other tests to fail, use the 3-Strike rule to revert the changes and return control to the user.
4. Once the fix is complete and the terminal shows all green, immediately append a `[BUGFIX Record]` to `docs/findings.md` in the source code repository to prevent falling into the same trap during future updates.

This strict constraint ensures that "bugs are not quietly patched," but instead permanently transformed into a part of the system's immune antibodies (the reproduction test case suite). The more vulnerabilities you patch, the thicker the system's ironclad defense shield becomes!