mirror of
https://github.com/azaion/detections.git
synced 2026-04-23 01:06:31 +00:00
Enhance coding guidelines and autopilot workflows
- Updated `.cursor/rules/coderule.mdc` to include new guidelines on maintaining test environments and avoiding hardcoded workarounds. - Revised state file rules in `.cursor/skills/autopilot/state.md` to ensure comprehensive updates after every meaningful state transition. - Improved existing-code workflow in `.cursor/skills/autopilot/flows/existing-code.md` to automate task re-entry without user confirmation. - Added requirements for test coverage in the implementation process within `.cursor/skills/implement/SKILL.md`, ensuring all acceptance criteria are validated by tests. - Enhanced new-task skill documentation to include test coverage gap analysis, ensuring all new requirements are covered by tests. These changes aim to strengthen project maintainability, improve testing practices, and streamline workflows.
This commit is contained in:
@@ -129,7 +129,7 @@ The `<task_slug>` is a short kebab-case name derived from the feature descriptio
|
||||
### Step 4: Codebase Analysis
|
||||
|
||||
**Role**: Software architect
|
||||
**Goal**: Determine where and how to insert the new functionality.
|
||||
**Goal**: Determine where and how to insert the new functionality, and whether existing tests cover the new requirements.
|
||||
|
||||
1. Read the codebase documentation from DOCUMENT_DIR:
|
||||
- `architecture.md` — overall structure
|
||||
@@ -144,6 +144,10 @@ The `<task_slug>` is a short kebab-case name derived from the feature descriptio
|
||||
- What new interfaces or models are needed
|
||||
- How data flows through the change
|
||||
4. If the change is complex enough, read the actual source files (not just docs) to verify insertion points
|
||||
5. **Test coverage gap analysis**: Read existing test files that cover the affected components. For each acceptance criterion from Step 1, determine whether an existing test already validates it. Classify each AC as:
|
||||
- **Covered**: an existing test directly validates this behavior
|
||||
- **Partially covered**: an existing test exercises the code path but doesn't assert the new requirement
|
||||
- **Not covered**: no existing test validates this behavior — a new test is required
|
||||
|
||||
Present the analysis:
|
||||
|
||||
@@ -156,9 +160,22 @@ Present the analysis:
|
||||
Interface changes: [list or "None"]
|
||||
New interfaces: [list or "None"]
|
||||
Data flow impact: [summary]
|
||||
─────────────────────────────────────
|
||||
TEST COVERAGE GAP ANALYSIS
|
||||
─────────────────────────────────────
|
||||
AC-1: [Covered / Partially covered / Not covered]
|
||||
[existing test name or "needs new test"]
|
||||
AC-2: [Covered / Partially covered / Not covered]
|
||||
[existing test name or "needs new test"]
|
||||
...
|
||||
─────────────────────────────────────
|
||||
New tests needed: [count]
|
||||
Existing tests to update: [count or "None"]
|
||||
══════════════════════════════════════
|
||||
```
|
||||
|
||||
When gaps are found, the task spec (Step 6) MUST include the missing tests in the Scope (Included) section and the Unit/Blackbox Tests tables. Tests are not optional — if an AC is not covered by an existing test, the task must deliver a test for it.
|
||||
|
||||
---
|
||||
|
||||
### Step 5: Validate Assumptions
|
||||
|
||||
Reference in New Issue
Block a user