ccg-ros2-workflow 1.4.0 → 2.1.0

package/templates/commands/spec-impl.md

@@ -0,0 +1,123 @@
+---
+description: '按规范执行 + 多模型协作 + 归档'
+---
+<!-- CCG:SPEC:IMPL:START -->
+**Core Philosophy**
+- Implementation is pure mechanical execution—all decisions were made in Plan phase.
+- External model outputs are prototypes only; must be rewritten to production-grade code.
+- Keep changes tightly scoped; enforce side-effect review before any modification.
+- Minimize documentation—prefer self-explanatory code over comments.
+
+**Guardrails**
+- **NEVER** apply Codex/Gemini prototypes directly—all outputs are reference only.
+- **MANDATORY**: Request `unified diff patch` format from external models; they have zero write permission.
+- Keep implementation strictly within `tasks.md` scope—no scope creep.
+- Refer to `openspec/config.yaml` for conventions.
+
+**Steps**
+1. **Select Change**
+   - Run `/opsx:list` to inspect Active Changes.
+   - Confirm with user which change ID to implement.
+   - Run `/opsx:show <change_id>` to review tasks.
+
+2. **Apply OPSX Change**
+   - Use `/ccg:spec-impl` (which uses OpenSpec skills internally) to enter implementation mode.
+   - This skill will guide you through the tasks defined in `tasks.md`.
+
+3. **Identify Minimal Verifiable Phase**
+   - Review `tasks.md` and identify the **smallest verifiable phase**.
+   - Do NOT complete all tasks at once—control context window.
+   - Announce: "Implementing Phase X: [task group name]"
+
+4. **Route Tasks to Appropriate Model**
+   - **Route A: Gemini** — Frontend/UI/styling (CSS, React, Vue, HTML, components)
+   - **Route B: Codex** — Backend/logic/algorithm (API, data processing, business logic)
+
+   For each task:
+   ```
+   codeagent-wrapper --backend <codex|gemini> - "$PWD" <<'EOF'
+   TASK: <task description from tasks.md>
+   CONTEXT: <relevant code context>
+   CONSTRAINTS: <constraints from spec>
+   OUTPUT: Unified Diff Patch format ONLY
+   EOF
+   ```
+
+5. **Rewrite Prototype to Production Code**
+   Upon receiving diff patch, **NEVER apply directly**. Rewrite by:
+   - Removing redundancy
+   - Ensuring clear naming and simple structure
+   - Aligning with project style
+   - Eliminating unnecessary comments
+   - Verifying no new dependencies introduced
+
+6. **Side-Effect Review** (Mandatory before apply)
+   Verify the change:
+   - [ ] Does not exceed `tasks.md` scope
+   - [ ] Does not affect unrelated modules
+   - [ ] Does not introduce new dependencies
+   - [ ] Does not break existing interfaces
+
+   If issues found, make targeted corrections.
+
+7. **Multi-Model Review (PARALLEL)**
+   - **CRITICAL**: You MUST launch BOTH Codex AND Gemini in a SINGLE message with TWO Bash tool calls.
+   - **DO NOT** call one model first and wait. Launch BOTH simultaneously with `run_in_background: true`.
+
+   **Step 7.1**: In ONE message, make TWO parallel Bash calls:
+
+   **FIRST Bash call (Codex)**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nReview the implementation changes:\n- Correctness: logic errors, edge cases\n- Security: injection, auth issues\n- Spec compliance: constraints satisfied\nOUTPUT: JSON with findings\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Codex: correctness/security review"
+   })
+   ```
+
+   **SECOND Bash call (Gemini) - IN THE SAME MESSAGE**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF'\nReview the implementation changes:\n- Maintainability: readability, complexity\n- Patterns: consistency with project style\n- Integration: cross-module impacts\nOUTPUT: JSON with findings\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Gemini: maintainability/patterns review"
+   })
+   ```
+
+   **Step 7.2**: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
+   ```
+   TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 })
+   TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })
+   ```
+
+   Address any critical findings before proceeding.
+
+8. **Update Task Status**
+   - Mark completed task in `tasks.md`: `- [x] Task description`
+   - Commit changes if appropriate.
+
+9. **Context Checkpoint**
+   - After completing a phase, report context usage.
+   - If below 80K: Ask user "Continue to next phase?"
+   - If approaching 80K: Suggest "Run `/clear` and resume with `/ccg:spec:impl`"
+
+10. **Archive on Completion**
+    - When ALL tasks in `tasks.md` are marked `[x]`:
+    - The agent will use OpenSpec skills to archive the change.
+    - This merges spec deltas to `openspec/specs/` and moves change to archive.
+
+**Reference**
+- Check task status: `/opsx:show <id>`
+- Validate before archive: `/opsx:validate <id>`
+- View active changes: `/opsx:list`
+- Search existing patterns: `rg -n "function|class" <file>`
+
+**Exit Criteria**
+Implementation is complete when:
+- [ ] All tasks in `tasks.md` marked `[x]`
+- [ ] All multi-model reviews passed
+- [ ] Side-effect review confirmed no regressions
+- [ ] Change archived successfully
+<!-- CCG:SPEC:IMPL:END -->

