Add QC orchestrator with git2 integration and 200-line PR policy

[Copilot]

Summary

Implements production QC orchestrator invoked via codex qc CLI. Analyzes git diffs, executes test profiles, scores risk, enforces 200-line policy, writes structured logs to _docs/logs/.

Motivation

Need automated quality gates before merge. Manual review insufficient for risk assessment at scale. 200-line policy required formal enforcement.

Changes

Core Module (codex-rs/core/src/qc_orchestrator.rs, 767 lines)

• Strongly-typed data model: TestProfile, QcConfig, QcInput, DiffStats, CommandStatus, TestResult, Recommendation, QcResult
• Git integration via git2: computes diff stats between configurable base refs (tries main → origin/main → origin/master → HEAD~1)
• Test execution: Minimal (CLI only), Standard (all tests + Clippy + web), Full (Standard + coverage + lint)
• Risk scoring: 0.0-1.0 based on test failures (+0.3 each, max 0.6) and diff size (+0.2 for 200-499 lines, +0.4 for 500+)
• Recommendation engine: MergeOk / NeedsFix / CreatePrForReview (triggered at >200 lines)
• Markdown logger: appends to _docs/logs/YYYY-MM-DD-{worktree}-impl.md with timestamp, stats, results, risk, issues

CLI Integration (codex-rs/cli/src/main.rs)

• Added /qc subcommand via clap with args: --feature, --profile, --agent-name, --ai-name
• Auto-detects codex-rs/ for Rust tests
• Rich console output with Unicode icons

Tests (9 total)

• 5 unit: profile parsing, risk scoring, recommendation logic
• 4 integration: full QC run, git repo creation, config defaults

Documentation

• codex-rs/_docs/qc-orchestrator.md: comprehensive user guide
• QC_IMPLEMENTATION_SUMMARY.md: technical details

Infrastructure

• Fixed workspace structure: removed duplicate [workspace] declarations in cli/Cargo.toml and tui/Cargo.toml
• Dependencies: git2 (0.18), chrono (0.4), clap (4.5), tempfile (3.10, dev)

# Example usage
codex qc --feature "Refactor auth module" --profile standard

# Output
📊 QC Summary
─────────────────────────────────────────
Changed Files:  4
Changed Lines:  423
Risk Score:     0.20
Recommendation: CreatePrForReview

Reasons:
  • 変更行数が423行を超えています (200行ルール)

Test Results:
  ✓ Rust CLI Tests

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 📝 Documentation update

Component

• Codex Core (Rust)
• Documentation

Testing

Test Environment:

• OS: Linux
• Codex Version: 2.3.0
• Rust: 1.90.0 (edition 2024)

Test Results:

running 5 tests (unit)
test qc_orchestrator::tests::test_profile_from_str ... ok
test qc_orchestrator::tests::test_profile_as_str ... ok
test qc_orchestrator::tests::test_recommendation_as_str ... ok
test qc_orchestrator::tests::test_compute_risk_score ... ok
test qc_orchestrator::tests::test_build_recommendation ... ok

running 4 tests (integration)
test test_qc_orchestrator_with_no_changes ... ok
test test_profile_parsing ... ok
test test_recommendation_display ... ok
test test_qc_config_default ... ok

test result: ok. 9 passed; 0 failed

Self-validation: QC analyzed own implementation, correctly recommended CreatePrForReview due to 423 lines changed.

Security Impact

• N/A (not kernel code)
• No new unsafe code

Checklist

• My code follows the code style of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Screenshots (if applicable)

N/A - CLI tool with text output shown in Changes section

Additional Notes

Ready for Tauri GUI integration. Log format designed for both CLI and GUI consumption. Base ref fallback handles various repo configurations robustly.

Original prompt

Implement a fully working QC orchestrator feature in the zapabob/codex repository and open a PR.

Goal

• Add a production-ready QC orchestrator sub-agent that can be invoked via a /qc slash subcommand from the Rust CLI and later from the Tauri GUI.
• Use git2 (already used in the official repo) for Git integration.
• Enforce a 200-line change policy (PR recommendation) and write human-readable QC logs into _docs/logs.
• Follow Rust 2024 style and best practices as much as possible while staying compatible with the upstream OpenAI/codex layout and conventions.

