mirror of
https://github.com/azaion/ai-training.git
synced 2026-04-22 11:06:35 +00:00
Refine coding standards and testing guidelines
- Updated the coding rule descriptions to emphasize readability, meaningful comments, and test verification. - Revised guidelines to clarify the importance of avoiding boilerplate while maintaining readability. - Enhanced the testing rules to set a minimum coverage threshold of 75% for business logic and specified criteria for test scenarios. - Introduced a mechanism for handling skipped tests, categorizing them as legitimate or illegitimate, and outlined resolution steps. These changes aim to improve code quality, maintainability, and testing effectiveness.
This commit is contained in:
@@ -28,7 +28,7 @@ The `implementer` agent is the specialist that writes all the code — it receiv
|
||||
- **Integrated review**: `/code-review` skill runs automatically after each batch
|
||||
- **Auto-start**: batches launch immediately — no user confirmation before a batch
|
||||
- **Gate on failure**: user confirmation is required only when code review returns FAIL
|
||||
- **Commit and push per batch**: after each batch is confirmed, commit and push to remote
|
||||
- **Commit per batch**: after each batch is confirmed, commit. Ask the user whether to push to remote unless the user previously opted into auto-push for this session.
|
||||
|
||||
## Context Resolution
|
||||
|
||||
@@ -134,25 +134,38 @@ Only proceed to Step 9 when every AC has a corresponding test.
|
||||
|
||||
### 10. Auto-Fix Gate
|
||||
|
||||
Auto-fix loop with bounded retries (max 2 attempts) before escalating to user:
|
||||
Bounded auto-fix loop — only applies to **mechanical** findings. Critical and Security findings are never auto-fixed.
|
||||
|
||||
1. If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue automatically to step 11
|
||||
2. If verdict is **FAIL** (attempt 1 or 2):
|
||||
- Parse the code review findings (Critical and High severity items)
|
||||
- For each finding, attempt an automated fix using the finding's location, description, and suggestion
|
||||
- Re-run `/code-review` on the modified files
|
||||
- If now PASS or PASS_WITH_WARNINGS → continue to step 11
|
||||
- If still FAIL → increment retry counter, repeat from (2) up to max 2 attempts
|
||||
3. If still **FAIL** after 2 auto-fix attempts: present all findings to user (**BLOCKING**). User must confirm fixes or accept before proceeding.
|
||||
**Auto-fix eligibility matrix:**
|
||||
|
||||
Track `auto_fix_attempts` count in the batch report for retrospective analysis.
|
||||
| Severity | Category | Auto-fix? |
|
||||
|----------|----------|-----------|
|
||||
| Low | any | yes |
|
||||
| Medium | Style, Maintainability, Performance | yes |
|
||||
| Medium | Bug, Spec-Gap, Security | escalate |
|
||||
| High | Style, Scope | yes |
|
||||
| High | Bug, Spec-Gap, Performance, Maintainability | escalate |
|
||||
| Critical | any | escalate |
|
||||
| any | Security | escalate |
|
||||
|
||||
### 11. Commit and Push
|
||||
Flow:
|
||||
|
||||
1. If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue to step 11
|
||||
2. If verdict is **FAIL**:
|
||||
- Partition findings into auto-fix-eligible and escalate (using the matrix above)
|
||||
- For eligible findings, attempt fixes using location/description/suggestion, then re-run `/code-review` on modified files (max 2 rounds)
|
||||
- If all remaining findings are auto-fix-eligible and re-review now passes → continue to step 11
|
||||
- If any non-eligible finding exists at any point → stop auto-fixing, present the full list to the user (**BLOCKING**)
|
||||
3. User must explicitly approve each non-auto-fix finding (accept, request manual fix, mark as out-of-scope) before proceeding.
|
||||
|
||||
Track `auto_fix_attempts` and `escalated_findings` in the batch report for retrospective analysis.
|
||||
|
||||
### 11. Commit (and optionally Push)
|
||||
|
||||
- After user confirms the batch (explicitly for FAIL, implicitly for PASS/PASS_WITH_WARNINGS):
|
||||
- `git add` all changed files from the batch
|
||||
- `git commit` with a message that includes ALL task IDs (tracker IDs or numeric prefixes) of tasks implemented in the batch, followed by a summary of what was implemented. Format: `[TASK-ID-1] [TASK-ID-2] ... Summary of changes`
|
||||
- `git push` to the remote branch
|
||||
- Ask the user whether to push to remote, unless the user previously opted into auto-push for this session
|
||||
|
||||
### 12. Update Tracker Status → In Testing
|
||||
|
||||
|
||||
Reference in New Issue
Block a user