package/templates/commands/spec-init.md

@@ -0,0 +1,91 @@
+---
+description: '初始化 OpenSpec (OPSX) 环境 + 验证多模型 MCP 工具'
+---
+<!-- CCG:SPEC:INIT:START -->
+**Core Philosophy**
+- OPSX provides the specification framework; CCG adds multi-model collaboration.
+- This phase ensures all tools are ready before any development work begins.
+- Fail fast: detect missing dependencies early rather than mid-workflow.
+
+**Guardrails**
+- Detect OS (Linux/macOS/Windows) and adapt commands accordingly.
+- Do not proceed to next step until current step completes successfully.
+- Provide clear, actionable error messages when a step fails.
+- Respect user's existing configurations; avoid overwriting without confirmation.
+
+**Steps**
+1. **Detect Operating System**
+   - Identify OS using `uname -s` (Unix) or environment variables (Windows).
+   - Inform user which OS was detected.
+
+2. **Check and Install OpenSpec (OPSX)**
+   - Verify if OPSX commands are available: `/opsx:version`
+   - If not installed or not found:
+     ```bash
+     npm install -g @fission-ai/openspec@latest
+     ```
+   - **Path Verification**:
+     - If `/opsx:version` command is not found after installation:
+       1. Ensure Claude Code commands are properly loaded
+       2. Restart Claude Code session if needed
+       3. Check if OPSX skills are installed in `.claude/skills/`
+   - Confirm installation success by running `/opsx:version` again.
+
+3. **Initialize OPSX for Current Project**
+   - Run:
+     ```bash
+     /opsx:init --tools claude
+     ```
+   - Verify `openspec/` directory structure is created.
+   - Verify `.claude/skills/` contains `opsx-*` skills.
+   - Report any errors with remediation steps.
+
+4. **Validate Multi-Model MCP Tools**
+   - Check `codeagent-wrapper` availability: `~/.claude/bin/codeagent-wrapper --version`
+   - Test Codex backend:
+     ```bash
+     ~/.claude/bin/codeagent-wrapper --backend codex - "$PWD" <<< "echo test"
+     ```
+   - Test Gemini backend:
+     ```bash
+     ~/.claude/bin/codeagent-wrapper --backend gemini - "$PWD" <<< "echo test"
+     ```
+   - For each unavailable tool, display warning with installation instructions.
+
+5. **Validate Context Retrieval MCP** (Optional)
+   - **Check Active Tool**: Is `mcp__ace-tool__search_context` available in the current session?
+   - **Check Configuration**: If tool is missing, check `~/.claude.json` (or `%APPDATA%\Claude\claude.json` on Windows) for `"ace-tool"` or `"ace-tool-rs"` in `mcpServers`.
+   - **Diagnosis**:
+     - If tool available: Mark as "✓ Active".
+     - If config exists but tool missing: Mark as "⚠️ Configured but inactive (Try restarting Claude)".
+     - If neither: Mark as "○ Not installed (Optional)".
+   - If not installed/configured, suggest: "Run `npx ccg-workflow` and select ace-tool MCP option."
+
+6. **Summary Report**
+   Display status table:
+   ```
+   Component                 Status
+   ─────────────────────────────────
+   OpenSpec (OPSX) CLI       ✓/✗
+   Project initialized       ✓/✗
+   OPSX Skills               ✓/✗
+   codeagent-wrapper         ✓/✗
+   Codex backend             ✓/✗
+   Gemini backend            ✓/✗
+   ace-tool MCP              ✓/✗ (optional)
+   ```
+
+   **Next Steps (Use CCG Encapsulated Commands)**
+   1. Start Research: `/ccg:spec-research "description"`
+   2. Plan & Design: `/ccg:spec-plan`
+   3. Implement: `/ccg:spec-impl` (Includes auto-review & archive)
+
+   **Standalone Tools (Available Anytime)**
+   - Code Review: `/ccg:spec-review` (Independent dual-model review)
+
+**Reference**
+- OpenSpec (OPSX) CLI: `/opsx:help`
+- CCG Workflow: `npx ccg-workflow`
+- Codex/Gemini MCP: Bundled with codeagent-wrapper
+- Node.js >= 18.x required for OpenSpec
+<!-- CCG:SPEC:INIT:END -->

