The T-Block system is all set, but software is never infallible. Imagine you suddenly receive user feedback this afternoon: "When I was dragging an event in Google Calendar, it stuttered and flickered for a second, then crashed to a white screen."
An ordinary large model user would immediately shout at the AI: "Go check the front-end drag-and-drop code, find out why it's erroring, and fix it!!" But this approach can easily lead to increasingly messy code.
We need to use our 'magic' to overcome this chaos. Let's establish a dedicated workflow: .agents/workflows/bug-fix.md:
1. The Ultimate Bug-Fixing Pipeline
# Standardized Pinpoint Bug-Fixing Method
Whenever you hear phrases with the meaning "fix a bug".
You are forbidden from immediately guessing and modifying the logic in production functions to submit for testing.
You must follow the procedure below:
1. **Reproduce the Environment (Leveraging TDD)**: After hearing the user's description, your very first action must be to write an automated test case that [reproduces this exact same error, resulting in red text].
2. Only after you see that "error message" in the terminal are you allowed to start modifying the core files.
3. If, after a series of modifications, the original error is masked or, even worse, causes other tests to fail, use the 3-Strike protocol to revert changes and return control.
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. This is to prevent hitting the same pitfall and reintroducing the bug during future updates.
This strict constraint ensures that bugs aren't just quietly patched away. Instead, they are permanently transformed into an 'antibody' for the system's immunity—a part of the regression test suite. The more vulnerabilities we encounter and patch, the thicker our system's 'iron-shirt' armor becomes