the-mindscape-of-bro-tsong/requirements/ccpe/2026-06-19-ccra-local-reviewer-runtime-patch2.md

CCPE Patch Request: Local CCRA Reviewer Runtime Patch 2

Date: 2026-06-19

Client repository:

C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong

Requested supplier repository:

C:\Users\wangq\Documents\Codex\ccpe-system

Related prior requests:

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:

local_ccra_reviews/round-04/pilot-02/

The same real Codex child session completed both required turns:

child_session_id: 019edcde-24be-7593-99b2-5cf014467340
review_turn_duration_ms: 512317
planning_turn_duration_ms: 342925

Primary outputs:

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:

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:

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:

C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md

Source range rule:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.