package/templates/commands/spec-plan.md

@@ -0,0 +1,109 @@
+---
+description: '多模型分析 → 消除歧义 → 零决策可执行计划'
+---
+<!-- CCG:SPEC:PLAN:START -->
+**Core Philosophy**
+- The goal is to eliminate ALL decision points—implementation should be pure mechanical execution.
+- Every ambiguity must be resolved into explicit constraints before proceeding.
+- Multi-model collaboration surfaces blind spots and conflicting assumptions.
+- Every requirement must have Property-Based Testing (PBT) properties—focus on invariants.
+
+**Guardrails**
+- Do not proceed to implementation until every ambiguity is resolved.
+- Multi-model collaboration is **mandatory**: use both Codex and Gemini.
+- If constraints cannot be fully specified, escalate to user or return to research phase.
+- Refer to `openspec/config.yaml` for project conventions.
+
+**Steps**
+1. **Select Change**
+   - Run `/opsx:list` to display Active Changes.
+   - Confirm with user which change ID to refine.
+   - Run `/opsx:status <change_id>` to review current state.
+
+2. **Multi-Model Implementation Analysis (PARALLEL)**
+   - **CRITICAL**: You MUST launch BOTH Codex AND Gemini in a SINGLE message with TWO Bash tool calls.
+   - **DO NOT** call one model first and wait. Launch BOTH simultaneously with `run_in_background: true`.
+
+   **Step 2.1**: In ONE message, make TWO parallel Bash calls:
+
+   **FIRST Bash call (Codex)**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nAnalyze change <change_id> from backend perspective:\n- Implementation approach\n- Technical risks\n- Alternative architectures\n- Edge cases and failure modes\nOUTPUT: JSON with analysis\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Codex: backend analysis"
+   })
+   ```
+
+   **SECOND Bash call (Gemini) - IN THE SAME MESSAGE**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF'\nAnalyze change <change_id> from frontend/integration perspective:\n- Maintainability assessment\n- Scalability considerations\n- Integration conflicts\nOUTPUT: JSON with analysis\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Gemini: frontend analysis"
+   })
+   ```
+
+   **Step 2.2**: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
+   ```
+   TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 })
+   TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })
+   ```
+
+   - Synthesize responses and present consolidated options to user.
+
+3. **Uncertainty Elimination Audit**
+   - **Codex**: "Review proposal for unspecified decision points. List each as: [AMBIGUITY] → [REQUIRED CONSTRAINT]"
+   - **Gemini**: "Identify implicit assumptions. Specify: [ASSUMPTION] → [EXPLICIT CONSTRAINT NEEDED]"
+
+   **Anti-Pattern Detection** (flag and reject):
+   - Information collection without decision boundaries
+   - Technical comparisons without selection criteria
+   - Deferred decisions marked "to be determined during implementation"
+
+   **Target Pattern** (required for approval):
+   - Explicit technology choices with parameters (e.g., "JWT with TTL=15min")
+   - Concrete algorithm selections with configs (e.g., "bcrypt cost=12")
+   - Precise behavioral rules (e.g., "Lock account 30min after 5 failed attempts")
+
+   Iterate with user until ALL ambiguities resolved.
+
+4. **PBT Property Extraction**
+   - **Codex**: "Extract PBT properties. For each requirement: [INVARIANT] → [FALSIFICATION STRATEGY]"
+   - **Gemini**: "Define system properties: [PROPERTY] | [DEFINITION] | [BOUNDARY CONDITIONS] | [COUNTEREXAMPLE GENERATION]"
+
+   **Property Categories**:
+   - **Commutativity/Associativity**: Order-independent operations
+   - **Idempotency**: Repeated operations yield same result
+   - **Round-trip**: Encode→Decode returns original
+   - **Invariant Preservation**: State constraints maintained
+   - **Monotonicity**: Ordering guarantees (e.g., timestamps increase)
+   - **Bounds**: Value ranges, size limits, rate constraints
+
+5. **Update OPSX Artifacts**
+   - The agent will use OpenSpec skills to generate/update:
+     * specs (Requirements + PBT)
+     * design (Technical decisions)
+     * tasks (Zero-decision implementation plan)
+   - Ensure all resolved constraints and PBT properties are included in the generated artifacts.
+
+6. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-impl`"
+
+**Exit Criteria**
+A change is ready for implementation only when:
+- [ ] All multi-model analyses completed and synthesized
+- [ ] Zero ambiguities remain (verified by step 3 audit)
+- [ ] All PBT properties documented with falsification strategies
+- [ ] Artifacts (specs, design, tasks) generated via OpenSpec skills
+- [ ] User has explicitly approved all constraint decisions
+
+**Reference**
+- Inspect change: `/opsx:status <id>`
+- Check conflicts: `/opsx:schemas`
+- Search patterns: `rg -n "INVARIANT:|PROPERTY:" openspec/`
+- Use `AskUserQuestion` for ANY ambiguity—never assume
+<!-- CCG:SPEC:PLAN:END -->

package/templates/commands/spec-research.md

@@ -0,0 +1,104 @@
+---
+description: '需求 → 约束集（并行探索 + OPSX 提案）'
+---
+<!-- CCG:SPEC:RESEARCH:START -->
+**Core Philosophy**
+- Research produces **constraint sets**, not information dumps. Each constraint narrows the solution space.
+- Constraints tell subsequent stages "don't consider this direction," enabling mechanical execution without decisions.
+- Output: 约束集合 + 可验证的成功判据 (constraint sets + verifiable success criteria).
+- Strictly adhere to OPSX rules when writing spec-structured documents.
+
+**Guardrails**
+- **STOP! BEFORE ANY OTHER ACTION**: You MUST call `mcp__ace-tool__enhance_prompt` FIRST. This is NON-NEGOTIABLE.
+- **NEVER** divide subagent tasks by roles (e.g., "架构师agent", "安全专家agent").
+- **ALWAYS** divide by context boundaries (e.g., "user-related code", "authentication logic").
+- Each subagent context must be self-contained with independent output.
+- Use `mcp__ace-tool__search_context` to minimize grep/find operations.
+- Do not make architectural decisions—surface constraints that guide decisions.
+
+**Steps**
+0. **MANDATORY: Enhance Requirement FIRST**
+   - **DO THIS IMMEDIATELY. DO NOT SKIP. DO NOT CALL ANY OTHER TOOL FIRST.**
+   - Call:
+   ```
+   mcp__ace-tool__enhance_prompt({
+     prompt: "$ARGUMENTS",
+     conversation_history: "<recent conversation>",
+     project_root_path: "$PWD"
+   })
+   ```
+   - Wait for enhanced prompt result.
+   - Use enhanced prompt for ALL subsequent steps.
+
+1. **Generate OPSX Change**
+   - Create a new change using OPSX command:
+     ```bash
+     /opsx:new "<brief-descriptive-name>"
+     ```
+   - This scaffolds `openspec/changes/<name>/` with proposal.md.
+   - If change already exists, use `/opsx:list` to find it and continue.
+
+2. **Initial Codebase Assessment**
+   - Use `mcp__ace-tool__search_context` to scan codebase.
+   - Determine project scale: single vs multi-directory structure.
+   - **Decision**: If multi-directory → enable parallel Explore subagents.
+
+3. **Define Exploration Boundaries (Context-Based)**
+   - Identify natural context boundaries (NOT functional roles):
+     * Subagent 1: User domain code (models, services, UI)
+     * Subagent 2: Auth & authorization (middleware, session, tokens)
+     * Subagent 3: Infrastructure (configs, deployments, builds)
+   - Each boundary should be self-contained: no cross-communication needed.
+
+4. **Parallel Multi-Model Exploration**
+   - Dispatch Explore subagents with unified output template:
+   ```json
+   {
+     "module_name": "context boundary explored",
+     "existing_structures": ["key patterns found"],
+     "existing_conventions": ["standards in use"],
+     "constraints_discovered": ["hard constraints limiting solution space"],
+     "open_questions": ["ambiguities requiring user input"],
+     "dependencies": ["cross-module dependencies"],
+     "risks": ["potential blockers"],
+     "success_criteria_hints": ["observable success behaviors"]
+   }
+   ```
+   - Run Codex for backend boundaries, Gemini for frontend boundaries.
+
+5. **Aggregate and Synthesize**
+   - Collect all subagent outputs.
+   - Merge into unified constraint sets:
+     * **Hard constraints**: Technical limitations, patterns that cannot be violated
+     * **Soft constraints**: Conventions, preferences, style guides
+     * **Dependencies**: Cross-module relationships affecting implementation order
+     * **Risks**: Blockers needing mitigation
+
+6. **User Interaction for Ambiguity Resolution**
+   - Compile prioritized list of open questions.
+   - Use `AskUserQuestion` tool to present systematically:
+     * Group related questions
+     * Provide context for each
+     * Suggest defaults when applicable
+   - Capture responses as additional constraints.
+
+7. **Finalize OPSX Proposal**
+   - Transform constraint sets into OPSX format:
+     * **Context**: User need + discovered constraints
+     * **Requirements**: Each constraint becomes requirement with scenario
+     * **Success Criteria**: Derived from hints and user confirmations
+   - Ensure proposal includes:
+     * All discovered constraints as requirements
+     * Verifiable scenarios for each requirement
+     * Clear dependencies and sequencing
+     * Risk mitigation strategies
+
+8. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-plan`"
+
+**Reference**
+- OPSX CLI: `/opsx:status`, `/opsx:show`
+- Check prior research: `ls openspec/changes/*/`
+- Use `AskUserQuestion` for ANY ambiguity—never assume or guess
+<!-- CCG:SPEC:RESEARCH:END -->

