# CCPE Patch Request: Local CCRA Reviewer Runtime Patch 2 Date: 2026-06-19 Status: implemented upstream in `ccpe-system` as `ccra-local-reviewer` / `ccra-local-review` v0.1.2. Client repository: ```text C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong ``` Requested supplier repository: ```text C:\Users\wangq\Documents\Codex\ccpe-system ``` Related prior requests: ```text requirements/ccpe/2026-06-19-ccra-local-reviewer-runtime.md requirements/ccpe/2026-06-19-ccra-local-reviewer-runtime-patch1.md ``` ## 1. Product Context CCPE Patch 1 has been tested with a second historical Local CCRA pilot. Pilot run directory: ```text local_ccra_reviews/round-04/pilot-02/ ``` The same real Codex child session completed both required turns: ```text child_session_id: 019edcde-24be-7593-99b2-5cf014467340 review_turn_duration_ms: 512317 planning_turn_duration_ms: 342925 ``` Primary outputs: ```text local_ccra_reviews/round-04/pilot-02/04_LOCAL_CCRA_REVIEW_REPORT.md local_ccra_reviews/round-04/pilot-02/next-review-requirements.md local_ccra_reviews/round-04/pilot-02/05_WEB_LOCAL_CCRA_COMPARISON.md local_ccra_reviews/round-04/pilot-02/returned-output.md local_ccra_reviews/round-04/pilot-02/run-notes.md ``` Pilot 02 achieved the main Patch 1 target: - it used the mandatory project knowledge base; - it preserved no-hindsight review scope for initial Round 04 evidence; - it reproduced the Web CCRA-style issue mechanism diagnosis; - it separated must-fix, same-class boundary, calibration-only, and explicitly-not-patched cases; - it produced a same-child-session `planning_turn` output for next review requirements. The project-side conclusion is: ```text ready_for_formal_local_first_review_with_conditions ``` Patch 2 is therefore a hardening patch, not a blocker before the next Owner/Web-defined round. It should improve repeatability and helper reliability before Local CCRA is used repeatedly. ## 2. Source Evidence For This Patch Use these project files as the primary evidence: ```text local_ccra_reviews/round-04/pilot-02/04_LOCAL_CCRA_REVIEW_REPORT.md local_ccra_reviews/round-04/pilot-02/next-review-requirements.md local_ccra_reviews/round-04/pilot-02/05_WEB_LOCAL_CCRA_COMPARISON.md local_ccra_reviews/round-04/pilot-02/run-notes.md local_ccra_reviews/round-04/pilot-02/returned-output.md local_ccra_reviews/round-04/pilot-02/helper-outputs/ knowledge_assets/10_本地CCRA评审机制说明.md ``` The comparison baseline remains: ```text C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md ``` Source range rule: ```text Only lines 1-214 are the Web baseline for initial Round 04 review and Round 04.1 requirements. Lines after 214 belong to later Round 04.1 review / closeout and must not be mixed into the initial comparison baseline. ``` ## 3. Needed Capability Changes Patch 2 should improve Local CCRA runtime reliability in five areas: 1. project-aware review bundle audit profile; 2. explicit gate-runner execution policy; 3. mandatory routing behavior diff for patch verification; 4. scoped lifecycle/status scan and triage; 5. short Owner-facing summary for long audit reports. Patch 2 should not redesign the full round automation/orchestration workflow. Round-level automation is a separate design topic. ## 4. Required Changes ### 4.1 Project-Aware Review Bundle Audit Profile Problem observed in pilot 02: ```text review-bundle-audit: exit 1 generic profile reports missing manifest and validation_sidecar BUNDLE_FILE_MANIFEST_04.md exists but is treated as extra by the generic profile ``` Requested behavior: - Local CCRA should distinguish real review bundle blockers from generic-profile mismatches. - Versioned manifest names such as `BUNDLE_FILE_MANIFEST_04.md`, `BUNDLE_FILE_MANIFEST_04.1.md`, and similar round-specific forms should be recognized. - If a validation sidecar is optional for a given review profile, absence should be recorded as `profile_warning` or `not_applicable`, not automatically as a blocker. - Helper confidence should name the active profile, recognized manifest path, missing required files, extra files, and whether the result blocks review. Acceptance criteria: - The helper integration guide or runtime setup guide defines a CCRA-aware bundle audit profile or an equivalent profile contract. - Local CCRA report wording does not claim a bundle failed merely because the generic profile does not understand project-specific versioned filenames. ### 4.2 Gate Runner Execution Policy Problem observed in pilot 02: ```text regression-validation-gate-runner ran in dry_run mode only dry-run output is useful for planning but cannot support pass claims ``` Requested behavior: - Runtime input contract should include a gate execution policy: ```text gate_execution_mode: dry_run | run | owner_waived | not_applicable ``` - `dry_run` means the reviewer may inspect planned gates but must not claim they passed. - `run` means the reviewer or runtime is allowed to execute declared validation/regression commands and cite command logs. - `owner_waived` means the owner explicitly chose not to run gates; the report must preserve that as an evidence limitation. - `not_applicable` means the reviewed material has no executable gates in scope. Acceptance criteria: - Report templates distinguish `planned`, `executed`, `skipped`, and `waived` gates. - `Final Action Recommendation` cannot use dry-run evidence as a passing validation result. - Planning output requires executed command logs when a patch verification package is being prepared. ### 4.3 Mandatory Routing Behavior Diff For Patch Verification Problem observed in pilot 02: ```text routing-behavior-diff-audit was correctly skipped for no-hindsight review_turn but before/after routing diff should be required when post-patch evidence exists ``` Requested behavior: - For `review_turn` on initial evidence with no allowed after-patch material, routing diff may be skipped with explicit reason. - For any patch, post-patch verification, or comparison review where before/after outputs exist, routing behavior diff is required. - If the helper cannot run, the report must require a manual equivalent table. Minimum required diff categories: ```text target_behavior_changes non_target_behavior_changes accepted_collateral_changes unexpected_regressions unchanged_expected_behavior cases_needing_owner_or_web_calibration ``` Acceptance criteria: - Runtime/report template includes a conditional requirement for routing diff. - `planning_turn` output asks for full frozen-pool before/after comparison when selector behavior changed. - Missing routing diff is surfaced as an evidence gap, not silently ignored. ### 4.4 Scoped Lifecycle / Status Scan And Triage Problem observed in pilot 02: ```text lifecycle-status-guard-scan scanned broad repository scope it reported many findings from older review materials and pilot-01 helper outputs the output is useful but noisy ``` Requested behavior: - Lifecycle/status scan should support scope modes: ```text current_review_bundle changed_files knowledge_assets model_library_state whole_repo ``` - Whole-repo scan should be treated as broad audit mode, not default blocker mode. - Findings should be triaged into: ```text current_scope_blocker owner_decision_needed historical_or_archive_noise policy_reference_not_claim false_positive_or_low_confidence ``` Acceptance criteria: - Helper integration guide defines recommended scan scope for Local CCRA `review_turn`, `planning_turn`, and `comparison_turn`. - Report template requires lifecycle findings to be triaged before they block review readiness. - The reviewer must not turn historical review chatter into current lifecycle blocker without explaining the path to current scope. ### 4.5 Short Owner-Facing Summary Problem observed in pilot 02: ```text 04_LOCAL_CCRA_REVIEW_REPORT.md is high-quality but long routine use needs a compact Owner-facing return shape ``` Requested behavior: - Keep the long audit report for traceability. - Add or formalize a short summary shape in `returned-output.md`. Minimum summary fields: ```text review_round local_pass turn_type child_session_id main_conclusion final_action_recommendation blocks_web_review blocks_owner_acceptance required_next_action output_paths evidence_limitations ``` Acceptance criteria: - Runtime/report templates preserve both long report and short return summary. - Main session can read `returned-output.md` quickly without parsing the entire audit report. ## 5. Explicit Non-Goals Patch 2 must not: - replace Owner judgment; - replace Web CCRA final review; - change the already accepted Patch 1 two-turn pattern; - introduce LLM selector, RAG, database, frontend, backend, user system, or platform behavior; - implement full Round 5 automation or multi-pass autonomous project execution; - copy canonical CCPE artifacts into this product repository; - route deterministic helper implementation directly to `skills-vault` unless CCPE classifies the operation as reusable automation. ## 6. Acceptance Criteria Patch 2 is acceptable when: 1. CCRA-aware bundle audit profile or profile contract is documented. 2. Gate execution policy is explicit and prevents dry-run pass claims. 3. Routing behavior diff is mandatory when before/after patch evidence exists. 4. Lifecycle/status scan scope and triage categories are documented. 5. Short Owner-facing `returned-output.md` shape is defined. 6. Helper-output confidence language covers profile mismatch, dry-run, skipped helper, broad-scope noise, and missing helper. 7. No change weakens Patch 1 requirements: mandatory `knowledge_base_path`, `review_turn`, `planning_turn`, same-child session reuse, and file-first evidence remain intact. 8. Patch 2 is described as hardening, not as a required third historical pilot. ## 7. Validation / Re-Test Policy A third historical pilot is not required after Patch 2 unless CCPE changes one of these core behaviors: - issue mechanism diagnosis; - patch scope judgment; - same-child-session turn continuation; - mandatory knowledge base use; - authority boundaries. If Patch 2 only changes helper policy, report summary shape, and runtime setup guidance, validate by: 1. CCPE-side spec/template review; 2. checking the updated setup guide against `pilot-02` evidence; 3. using the next real Owner/Web-defined Local CCRA run as the first live validation. ## 8. Human Gate Owner approval is required before: - treating any helper execution mode as mandatory in all formal runs; - sending Local CCRA reports to Web CCRA as part of formal upload; - accepting Local CCRA findings as project work; - designing the larger Round-level automation workflow. ## 9. Urgency And Dependency Urgency: medium-high. Patch 2 is recommended before repeated formal Local CCRA use, but it should not block the next Owner/Web-defined round if Patch 1 behavior remains intact. The next larger topic is round-level automation/orchestration. That should be discussed separately from this Patch 2 hardening request.