feat: add CE-inspired Wave 2-3 features -- multi-persona review, action routing, explore mode, headless protocol, conditional triggering#284
Open
sanmak wants to merge 1 commit into
Conversation
…on routing, explore mode, headless protocol, conditional triggering Initiative ce-wave1-foundation complete (8 specs, 3 waves, 48 tasks). Wave 2 adds multi-persona review with 4 specialized reviewer personas at Phase 4A, action routing for finding classification (auto_fix/gated_fix/manual/advisory), and a solution exploration mode for codebase-grounded approach generation. Wave 3 adds headless mode-to-mode JSON communication protocol and per-persona conditional triggering with file-pattern matching. All 5 platforms regenerated, 200+ validation checks pass, 8/8 tests pass.
|
Too many files changed for review. ( |
📝 WalkthroughWalkthroughThis PR introduces eight major SpecOps feature specifications with comprehensive design, evaluation, and implementation documentation. It adds depth-based workflow calibration, confidence tiers for findings, multi-persona review during evaluation, action routing for remediation dispatch, environment pre-flight checks, conditional persona activation, headless JSON protocols for inter-mode communication, and a new explore mode for solution discovery. Core modules (workflow, evaluation, dispatcher, pipeline) receive corresponding logic updates, generator validation gains new marker sets, and all platform outputs are regenerated. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Dispatcher
participant Evaluator
participant Personas as Multi-Persona<br/>Reviewers
participant Pipeline
User->>Dispatcher: Trigger Phase 2 spec evaluation<br/>(depth: standard)
Dispatcher->>Evaluator: Dispatch eval (headless: true)
Evaluator->>Evaluator: Run adversarial dimension scoring
Evaluator->>Evaluator: Assign confidence tiers (HIGH/MODERATE/LOW)<br/>per finding
Evaluator->>Evaluator: Compute scores from HIGH/MODERATE only
Evaluator->>Personas: Trigger Phase 4A multi-persona review
Personas->>Personas: Security activation check<br/>(filePatterns match?)
Personas->>Personas: Run 4 personas (or 3 if Security skipped)
Personas->>Personas: Deduplicate findings by<br/>file/line range
Personas->>Evaluator: Return aggregated findings<br/>(P0–P3 severity, confidence tiers)
Evaluator->>Evaluator: Apply action routing matrix<br/>(determinism, scope, risk)
Evaluator->>Evaluator: Route findings to<br/>auto_fix/gated_fix/manual/advisory
Evaluator->>Evaluator: Classify LOW confidence →<br/>advisory override
Evaluator->>Evaluator: Check combined verdict:<br/>dimension scores + P0/P1 HIGH/MODERATE?
Evaluator-->>Dispatcher: Return JSON (headless mode)
Dispatcher->>Pipeline: Parse JSON<br/>(scores, verdict, findings, fixClass)
Pipeline->>Pipeline: Apply action routing in Phase 4<br/>execute auto_fix, batch gated_fix
Pipeline-->>User: Report results
sequenceDiagram
participant User
participant Dispatcher
participant ExploreMode as Explore Mode<br/>(New)
participant SpecMode
participant Phase2
User->>Dispatcher: Request with "explore" +<br/>problem description<br/>(depth affects approach count)
Note over Dispatcher: Step 11.75 route detection
Dispatcher->>ExploreMode: Invoke explore (depth-aware config)
ExploreMode->>ExploreMode: Load repo-map, steering files,<br/>memory context
ExploreMode->>ExploreMode: Parse problem, determine<br/>approach count (lightweight:1,<br/>standard:3, deep:5)
ExploreMode->>ExploreMode: Generate 3–5 approaches<br/>with real file references
alt Interactive Platform
ExploreMode->>User: Present approaches,<br/>ask selection
User->>ExploreMode: Choose approach
else Non-Interactive
ExploreMode-->>Dispatcher: Return all approaches<br/>JSON or batch output
end
ExploreMode-->>Phase2: Enrich design-direction context<br/>with selected approach
Phase2->>SpecMode: Trigger spec mode with<br/>pre-populated approach
sequenceDiagram
participant Phase1
participant Depth as Depth Calibration<br/>(Step 9.7)
participant Workflow
participant Phase2
participant Phase3
participant Phase4
Phase1->>Depth: Compute depth from:<br/>task count, directory breadth,<br/>new dependencies
Note over Depth: Result: lightweight|standard|deep
Depth->>Phase1: Record in context summary<br/>& spec.json
Workflow->>Phase1: Check user override keywords<br/>(quick→lightweight, thorough→deep)
Workflow->>Phase2: Branch by depth
alt lightweight
Phase2->>Phase2: Skip repo-map refresh<br/>Skip scope assessment<br/>Skip spec evaluation
else standard
Phase2->>Phase2: Conditional staleness check<br/>Run scope assessment<br/>Cap spec eval to 1 iteration
else deep
Phase2->>Phase2: Force repo-map refresh<br/>Run scope assessment<br/>Allow full iterations
end
Workflow->>Phase3: Environment pre-flight<br/>(unconditional)
Phase3->>Phase3: Detect test command,<br/>check deps, git status
Workflow->>Phase4: Branch adversarial eval
alt lightweight
Phase4->>Phase4: Skip adversarial,<br/>check acceptance criteria
else standard/deep
Phase4->>Phase4: Run adversarial + personas<br/>(persona step skipped<br/>for lightweight)
end
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related issues
Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
|
There was a problem hiding this comment.
Pull request overview
Adds CE-inspired “Wave 2–3” capabilities to the SpecOps workflow by introducing explore mode, multi-persona review + action routing, and a headless JSON protocol for mode composition, then wiring these features through generation/validation, docs, and spec artifacts.
Changes:
- Introduces Explore mode (problem → 3–5 codebase-grounded approaches → selection → handoff to spec).
- Adds Multi-Persona Review, Action Routing, and Headless Mode Protocol validation + template updates, plus conditional reviewer triggering + initiative planned waves schema support.
- Updates generator templates/context, platform outputs, tests, and documentation to register and enforce the new modules/modes (Claude mode count 16).
Reviewed changes
Copilot reviewed 96 out of 115 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/test_platform_consistency.py | Imports new marker sets and extends REQUIRED_MARKERS coverage. |
| tests/test_initiative_schema.py | Adds schema tests for new plannedWaves initiative field. |
| tests/test_build.py | Updates expected Claude modes list to include explore mode. |
| spec-schema.json | Adds per-spec depth enum field. |
| skills/specops/modes/view.md | Documents depth calibration and initiative planned waves in skills output. |
| skills/specops/modes/steering.md | Documents depth calibration in skills output. |
| skills/specops/modes/memory.md | Documents depth calibration in skills output. |
| skills/specops/modes/map.md | Documents depth calibration in skills output. |
| skills/specops/modes/learn.md | Documents depth calibration in skills output. |
| skills/specops/modes/initiative.md | Enriches initiative dispatch with plannedWaves context + documents depth calibration. |
| skills/specops/modes/init.md | Documents depth calibration in skills output. |
| skills/specops/modes/from-plan.md | Documents depth calibration + planned waves + implementation context depth line. |
| skills/specops/modes/audit.md | Documents depth calibration + planned waves in audit mode output. |
| platforms/claude/modes/view.md | Regenerated Claude mode with depth calibration + planned waves content. |
| platforms/claude/modes/steering.md | Regenerated Claude mode with depth calibration content. |
| platforms/claude/modes/memory.md | Regenerated Claude mode with depth calibration content. |
| platforms/claude/modes/map.md | Regenerated Claude mode with depth calibration content. |
| platforms/claude/modes/learn.md | Regenerated Claude mode with depth calibration content. |
| platforms/claude/modes/initiative.md | Regenerated Claude mode with plannedWaves enrichment + depth calibration. |
| platforms/claude/modes/init.md | Regenerated Claude mode with depth calibration content. |
| platforms/claude/modes/from-plan.md | Regenerated Claude mode with depth calibration + planned waves + depth context line. |
| platforms/claude/modes/audit.md | Regenerated Claude mode with depth calibration + planned waves content. |
| initiative-schema.json | Adds optional plannedWaves structure with strict object validation. |
| generator/validate.py | Adds new marker sets + mode count update + validation enforcement for new features. |
| generator/templates/cursor.j2 | Includes explore + review_agents in Cursor output composition. |
| generator/templates/copilot.j2 | Includes explore + review_agents in Copilot output composition. |
| generator/templates/codex.j2 | Includes explore + review_agents in Codex output composition. |
| generator/templates/claude.j2 | Includes explore + review_agents in Claude output composition. |
| generator/templates/antigravity.j2 | Includes explore + review_agents in Antigravity output composition. |
| generator/generate.py | Wires review-agents and explore into shared render context. |
| docs/STRUCTURE.md | Documents new core modules/modes and updates mode count + version/date. |
| docs/COMPARISON.md | Updates feature matrix for multi-persona, explore, action routing, headless protocol. |
| docs/COMMANDS.md | Adds /specops explore command documentation and usage guidance. |
| core/templates/implementation.md | Adds Depth: line to Phase 1 context summary template. |
| core/templates/evaluation.md | Extends evaluation template with confidence findings detail, multi-persona section, action routing summary. |
| core/pipeline.md | Adds headless evaluation consumption + action routing handling in pipeline pseudocode/docs. |
| core/mode-manifest.json | Registers explore mode and adds review-agents/explore modules to relevant modes. |
| core/initiative-orchestration.md | Adds plannedWaves enrichment guidance for initiative execution. |
| core/explore.md | New explore mode core module (detection, workflow, approach format, safety). |
| core/decomposition.md | Documents plannedWaves initiative field and how to populate it. |
| core/config-handling.md | Documents depth field semantics and workflow impact references. |
| CLAUDE.md | Updates core modules list + Claude mode count and mode list. |
| CHECKSUMS.sha256 | Updates checksums for regenerated outputs (but see PR comments re: canonical list mismatch). |
| .specops/solution-exploration/tasks.md | Adds tasks for the solution-exploration spec artifact set. |
| .specops/solution-exploration/spec.json | Spec metadata for solution-exploration (includes depth). |
| .specops/solution-exploration/requirements.md | Requirements for explore mode feature. |
| .specops/solution-exploration/implementation.md | Implementation journal for explore mode feature. |
| .specops/solution-exploration/design.md | Design for explore mode feature. |
| .specops/runs/multi-persona-review-20260329-171013.md | Run log artifact for multi-persona review work. |
| .specops/multi-persona-review/spec.json | Spec metadata for multi-persona review feature. |
| .specops/multi-persona-review/implementation.md | Implementation journal for multi-persona review feature. |
| .specops/multi-persona-review/evaluation.md | Evaluation report for multi-persona review feature. |
| .specops/memory/patterns.json | Updates memory patterns with multi-persona-review references/counts. |
| .specops/memory/decisions.json | Adds decisions captured during multi-persona review implementation. |
| .specops/memory/context.md | Extends completed specs context with new wave features summaries. |
| .specops/inter-mode-communication/tasks.md | Tasks for headless inter-mode communication feature. |
| .specops/inter-mode-communication/spec.json | Spec metadata for inter-mode communication feature. |
| .specops/inter-mode-communication/requirements.md | Requirements for headless JSON response schema + pipeline consumption. |
| .specops/inter-mode-communication/implementation.md | Implementation journal for headless inter-mode communication. |
| .specops/inter-mode-communication/design.md | Design for headless inter-mode communication protocol. |
| .specops/initiatives/ce-wave1-foundation.json | Initiative record with order + plannedWaves context and completion status. |
| .specops/initiatives/ce-wave1-foundation-log.md | Initiative log capturing progress across waves/specs. |
| .specops/index.json | Adds completed specs to the spec index for initiative tracking. |
| .specops/environment-preflight/tasks.md | Tasks for environment pre-flight feature. |
| .specops/environment-preflight/spec.json | Spec metadata for environment pre-flight feature. |
| .specops/environment-preflight/requirements.md | Requirements for environment pre-flight checks. |
| .specops/environment-preflight/implementation.md | Implementation journal for environment pre-flight feature. |
| .specops/environment-preflight/evaluation.md | Spec evaluation report for environment pre-flight feature. |
| .specops/environment-preflight/design.md | Design for environment pre-flight feature. |
| .specops/depth-calibration/tasks.md | Tasks for depth calibration feature. |
| .specops/depth-calibration/spec.json | Spec metadata for depth calibration feature. |
| .specops/depth-calibration/requirements.md | Requirements for depth calibration feature. |
| .specops/depth-calibration/implementation.md | Implementation journal for depth calibration feature. |
| .specops/depth-calibration/evaluation.md | Spec evaluation report for depth calibration feature. |
| .specops/depth-calibration/design.md | Design for depth calibration feature. |
| .specops/confidence-gating/tasks.md | Tasks for confidence gating feature. |
| .specops/confidence-gating/spec.json | Spec metadata for confidence gating feature. |
| .specops/confidence-gating/requirements.md | Requirements for confidence gating feature. |
| .specops/confidence-gating/implementation.md | Implementation journal for confidence gating feature. |
| .specops/confidence-gating/evaluation.md | Spec evaluation report for confidence gating feature. |
| .specops/confidence-gating/design.md | Design for confidence gating feature. |
| .specops/conditional-reviewer-triggering/tasks.md | Tasks for conditional reviewer triggering feature. |
| .specops/conditional-reviewer-triggering/spec.json | Spec metadata for conditional reviewer triggering feature. |
| .specops/conditional-reviewer-triggering/requirements.md | Requirements for conditional reviewer triggering feature. |
| .specops/conditional-reviewer-triggering/implementation.md | Implementation journal for conditional reviewer triggering feature. |
| .specops/conditional-reviewer-triggering/evaluation.md | Evaluation report for conditional reviewer triggering feature. |
| .specops/conditional-reviewer-triggering/design.md | Design for conditional reviewer triggering feature. |
| .specops/action-routing/tasks.md | Tasks for action routing feature. |
| .specops/action-routing/spec.json | Spec metadata for action routing feature. |
| .specops/action-routing/implementation.md | Implementation journal for action routing feature. |
| .specops/action-routing/evaluation.md | Evaluation report for action routing feature. |
| .specops/action-routing/design.md | Design for action routing feature. |
| .claude/commands/docs-sync.md | Adds docs-sync mapping entries for new core modules. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
1359
to
1362
| platforms = list(generated.keys()) | ||
| consistency_errors = [] | ||
| for marker in WORKFLOW_MARKERS + SAFETY_MARKERS + TEMPLATE_MARKERS + VERTICAL_MARKERS + SIMPLICITY_MARKERS + DATA_HANDLING_MARKERS + INTERVIEW_MARKERS + STEERING_MARKERS + REVIEW_MARKERS + VIEW_MARKERS + UPDATE_MARKERS + TASK_TRACKING_MARKERS + EXTERNAL_TRACKING_MARKERS + REGRESSION_MARKERS + RECONCILIATION_MARKERS + FROM_PLAN_MARKERS + MEMORY_MARKERS + REPO_MAP_MARKERS + DELEGATION_MARKERS + WRITING_QUALITY_MARKERS + ENGINEERING_DISCIPLINE_MARKERS + FEEDBACK_MARKERS + COHERENCE_MARKERS + METRICS_MARKERS + RUN_LOGGING_MARKERS + PLAN_VALIDATION_MARKERS + GIT_CHECKPOINT_MARKERS + PIPELINE_MARKERS + ISSUE_BODY_MARKERS + DEPENDENCY_SAFETY_MARKERS + DEPENDENCY_INTRODUCTION_MARKERS + LEARNINGS_MARKERS + DECOMPOSITION_MARKERS + EVALUATION_MARKERS: | ||
| for marker in WORKFLOW_MARKERS + SAFETY_MARKERS + TEMPLATE_MARKERS + VERTICAL_MARKERS + SIMPLICITY_MARKERS + DATA_HANDLING_MARKERS + INTERVIEW_MARKERS + STEERING_MARKERS + REVIEW_MARKERS + VIEW_MARKERS + UPDATE_MARKERS + TASK_TRACKING_MARKERS + EXTERNAL_TRACKING_MARKERS + REGRESSION_MARKERS + RECONCILIATION_MARKERS + FROM_PLAN_MARKERS + MEMORY_MARKERS + REPO_MAP_MARKERS + DELEGATION_MARKERS + WRITING_QUALITY_MARKERS + ENGINEERING_DISCIPLINE_MARKERS + FEEDBACK_MARKERS + COHERENCE_MARKERS + METRICS_MARKERS + RUN_LOGGING_MARKERS + PLAN_VALIDATION_MARKERS + GIT_CHECKPOINT_MARKERS + PIPELINE_MARKERS + ISSUE_BODY_MARKERS + DEPENDENCY_SAFETY_MARKERS + DEPENDENCY_INTRODUCTION_MARKERS + LEARNINGS_MARKERS + DECOMPOSITION_MARKERS + EVALUATION_MARKERS + REVIEW_AGENTS_MARKERS + DEPTH_MARKERS + PREFLIGHT_MARKERS + TRIGGERING_MARKERS: | ||
| present_in = [p for p in platforms if marker in generated[p]["content"]] |
There was a problem hiding this comment.
The cross-platform consistency loop omits some newly introduced marker sets (e.g., ACTION_ROUTING_MARKERS, EXPLORE_MARKERS, HEADLESS_MARKERS). Per-platform validation checks these, and tests/test_platform_consistency checks them too, but generator/validate.py’s own consistency check should include the same marker sets to avoid false “PASS” when one platform output is missing these sections.
Comment on lines
677
to
+683
| # Check modes directory exists and has exactly 13 .md files | ||
| modes_dir = os.path.join(PLATFORMS_DIR, "claude", "modes") | ||
| if not os.path.isdir(modes_dir): | ||
| errors.append(" Missing platforms/claude/modes/ directory") | ||
| else: | ||
| mode_files = [f for f in os.listdir(modes_dir) if f.endswith(".md")] | ||
| if len(mode_files) != 15: | ||
| if len(mode_files) != 16: |
There was a problem hiding this comment.
Comment says the modes directory should have “exactly 13 .md files”, but the validator now expects 16. Update the comment to match the new expected count to avoid confusion when debugging dispatcher validation failures.
Comment on lines
+1
to
12
| 5b2bde046d1081216021c2e5ae48acc2eae7b90f42042f80bfcf103403e2a46d skills/specops/SKILL.md | ||
| 39b0ddfd465d3dadd9605860c2765f184eb6fc8e87b8e9e49c55334d861d4471 schema.json | ||
| b55e6171710e5358fcd60fe0a6c9b278f2ffc36b0db07be871db121e1012d560 platforms/claude/SKILL.md | ||
| 5b2bde046d1081216021c2e5ae48acc2eae7b90f42042f80bfcf103403e2a46d platforms/claude/SKILL.md | ||
| 67ebd5127d40042f38a909fbb96ef311352008774e5c5cbb8dedaaace3387b95 platforms/claude/platform.json | ||
| 075960cd218a7447bd232bad45f53599320a1c2a34d73f9246ff64193a5bc617 platforms/cursor/specops.mdc | ||
| 7a54a3f1974568b430867fa552cd83879588fdffd6845aa50dbee75c427d2fc9 platforms/cursor/specops.mdc | ||
| 35b82df4e05f21bd52f46e4d32a1b2771235cbc4e8a4c225f040088326831e67 platforms/cursor/platform.json | ||
| 8f1f44c6d63f9f245c2faaf91d29927005d5d9c1588fd7fe0c8f92322f6aafcf platforms/codex/SKILL.md | ||
| 6a84e8a4f72ee29d421e8390624bb2961b34a3dee8ec0a25b2783a8897e9e533 platforms/codex/SKILL.md | ||
| 8e9327d9f129254690678ad1fdc8b34c32313866db82dd2af9d6b516cd38cd54 platforms/codex/platform.json | ||
| 7b93428e5737a47529ccf3021dff411f9f952d30027c957443487ba90f95cf18 platforms/copilot/specops.instructions.md | ||
| 763f3066b596d08a4cb3cb8f9f5e656ea84408da80c5d71c2102f18af3a87dbd platforms/copilot/specops.instructions.md | ||
| 77a9565abe02085d89c5b0a3620ae2b0fcb9c1b1a792e7d5b0fa65fb36d411f9 platforms/copilot/platform.json | ||
| 0f79e46c985e39cc22d163b149e996d5b40db4edb41e410b5cacee7657e7e324 platforms/antigravity/specops.md | ||
| 7469ca3a3cb365e778d04581c9501f35a87afbcc206ff8873219050c637f7e4d platforms/antigravity/platform.json | ||
| db144ebaf7d73edb3eac3d66b7d58cec492b857c8ba0990b472e72bce80d2cfb core/workflow.md | ||
| 6dccd9f199253ee83ec20b12ef6d15e7f6d91af0549fa795a91741eeef7876c5 core/workflow.md | ||
| 295777e6d065ad974ef3c5cc8795ead064cc8528eb74d686fb142d891893e888 core/safety.md |
There was a problem hiding this comment.
CHECKSUMS.sha256 no longer includes several files that are treated as checksummed elsewhere (e.g., platforms/antigravity/specops.md + platform.json, and core/reconciliation.md/core/engineering-discipline.md/core/writing-quality.md). This makes shasum -c CHECKSUMS.sha256 stop covering those artifacts and also diverges from the canonical regeneration list embedded in scripts/bump-version.sh --checksums and hooks/pre-commit. Regenerate CHECKSUMS.sha256 using the canonical command (or update the canonical lists if the intent is to change what’s checksummed) so all three stay in sync.
Comment on lines
30
to
+33
| # Claude split output: 15 mode files (from core/mode-manifest.json) | ||
| EXPECTED_CLAUDE_MODES = [ | ||
| "audit.md", | ||
| "explore.md", |
There was a problem hiding this comment.
The comment above EXPECTED_CLAUDE_MODES still says “15 mode files”, but the list (and validator) now expects 16 including explore.md. Update the comment to avoid confusion when maintaining the expected mode list.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 20
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
generator/validate.py (1)
1361-1367:⚠️ Potential issue | 🟠 MajorAdd the missing marker groups to the cross-platform pass.
validate_platform()checksACTION_ROUTING_MARKERS,EXPLORE_MARKERS, andHEADLESS_MARKERS, but the consistency loop starting on Line 1361 omits all three. One platform can therefore drift on those sections without the cross-platform check noticing.As per coding guidelines, "When new *_MARKERS constants are added, they must also be added to the cross-platform consistency check loop later in the same file. This is the most common recurring review issue — check both locations."🔧 Proposed fix
- for marker in WORKFLOW_MARKERS + SAFETY_MARKERS + TEMPLATE_MARKERS + VERTICAL_MARKERS + SIMPLICITY_MARKERS + DATA_HANDLING_MARKERS + INTERVIEW_MARKERS + STEERING_MARKERS + REVIEW_MARKERS + VIEW_MARKERS + UPDATE_MARKERS + TASK_TRACKING_MARKERS + EXTERNAL_TRACKING_MARKERS + REGRESSION_MARKERS + RECONCILIATION_MARKERS + FROM_PLAN_MARKERS + MEMORY_MARKERS + REPO_MAP_MARKERS + DELEGATION_MARKERS + WRITING_QUALITY_MARKERS + ENGINEERING_DISCIPLINE_MARKERS + FEEDBACK_MARKERS + COHERENCE_MARKERS + METRICS_MARKERS + RUN_LOGGING_MARKERS + PLAN_VALIDATION_MARKERS + GIT_CHECKPOINT_MARKERS + PIPELINE_MARKERS + ISSUE_BODY_MARKERS + DEPENDENCY_SAFETY_MARKERS + DEPENDENCY_INTRODUCTION_MARKERS + LEARNINGS_MARKERS + DECOMPOSITION_MARKERS + EVALUATION_MARKERS + REVIEW_AGENTS_MARKERS + DEPTH_MARKERS + PREFLIGHT_MARKERS + TRIGGERING_MARKERS: + for marker in WORKFLOW_MARKERS + SAFETY_MARKERS + TEMPLATE_MARKERS + VERTICAL_MARKERS + SIMPLICITY_MARKERS + DATA_HANDLING_MARKERS + INTERVIEW_MARKERS + STEERING_MARKERS + REVIEW_MARKERS + VIEW_MARKERS + UPDATE_MARKERS + TASK_TRACKING_MARKERS + EXTERNAL_TRACKING_MARKERS + REGRESSION_MARKERS + RECONCILIATION_MARKERS + FROM_PLAN_MARKERS + MEMORY_MARKERS + REPO_MAP_MARKERS + DELEGATION_MARKERS + WRITING_QUALITY_MARKERS + ENGINEERING_DISCIPLINE_MARKERS + FEEDBACK_MARKERS + COHERENCE_MARKERS + METRICS_MARKERS + RUN_LOGGING_MARKERS + PLAN_VALIDATION_MARKERS + GIT_CHECKPOINT_MARKERS + PIPELINE_MARKERS + ISSUE_BODY_MARKERS + DEPENDENCY_SAFETY_MARKERS + DEPENDENCY_INTRODUCTION_MARKERS + LEARNINGS_MARKERS + DECOMPOSITION_MARKERS + EVALUATION_MARKERS + REVIEW_AGENTS_MARKERS + ACTION_ROUTING_MARKERS + PREFLIGHT_MARKERS + DEPTH_MARKERS + EXPLORE_MARKERS + HEADLESS_MARKERS + TRIGGERING_MARKERS:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@generator/validate.py` around lines 1361 - 1367, The cross-platform consistency loop that iterates over WORKFLOW_MARKERS + ... currently omits ACTION_ROUTING_MARKERS, EXPLORE_MARKERS, and HEADLESS_MARKERS, so add those three marker groups to the concatenated sequence in the loop (the same place that builds markers for validation in validate_platform()) so each marker (including ACTION_ROUTING_MARKERS, EXPLORE_MARKERS, HEADLESS_MARKERS) is checked across all platforms; ensure the added constants are included in the same order/concatenation used for other *_MARKERS and that any error reporting still appends to consistency_errors when a marker is missing.
🟡 Minor comments (4)
.specops/runs/multi-persona-review-20260329-171013.md-12-12 (1)
12-12:⚠️ Potential issue | 🟡 MinorMinor: Consider capitalizing "GitHub" if this is display text.
The static analysis flagged that "github" should be "GitHub" (official spelling). However, if
taskTracking=githubrepresents a literal config value rather than display text, the lowercase may be intentional. Verify whether this should match the config key format or be human-readable.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/runs/multi-persona-review-20260329-171013.md at line 12, The review notes that the string taskTracking=github may need to be capitalized; locate occurrences of the literal "github" used for display (e.g., the entry showing "taskTracking=github" in the spec output) and if it's meant for human-readable output, change it to "GitHub"; if instead it is a machine/config key, leave the literal lowercase but add a clarifying comment or separate display field so UI/docs show "GitHub" while the config key remains "github"..specops/depth-calibration/spec.json-14-26 (1)
14-26:⚠️ Potential issue | 🟡 MinorMissing implementation evaluation record for completed spec.
Same as
environment-preflight/spec.json: this spec is marked"status": "completed"but lacksevaluation.implementation. For consistency with other completed specs in this PR, consider adding the implementation evaluation record.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/depth-calibration/spec.json around lines 14 - 26, The spec file marks the spec as "status": "completed" but is missing the implementation evaluation record under evaluation. Add an evaluation.implementation object similar to the one used in other completed specs (e.g., include fields like iterations, passed, scores, and evaluatedAt) so the completed spec has both evaluation.spec and evaluation.implementation entries; update the "evaluation" object in the JSON to include the implementation evaluation record with appropriate values and timestamps to match the format used elsewhere..specops/environment-preflight/spec.json-14-26 (1)
14-26:⚠️ Potential issue | 🟡 MinorMissing implementation evaluation record for completed spec.
The spec has
"status": "completed"but only containsevaluation.spec. Other completed specs in this PR (e.g.,action-routing/spec.json) include bothevaluation.specandevaluation.implementationrecords.Suggested addition
"evaluatedAt": "2026-03-29T14:44:25Z" - } + }, + "implementation": { + "iterations": 1, + "passed": true, + "scores": { + "functionalityDepth": 8, + "designFidelity": 8, + "codeQuality": 8, + "testVerification": 8 + }, + "evaluatedAt": "2026-03-29T15:10:00Z" + } },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/environment-preflight/spec.json around lines 14 - 26, This spec has "status": "completed" but only includes evaluation.spec; add a matching evaluation.implementation object alongside evaluation.spec containing the implementation evaluation details (e.g., iterations, passed, scores, evaluatedAt) so completed specs mirror other files; update the JSON under the existing "evaluation" key to include an "implementation" entry consistent with the structure used by action-routing/spec.json and ensure keys are populated (iterations, passed, scores, evaluatedAt) to reflect the implementation evaluation..specops/depth-calibration/design.md-47-52 (1)
47-52:⚠️ Potential issue | 🟡 MinorMinor inconsistency in override keyword documentation.
This design document lists "lightweight" as an override keyword (line 49), but
.specops/depth-calibration/requirements.mdline 47 lists "quick" or "lightweight" as separate keywords with the same effect.Ensure consistency across both documents. The requirements document (FR-3, line 47) should be considered authoritative for acceptance criteria.
📝 Align keyword lists
Verify that both documents list the same keywords:
- Lightweight: "quick", "lightweight", "simple", "trivial", "minor"
- Deep: "thorough", "deep", "deep dive", "exhaustive", "comprehensive"
Consider consolidating the authoritative keyword list in one location (requirements.md) and having design.md reference it.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/depth-calibration/design.md around lines 47 - 52, The design doc's Phase 1 step 6 depth-override keyword lists must be aligned with the authoritative list in requirements.md (FR-3); update the "lightweight" and "deep" keyword arrays in .specops/depth-calibration/design.md (Phase 1 step 6) to exactly match the keywords in .specops/depth-calibration/requirements.md (FR-3): Lightweight = "quick", "lightweight", "simple", "trivial", "minor" and Deep = "thorough", "deep", "deep dive", "exhaustive", "comprehensive"; alternatively remove the duplicated lists from design.md and add a single line that references FR-3 as the authoritative source so both docs remain consistent.
🧹 Nitpick comments (15)
.specops/environment-preflight/requirements.md (1)
14-18: Consider unchecking acceptance criteria in requirements documents.All acceptance criteria are pre-marked as
[x]complete. Requirements documents typically define what needs to be verified, with criteria being checked during or after implementation. Pre-checking them in the requirements doc may cause confusion about whether these are "to-be-verified" or "already-verified" items.If this spec is already completed (status
completed), consider noting this clearly in the document header, or move the checked criteria to the evaluation report instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/environment-preflight/requirements.md around lines 14 - 18, The "Acceptance Criteria" checklist currently has all items pre-checked ([x]) which gives the impression they are already verified; edit the "Acceptance Criteria" block to uncheck items (use [-] or [ ] instead of [x]) so they represent pending verification, or if the spec truly is complete update the document header to explicitly state status: completed and move checked items into the evaluation report/implementation.md; specifically modify the checklist lines under "Acceptance Criteria" and update the document header or move the checked entries to the evaluation report to avoid confusion..specops/action-routing/evaluation.md (1)
29-29: Minor: Consider hyphenating compound adjective."High risk row" could be written as "High-risk row" when used as a compound adjective modifying "row."
📝 Suggested fix
-| 1 | The matrix does not explicitly cover "Deterministic + Wide + High" -- row 5 uses "Any" for scope but this is the only High risk row | MODERATE (0.65) | requirements.md FR-2 decision matrix | The "Any" covers it implicitly, but a reader may miss that Wide + High is manual | +| 1 | The matrix does not explicitly cover "Deterministic + Wide + High" -- row 5 uses "Any" for scope but this is the only High-risk row | MODERATE (0.65) | requirements.md FR-2 decision matrix | The "Any" covers it implicitly, but a reader may miss that Wide + High is manual |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/action-routing/evaluation.md at line 29, Edit the phrase "High risk row" in the evaluation.md table/text to the hyphenated form "High-risk row" wherever it appears (e.g., the cell discussing "Deterministic + Wide + High" / "Wide + High" scope) so the compound adjective correctly modifies "row."core/templates/evaluation.md (1)
17-33: Add explicit confidence-tier threshold mapping in-template.The template shows
HIGH/MODERATE/LOW (value)examples but does not define canonical cutoffs, which can cause inconsistent classification between evaluators. Add a short normative mapping block once (e.g.,HIGH >= x,MODERATE >= y, elseLOW).Also applies to: 51-62, 99-101
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@core/templates/evaluation.md` around lines 17 - 33, Add a canonical confidence-tier mapping to the "Findings Detail" section so evaluators have explicit cutoffs: insert a short normative block under the "Findings Detail" heading (or immediately above the confidence examples table) that states the thresholds (e.g., "HIGH: score >= 0.80; MODERATE: 0.50–0.79; LOW: < 0.50") and a one-line note that these are the authoritative cutoffs to use when converting numeric scores to HIGH/MODERATE/LOW; update any duplicate examples elsewhere in the template (the other instances around lines 51-62 and 99-101) to reference or reuse this single mapping block..specops/initiatives/ce-wave1-foundation.json (2)
7-7: Author name inconsistent with spec.json files.The initiative uses
"author": "sanketmakhija"while the individual spec.json files use"author": { "name": "sanmak" }. Consider aligning to a consistent author identifier across initiative and spec metadata.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/initiatives/ce-wave1-foundation.json at line 7, The initiative metadata uses a string author entry ("author": "sanketmakhija") which is inconsistent with the spec.json convention of an author object; update the initiative's author field to the same structure (e.g., replace the string value for "author" with an object like { "name": "sanmak" } or whatever canonical name is used across spec.json files) so the author symbol is consistent across initiative and spec metadata.
26-57: Wave descriptions use opaque D-numbering.The
plannedWavesdescriptions reference specs using shorthand like "D2", "D4", "D7", "D9" (e.g., line 26: "D2 uses D4 confidence format"). This numbering isn't explained and doesn't obviously map to the spec IDs. Consider using the actual spec IDs for clarity, or adding a legend.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/initiatives/ce-wave1-foundation.json around lines 26 - 57, Replace opaque D-number references (D2, D4, D7, D9) in the wave/spec descriptions with explicit spec IDs or add a short legend mapping each D-number to the corresponding spec id; update occurrences in the "Smart Review & Exploration" description (where D2/D3/D4/D5 are referenced) and in "Composability & Intelligence" (D7/D2/D3/D9) to either spell out the target spec ids (e.g., multi-persona-review, action-routing, solution-exploration, inter-mode-communication, conditional-reviewer-triggering) or add a top-level mapping object (e.g., dNumberLegend) so readers can unambiguously resolve D-numbers to spec ids..specops/environment-preflight/spec.json (1)
28-37: InconsistentrelatedSpecsformat across spec files.This file uses an object format with
specIdandrelationshipfields, whileaction-routing/spec.jsonuses a simple string array. Consider aligning on a single format for consistency across the initiative.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/environment-preflight/spec.json around lines 28 - 37, The relatedSpecs entry uses object items with specId and relationship (the keys specId and relationship) while other specs (e.g., action-routing) use a simple string array; update this file so relatedSpecs is a string array of spec IDs (e.g., replace the objects that contain specId/relationship with just "depth-calibration" and "confidence-gating") to match the project-wide format for relatedSpecs..specops/confidence-gating/implementation.md (1)
45-48: Session Log table is incomplete.Same observation as
environment-preflight/implementation.md: the Session Log has headers but no entries. Consider documenting implementation sessions for consistency with other journals in this PR.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/confidence-gating/implementation.md around lines 45 - 48, The "Session Log" table in the .specops/confidence-gating/implementation.md currently has only headers and no entries; add one or more session entries (rows) documenting implementation sessions similar to environment-preflight/implementation.md, including Phase, Task, Status, and Notes for each entry so the Session Log is complete and consistent with other journals; update the "Session Log" table under the Session Log heading to include concrete rows describing the work performed, e.g., phases and tasks, statuses (e.g., Complete/In Progress), and brief notes..specops/environment-preflight/implementation.md (1)
45-48: Session Log table is incomplete.The Session Log section has column headers but no entries documenting the implementation sessions. Other implementation journals in this PR (e.g.,
inter-mode-communication/implementation.md) include actual session entries. Consider adding session details for traceability.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/environment-preflight/implementation.md around lines 45 - 48, The "Session Log" section currently contains only the table header (columns "Phase | Task | Status | Notes") with no entries; populate this table with one or more session entries documenting implementation work (e.g., Phase names, Task descriptions, Status values such as "Completed"/"In Progress", and concise Notes), following the format and level of detail used in inter-mode-communication/implementation.md so reviewers can trace changes; update the "Session Log" table under the "Session Log" header in .specops/environment-preflight/implementation.md to include these rows.generator/validate.py (1)
683-686: Derive the expected Claude mode count from the manifest.Line 683 hardcodes
16, so every future mode addition/removal requires a second manual edit here.core/mode-manifest.jsonalready has the source of truth.♻️ Suggested refactor
- if len(mode_files) != 16: + manifest_path = os.path.join(CORE_DIR, "mode-manifest.json") + with open(manifest_path, "r", encoding="utf-8") as f: + manifest = json.load(f) + expected_mode_count = len(manifest.get("modes", {})) + if len(mode_files) != expected_mode_count: errors.append( - f" Expected 16 mode files in platforms/claude/modes/," + f" Expected {expected_mode_count} mode files in platforms/claude/modes/," f" found {len(mode_files)}: {sorted(mode_files)}" )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@generator/validate.py` around lines 683 - 686, Replace the hardcoded 16 with a derived count from the manifest: open and parse core/mode-manifest.json, compute expected_count = sum(1 for m in manifest["modes"] if m.get("platform") == "claude" or m.get("path", "").startswith("platforms/claude/")), then compare len(mode_files) to expected_count and update the error message accordingly (use the existing mode_files and errors variables so only the numeric literal and message logic change)..specops/conditional-reviewer-triggering/design.md (1)
44-49: Clarify D5 by separating “alternatives considered” from the final decision.This section currently states one approach, then immediately reverses it. Consider restructuring into “Option A / Option B / Final decision” to avoid ambiguity for future readers.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/conditional-reviewer-triggering/design.md around lines 44 - 49, The D5 paragraph mixes alternatives and the final decision; refactor it to clearly separate "Option A" (adding new markers to REVIEW_AGENTS_MARKERS) and "Option B" (introducing a separate TRIGGERING_MARKERS constant), then state the final decision (use TRIGGERING_MARKERS) as its own sentence; mention the rationale for each option briefly and reference existing marker sets like REVIEW_AGENTS_MARKERS, TRIGGERING_MARKERS, ACTION_ROUTING_MARKERS, HEADLESS_MARKERS and the test file test_platform_consistency.py so readers can see the consistency implications and where the change affects validation..specops/environment-preflight/design.md (1)
27-30: Expand Python test framework detection.The current detection only checks for
[tool.pytest]and[tool.unittest]inpyproject.toml. Many Python projects use pytest without explicitpyproject.tomlconfiguration, or use other test runners liketox,nose, or define tests viasetup.py.Consider adding:
- Check for
pytestinrequirements.txtorpyproject.tomldependencies- Check for
tox.ini(tox test runner)- Check for
setup.pywithtest_suiteconfiguration🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/environment-preflight/design.md around lines 27 - 30, Extend the test detection logic so FILE_EXISTS/READ_FILE checks also look for common runners and dependency declarations: when pyproject.toml is present, inspect its dependencies for "pytest" or other test packages to set test_cmd="pytest"; if requirements.txt exists, READ_FILE it and set test_cmd="pytest" when "pytest" is listed; add FILE_EXISTS checks for "tox.ini" and set test_cmd="tox"; add FILE_EXISTS for "setup.py" and READ_FILE to look for a "test_suite" or invocation of unittest/pytest and set test_cmd to "python -m unittest" or "python setup.py test" appropriately; keep using the existing test_cmd variable and existing FILE_EXISTS/READ_FILE control flow..specops/multi-persona-review/implementation.md (1)
22-23: Document auto-loading assumption for future maintainability.Decision
#2relies onload_core_modules()glob pattern automatically includingcore/review-agents.mdwithout explicit registration. While this works currently, it creates an undocumented assumption that could break if:
- The glob pattern is changed to be more selective
- Module loading order becomes important
- Conditional loading logic is added
Consider adding a comment in
generator/generate.pynear theload_core_modules()call documenting thatcore/*.mdauto-loading is relied upon by multiple modules, or add explicit registration for critical modules likereview-agents.md.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/multi-persona-review/implementation.md around lines 22 - 23, Add an explicit note or registration to avoid the undocumented auto-load assumption: update the code around the load_core_modules() call (function name load_core_modules()) in generator/generate.py to either add a clear comment that core/*.md (including review-agents.md) is intentionally relied upon by other modules, or add an explicit registration/entry for review-agents.md in the build_common_context()/module mapping so critical modules are guaranteed to load regardless of future glob changes..specops/inter-mode-communication/tasks.md (1)
64-66: Add observability for JSON parse failures.The headless protocol includes fallback to markdown parsing when JSON parsing fails (line 65-66), which is good for backward compatibility. However, frequent JSON parse failures could indicate:
- Evaluation mode not producing valid JSON
- Schema changes not propagated
- LLM hallucination issues
Consider adding observability:
- Log a warning when JSON parse fails and fallback is used
- Track the frequency of fallback usage as a metric
- Consider surfacing this in the evaluation report ("evaluation returned unparseable JSON, used markdown fallback")
This helps detect and debug headless protocol adoption issues.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/inter-mode-communication/tasks.md around lines 64 - 66, When JSON parsing falls back to markdown in the headless protocol (the JSON parse + markdown fallback logic in parseEvaluationResponse / evaluation result handling), add observability: log a warning including the parse error and the raw response when JSON.parse fails, increment a metric counter (e.g., evaluation_json_fallback_count) each time the fallback is used, and annotate the produced evaluation report with a short flag/message ("evaluation returned unparseable JSON, used markdown fallback") so downstream tooling can detect and aggregate these events..specops/depth-calibration/design.md (1)
47-52: User override for depth is intentional; consider defensive safeguards if override scope should be constrained.The user override mechanism (allowing keywords like "quick" to force lightweight depth) exists as designed and is intentional per FR-3. Lightweight depth is explicitly meant to skip evaluation steps (FR-2 acceptance criteria), and the override is auditable—recorded as "user override" in implementation.md.
However, if preventing unintended depth reduction is desired, consider:
- Restrict override to adjacent tiers only (standard ↔ lightweight or standard ↔ deep, not lightweight ↔ deep)
- Log override decisions when they reduce evaluation rigor
- Force minimum depth for security-sensitive file modifications (via file path patterns)
These safeguards were not identified as gaps during evaluation and would enhance the system's defensibility, but are not required to match the current design specification.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.specops/depth-calibration/design.md around lines 47 - 52, Summary: The user override for depth in Phase 1 step 6 is intentional but needs optional defensive safeguards. Update the request-analysis logic (Phase 1 step 6) and the "user override" handling to: 1) constrain overrides to adjacent tiers only (allow standard↔lightweight and standard↔deep but disallow lightweight↔deep); 2) emit a structured audit/log entry whenever an override decreases evaluation rigor (include detected keyword, original computed depth, and final depth); and 3) enforce a configurable minimum depth for security-sensitive file modifications by matching file path patterns (implement configuration keys and checks referenced from implementation.md and FR-3/FR-2). Ensure these safeguards are documented in implementation.md and that the logging and path-pattern checks are pluggable/configurable.platforms/antigravity/specops.md (1)
183-186: Python dependency readiness check can false-pass.Using
__pycache__/as a proxy for installed dependencies is unreliable (it can exist without project deps being installed). This weakens pre-flight signal quality on Line 185.Suggested fix
- - Python: Check if the file exists at(`.venv/`) or Check if the file exists at(`__pycache__/`). If both missing, Tell the user("Python dependencies may not be installed. Run `pip install -r requirements.txt` or `pip install -e .` before proceeding."). + - Python: Check if the file exists at(`.venv/`) or Check if the file exists at(`venv/`) or Check if the file exists at(`poetry.lock`) or Check if the file exists at(`requirements.txt`). If no environment indicator is present, Tell the user("Python environment/dependencies may not be initialized. Run your environment setup (for example: `python -m venv .venv && pip install -r requirements.txt` or `pip install -e .`) before proceeding.").🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@platforms/antigravity/specops.md` around lines 183 - 186, The Python readiness check currently treats presence of "__pycache__/" as proof that dependencies are installed; update the dependency-installation detection logic (the block that checks ".venv/" and "__pycache__/" and emits the message "Python dependencies may not be installed. Run `pip install -r requirements.txt` or `pip install -e .` before proceeding.") so it no longer uses "__pycache__/" as a proxy: instead require either a virtualenv indicator file/directory inside the project (e.g., ".venv/" plus "pyvenv.cfg") or a populated site-packages directory (match ".venv/lib/python*/site-packages" or ".venv/Lib/site-packages" on Windows); if those checks fail, keep the existing user-facing message. Ensure you only change the detection logic and message emission in the same dependency-check block that references ".venv/" and "__pycache__/".
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.specops/confidence-gating/requirements.md:
- Around line 7-18: FR-1 contains an inconsistent LOW confidence threshold ("LOW
(below 0.50)" vs "LOW (< 0.60)"); standardize to a single threshold by changing
the earlier "LOW (below 0.50)" occurrence to "LOW (below 0.60)" (or vice versa
if product decides on 0.50) and update any matching text in the "Confidence Tier
Classification", acceptance criteria, and any "Confidence:" annotation examples
so all references (e.g., the FR-1 section, the "Confidence tiers" line, and the
acceptance criteria) consistently use LOW < 0.60.
In @.specops/depth-calibration/requirements.md:
- Around line 12-19: Clarify and resolve the circular dependency between FR-1
and FR-2 by choosing one of two fixes: (A) state that the depth flag is
initially computed prior to Phase 1 step 9.5 using only request/PR metadata
(e.g., task count estimate and declared affected domains) and name this
pre-computed field (e.g., "initial_depth") which is later reconciled after full
scope assessment in step 9.5 and persisted to spec.json as "depth"; or (B)
require a minimal mandatory scope assessment pass that always runs to produce
the three signals (task count, directory breadth, new dependencies) necessary
for depth computation, after which FR-2’s "skip scope assessment" becomes a
conditional short-circuit that only skips further iteration/validation but not
the minimal signal collection; update the requirement text around "Phase 1
completes step 9.5 (Scope Assessment)", FR-2, and the acceptance criteria
(implementation.md Phase 1 Context Summary and spec.json depth) to reflect the
chosen approach so there is no ambiguity about when and how the depth flag is
computed and persisted.
In @.specops/environment-preflight/design.md:
- Line 45: Replace the invalid Python dependency check that looks for
FILE_EXISTS(`.venv/`) or FILE_EXISTS(`__pycache__/`) with checks that actually
verify installed packages: for pip-based projects verify `site-packages/` exists
inside `.venv/` or `.venv/pyvenv.cfg` is present; for Poetry verify the project
`.venv/` created by Poetry exists; for Pipenv verify `Pipfile.lock` exists and
then confirm the virtualenv directory referenced in that lockfile (or pipenv
--venv equivalent) is present. Update the logic that currently uses
FILE_EXISTS(`.venv/`) and FILE_EXISTS(`__pycache__/`) to perform these more
specific checks.
In @.specops/inter-mode-communication/design.md:
- Around line 144-151: After parsing evaluationResponse JSON, validate that it
contains the required fields and types before accessing
evaluationResponse.scores, evaluationResponse.verdict, and
evaluationResponse.findings: implement a small validator (e.g.,
validateEvaluationResponse) that returns true only if scores is an array/object
of numeric values, verdict is a non-empty string, and findings is an
array/string as expected; if validation fails, fall back to the existing
markdown parsing logic or raise a clear error, and use the validator to gate
setting evaluationScores, overallVerdict, and findings.
In @.specops/multi-persona-review/spec.json:
- Around line 15-68: The spec JSON uses the wrong property names and shapes:
update each object in specDependencies to replace the relationship field with
reason (preserve specId and required), and convert relatedSpecs from an array of
objects to a string array of specId values (e.g.,
["depth-calibration","environment-preflight",...]); then re-run JSON/schema
validation to ensure specDependencies and relatedSpecs conform to the expected
schema (check specDependencies, specId, reason, required and relatedSpecs).
In @.specops/solution-exploration/requirements.md:
- Around line 24-30: Unify the conflicting approach-count rules in
requirements.md by replacing the two different ranges with a single canonical
contract (for example: "default 3–5 approaches, lightweight 2–3 approaches, deep
up to 5 approaches"); update the checklist items that mention "Explore mode
generates 3-5 codebase-grounded solution approaches" and the "Depth flag
integration" line so they both reflect the chosen canonical rule and ensure any
reference to detection patterns in core/dispatcher.md remains unchanged.
In `@core/evaluation.md`:
- Around line 296-299: The current flow converts gated_fix into auto_fix when
canAskInteractive is false; instead, change the decision logic that handles
gated_fix items so they are not auto-applied: if canAskInteractive is false,
mark gated_fix findings as manual/pending (retain their gated_fix
classification), add them to the post-run report (and/or a review queue) and
record them in implementation.md as pending approval rather than applying
changes; keep ASK_USER behavior unchanged when canAskInteractive is true and
ensure the code path that previously applied gated_fix (the conditional that
checks canAskInteractive and promotes gated_fix to auto_fix) is updated to only
auto-apply findings tagged auto_fix while leaving gated_fix untouched.
- Around line 223-282: The router expects a severity (P0-P3) on every finding
but adversarial evaluator outputs lack severity, so add a deterministic mapping
step that injects severity before routing: implement a helper (e.g.,
mapScoreToSeverity or assignSeverityToFindings) that reads adversarial evaluator
fields (score/confidence) and sets severity P0-P3 using clear thresholds, or
modify the adversarial evaluator output to include a severity field directly
(update functions/classes named adversarialEvaluator, aggregateFindings, and the
routing entry point actionRouter/classifyFinding to consume the new severity);
ensure the mapping runs immediately after aggregation and before the Routing
Decision Matrix and update any references in the routing procedure to use the
new severity field for override rules.
- Around line 39-47: The "Confidence Tiers for Findings" table currently
requires code-specific evidence for HIGH and MODERATE tiers which breaks
spec-only evaluations; update the HIGH and MODERATE rows so their evidence
requirements are artifact-agnostic by replacing "Specific file path and line
reference" and "File path or code pattern reference" with neutral alternatives
like "precise artifact reference (e.g., spec section, design ID, or code path)"
and ensure the rest of required items (quoted/ described passage and impact
statement for HIGH; likely impact statement for MODERATE) remain; edit the table
header "Confidence Tiers for Findings" and the HIGH and MODERATE lines to use
these generic evidence rules so the table applies equally to spec and
implementation reviews.
- Around line 286-292: The described auto-fix protocol is unsafe because it
calls EDIT_FILE (and then “revert”) without preserving pre-edit state and
“revert” is not an abstract operation; update the protocol steps (the numbered
steps using EDIT_FILE, RUN_COMMAND, logging to implementation.md) to be atomic
by first invoking a declared save/rollback operation (e.g., CREATE_SNAPSHOT or
SAVE_WORKSPACE_STATE) before EDIT_FILE and, on failure, call the corresponding
declared RESTORE_SNAPSHOT or REVERT_FILE operation; alternatively add and
document a new abstract operation REVERT_FILE/RESTORE_WORKSPACE in
core/tool-abstraction.md and replace the ad-hoc “revert” wording with that
operation, ensuring all references (EDIT_FILE, RUN_COMMAND, implementation.md,
and the new snapshot/revert op) are consistent.
In `@core/explore.md`:
- Line 32: The README/diff shows an unconditional READ_FILE(`.specops.json`)
call that will throw on uninitialized repos; update the load logic to first
check for the presence of `.specops.json` (or catch the read error) and fall
back to the same default config used elsewhere, then apply the existing Safety
Rules to all loaded values; specifically, modify the code around the READ_FILE
call so it returns the default configuration when the file is missing or
unreadable and still runs the Safety Rules validation on either the loaded
config or the defaults.
In `@core/initiative-orchestration.md`:
- Line 82: The plannedWaves.description and plannedWaves.context are being
injected directly into sub-agent prompt/context for Initiative Context and Spec
Identity; add an explicit sanitization/neutralization step that runs before any
dispatch/handoff injection (e.g., a sanitizeForPrompt/safePromptText function)
and apply it to both the wave-level description and each spec's
description/context; ensure the sanitizer strips or neutralizes instruction-like
tokens, control characters, and prompt markers and validate/trim length, and
call it wherever plannedWaves entries are assembled for the agent request so no
raw plannedWaves text is ever inserted directly.
In `@core/pipeline.md`:
- Around line 108-114: The current branch turns items with classification
gated_fix into silent auto edits when canAskInteractive is false; instead keep
gated_fix gated in non-interactive runs by leaving their classification
unchanged and surface them for manual review or fail the run: in the block
guarded by canAskInteractive, do not reclassify gated_fix to auto_fix when
canAskInteractive is false—either enqueue them into a NEEDS_REVIEW/manual queue
or return an error status so ASK_USER approval is still required before applying
changes.
- Around line 63-80: The headless evaluation handler must check
evaluationResponse.status and evaluationResponse.verdict before treating the
payload as valid: in the dispatch evaluation / evaluationResponse handling, only
accept the structured JSON path when evaluationResponse.status === "success" (or
an explicit success token used by the schema) and evaluationResponse.verdict is
non-null; otherwise treat it as a failure/partial case—log/persist the failure,
set overallVerdict to an appropriate fallback (e.g., "incomplete" or leave null)
and route to the fallback branch that reads/parses evaluation.md and derives
evaluationScores, overallVerdict, and findings. Ensure you update the decision
logic that assigns evaluationScores, overallVerdict, and findings so it only
executes for successful headless responses.
In `@core/review-agents.md`:
- Around line 168-173: The deduplication step ("Deduplicate") must preserve
severity/confidence pairs instead of combining max severity and max confidence
independently; update the logic that merges findings for the same
file/path/line-range to retain each contributing finding's original
(severity,confidence) tuple or select a single representative tuple from an
actual contributor, and record explicit disagreement notes when tuples differ
(e.g., "Severity/Confidence disagreement: [persona-A] P1/LOW, [persona-B]
P3/HIGH; using representative [persona-X] Pn/LEVEL"). Ensure the grouping code
that handles "overlapping line range within 5 lines" and the rules for "most
conservative" are changed to: (1) preserve all source tuples as evidence, (2)
evaluate pass/fail against the preserved tuples or a chosen real contributor
tuple, and (3) emit a clear disagreement field when contributors disagree—do
this where the deduplication logic referenced as "Deduplicate" merges findings.
- Around line 124-153: The activation logic in Step 4A.2.5 must validate and
sanitize all persona trigger entries and changed-file paths before any glob
matching or READ_FILE: implement a utility (e.g., normalizeAndValidatePath /
isPathWithinRepo) that 1) rejects absolute paths and any segments containing
"..", 2) resolves each pattern or "Files to Modify" entry against the repository
root, 3) ensures the resolved path is inside the repo root, and 4) returns
normalized relative paths; call this sanitizer when loading extended
filePatterns (from steering/ and CLAUDE.md) and when reading the
implementation.md "Files to Modify" list and before any content-based READ_FILE
or glob matching so malformed entries are rejected or logged and cannot escape
the repo.
In `@core/workflow.md`:
- Around line 187-190: The merge-conflict detection logic that parses
RUN_COMMAND(`git status --porcelain`) currently blocks on markers UU, AA, DD,
AU, UA but omits DU and UD; update the check that inspects the porcelain output
(the branch state check) to treat lines starting with DU and UD as unresolved
merge conflicts as well so they trigger NOTIFY_USER("Merge conflicts detected
...") and STOP, keeping the existing behavior for the other markers and the
non-blocking warning for any other non-empty output.
- Around line 76-87: The Scope Assessment (step 9.5 / "Scope Assessment Gate")
currently depends on the depth flag from Depth assessment (step 9.7), creating a
circular dependency; fix by removing that dependency: either compute the depth
flag earlier (move 9.7 before 9.5) or make 9.5 use only an explicit user depth
override (do not read computed depth) and treat computed depth as provisional
until after scope analysis; update the doc text to record in "Phase 1 Context
Summary" and to have the EDIT_FILE step that writes "depth" into
<specsDir>/<spec-name>/spec.json occur only after the final depth decision is
made (i.e., after scope assessment and depth computation), and ensure the Scope
Assessment Gate description refers to “user override only” or “provisional
depth” as appropriate.
In `@platforms/antigravity/specops.md`:
- Around line 78-87: The Phase 1 flow references depth in step 9.5 before it is
computed in 9.7 causing ordering ambiguity; move or duplicate the depth
computation so the depth flag is available to Scope Assessment: either relocate
"9.7 Depth assessment" to run before "9.5 Scope Assessment", or add a short
pre-step that computes the depth flag (using the three signals: estimated task
count, file domain breadth, new dependency presence) and records it in the Phase
1 Context Summary before executing "Scope Assessment"; ensure "Scope Assessment"
(step 9.5) references the depth flag only after this computation and keep the
recording format "- Depth: <flag> [computed | user override]".
- Around line 191-192: Update the merge-conflict detection to include the two
missing unmerged states 'DU' and 'UD' so they are treated the same as
'UU','AA','DD','AU','UA'; locate the function or code block that checks git
porcelain status (e.g., the routine that builds the unmerged-state set or the
function named like isUnmergedState/detectMergeConflicts) and add 'DU' and 'UD'
to that list, ensuring these states trigger the blocking message "Merge
conflicts detected in: [file list]. Resolve conflicts before implementation."
rather than being treated as non-blocking dirty state.
---
Outside diff comments:
In `@generator/validate.py`:
- Around line 1361-1367: The cross-platform consistency loop that iterates over
WORKFLOW_MARKERS + ... currently omits ACTION_ROUTING_MARKERS, EXPLORE_MARKERS,
and HEADLESS_MARKERS, so add those three marker groups to the concatenated
sequence in the loop (the same place that builds markers for validation in
validate_platform()) so each marker (including ACTION_ROUTING_MARKERS,
EXPLORE_MARKERS, HEADLESS_MARKERS) is checked across all platforms; ensure the
added constants are included in the same order/concatenation used for other
*_MARKERS and that any error reporting still appends to consistency_errors when
a marker is missing.
---
Minor comments:
In @.specops/depth-calibration/design.md:
- Around line 47-52: The design doc's Phase 1 step 6 depth-override keyword
lists must be aligned with the authoritative list in requirements.md (FR-3);
update the "lightweight" and "deep" keyword arrays in
.specops/depth-calibration/design.md (Phase 1 step 6) to exactly match the
keywords in .specops/depth-calibration/requirements.md (FR-3): Lightweight =
"quick", "lightweight", "simple", "trivial", "minor" and Deep = "thorough",
"deep", "deep dive", "exhaustive", "comprehensive"; alternatively remove the
duplicated lists from design.md and add a single line that references FR-3 as
the authoritative source so both docs remain consistent.
In @.specops/depth-calibration/spec.json:
- Around line 14-26: The spec file marks the spec as "status": "completed" but
is missing the implementation evaluation record under evaluation. Add an
evaluation.implementation object similar to the one used in other completed
specs (e.g., include fields like iterations, passed, scores, and evaluatedAt) so
the completed spec has both evaluation.spec and evaluation.implementation
entries; update the "evaluation" object in the JSON to include the
implementation evaluation record with appropriate values and timestamps to match
the format used elsewhere.
In @.specops/environment-preflight/spec.json:
- Around line 14-26: This spec has "status": "completed" but only includes
evaluation.spec; add a matching evaluation.implementation object alongside
evaluation.spec containing the implementation evaluation details (e.g.,
iterations, passed, scores, evaluatedAt) so completed specs mirror other files;
update the JSON under the existing "evaluation" key to include an
"implementation" entry consistent with the structure used by
action-routing/spec.json and ensure keys are populated (iterations, passed,
scores, evaluatedAt) to reflect the implementation evaluation.
In @.specops/runs/multi-persona-review-20260329-171013.md:
- Line 12: The review notes that the string taskTracking=github may need to be
capitalized; locate occurrences of the literal "github" used for display (e.g.,
the entry showing "taskTracking=github" in the spec output) and if it's meant
for human-readable output, change it to "GitHub"; if instead it is a
machine/config key, leave the literal lowercase but add a clarifying comment or
separate display field so UI/docs show "GitHub" while the config key remains
"github".
---
Nitpick comments:
In @.specops/action-routing/evaluation.md:
- Line 29: Edit the phrase "High risk row" in the evaluation.md table/text to
the hyphenated form "High-risk row" wherever it appears (e.g., the cell
discussing "Deterministic + Wide + High" / "Wide + High" scope) so the compound
adjective correctly modifies "row."
In @.specops/conditional-reviewer-triggering/design.md:
- Around line 44-49: The D5 paragraph mixes alternatives and the final decision;
refactor it to clearly separate "Option A" (adding new markers to
REVIEW_AGENTS_MARKERS) and "Option B" (introducing a separate TRIGGERING_MARKERS
constant), then state the final decision (use TRIGGERING_MARKERS) as its own
sentence; mention the rationale for each option briefly and reference existing
marker sets like REVIEW_AGENTS_MARKERS, TRIGGERING_MARKERS,
ACTION_ROUTING_MARKERS, HEADLESS_MARKERS and the test file
test_platform_consistency.py so readers can see the consistency implications and
where the change affects validation.
In @.specops/confidence-gating/implementation.md:
- Around line 45-48: The "Session Log" table in the
.specops/confidence-gating/implementation.md currently has only headers and no
entries; add one or more session entries (rows) documenting implementation
sessions similar to environment-preflight/implementation.md, including Phase,
Task, Status, and Notes for each entry so the Session Log is complete and
consistent with other journals; update the "Session Log" table under the Session
Log heading to include concrete rows describing the work performed, e.g., phases
and tasks, statuses (e.g., Complete/In Progress), and brief notes.
In @.specops/depth-calibration/design.md:
- Around line 47-52: Summary: The user override for depth in Phase 1 step 6 is
intentional but needs optional defensive safeguards. Update the request-analysis
logic (Phase 1 step 6) and the "user override" handling to: 1) constrain
overrides to adjacent tiers only (allow standard↔lightweight and standard↔deep
but disallow lightweight↔deep); 2) emit a structured audit/log entry whenever an
override decreases evaluation rigor (include detected keyword, original computed
depth, and final depth); and 3) enforce a configurable minimum depth for
security-sensitive file modifications by matching file path patterns (implement
configuration keys and checks referenced from implementation.md and FR-3/FR-2).
Ensure these safeguards are documented in implementation.md and that the logging
and path-pattern checks are pluggable/configurable.
In @.specops/environment-preflight/design.md:
- Around line 27-30: Extend the test detection logic so FILE_EXISTS/READ_FILE
checks also look for common runners and dependency declarations: when
pyproject.toml is present, inspect its dependencies for "pytest" or other test
packages to set test_cmd="pytest"; if requirements.txt exists, READ_FILE it and
set test_cmd="pytest" when "pytest" is listed; add FILE_EXISTS checks for
"tox.ini" and set test_cmd="tox"; add FILE_EXISTS for "setup.py" and READ_FILE
to look for a "test_suite" or invocation of unittest/pytest and set test_cmd to
"python -m unittest" or "python setup.py test" appropriately; keep using the
existing test_cmd variable and existing FILE_EXISTS/READ_FILE control flow.
In @.specops/environment-preflight/implementation.md:
- Around line 45-48: The "Session Log" section currently contains only the table
header (columns "Phase | Task | Status | Notes") with no entries; populate this
table with one or more session entries documenting implementation work (e.g.,
Phase names, Task descriptions, Status values such as "Completed"/"In Progress",
and concise Notes), following the format and level of detail used in
inter-mode-communication/implementation.md so reviewers can trace changes;
update the "Session Log" table under the "Session Log" header in
.specops/environment-preflight/implementation.md to include these rows.
In @.specops/environment-preflight/requirements.md:
- Around line 14-18: The "Acceptance Criteria" checklist currently has all items
pre-checked ([x]) which gives the impression they are already verified; edit the
"Acceptance Criteria" block to uncheck items (use [-] or [ ] instead of [x]) so
they represent pending verification, or if the spec truly is complete update the
document header to explicitly state status: completed and move checked items
into the evaluation report/implementation.md; specifically modify the checklist
lines under "Acceptance Criteria" and update the document header or move the
checked entries to the evaluation report to avoid confusion.
In @.specops/environment-preflight/spec.json:
- Around line 28-37: The relatedSpecs entry uses object items with specId and
relationship (the keys specId and relationship) while other specs (e.g.,
action-routing) use a simple string array; update this file so relatedSpecs is a
string array of spec IDs (e.g., replace the objects that contain
specId/relationship with just "depth-calibration" and "confidence-gating") to
match the project-wide format for relatedSpecs.
In @.specops/initiatives/ce-wave1-foundation.json:
- Line 7: The initiative metadata uses a string author entry ("author":
"sanketmakhija") which is inconsistent with the spec.json convention of an
author object; update the initiative's author field to the same structure (e.g.,
replace the string value for "author" with an object like { "name": "sanmak" }
or whatever canonical name is used across spec.json files) so the author symbol
is consistent across initiative and spec metadata.
- Around line 26-57: Replace opaque D-number references (D2, D4, D7, D9) in the
wave/spec descriptions with explicit spec IDs or add a short legend mapping each
D-number to the corresponding spec id; update occurrences in the "Smart Review &
Exploration" description (where D2/D3/D4/D5 are referenced) and in
"Composability & Intelligence" (D7/D2/D3/D9) to either spell out the target spec
ids (e.g., multi-persona-review, action-routing, solution-exploration,
inter-mode-communication, conditional-reviewer-triggering) or add a top-level
mapping object (e.g., dNumberLegend) so readers can unambiguously resolve
D-numbers to spec ids.
In @.specops/inter-mode-communication/tasks.md:
- Around line 64-66: When JSON parsing falls back to markdown in the headless
protocol (the JSON parse + markdown fallback logic in parseEvaluationResponse /
evaluation result handling), add observability: log a warning including the
parse error and the raw response when JSON.parse fails, increment a metric
counter (e.g., evaluation_json_fallback_count) each time the fallback is used,
and annotate the produced evaluation report with a short flag/message
("evaluation returned unparseable JSON, used markdown fallback") so downstream
tooling can detect and aggregate these events.
In @.specops/multi-persona-review/implementation.md:
- Around line 22-23: Add an explicit note or registration to avoid the
undocumented auto-load assumption: update the code around the
load_core_modules() call (function name load_core_modules()) in
generator/generate.py to either add a clear comment that core/*.md (including
review-agents.md) is intentionally relied upon by other modules, or add an
explicit registration/entry for review-agents.md in the
build_common_context()/module mapping so critical modules are guaranteed to load
regardless of future glob changes.
In `@core/templates/evaluation.md`:
- Around line 17-33: Add a canonical confidence-tier mapping to the "Findings
Detail" section so evaluators have explicit cutoffs: insert a short normative
block under the "Findings Detail" heading (or immediately above the confidence
examples table) that states the thresholds (e.g., "HIGH: score >= 0.80;
MODERATE: 0.50–0.79; LOW: < 0.50") and a one-line note that these are the
authoritative cutoffs to use when converting numeric scores to
HIGH/MODERATE/LOW; update any duplicate examples elsewhere in the template (the
other instances around lines 51-62 and 99-101) to reference or reuse this single
mapping block.
In `@generator/validate.py`:
- Around line 683-686: Replace the hardcoded 16 with a derived count from the
manifest: open and parse core/mode-manifest.json, compute expected_count = sum(1
for m in manifest["modes"] if m.get("platform") == "claude" or m.get("path",
"").startswith("platforms/claude/")), then compare len(mode_files) to
expected_count and update the error message accordingly (use the existing
mode_files and errors variables so only the numeric literal and message logic
change).
In `@platforms/antigravity/specops.md`:
- Around line 183-186: The Python readiness check currently treats presence of
"__pycache__/" as proof that dependencies are installed; update the
dependency-installation detection logic (the block that checks ".venv/" and
"__pycache__/" and emits the message "Python dependencies may not be installed.
Run `pip install -r requirements.txt` or `pip install -e .` before proceeding.")
so it no longer uses "__pycache__/" as a proxy: instead require either a
virtualenv indicator file/directory inside the project (e.g., ".venv/" plus
"pyvenv.cfg") or a populated site-packages directory (match
".venv/lib/python*/site-packages" or ".venv/Lib/site-packages" on Windows); if
those checks fail, keep the existing user-facing message. Ensure you only change
the detection logic and message emission in the same dependency-check block that
references ".venv/" and "__pycache__/".
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 001401c2-a2a6-4829-8e0e-fa87d463e4c8
⛔ Files ignored due to path filters (32)
CHECKSUMS.sha256is excluded by!CHECKSUMS.sha256platforms/claude/SKILL.mdis excluded by!platforms/claude/SKILL.mdplatforms/claude/SKILL.monolithic.mdis excluded by!platforms/claude/SKILL.monolithic.mdplatforms/claude/modes/audit.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/explore.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/from-plan.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/init.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/initiative.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/learn.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/map.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/memory.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/pipeline.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/spec.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/steering.mdis excluded by!platforms/*/modes/*.mdplatforms/claude/modes/view.mdis excluded by!platforms/*/modes/*.mdplatforms/codex/SKILL.mdis excluded by!platforms/codex/SKILL.mdplatforms/copilot/specops.instructions.mdis excluded by!platforms/copilot/specops.instructions.mdplatforms/cursor/specops.mdcis excluded by!platforms/cursor/specops.mdcskills/specops/SKILL.mdis excluded by!skills/specops/SKILL.mdskills/specops/SKILL.monolithic.mdis excluded by!skills/*/SKILL.monolithic.mdskills/specops/modes/audit.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/explore.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/from-plan.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/init.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/initiative.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/learn.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/map.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/memory.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/pipeline.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/spec.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/steering.mdis excluded by!skills/*/modes/*.mdskills/specops/modes/view.mdis excluded by!skills/*/modes/*.md
📒 Files selected for processing (83)
.claude/commands/docs-sync.md.specops/action-routing/design.md.specops/action-routing/evaluation.md.specops/action-routing/implementation.md.specops/action-routing/requirements.md.specops/action-routing/spec.json.specops/action-routing/tasks.md.specops/conditional-reviewer-triggering/design.md.specops/conditional-reviewer-triggering/evaluation.md.specops/conditional-reviewer-triggering/implementation.md.specops/conditional-reviewer-triggering/requirements.md.specops/conditional-reviewer-triggering/spec.json.specops/conditional-reviewer-triggering/tasks.md.specops/confidence-gating/design.md.specops/confidence-gating/evaluation.md.specops/confidence-gating/implementation.md.specops/confidence-gating/requirements.md.specops/confidence-gating/spec.json.specops/confidence-gating/tasks.md.specops/depth-calibration/design.md.specops/depth-calibration/evaluation.md.specops/depth-calibration/implementation.md.specops/depth-calibration/requirements.md.specops/depth-calibration/spec.json.specops/depth-calibration/tasks.md.specops/environment-preflight/design.md.specops/environment-preflight/evaluation.md.specops/environment-preflight/implementation.md.specops/environment-preflight/requirements.md.specops/environment-preflight/spec.json.specops/environment-preflight/tasks.md.specops/index.json.specops/initiatives/ce-wave1-foundation-log.md.specops/initiatives/ce-wave1-foundation.json.specops/inter-mode-communication/design.md.specops/inter-mode-communication/implementation.md.specops/inter-mode-communication/requirements.md.specops/inter-mode-communication/spec.json.specops/inter-mode-communication/tasks.md.specops/memory/context.md.specops/memory/decisions.json.specops/memory/patterns.json.specops/multi-persona-review/design.md.specops/multi-persona-review/evaluation.md.specops/multi-persona-review/implementation.md.specops/multi-persona-review/requirements.md.specops/multi-persona-review/spec.json.specops/multi-persona-review/tasks.md.specops/runs/multi-persona-review-20260329-171013.md.specops/solution-exploration/design.md.specops/solution-exploration/implementation.md.specops/solution-exploration/requirements.md.specops/solution-exploration/spec.json.specops/solution-exploration/tasks.mdCLAUDE.mdcore/config-handling.mdcore/decomposition.mdcore/dispatcher.mdcore/evaluation.mdcore/explore.mdcore/initiative-orchestration.mdcore/mode-manifest.jsoncore/pipeline.mdcore/review-agents.mdcore/templates/evaluation.mdcore/templates/implementation.mdcore/workflow.mddocs/COMMANDS.mddocs/COMPARISON.mddocs/STRUCTURE.mdgenerator/generate.pygenerator/templates/antigravity.j2generator/templates/claude.j2generator/templates/codex.j2generator/templates/copilot.j2generator/templates/cursor.j2generator/validate.pyinitiative-schema.jsonplatforms/antigravity/specops.mdspec-schema.jsontests/test_build.pytests/test_initiative_schema.pytests/test_platform_consistency.py
Comment on lines
+7
to
+18
| Confidence gating adds tiered evidence requirements to findings: HIGH confidence requires direct code citations, MODERATE requires pattern-level evidence, and LOW (below 0.50) is advisory-only and excluded from pass/fail scoring. | ||
|
|
||
| ## Product Requirements | ||
|
|
||
| ### FR-1: Confidence Tier Classification | ||
|
|
||
| <!-- EARS: Ubiquitous --> | ||
| THE SYSTEM SHALL classify each evaluation finding into one of three confidence tiers: HIGH (0.80+), MODERATE (0.60-0.79), or LOW (below 0.60). | ||
|
|
||
| **Acceptance Criteria:** | ||
| - [x] Each finding in evaluation.md includes a `Confidence:` annotation with tier and numeric value | ||
| - [x] Confidence tiers are: HIGH (>= 0.80), MODERATE (0.60-0.79), LOW (< 0.60) |
There was a problem hiding this comment.
LOW confidence threshold is inconsistent in this spec.
Line 7 says LOW is below 0.50, while Lines 14/18 define LOW as below 0.60. Please standardize to one threshold to prevent implementation/reporting drift.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specops/confidence-gating/requirements.md around lines 7 - 18, FR-1
contains an inconsistent LOW confidence threshold ("LOW (below 0.50)" vs "LOW (<
0.60)"); standardize to a single threshold by changing the earlier "LOW (below
0.50)" occurrence to "LOW (below 0.60)" (or vice versa if product decides on
0.50) and update any matching text in the "Confidence Tier Classification",
acceptance criteria, and any "Confidence:" annotation examples so all references
(e.g., the FR-1 section, the "Confidence tiers" line, and the acceptance
criteria) consistently use LOW < 0.60.
Comment on lines
+12
to
+19
| WHEN Phase 1 completes step 9.5 (Scope Assessment), THE SYSTEM SHALL assess complexity using three signals: estimated task count, file domain breadth (number of distinct directories modified), and presence of new dependencies. THE SYSTEM SHALL compute a depth flag from these signals. | ||
|
|
||
| **Acceptance Criteria:** | ||
| - [x] Task count <= 2 AND single directory domain AND no new dependencies = `lightweight` | ||
| - [x] Task count 3-8 AND multiple directories but within a single code domain = `standard` | ||
| - [x] Task count > 8 OR cross-domain (e.g., core + generator + tests) OR new external dependencies = `deep` | ||
| - [x] Depth flag is recorded in `implementation.md` Phase 1 Context Summary | ||
| - [x] Depth flag is persisted to `spec.json` as `depth` field |
There was a problem hiding this comment.
Potential circular dependency in depth computation.
FR-1 states depth is computed "WHEN Phase 1 completes step 9.5 (Scope Assessment)" (line 12), but FR-2 states "WHILE the depth flag is lightweight, THE SYSTEM SHALL skip scope assessment" (line 24).
If depth computation depends on scope assessment results (affected files for directory breadth calculation), but lightweight specs skip scope assessment, how is depth initially computed?
Design implications:
- Either depth must be computed before step 9.5 (using request analysis only)
- Or scope assessment must always run for depth computation, then conditionally skip iteration/validation
Please clarify the execution order and whether scope assessment partial execution is required for depth computation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specops/depth-calibration/requirements.md around lines 12 - 19, Clarify and
resolve the circular dependency between FR-1 and FR-2 by choosing one of two
fixes: (A) state that the depth flag is initially computed prior to Phase 1 step
9.5 using only request/PR metadata (e.g., task count estimate and declared
affected domains) and name this pre-computed field (e.g., "initial_depth") which
is later reconciled after full scope assessment in step 9.5 and persisted to
spec.json as "depth"; or (B) require a minimal mandatory scope assessment pass
that always runs to produce the three signals (task count, directory breadth,
new dependencies) necessary for depth computation, after which FR-2’s "skip
scope assessment" becomes a conditional short-circuit that only skips further
iteration/validation but not the minimal signal collection; update the
requirement text around "Phase 1 completes step 9.5 (Scope Assessment)", FR-2,
and the acceptance criteria (implementation.md Phase 1 Context Summary and
spec.json depth) to reflect the chosen approach so there is no ambiguity about
when and how the depth flag is computed and persisted.
| ``` | ||
| Project type detection (reuse from test command detection): | ||
| - npm/yarn: check FILE_EXISTS(`node_modules/`) | ||
| - Python: check FILE_EXISTS(`.venv/`) or FILE_EXISTS(`__pycache__/`) |
There was a problem hiding this comment.
Invalid dependency check for Python projects.
Checking for __pycache__/ does not verify dependency installation—it only indicates that Python bytecode has been generated. A Python project without dependencies installed can still have __pycache__/ from running any .py file.
For pip-based projects, check for site-packages/ within .venv/ or the presence of .venv/pyvenv.cfg. For poetry, check .venv/ created by poetry. For pipenv, check for Pipfile.lock and the virtualenv directory referenced in it.
🐍 Proposed fix for Python dependency detection
Project type detection (reuse from test command detection):
- npm/yarn: check FILE_EXISTS(`node_modules/`)
-- Python: check FILE_EXISTS(`.venv/`) or FILE_EXISTS(`__pycache__/`)
+- Python: check FILE_EXISTS(`.venv/lib/`) or FILE_EXISTS(`.venv/pyvenv.cfg`)
- Rust: check FILE_EXISTS(`target/`)
- Go (vendor): check FILE_EXISTS(`vendor/`)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - Python: check FILE_EXISTS(`.venv/`) or FILE_EXISTS(`__pycache__/`) | |
| - Python: check FILE_EXISTS(`.venv/lib/`) or FILE_EXISTS(`.venv/pyvenv.cfg`) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specops/environment-preflight/design.md at line 45, Replace the invalid
Python dependency check that looks for FILE_EXISTS(`.venv/`) or
FILE_EXISTS(`__pycache__/`) with checks that actually verify installed packages:
for pip-based projects verify `site-packages/` exists inside `.venv/` or
`.venv/pyvenv.cfg` is present; for Poetry verify the project `.venv/` created by
Poetry exists; for Pipenv verify `Pipfile.lock` exists and then confirm the
virtualenv directory referenced in that lockfile (or pipenv --venv equivalent)
is present. Update the logic that currently uses FILE_EXISTS(`.venv/`) and
FILE_EXISTS(`__pycache__/`) to perform these more specific checks.
Comment on lines
+144
to
+151
| if evaluationResponse is valid JSON: | ||
| evaluationScores = evaluationResponse.scores | ||
| overallVerdict = evaluationResponse.verdict | ||
| findings = evaluationResponse.findings | ||
| else: | ||
| // Fallback: read evaluation.md and parse markdown (backward compat) | ||
| // ... existing markdown parsing logic ... | ||
| ``` |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add schema validation for parsed JSON response.
The fallback logic only checks whether the response is "valid JSON" but doesn't verify that required fields (scores, verdict, findings) are present. If evaluation returns valid JSON with missing fields, the pipeline will fail when accessing evaluationResponse.scores or evaluationResponse.verdict.
Add a validation step after JSON parsing:
🛡️ Proposed schema validation logic
if evaluationResponse is valid JSON:
+ // Validate required fields are present
+ if not (hasField(evaluationResponse, "scores") and
+ hasField(evaluationResponse, "verdict") and
+ hasField(evaluationResponse, "findings")):
+ // Fallback: invalid schema, parse as markdown
+ // ... existing markdown parsing logic ...
+ else:
evaluationScores = evaluationResponse.scores
overallVerdict = evaluationResponse.verdict
findings = evaluationResponse.findings
else:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if evaluationResponse is valid JSON: | |
| evaluationScores = evaluationResponse.scores | |
| overallVerdict = evaluationResponse.verdict | |
| findings = evaluationResponse.findings | |
| else: | |
| // Fallback: read evaluation.md and parse markdown (backward compat) | |
| // ... existing markdown parsing logic ... | |
| ``` | |
| if evaluationResponse is valid JSON: | |
| // Validate required fields are present | |
| if not (hasField(evaluationResponse, "scores") and | |
| hasField(evaluationResponse, "verdict") and | |
| hasField(evaluationResponse, "findings")): | |
| // Fallback: invalid schema, parse as markdown | |
| // ... existing markdown parsing logic ... | |
| else: | |
| evaluationScores = evaluationResponse.scores | |
| overallVerdict = evaluationResponse.verdict | |
| findings = evaluationResponse.findings | |
| else: | |
| // Fallback: read evaluation.md and parse markdown (backward compat) | |
| // ... existing markdown parsing logic ... |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specops/inter-mode-communication/design.md around lines 144 - 151, After
parsing evaluationResponse JSON, validate that it contains the required fields
and types before accessing evaluationResponse.scores,
evaluationResponse.verdict, and evaluationResponse.findings: implement a small
validator (e.g., validateEvaluationResponse) that returns true only if scores is
an array/object of numeric values, verdict is a non-empty string, and findings
is an array/string as expected; if validation fails, fall back to the existing
markdown parsing logic or raise a clear error, and use the validator to gate
setting evaluationScores, overallVerdict, and findings.
Comment on lines
+15
to
+68
| "specDependencies": [ | ||
| { | ||
| "specId": "confidence-gating", | ||
| "relationship": "uses-format", | ||
| "required": true | ||
| }, | ||
| { | ||
| "specId": "adversarial-evaluation", | ||
| "relationship": "extends", | ||
| "required": true | ||
| } | ||
| ], | ||
| "evaluation": { | ||
| "spec": { | ||
| "iterations": 1, | ||
| "passed": true, | ||
| "scores": { | ||
| "criteriaTestability": 8, | ||
| "criteriaCompleteness": 7, | ||
| "designCoherence": 7, | ||
| "taskCoverage": 8 | ||
| }, | ||
| "evaluatedAt": "2026-03-29T17:15:00Z" | ||
| }, | ||
| "implementation": { | ||
| "iterations": 1, | ||
| "passed": true, | ||
| "scores": { | ||
| "functionalityDepth": 9, | ||
| "designFidelity": 9, | ||
| "codeQuality": 8, | ||
| "testVerification": 8 | ||
| }, | ||
| "evaluatedAt": "2026-03-29T17:57:00Z" | ||
| } | ||
| }, | ||
| "relatedSpecs": [ | ||
| { | ||
| "specId": "depth-calibration", | ||
| "relationship": "same-initiative" | ||
| }, | ||
| { | ||
| "specId": "environment-preflight", | ||
| "relationship": "same-initiative" | ||
| }, | ||
| { | ||
| "specId": "action-routing", | ||
| "relationship": "same-initiative" | ||
| }, | ||
| { | ||
| "specId": "solution-exploration", | ||
| "relationship": "same-initiative" | ||
| } | ||
| ] |
There was a problem hiding this comment.
Schema-shape mismatch in specDependencies and relatedSpecs.
Line 18 and Line 23 use relationship where the spec dependency model expects reason, and Line 51-68 uses object entries for relatedSpecs where the current model uses a string array. This can break validation/parsing consistency.
Proposed normalization
"specDependencies": [
{
"specId": "confidence-gating",
- "relationship": "uses-format",
+ "reason": "Uses confidence-tier format and thresholds defined by confidence-gating.",
"required": true
},
{
"specId": "adversarial-evaluation",
- "relationship": "extends",
+ "reason": "Extends adversarial-evaluation outputs with persona-based reviewers.",
"required": true
}
],
@@
- "relatedSpecs": [
- {
- "specId": "depth-calibration",
- "relationship": "same-initiative"
- },
- {
- "specId": "environment-preflight",
- "relationship": "same-initiative"
- },
- {
- "specId": "action-routing",
- "relationship": "same-initiative"
- },
- {
- "specId": "solution-exploration",
- "relationship": "same-initiative"
- }
- ]
+ "relatedSpecs": [
+ "depth-calibration",
+ "environment-preflight",
+ "action-routing",
+ "solution-exploration"
+ ]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| "specDependencies": [ | |
| { | |
| "specId": "confidence-gating", | |
| "relationship": "uses-format", | |
| "required": true | |
| }, | |
| { | |
| "specId": "adversarial-evaluation", | |
| "relationship": "extends", | |
| "required": true | |
| } | |
| ], | |
| "evaluation": { | |
| "spec": { | |
| "iterations": 1, | |
| "passed": true, | |
| "scores": { | |
| "criteriaTestability": 8, | |
| "criteriaCompleteness": 7, | |
| "designCoherence": 7, | |
| "taskCoverage": 8 | |
| }, | |
| "evaluatedAt": "2026-03-29T17:15:00Z" | |
| }, | |
| "implementation": { | |
| "iterations": 1, | |
| "passed": true, | |
| "scores": { | |
| "functionalityDepth": 9, | |
| "designFidelity": 9, | |
| "codeQuality": 8, | |
| "testVerification": 8 | |
| }, | |
| "evaluatedAt": "2026-03-29T17:57:00Z" | |
| } | |
| }, | |
| "relatedSpecs": [ | |
| { | |
| "specId": "depth-calibration", | |
| "relationship": "same-initiative" | |
| }, | |
| { | |
| "specId": "environment-preflight", | |
| "relationship": "same-initiative" | |
| }, | |
| { | |
| "specId": "action-routing", | |
| "relationship": "same-initiative" | |
| }, | |
| { | |
| "specId": "solution-exploration", | |
| "relationship": "same-initiative" | |
| } | |
| ] | |
| "specDependencies": [ | |
| { | |
| "specId": "confidence-gating", | |
| "reason": "Uses confidence-tier format and thresholds defined by confidence-gating.", | |
| "required": true | |
| }, | |
| { | |
| "specId": "adversarial-evaluation", | |
| "reason": "Extends adversarial-evaluation outputs with persona-based reviewers.", | |
| "required": true | |
| } | |
| ], | |
| "evaluation": { | |
| "spec": { | |
| "iterations": 1, | |
| "passed": true, | |
| "scores": { | |
| "criteriaTestability": 8, | |
| "criteriaCompleteness": 7, | |
| "designCoherence": 7, | |
| "taskCoverage": 8 | |
| }, | |
| "evaluatedAt": "2026-03-29T17:15:00Z" | |
| }, | |
| "implementation": { | |
| "iterations": 1, | |
| "passed": true, | |
| "scores": { | |
| "functionalityDepth": 9, | |
| "designFidelity": 9, | |
| "codeQuality": 8, | |
| "testVerification": 8 | |
| }, | |
| "evaluatedAt": "2026-03-29T17:57:00Z" | |
| } | |
| }, | |
| "relatedSpecs": [ | |
| "depth-calibration", | |
| "environment-preflight", | |
| "action-routing", | |
| "solution-exploration" | |
| ] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specops/multi-persona-review/spec.json around lines 15 - 68, The spec JSON
uses the wrong property names and shapes: update each object in specDependencies
to replace the relationship field with reason (preserve specId and required),
and convert relatedSpecs from an array of objects to a string array of specId
values (e.g., ["depth-calibration","environment-preflight",...]); then re-run
JSON/schema validation to ensure specDependencies and relatedSpecs conform to
the expected schema (check specDependencies, specId, reason, required and
relatedSpecs).
Comment on lines
+168
to
+173
| 4. **Deduplicate**: Group findings by file path and line range. Within each group: | ||
| - Merge findings that reference the same code location (overlapping line range within 5 lines). | ||
| - Use the most conservative severity (lowest P-number wins: P0 > P1 > P2 > P3). | ||
| - Use the most conservative confidence (highest tier wins: HIGH > MODERATE > LOW). | ||
| - Preserve all evidence from contributing personas. | ||
| - Record disagreements: if personas disagree on severity, note "Severity disagreement: [persona-A] classified P[X], [persona-B] classified P[Y]. Using P[min(X,Y)] (conservative)." |
There was a problem hiding this comment.
Keep severity and confidence paired during deduplication.
Taking the max severity and max confidence independently can manufacture a finding that no persona actually made. For example, merging P1/LOW with P3/HIGH at the same location produces P1/HIGH, which can fail the review even though there was no high-confidence severe finding. Preserve each source pair and either evaluate pass/fail against the original pairs or choose a single representative pair from one contributing finding.
🛠️ Suggested wording
- - Use the most conservative severity (lowest P-number wins: P0 > P1 > P2 > P3).
- - Use the most conservative confidence (highest tier wins: HIGH > MODERATE > LOW).
+ - Preserve each contributing finding's severity/confidence pair.
+ - If a merged summary needs a single classification, select one contributing pair using a fixed fail-precedence order instead of combining severity from one finding with confidence from another.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@core/review-agents.md` around lines 168 - 173, The deduplication step
("Deduplicate") must preserve severity/confidence pairs instead of combining max
severity and max confidence independently; update the logic that merges findings
for the same file/path/line-range to retain each contributing finding's original
(severity,confidence) tuple or select a single representative tuple from an
actual contributor, and record explicit disagreement notes when tuples differ
(e.g., "Severity/Confidence disagreement: [persona-A] P1/LOW, [persona-B]
P3/HIGH; using representative [persona-X] Pn/LEVEL"). Ensure the grouping code
that handles "overlapping line range within 5 lines" and the rules for "most
conservative" are changed to: (1) preserve all source tuples as evidence, (2)
evaluate pass/fail against the preserved tuples or a chosen real contributor
tuple, and (3) emit a clear disagreement field when contributors disagree—do
this where the deduplication logic referenced as "Deduplicate" merges findings.
Comment on lines
+76
to
87
| 9.5. **Scope Assessment (always runs)**: Run the Scope Assessment Gate from the Spec Decomposition module (`core/decomposition.md` section 1). This step is unconditional — it runs for every spec regardless of project size, vertical, or configuration. However, if the depth flag (step 9.7) is `lightweight`, this gate passes trivially — skip complexity signal evaluation and proceed as a single spec. The gate evaluates the user's feature request against 5 complexity signals (independent deliverables, distinct code domains, language signals, estimated task count, independent criteria clusters). If 2+ signals are present, decomposition is recommended and the interactive/non-interactive flow from the decomposition module is followed. If decomposition is approved, an initiative is created and the current spec becomes the first spec in the initiative. If decomposition is not recommended or is declined, proceed as a single spec. | ||
| 9.7. **Depth assessment**: Compute the depth flag that calibrates ceremony to complexity. If a depth override was detected in step 6, use the override value. Otherwise, compute from three signals available at this point: | ||
| - **Signal 1 — Estimated task count**: From the scope assessment or request analysis, estimate the number of implementation tasks. | ||
| - **Signal 2 — File domain breadth**: Count the number of distinct top-level directories in the affected files identified in step 9 (or step 8g for greenfield). A single directory = 1, multiple directories within one code domain = 2, directories spanning core logic and build/test/platform infrastructure = 3+. | ||
| - **Signal 3 — New dependency presence**: Check if the user's request mentions installing new packages, adding dependencies, or references specific third-party libraries not already in the project. | ||
| - **Depth computation**: | ||
| - `lightweight`: task count <= 2 AND domain breadth <= 1 AND no new dependencies | ||
| - `deep`: task count > 8 OR domain breadth > 3 OR cross-domain changes detected (e.g., changes spanning both core application logic and build/test/platform infrastructure) | ||
| - `standard`: all other cases (default) | ||
| - Record the depth flag in the Phase 1 Context Summary as `- Depth: <flag> [computed | user override]`. | ||
| - EDIT_FILE `<specsDir>/<spec-name>/spec.json` to set `"depth": "<flag>"` when the spec is created in Phase 2. | ||
|
|
There was a problem hiding this comment.
Depth gate order is self-referential and can misroute decomposition.
Line 76 makes Scope Assessment behavior depend on a depth flag from step 9.7, but step 9.7 itself depends on outputs from steps 8/9 and scope analysis. This creates a circular/ordering ambiguity.
Suggested fix
-9.5. **Scope Assessment (always runs)**: ... if the depth flag (step 9.7) is `lightweight`, this gate passes trivially ...
+9.5. **Scope Assessment (always runs)**: Run this gate unconditionally using request + affected-files signals.
+...
+9.7. **Depth assessment**: Compute depth after scope assessment outputs are available.
+ - If computed depth is `lightweight`, record that downstream gates (spec evaluation/dependency deep checks) use lightweight behavior.🧰 Tools
🪛 LanguageTool
[style] ~76-~76: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...comes the first spec in the initiative. If decomposition is not recommended or is ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@core/workflow.md` around lines 76 - 87, The Scope Assessment (step 9.5 /
"Scope Assessment Gate") currently depends on the depth flag from Depth
assessment (step 9.7), creating a circular dependency; fix by removing that
dependency: either compute the depth flag earlier (move 9.7 before 9.5) or make
9.5 use only an explicit user depth override (do not read computed depth) and
treat computed depth as provisional until after scope analysis; update the doc
text to record in "Phase 1 Context Summary" and to have the EDIT_FILE step that
writes "depth" into <specsDir>/<spec-name>/spec.json occur only after the final
depth decision is made (i.e., after scope assessment and depth computation), and
ensure the Scope Assessment Gate description refers to “user override only” or
“provisional depth” as appropriate.
Comment on lines
+187
to
+190
| - **Git branch state check**: RUN_COMMAND(`git status --porcelain`). Parse the output: | ||
| - If the command fails (not a git repo), skip this check silently. | ||
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected. NOTIFY_USER("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | ||
| - If output is non-empty but no conflict markers: NOTIFY_USER("Working tree has uncommitted changes.") -- non-blocking warning, continue. |
There was a problem hiding this comment.
Merge conflict detection misses valid porcelain conflict states.
The conflict check handles UU/AA/DD/AU/UA but omits DU and UD, which are also unresolved conflicts in git status --porcelain. Those cases should block implementation too.
Suggested fix
- - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected.
+ - If any output lines start with `UU`, `AA`, `DD`, `AU`, `UA`, `DU`, or `UD`: merge conflicts detected.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - **Git branch state check**: RUN_COMMAND(`git status --porcelain`). Parse the output: | |
| - If the command fails (not a git repo), skip this check silently. | |
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected. NOTIFY_USER("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | |
| - If output is non-empty but no conflict markers: NOTIFY_USER("Working tree has uncommitted changes.") -- non-blocking warning, continue. | |
| - **Git branch state check**: RUN_COMMAND(`git status --porcelain`). Parse the output: | |
| - If the command fails (not a git repo), skip this check silently. | |
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, `UA`, `DU`, or `UD`: merge conflicts detected. NOTIFY_USER("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | |
| - If output is non-empty but no conflict markers: NOTIFY_USER("Working tree has uncommitted changes.") -- non-blocking warning, continue. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@core/workflow.md` around lines 187 - 190, The merge-conflict detection logic
that parses RUN_COMMAND(`git status --porcelain`) currently blocks on markers
UU, AA, DD, AU, UA but omits DU and UD; update the check that inspects the
porcelain output (the branch state check) to treat lines starting with DU and UD
as unresolved merge conflicts as well so they trigger NOTIFY_USER("Merge
conflicts detected ...") and STOP, keeping the existing behavior for the other
markers and the non-blocking warning for any other non-empty output.
Comment on lines
+78
to
+87
| 9.5. **Scope Assessment (always runs)**: Run the Scope Assessment Gate from the Spec Decomposition module (`core/decomposition.md` section 1). This step is unconditional — it runs for every spec regardless of project size, vertical, or configuration. However, if the depth flag (step 9.7) is `lightweight`, this gate passes trivially — skip complexity signal evaluation and proceed as a single spec. The gate evaluates the user's feature request against 5 complexity signals (independent deliverables, distinct code domains, language signals, estimated task count, independent criteria clusters). If 2+ signals are present, decomposition is recommended and the interactive/non-interactive flow from the decomposition module is followed. If decomposition is approved, an initiative is created and the current spec becomes the first spec in the initiative. If decomposition is not recommended or is declined, proceed as a single spec. | ||
| 9.7. **Depth assessment**: Compute the depth flag that calibrates ceremony to complexity. If a depth override was detected in step 6, use the override value. Otherwise, compute from three signals available at this point: | ||
| - **Signal 1 — Estimated task count**: From the scope assessment or request analysis, estimate the number of implementation tasks. | ||
| - **Signal 2 — File domain breadth**: Count the number of distinct top-level directories in the affected files identified in step 9 (or step 8g for greenfield). A single directory = 1, multiple directories within one code domain = 2, directories spanning core logic and build/test/platform infrastructure = 3+. | ||
| - **Signal 3 — New dependency presence**: Check if the user's request mentions installing new packages, adding dependencies, or references specific third-party libraries not already in the project. | ||
| - **Depth computation**: | ||
| - `lightweight`: task count <= 2 AND domain breadth <= 1 AND no new dependencies | ||
| - `deep`: task count > 8 OR domain breadth > 3 OR cross-domain changes detected (e.g., changes spanning both core application logic and build/test/platform infrastructure) | ||
| - `standard`: all other cases (default) | ||
| - Record the depth flag in the Phase 1 Context Summary as `- Depth: <flag> [computed | user override]`. |
There was a problem hiding this comment.
Depth flag is referenced before it is computed.
Line 78 says the Scope Assessment behavior depends on the depth flag from step 9.7, but step 9.7 runs later. This creates ordering ambiguity in Phase 1 control flow.
Suggested fix
-9.5. **Scope Assessment (always runs)**: ... However, if the depth flag (step 9.7) is `lightweight`, this gate passes trivially ...
+9.5. **Scope Assessment (always runs)**: ... If a depth override from step 6 is `lightweight`, this gate passes trivially ...
...
-9.7. **Depth assessment**: Compute the depth flag ...
+9.7. **Depth assessment**: Compute the depth flag ...
+ - If depth is computed as `lightweight` and Scope Assessment has not yet been shortcut via step 6 override, record that Scope Assessment is treated as trivially passed for this run.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@platforms/antigravity/specops.md` around lines 78 - 87, The Phase 1 flow
references depth in step 9.5 before it is computed in 9.7 causing ordering
ambiguity; move or duplicate the depth computation so the depth flag is
available to Scope Assessment: either relocate "9.7 Depth assessment" to run
before "9.5 Scope Assessment", or add a short pre-step that computes the depth
flag (using the three signals: estimated task count, file domain breadth, new
dependency presence) and records it in the Phase 1 Context Summary before
executing "Scope Assessment"; ensure "Scope Assessment" (step 9.5) references
the depth flag only after this computation and keep the recording format "-
Depth: <flag> [computed | user override]".
Comment on lines
+191
to
+192
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected. Tell the user("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | ||
| - If output is non-empty but no conflict markers: Tell the user("Working tree has uncommitted changes.") -- non-blocking warning, continue. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What XY status codes in git status --porcelain indicate unmerged/conflict states?
💡 Result:
The XY status codes in git status --porcelain (v1 format, which is the default for --porcelain) that indicate unmerged/conflict states are those where either X or Y is 'U', or specifically the combinations listed in the unmerged section of the documentation: DD, AU, UD, UA, DU, AA, UU. These represent: - DD: unmerged, both deleted - AU: unmerged, added by us - UD: unmerged, deleted by them - UA: unmerged, added by them - DU: unmerged, deleted by us - AA: unmerged, both added - UU: unmerged, both modified In porcelain v1, these appear exactly as in the short format (e.g., "UU path"). In porcelain v2, unmerged entries are prefixed with 'u ' followed by the XY (e.g., "u UU ... path"), but the XY field itself uses the same codes. Note that 'U' can also appear in non-merge situations (e.g., AU where A is staged added and U means updated but unmerged, but primarily unmerged states are during merge conflicts).
Citations:
- 1: https://git-scm.com/docs/git-status/2.35.0.html
- 2: https://git-scm.com/docs/git-status.html
- 3: https://git-scm.com/docs/git-status/2.6.7
- 4: https://stackoverflow.com/questions/44573213/parsing-git-status
- 5: https://7id.xray.aps.anl.gov/~dohnarms/software/git/git-status.html
- 6: https://git.seveas.net/manpages/git-status.html
- 7: https://manpages.ubuntu.com/manpages/trusty/man1/git-status.1.html
- 8: https://schacon.github.io/git/git-status.html
- 9: https://stackoverflow.com/questions/44448087/reference-for-git-status-shorthand
Add missing merge conflict states to detection logic.
The code currently detects only UU, AA, DD, AU, UA as unmerged states, but git status --porcelain also reports DU (unmerged, deleted by us) and UD (unmerged, deleted by them). These states slip through as non-blocking dirty state instead of being caught as merge conflicts.
Suggested fix
- - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected.
+ - If any output lines start with `UU`, `AA`, `DD`, `AU`, `UA`, `DU`, or `UD`: merge conflicts detected.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, or `UA`: merge conflicts detected. Tell the user("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | |
| - If output is non-empty but no conflict markers: Tell the user("Working tree has uncommitted changes.") -- non-blocking warning, continue. | |
| - If any output lines start with `UU`, `AA`, `DD`, `AU`, `UA`, `DU`, or `UD`: merge conflicts detected. Tell the user("Merge conflicts detected in: [file list]. Resolve conflicts before implementation.") and STOP -- do not proceed to implementation. | |
| - If output is non-empty but no conflict markers: Tell the user("Working tree has uncommitted changes.") -- non-blocking warning, continue. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@platforms/antigravity/specops.md` around lines 191 - 192, Update the
merge-conflict detection to include the two missing unmerged states 'DU' and
'UD' so they are treated the same as 'UU','AA','DD','AU','UA'; locate the
function or code block that checks git porcelain status (e.g., the routine that
builds the unmerged-state set or the function named like
isUnmergedState/detectMergeConflicts) and add 'DU' and 'UD' to that list,
ensuring these states trigger the blocking message "Merge conflicts detected in:
[file list]. Resolve conflicts before implementation." rather than being treated
as non-blocking dirty state.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
core/review-agents.md), action routing for finding classification into auto_fix/gated_fix/manual/advisory fix classes, and a solution exploration mode (core/explore.md) for generating codebase-grounded approaches before spec writingChanges
core/review-agents.mdcore/explore.mdcore/evaluation.mdcore/dispatcher.mdcore/pipeline.mdcore/workflow.mdcore/review-agents.mdcore/mode-manifest.jsoncore/templates/evaluation.mdgenerator/generate.pyreview_agentsandexploreadded tobuild_common_context()generator/validate.pytests/test_platform_consistency.pydocs/COMMANDS.mddocs/COMPARISON.md.specops/initiatives/.specops/*/Test Plan
python3 generator/validate.pypasses all checks across 5 platformsbash scripts/run-tests.shpasses 8/8 testsshasum -a 256 -c CHECKSUMS.sha256verifies all 17 checksumscore/workflow.md,generator/generate.py,platforms/claude/SKILL.md,spec-schema.jsonSummary by CodeRabbit