package/templates/commands/spec-review.md

@@ -0,0 +1,120 @@
+---
+description: '双模型交叉审查（独立工具，随时可用）'
+---
+<!-- CCG:SPEC:REVIEW:START -->
+**Core Philosophy**
+- Dual-model cross-validation catches blind spots single-model review would miss.
+- Critical findings SHOULD be addressed before proceeding.
+- Review validates implementation against spec constraints and code quality.
+- This is an independent review tool—can be used anytime, not tied to archive workflow.
+
+**Guardrails**
+- **MANDATORY**: Both Codex AND Gemini must complete review before synthesis.
+- Review scope is strictly limited to the proposal's changes—no scope creep.
+- Refer to `openspec/AGENTS.md` for spec conventions if reviewing OpenSpec proposals.
+
+**Steps**
+1. **Select Proposal**
+   - Run `/opsx:list` to display Active Changes.
+   - Confirm with user which proposal ID to review.
+   - Run `/opsx:show <proposal_id>` to load spec and tasks.
+
+2. **Collect Implementation Artifacts**
+   - Identify all files modified by this proposal.
+   - Use `git diff` or `/opsx:diff <proposal_id>` to get change summary.
+   - Load relevant spec constraints and PBT properties from `openspec/changes/<id>/specs/`.
+
+3. **Multi-Model Review (PARALLEL)**
+   - **CRITICAL**: You MUST launch BOTH Codex AND Gemini in a SINGLE message with TWO Bash tool calls.
+   - **DO NOT** call one model first and wait. Launch BOTH simultaneously with `run_in_background: true`.
+
+   **Step 3.1**: In ONE message, make TWO parallel Bash calls:
+
+   **FIRST Bash call (Codex)**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend codex - \"$PWD\" <<'EOF'\nReview proposal <proposal_id> implementation:\n\n## Codex Review Dimensions\n1. **Spec Compliance**: Verify ALL constraints from spec are satisfied\n2. **PBT Properties**: Check invariants, idempotency, bounds are correctly implemented\n3. **Logic Correctness**: Edge cases, error handling, algorithm correctness\n4. **Backend Security**: Injection vulnerabilities, auth checks, input validation\n5. **Regression Risk**: Interface compatibility, type safety, breaking changes\n\n## Output Format (JSON)\n{\n  \"findings\": [\n    {\n      \"severity\": \"Critical|Warning|Info\",\n      \"dimension\": \"spec_compliance|pbt|logic|security|regression\",\n      \"file\": \"path/to/file.ts\",\n      \"line\": 42,\n      \"description\": \"What is wrong\",\n      \"constraint_violated\": \"Constraint ID from spec (if applicable)\",\n      \"fix_suggestion\": \"How to fix\"\n    }\n  ],\n  \"passed_checks\": [\"List of verified constraints/properties\"],\n  \"summary\": \"Overall assessment\"\n}\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Codex: backend/logic review"
+   })
+   ```
+
+   **SECOND Bash call (Gemini) - IN THE SAME MESSAGE**:
+   ```
+   Bash({
+     command: "~/.claude/bin/codeagent-wrapper --backend gemini - \"$PWD\" <<'EOF'\nReview proposal <proposal_id> implementation:\n\n## Gemini Review Dimensions\n1. **Pattern Consistency**: Naming conventions, code style, project patterns\n2. **Maintainability**: Readability, complexity, documentation adequacy\n3. **Integration Risk**: Dependency changes, cross-module impacts\n4. **Frontend Security**: XSS, CSRF, sensitive data exposure\n5. **Spec Alignment**: Implementation matches spec intent (not just letter)\n\n## Output Format (JSON)\n{\n  \"findings\": [\n    {\n      \"severity\": \"Critical|Warning|Info\",\n      \"dimension\": \"patterns|maintainability|integration|security|alignment\",\n      \"file\": \"path/to/file.ts\",\n      \"line\": 42,\n      \"description\": \"What is wrong\",\n      \"spec_reference\": \"Spec section (if applicable)\",\n      \"fix_suggestion\": \"How to fix\"\n    }\n  ],\n  \"passed_checks\": [\"List of verified aspects\"],\n  \"summary\": \"Overall assessment\"\n}\nEOF",
+     run_in_background: true,
+     timeout: 300000,
+     description: "Gemini: patterns/integration review"
+   })
+   ```
+
+   **Step 3.2**: After BOTH Bash calls return task IDs, wait for results with TWO TaskOutput calls:
+   ```
+   TaskOutput({ task_id: "<codex_task_id>", block: true, timeout: 600000 })
+   TaskOutput({ task_id: "<gemini_task_id>", block: true, timeout: 600000 })
+   ```
+
+4. **Synthesize Findings**
+   - Merge findings from both models.
+   - Deduplicate overlapping issues.
+   - Classify by severity:
+     * **Critical**: Spec violation, security vulnerability, breaking change → MUST fix
+     * **Warning**: Pattern deviation, maintainability concern → SHOULD fix
+     * **Info**: Minor improvement suggestion → MAY fix
+
+5. **Present Review Report**
+   - Display findings grouped by severity:
+   ```
+   ## Review Report: <proposal_id>
+
+   ### Critical (X issues) - MUST FIX
+   - [ ] [SPEC] file.ts:42 - Constraint X violated: description
+   - [ ] [SEC] api.ts:15 - SQL injection vulnerability
+
+   ### Warning (Y issues) - SHOULD FIX
+   - [ ] [PATTERN] utils.ts:88 - Inconsistent naming convention
+
+   ### Info (Z issues) - MAY FIX
+   - [ ] [MAINT] helper.ts:20 - Consider extracting to separate function
+
+   ### Passed Checks
+   - ✅ PBT: Idempotency property verified
+   - ✅ Security: No XSS vulnerabilities found
+   ```
+
+6. **Decision Gate**
+   - **If Critical > 0**:
+     * Present findings to user.
+     * Ask: "Fix now or return to `/ccg:spec-impl` to address?"
+     * Do NOT allow archiving.
+
+   - **If Critical = 0**:
+     * Ask user: "All critical checks passed. Proceed to archive?"
+     * If Warning > 0, recommend addressing before archive.
+
+7. **Optional: Inline Fix Mode**
+   - If user chooses "Fix now" for Critical issues:
+     * Route each fix to appropriate model (backend→Codex, frontend→Gemini).
+     * Apply fix using unified diff patch pattern.
+     * Re-run affected review dimension.
+     * Repeat until Critical = 0.
+
+8. **Context Checkpoint**
+   - Report current context usage.
+   - If approaching 80K tokens, suggest: "Run `/clear` and continue with `/ccg:spec-review` or `/ccg:spec-impl`"
+
+**Exit Criteria**
+Review is complete when:
+- [ ] Both Codex and Gemini reviews completed
+- [ ] All findings synthesized and classified
+- [ ] Zero Critical issues remain (fixed or user-acknowledged)
+- [ ] User decision captured (archive / return to impl / defer)
+
+**Reference**
+- View proposal: `/opsx:show <id>`
+- Check spec constraints: `rg -n "CONSTRAINT:|MUST|INVARIANT:" openspec/changes/<id>/specs/`
+- View implementation diff: `/opsx:diff <id>` or `git diff`
+- Archive (after passing): `/ccg:spec-impl` → Step 10
+<!-- CCG:SPEC:REVIEW:END -->

package/{src/commands/ccg → templates/commands}/test.md

@@ -1,28 +1,28 @@
 ---
-description: '多模型测试生成：智能路由 Codex 底层单元测试 / Gemini 上层集成测试'
+description: 'ROS2 多模型测试生成：智能路由 Codex 单元测试 / Gemini 集成测试'
 ---
 
-# Test - 多模型测试生成
+# Test - ROS2 多模型测试生成
 
-根据代码类型智能路由，生成高质量测试用例。
+根据 ROS2 代码类型智能路由，生成高质量测试用例。
 
 ## 使用方法
 
 ```bash
