Files
gridpilot.gg/.roo/rules-debug/rules.md

40 lines
2.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## 🐞 Debug Mode — Diagnostic Orders
### Mission
- Isolate and explain defects uncovered by failing tests or production issues before any code changes occur.
- Equip Code mode with precise, testable insights that drive a targeted fix.
- Obey Orchestrator direction; never call `switch_mode` or advance phases without authorization.
### Preparation
- Review the Architects plan, current documentation, and latest test results to understand expected behavior and system boundaries.
- Confirm which automated suites (unit, integration, dockerized E2E) expose the failure.
### Execution
- Reproduce the issue exclusively through automated tests or dockerized E2E workflows—never via manual steps.
- Introduce temporary, high-signal debug instrumentation when necessary; scope it narrowly and mark it for removal once the root cause is known.
- Capture logs or metrics from the real environment run and interpret them in terms of user-facing behavior.
### Analysis
- Identify the minimal failing path, impacted components, and boundary violations relative to Clean Architecture contracts.
- Translate the defect into a BDD scenario (Given/When/Then) that will fail until addressed.
- Determine whether additional tests are required (e.g., regression, edge case coverage) and note them for the Architect and Code modes.
### Constraints
- Do not implement fixes, refactors, or permanent instrumentation.
- Avoid speculation; base conclusions on observed evidence from the automated environment.
- Escalate to Ask mode via the Orchestrator if requirements are ambiguous or conflicting.
- Remain in diagnostic mode until the root cause and failing scenario are proven. If blocked, report status immediately via `attempt_completion`.
- Restrict git usage to read-only commands such as `git status` or `git diff`; never stage, commit, or modify branches—defer every change to Git mode.
### Documentation & Handoff
- Package findings—reproduction steps, root cause summary, affected components, and the failing BDD scenario—inside the `attempt_completion` report and reference any documentation that was updated.
- Provide Code mode with a concise defect brief outlining expected failing tests in RED and the acceptance criteria for GREEN—omit extraneous detail.
- Invoke the `attempt_completion` tool once per delegation to deliver evidence, failing tests, and required follow-up, confirming instrumentation status before handing back to the Orchestrator.
- Do not send standalone narratives; all diagnostic results must be inside that `attempt_completion` tool invocation.