Key requirements

1. CLI integration (codex-rs/cli/src/main.rs and related CLI code)

   • Add a new subcommand /qc exposed as a slash-style command so it can be called as:
     • codex /qc --profile standard --feature "..." --agent-name "..." --ai-name "..."
   • Use clap (or existing CLI parser) to define:
     • profile (optional): minimal | standard | full, default from config.
     • agent_name (optional): logical agent name (e.g. codex-cli-agent), default to a sensible value.
     • ai_name (optional): model/front-end identifier (e.g. claude-code, gemini, gpt-4.1), default to a sensible value.
     • feature (optional): short human-readable description of the change.
   • The handler for /qc should:
     • Detect the repository root (current working directory).
     • Load QC configuration (see below).
     • Build a QcInput struct and call a new run_qc API in a qc_orchestrator module.
     • Print a concise summary to stdout:
       • changed lines / files
       • recommendation (merge OK / needs fix / PR for review)
       • reasons
       • log path

2. QC orchestrator module (new Rust module, e.g. codex-rs/core/src/qc_orchestrator.rs or appropriate location)

   • Define clear, strongly typed structures (no untyped String maps) to represent configuration, inputs, diff stats, test results, and the QC outcome. For example:
     • TestProfile enum: Minimal, Standard, Full (with from_str and as_str).
     • QcConfig struct: default_profile: TestProfile, max_lines_without_pr: usize, base_ref: String.
     • QcInput struct: feature, agent_name, ai_name, profile.
     • DiffStats struct: changed_lines, changed_files.
     • CommandStatus enum: NotRun { reason }, Passed, Failed { summary }.
     • TestResult struct: label, command, status, warnings.
     • Recommendation enum: MergeOk, NeedsFix, CreatePrForReview.
     • QcResult struct: timestamp, worktree, diff, tests, risk_score, recommendation, reasons, issues, log_path.
   • Implement run_qc(repo_root: &Path, input: QcInput, config: QcConfig) -> Result<QcResult, anyhow::Error> that:
     1. Gets local system time (with timezone offset) via chrono::Local.
     2. Uses git2 to open the repo and compute diff stats between config.base_ref (e.g. main or configured branch) and HEAD:
        • changed_lines = sum of added+deleted lines from git2::DiffLineType::Addition | Deletion.
        • changed_files = count of non-unmodified deltas.
     3. Executes a test profile based on input.profile:
        • Minimal:
          • Rust: cargo test -p codex-cli.
        • Standard (default):
          • Rust: cargo test --all.
          • Rust Lint: cargo clippy --all --all-targets -- -D warnings.
          • Web/GUI: pnpm test or, if pnpm is unavailable, npm test.
        • Full:
          • Everything in Standard.
          • If available: Rust coverage via cargo tarpaulin --workspace.
          • Web lint via pnpm lint or npm run lint.
        • Use std::process::Command to run these commands relative to repo_root.
        • Collect stdout/stderr and exit codes and map them into TestResult instances; never panic if a command is missing. Instead, mark that test as NotRun { reason }.
     4. Compute a simple risk_score: f32 using diff size and failed tests (e.g. add weight for failures and for large diffs, then clamp to 0.0–1.0).
     5. Apply the 200-line rule and build a Recommendation plus textual reasons:
        • If any test or lint failed, at minimum recommend NeedsFix.
        • If changed_lines > max_lines_without_pr (200), override recommendation to CreatePrForReview and add a reason mentioning the "200行ルール".
        • Optionally, if risk_score > 0.7 but diff is small, still consider NeedsFix.
     6. Derive a worktree name for logging (e.g. from HEAD branch name or worktree path) using git2.
     7. Call a helper to append a log entry to _docs/logs/YYYY-MM-DD-{worktree}-impl.md (see logging).

3. Logging in _docs/logs

   • All QC runs must append to a markdown file under _docs/logs in the repo root.
   • Create the directory _docs/logs if it does not exist.
   • File naming pattern:
     • _docs/logs/YYYY-MM-DD-{worktree}-impl.md
     • Use the local date portion from Local::now().
   • Each QC ru...