-/test <测试目标>
+/test <ROS2测试目标>
 ```
 
 ## 上下文
 
 - 测试目标：$ARGUMENTS
-- 智能路由：底层控制 → Codex，上层应用 → Gemini，全栈 → 并行
-- 遵循项目现有测试框架和风格
+- 智能路由：底层控制 → Codex（gtest/pytest），上层应用 → Gemini（launch_testing）
+- 遵循 ROS2 测试框架和最佳实践
 
 ## 你的角色
 
-你是**测试工程师**，编排测试生成流程：
-- **Codex** – 底层控制测试生成（**C++/实时/硬件权威**）
-- **Gemini** – 上层应用测试生成（**Python/Launch/集成权威**）
+你是**ROS2 测试工程师**，编排测试生成流程：
+- **Codex** – 底层控制测试：gtest/pytest 单元测试（**底层权威**）
+- **Gemini** – 上层应用测试：launch_testing 集成测试（**上层权威**）
 - **Claude (自己)** – 整合测试、验证运行
 
 ---
@@ -33,7 +33,7 @@ description: '多模型测试生成：智能路由 Codex 底层单元测试 / Ge
 
 ```
 Bash({
-  command: "$HOME/.claude/bin/codeagent-wrapper --lite --backend <codex|gemini> - \"$PWD\" <<'EOF'
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> - \"$PWD\" <<'EOF'
 ROLE_FILE: <角色提示词路径>
 <TASK>
 需求：为以下代码生成测试
@@ -55,15 +55,15 @@ EOF",
 
 | 模型 | 提示词 |
 |------|--------|
-| Codex | `$HOME/.claude/.ccg/prompts/codex/tester.md` |
-| Gemini | `$HOME/.claude/.ccg/prompts/gemini/tester.md` |
+| Codex | `~/.claude/.ccg/prompts/codex/tester.md` |
+| Gemini | `~/.claude/.ccg/prompts/gemini/tester.md` |
 
 **智能路由**：
 
 | 代码类型 | 路由 |
 |---------|------|
-| 底层控制 | Codex |
-| 上层应用 | Gemini |
+| 底层控制（C++节点/算法） | Codex (gtest) |
+| 上层应用（Launch/Python） | Gemini (launch_testing) |
 | 全栈 | 并行执行两者 |
 
 **并行调用**：使用 `run_in_background: true` 启动，用 `TaskOutput` 等待结果。**必须等所有模型返回后才能进入下一阶段**。
@@ -105,14 +105,14 @@ TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })
 **⚠️ 根据代码类型必须调用对应模型**（参照上方调用规范）：
 
 - **底层控制代码** → `Bash({ command: "...--backend codex...", run_in_background: false })`
