This commit is contained in:
Alex Verkhovsky 2026-03-19 06:42:24 +00:00 committed by GitHub
commit faae3b0609
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 45 additions and 26 deletions

View File

@ -30,19 +30,18 @@
- Set `source` to the merged sources (e.g., `blind+edge`). - Set `source` to the merged sources (e.g., `blind+edge`).
3. **Classify** each finding into exactly one bucket: 3. **Classify** each finding into exactly one bucket:
- **intent_gap** -- The spec/intent is incomplete; cannot resolve from existing information. Only possible if `{review_mode}` = `"full"`. - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
- **bad_spec** -- The spec should have prevented this; spec is wrong or ambiguous. Only possible if `{review_mode}` = `"full"`. - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
- **patch** -- Code issue that is trivially fixable without human input. Just needs a code change.
- **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now. - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
- **reject** -- Noise, false positive, or handled elsewhere. - **dismiss** -- Noise, false positive, or handled elsewhere.
If `{review_mode}` = `"no-spec"` and a finding would otherwise be `intent_gap` or `bad_spec`, reclassify it as `patch` (if code-fixable) or `defer` (if not). If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
4. **Drop** all `reject` findings. Record the reject count for the summary. 4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping rejects AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review. 5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
6. If zero findings remain after dropping rejects and no layers failed, note clean review. 6. If zero findings remain after dropping dismissed and no layers failed, note clean review.
## NEXT ## NEXT

View File

@ -1,38 +1,58 @@
--- ---
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
--- ---
# Step 4: Present # Step 4: Present and Act
## RULES ## RULES
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- Do NOT auto-fix anything. Present findings and let the user decide next steps. - Always write findings to the story file before offering action choices.
- Decision-needed findings must be resolved before handling patches.
## INSTRUCTIONS ## INSTRUCTIONS
1. Group remaining findings by category. ### 1. Clean review shortcut
2. Present to the user in this order (include a section only if findings exist in that category): If zero findings remain after triage (all dismissed or none raised): state that and end the workflow.
- **Intent Gaps**: "These findings suggest the captured intent is incomplete. Consider clarifying intent before proceeding." ### 2. Write findings to the story file
- List each with title + detail.
- **Bad Spec**: "These findings suggest the spec should be amended. Consider regenerating or amending the spec with this context:" If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection. Write all findings in this order:
- List each with title + detail + suggested spec amendment.
- **Patch**: "These are fixable code issues:" 1. **Decision needed** findings (unchecked):
- List each with title + detail + location (if available). `- [ ] [Review][Decision] {Title} — {Detail}`
- **Defer**: "Pre-existing issues surfaced by this review (not caused by current changes):" 2. **Patch** findings (unchecked):
- List each with title + detail. `- [ ] [Review][Patch] {Title} [{file}:{line}]`
3. Summary line: **X** intent_gap, **Y** bad_spec, **Z** patch, **W** defer findings. **R** findings rejected as noise. 3. **Defer** findings (checked off, marked deferred):
`- [x] [Review][Defer] {Title} [{file}:{line}] — deferred, pre-existing`
4. If clean review (zero findings across all layers after triage): state that N findings were raised but all were classified as noise, or that no findings were raised at all (as applicable). Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description.
5. Offer the user next steps (recommendations, not automated actions): ### 3. Present summary
- If `patch` findings exist: "These can be addressed in a follow-up implementation pass or manually."
- If `intent_gap` or `bad_spec` findings exist: "Consider running the planning workflow to clarify intent or amend the spec before continuing." Announce what was written:
- If only `defer` findings remain: "No action needed for this change. Deferred items are noted for future attention."
> **Code review complete.** {D} decision-needed, {P} patch, {W} deferred, {R} dismissed as noise.
> Findings written to the review findings section in `{spec_file}`.
### 4. Resolve decision-needed findings
If `decision_needed` findings exist, present each one with its detail and the options available. The user must decide — the correct fix is ambiguous without their input. Walk through each finding (or batch related ones) and get the user's call. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
### 5. Handle patch findings
If `patch` findings exist (including any resolved from step 4), ask the user:
> **How would you like to handle the {Z} patch findings?**
> 1. **Fix them automatically** — I will apply fixes now
> 2. **Leave as action items** — they are already in the story file
> 3. **Walk through each** — let me show details before deciding
- **Option 1**: Apply each fix. After all patches are applied, present a summary of changes made and check off the items in the story file.
- **Option 2**: Done — findings are already written to the story.
- **Option 3**: Present each finding with full detail, diff context, and suggested fix. After walkthrough, re-offer options 1 and 2.
Workflow complete. Workflow complete.