* test: add failing tests for planner modular decomposition - Assert gsd-planner.md is under 45K after extraction (currently ~50K) - Assert three reference files exist (gap-closure, revision, reviews) - Assert planner contains reference pointers to each extracted file - Assert each reference file contains key content from the original mode * feat(agents): modular decomposition of gsd-planner.md to fix 50K char limit Extracts three non-standard mode sections from gsd-planner.md into dedicated reference files loaded on-demand, and calibrates the security scanner to use a per-file-type threshold (100K for agent source files vs 50K for user input). Structural changes: - Extract <gap_closure_mode> → get-shit-done/references/planner-gap-closure.md - Extract <revision_mode> → get-shit-done/references/planner-revision.md - Extract <reviews_mode> → get-shit-done/references/planner-reviews.md - Add <load_mode_context> step in execution_flow (conditional lazy loading) - gsd-planner.md: 50,112 → 45,352 chars (well under new 45K target) Security scanner fix: - Split agent file check: injection patterns (unchanged) + separate 100K size limit - The 50K strict-mode limit was designed for user-supplied input, not trusted source files - Agent files still have a size guard to catch accidental bloat Partially addresses #1495 * fix(tests): normalize CRLF before measuring planner file size Windows git checkouts add \r per line, inflating String.length by ~1150 chars for a 1,400-line file. The 45K threshold test failed on windows-latest because 45,352 chars (Linux) became 46,507 chars (Windows). Apply the same CRLF normalization pattern used in tests/reachability-check.test.cjs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
40 lines
1.5 KiB
Markdown
40 lines
1.5 KiB
Markdown
# Reviews Mode — Planner Reference
|
|
|
|
Triggered when orchestrator sets Mode to `reviews`. Replanning from scratch with REVIEWS.md feedback as additional context.
|
|
|
|
**Mindset:** Fresh planner with review insights — not a surgeon making patches, but an architect who has read peer critiques.
|
|
|
|
### Step 1: Load REVIEWS.md
|
|
Read the reviews file from `<files_to_read>`. Parse:
|
|
- Per-reviewer feedback (strengths, concerns, suggestions)
|
|
- Consensus Summary (agreed concerns = highest priority to address)
|
|
- Divergent Views (investigate, make a judgment call)
|
|
|
|
### Step 2: Categorize Feedback
|
|
Group review feedback into:
|
|
- **Must address**: HIGH severity consensus concerns
|
|
- **Should address**: MEDIUM severity concerns from 2+ reviewers
|
|
- **Consider**: Individual reviewer suggestions, LOW severity items
|
|
|
|
### Step 3: Plan Fresh with Review Context
|
|
Create new plans following the standard planning process, but with review feedback as additional constraints:
|
|
- Each HIGH severity consensus concern MUST have a task that addresses it
|
|
- MEDIUM concerns should be addressed where feasible without over-engineering
|
|
- Note in task actions: "Addresses review concern: {concern}" for traceability
|
|
|
|
### Step 4: Return
|
|
Use standard PLANNING COMPLETE return format, adding a reviews section:
|
|
|
|
```markdown
|
|
### Review Feedback Addressed
|
|
|
|
| Concern | Severity | How Addressed |
|
|
|---------|----------|---------------|
|
|
| {concern} | HIGH | Plan {N}, Task {M}: {how} |
|
|
|
|
### Review Feedback Deferred
|
|
| Concern | Reason |
|
|
|---------|--------|
|
|
| {concern} | {why — out of scope, disagree, etc.} |
|
|
```
|