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

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.