-  - ROLE_FILE: `$HOME/.claude/.ccg/prompts/codex/tester.md`
+  - ROLE_FILE: `~/.claude/.ccg/prompts/codex/tester.md`
 - **上层应用代码** → `Bash({ command: "...--backend gemini...", run_in_background: false })`
-  - ROLE_FILE: `$HOME/.claude/.ccg/prompts/gemini/tester.md`
+  - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/tester.md`
 - **全栈代码** → 并行调用两者：
   1. `Bash({ command: "...--backend codex...", run_in_background: true })`
-     - ROLE_FILE: `$HOME/.claude/.ccg/prompts/codex/tester.md`
+     - ROLE_FILE: `~/.claude/.ccg/prompts/codex/tester.md`
   2. `Bash({ command: "...--backend gemini...", run_in_background: true })`
-     - ROLE_FILE: `$HOME/.claude/.ccg/prompts/gemini/tester.md`
+     - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/tester.md`
   用 `TaskOutput` 等待结果
 
 OUTPUT：完整测试代码（使用项目现有测试框架，覆盖正常路径、边界条件、异常处理）
@@ -156,12 +156,12 @@ OUTPUT：完整测试代码（使用项目现有测试框架，覆盖正常路
 - 失败：<如有，列出原因>
 ```
 
-## 测试策略金字塔
+## ROS2 测试策略金字塔
 
 ```
-    /\      E2E (10%)
-   /--\     Integration (20%)
-  /----\    Unit (70%)
+    /\      Simulation (10%) - Gazebo 完整功能测试
+   /--\     Integration (20%) - launch_testing 节点通信测试
+  /----\    Unit (70%) - gtest/pytest 算法和逻辑测试
 ```
 
 ---
@@ -170,5 +170,5 @@ OUTPUT：完整测试代码（使用项目现有测试框架，覆盖正常路
 
 1. **测试行为，不测试实现** – 关注输入输出
 2. **智能路由** – 底层控制测试用 Codex，上层应用测试用 Gemini
-3. **复用现有模式** – 遵循项目已有的测试风格
+3. **复用现有模式** – 遵循 ROS2 已有的测试风格
 4. 外部模型对文件系统**零写入权限**