This pull request was created as a result of the following prompt from Copilot chat.

Implement a fully working QC orchestrator feature in the zapabob/codex repository and open a PR.

Goal

• Add a production-ready QC orchestrator sub-agent that can be invoked via a /qc slash subcommand from the Rust CLI and later from the Tauri GUI.
• Use git2 (already used in the official repo) for Git integration.
• Enforce a 200-line change policy (PR recommendation) and write human-readable QC logs into _docs/logs.
• Follow Rust 2024 style and best practices as much as possible while staying compatible with the upstream OpenAI/codex layout and conventions.

Key requirements

1. CLI integration (codex-rs/cli/src/main.rs and related CLI code)

   • Add a new subcommand /qc exposed as a slash-style command so it can be called as:
     • codex /qc --profile standard --feature "..." --agent-name "..." --ai-name "..."
   • Use clap (or existing CLI parser) to define:
     • profile (optional): minimal | standard | full, default from config.
     • agent_name (optional): logical agent name (e.g. codex-cli-agent), default to a sensible value.
     • ai_name (optional): model/front-end identifier (e.g. claude-code, gemini, gpt-4.1), default to a sensible value.
     • feature (optional): short human-readable description of the change.
   • The handler for /qc should:
     • Detect the repository root (current working directory).
     • Load QC configuration (see below).
     • Build a QcInput struct and call a new run_qc API in a qc_orchestrator module.
     • Print a concise summary to stdout:
       • changed lines / files
       • recommendation (merge OK / needs fix / PR for review)
       • reasons
       • log path

2. QC orchestrator module (new Rust module, e.g. codex-rs/core/src/qc_orchestrator.rs or appropriate location)

   • Define clear, strongly typed structures (no untyped String maps) to represent configuration, inputs, diff stats, test results, and the QC outcome. For example:
     • TestProfile enum: Minimal, Standard, Full (with from_str and as_str).
     • QcConfig struct: default_profile: TestProfile, max_lines_without_pr: usize, base_ref: String.
     • QcInput struct: feature, agent_name, ai_name, profile.
     • DiffStats struct: changed_lines, changed_files.
     • CommandStatus enum: NotRun { reason }, Passed, Failed { summary }.
     • TestResult struct: label, command, status, warnings.
     • Recommendation enum: MergeOk, NeedsFix, CreatePrForReview.
     • QcResult struct: timestamp, worktree, diff, tests, risk_score, recommendation, reasons, issues, log_path.
   • Implement run_qc(repo_root: &Path, input: QcInput, config: QcConfig) -> Result<QcResult, anyhow::Error> that:
     1. Gets local system time (with timezone offset) via chrono::Local.
     2. Uses git2 to open the repo and compute diff stats between config.base_ref (e.g. main or configured branch) and HEAD:
        • changed_lines = sum of added+deleted lines from git2::DiffLineType::Addition | Deletion.
        • changed_files = count of non-unmodified deltas.
     3. Executes a test profile based on input.profile:
        • Minimal:
          • Rust: cargo test -p codex-cli.
        • Standard (default):
          • Rust: cargo test --all.
          • Rust Lint: cargo clippy --all --all-targets -- -D warnings.
          • Web/GUI: pnpm test or, if pnpm is unavailable, npm test.
        • Full:
          • Everything in Standard.
          • If available: Rust coverage via cargo tarpaulin --workspace.
          • Web lint via pnpm lint or npm run lint.
        • Use std::process::Command to run these commands relative to repo_root.
        • Collect stdout/stderr and exit codes and map them into TestResult instances; never panic if a command is missing. Instead, mark that test as NotRun { reason }.
     4. Compute a simple risk_score: f32 using diff size and failed tests (e.g. add weight for failures and for large diffs, then clamp to 0.0–1.0).
     5. Apply the 200-line rule and build a Recommendation plus textual reasons:
        • If any test or lint failed, at minimum recommend NeedsFix.
        • If changed_lines > max_lines_without_pr (200), override recommendation to CreatePrForReview and add a reason mentioning the "200行ルール".
        • Optionally, if risk_score > 0.7 but diff is small, still consider NeedsFix.
     6. Derive a worktree name for logging (e.g. from HEAD branch name or worktree path) using git2.
     7. Call a helper to append a log entry to _docs/logs/YYYY-MM-DD-{worktree}-impl.md (see logging).

3. Logging in _docs/logs

   • All QC runs must append to a markdown file under _docs/logs in the repo root.

   • Create the directory _docs/logs if it does not exist.

   • File naming pattern:

     • _docs/logs/YYYY-MM-DD-{worktree}-impl.md
     • Use the local date portion from Local::now().

   • Each QC run appends a section with this exact structure (values filled in):

     ## 2025-11-19 13:40:12 +0900
     
     - Worktree: feature-tauri-gui
     - 機能: <feature description>
     - 実装担当エージェント: <agent_name>
     - AI名: <ai_name>
     - テストプロファイル: <minimal|standard|full>
     
     ### テスト結果
     - Rust: <command> → <PASSED | FAILED | NOT RUN(reason)>
     - Rust Lint: <command> → <...>
     - Web: <command> → <...>
     
     ### 品質評価 (QC / 統計)
     - 変更行数: <integer>
     - 影響ファイル数: <integer>
     - 新規警告: <integer>
     - リスクスコア: <0.0–1.0>
     
     ### マージ可否の判断
     - 推奨: <マージしてよい | マージしない (要修正) | PRを作成してレビュー>
     - 理由:
       - <reason1>
       - <reason2>
     
     ### 指摘事項 (要修正)
     - <issue1>
     - <issue2>
     
     ---

   • Ensure timestamp format includes timezone offset, e.g. %Y-%m-%d %H:%M:%S %z.

   • At minimum, include failed tests and key error messages in the "指摘事項" section.

4. QC configuration via .codex/config.toml

   • Extend or create .codex/config.toml with a [qc] section, e.g.:

     [qc]
     default_profile = "standard"   # minimal | standard | full
     max_lines_without_pr = 200
     base_branch = "main"

   • Implement a robust loader (in CLI or shared config module) that:

     • Parses this section using serde + toml or the existing config mechanism.
     • Provides safe defaults if keys are missing.

5. Code quality, edition, and upstream compatibility

   • Write the new Rust code in a style compatible with Rust 2024 best practices:
     • Strong typing, clear enums, no unnecessary unwrap/expect on user input or external commands.
     • Use anyhow::Result or the project-standard error type for run_qc and top-level CLI functions.
   • Ensure cargo clippy --all --all-targets -- -D warnings passes (warning-free new code).
   • Do not break existing CLI behavior; /qc must be additive.
   • Keep module/file placement consistent with the existing codex-rs structure and how other sub-systems are organized (e.g. core, orchestrator, etc.).

6. Documentation

   • Add _docs/test-profiles.md describing the minimal, standard, and full profiles.
   • Add a brief _docs/qc-orchestrator.md or extend an appropriate existing doc (e.g. under docs/ or _docs/) to explain:
     • What /qc does.
     • How the 200-line PR recommendation policy works.
     • How logs are stored and how agents should read them before starting work.

7. Tauri GUI entry point (minimal stub)

   • If the Tauri GUI code path is clearly defined in the repo, add a minimal Rust command stub that calls run_qc so the GUI can later bind a "QC テスト実行" button to it.
   • The GUI wiring itself can be minimal or left as a TODO, but the backend function should be present and usable.

Notes

• Use git2 (already present in the repo or in the upstream) to compute diffs and branch/worktree info instead of shelling out to git when possible.
• Handle missing tools (pnpm, tarpaulin, etc.) gracefully: mark tests as NotRun with a clear reason instead of failing the whole QC run.
• Keep the changes per file and per module to a human-reviewable size; avoid giant multi-purpose functions.

Deliverable

• A pull request in zapabob/codex that:
  • Adds the QC orchestrator module.
  • Adds the /qc CLI subcommand.
  • Writes _docs/logs QC logs.
  • Updates .codex/config.toml and _docs documentation.
  • Passes tests and clippy with warnings treated as errors for the new code.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[zapabob]

2024

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

0 out of 2 committers have signed the CLA.
❌ @Copilot
❌ @zapabob
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[zapabob]

I have read the CLA Document and I hereby sign the CLA