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

# CCPE Patch Request: Local CCRA Reviewer Runtime Patch 1

Date: 2026-06-19

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 request:

```text
requirements/ccpe/2026-06-19-ccra-local-reviewer-runtime.md
```

## 1. Product Context

The first Local CCRA pilot has been executed against historical Round 04 material.

Pilot run directory:

```text
local_ccra_reviews/round-04/pilot-01/
```

The pilot used a real Codex child session and wrote:

```text
local_ccra_reviews/round-04/pilot-01/04_LOCAL_CCRA_REVIEW_REPORT.md
local_ccra_reviews/round-04/pilot-01/returned-output.md
local_ccra_reviews/round-04/pilot-01/05_WEB_LOCAL_CCRA_COMPARISON.md
```

The comparison note found a clear division:

- Web CCRA / GPT was stronger at product diagnosis and next-action framing.
- Local CCRA was stronger at full-file evidence coverage, auditability, runtime/helper risk discovery, lifecycle guard review, and before/after evidence preservation.

The desired Local CCRA target is not to replace Web CCRA. The goal is to reduce small follow-up review rounds such as `04.1` and `04.2` by improving local first-pass review quality before Web final review.

## 2. Source Evidence For This Patch

Use these project-side files as the primary evidence for the patch:

```text
local_ccra_reviews/round-04/pilot-01/04_LOCAL_CCRA_REVIEW_REPORT.md
local_ccra_reviews/round-04/pilot-01/05_WEB_LOCAL_CCRA_COMPARISON.md
local_ccra_reviews/round-04/pilot-01/run-notes.md
local_ccra_reviews/README.md
knowledge_assets/10_本地CCRA评审机制说明.md
```

Use this Web CCRA / GPT record for the comparison baseline:

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

Important source-range rule:

```text
Only lines 1-214 are the Web discussion for initial Round 04 review and Round 04.1 requirements.
Lines after 214 are later Round 04.1 review and closeout discussion, and should not be mixed into the initial comparison baseline.
```

The owner records AI discussions as one file per conversation. First-level numbered headings such as `# 1`, `# 2`, `# 3` mark discussion rounds inside the same conversation file. CCPE should preserve this interpretation when referencing Web / GPT discussion records.

## 3. Needed Capability Change

Patch `ccra-local-reviewer` and `ccra-local-review` so Local CCRA can combine two review modes in one formal local review:

1. Web-style product diagnosis mode.
2. Local file-first audit mode.

The current pilot leaned too far toward governance/readiness audit after the repair already existed. Patch 1 should make the reviewer produce a sharper product diagnosis before or during the repair-planning stage, while preserving the local audit advantages.

Patch 1 should also support a two-turn usage pattern inside the same child review session:

1. Turn 1: review the current round material and identify issues.
2. Turn 2: continue the same child session to plan the next review requirements and the material package that should be submitted.

This is a session-continuity requirement. The second turn should reuse the same child session id instead of starting a fresh reviewer context.

## 4. Required Reviewer Behavior

### 4.0 Two-Turn Review And Planning Protocol

The Local CCRA runtime should support two explicit prompts against the same child session.

Turn 1 is the review turn:

- input: current round review material, review bundle, project knowledge base, reports, tests, helper outputs, and owner-provided review question;
- task: inspect the current material, find issues, classify findings, identify evidence gaps, and recommend whether current material is ready for Web CCRA / Owner decision / another local iteration;
- primary output: Local CCRA review report;
- prohibited focus: do not make the main output a next-round planning document before the current material has been judged.

Turn 2 is the planning turn:

- input: the same child session id, the Turn 1 report, any Owner decision on findings, and the target of the next review round;
- task: plan the next review requirements and specify the materials that should be prepared or submitted;
- primary output: next-review requirements / submission-material plan;
- prohibited focus: do not re-review the full current bundle unless new evidence has been added or the owner explicitly asks for re-review.

Required runtime behavior:

- preserve `child_session_id` across Turn 1 and Turn 2;
- record both turn prompts and output paths in the run metadata or run notes;
- make the turn type explicit, for example `review_turn` and `planning_turn`;
- require the second turn to reference the first-turn report rather than relying on main-session chat summaries;
- allow the second turn to produce a separate file such as `next-review-requirements.md` or another CCPE-defined filename.

This two-turn pattern mirrors the intended owner workflow: first ask Local CCRA what is wrong with the current materials, then ask the same reviewer context what the next review should require.

### 4.1 Web-Style Product Diagnosis

For each material issue, the reviewer must identify:

- what failed;
- why it failed;
- why it is not a different failure category;
- whether it is a product routing problem, rule boundary problem, model-content problem, runtime problem, or lifecycle/governance problem.

For Round 04, Web CCRA did this well by identifying `R04-BI-002` as a rule-based selector no-call / instruction-payload boundary problem, not an LLM-understanding problem.

### 4.2 Patch Scope Judgment

The report must explicitly separate:

- must-fix cases;
- same-class boundary cases;
- calibration-only cases;
- cases explicitly not patched;
- cases that should not open another small patch round.

For Round 04, the expected pattern was:

- `R04-BI-002`: must-fix translation no-call case.
- `R04-BI-024`: same-class model-level exclusion boundary case.
- `R04-BI-035` and `R04-BI-036`: same-class depth-limiting override cases.
- governance / capacity / ambiguous low-context cases: defer to calibration, not immediate broadening.

### 4.3 Verification-First Review Package Requirements

When a patch is proposed or already exists, the reviewer must say whether the review package contains enough verification evidence.

For selector patches, Local CCRA should require:

- targeted regression for confirmed target cases;
- full frozen-pool rerun as post-patch comparison;
- existing selector regression / calibration smoke / unit tests;
- command log or validation report that distinguishes dry-run from executed gates.

The reviewer should explicitly state that rule diffs alone are insufficient.

### 4.4 Before / After Behavior Review

When before/after routing evidence exists, the report must include:

- target behavior changes;
- non-target behavior changes;
- accepted collateral behavior changes;
- unexpected regressions;
- cases needing Owner/Web CCRA calibration labels.

For Round 04.1, `R04-BI-022` is the key example: it was a non-target behavior change that was documented and regression-covered. Local CCRA found this well; Patch 1 should make this section mandatory whenever post-patch evidence exists.

### 4.5 Full-File Local Audit

Preserve the local strengths from pilot 01:

- read full local review material directly from files;
- use `knowledge_assets/` as the mandatory knowledge base;
- inspect review bundles, reports, selector rules, tests, scripts, helper outputs, and model status;
- cite files actually read;
- distinguish helper evidence from reviewer judgment;
- preserve Owner / Web CCRA / lifecycle authority boundaries.

### 4.6 Helper-Output Confidence

The report must include a helper-output confidence section:

- helper output used as evidence;
- helper output that appears stale, generic, false-positive, or profile-mismatched;
- dry-run versus executed validation;
- missing helper that should have run;
- whether helper findings block the current review or only require runtime tuning.

For pilot 01, relevant examples were:

- `review-bundle-audit` generic profile did not recognize versioned bundle manifests.
- `regression-validation-gate-runner` ran in dry-run mode only.
- `routing-behavior-diff-audit` was skipped even though before/after evidence existed.
- `lifecycle-status-guard-scan` produced broad findings requiring triage.

## 5. Runtime / Template Changes Requested

CCPE should update or patch these artifact families as needed:

- `ccra-local-reviewer` Agent Spec.
- `ccra-local-review` Runtime Spec.
- invocation packet template.
- report template.
- runtime setup guide.
- helper integration guide.

The runtime and templates should explicitly distinguish these invocation modes:

```text
review_turn
planning_turn
comparison_turn
```

Minimum expected file contract:

```text
review_turn -> 04_LOCAL_CCRA_REVIEW_REPORT.md
planning_turn -> next-review-requirements.md or a CCPE-defined equivalent
comparison_turn -> optional Web / Local comparison note, if requested by the owner
```

The exact filenames can be defined by CCPE, but the contract must avoid treating all child-session follow-up turns as new independent reviews.

The exact CCPE paths are supplier-owned, but the currently known artifacts are:

```text
C:\Users\wangq\Documents\Codex\ccpe-system\agents\agent-specs\ccra-local-reviewer.agent.md
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccra-local-review.runtime.md
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccra-local-review-runtime-setup.md
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccra-local-review-invocation-packet.template.md
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccra-local-review-report.template.md
C:\Users\wangq\Documents\Codex\ccpe-system\integrations\skills-vault\ccra-local-review-helpers.integration.md
```

## 6. Required Report Shape

Patch 1 should make these sections required or strongly required when applicable:

1. `Issue Mechanism Diagnosis`
2. `Patch Scope Judgment`
3. `Verification Evidence Requirements`
4. `Before / After Behavior Review`
5. `Non-Target Behavior Changes`
6. `Calibration-Only Candidates`
7. `Helper Output Confidence`
8. `Final Action Recommendation`

For planning turns, Patch 1 should provide a separate planning output shape with at least:

1. `Next Review Goal`
2. `Required Submitted Materials`
3. `Required Verification Evidence`
4. `Expected Before / After Comparisons`
5. `Open Owner Decisions`
6. `Explicit Non-Goals`
7. `Recommended Web CCRA Review Questions`

`Final Action Recommendation` should use a compact decision shape:

```text
fix_now
document_only
defer_to_calibration
do_not_open_patch_round
ready_for_web_review_after_local_repairs
```

## 7. Runtime Time Budget

Local CCRA is a deep file-first review, not a quick chat summary.

Expected mature-run duration:

```text
5-10 minutes
```

The exact duration depends on client/API/runtime configuration and on whether tools, helper Skills, archive inspection, and validation commands run.

The runtime should not treat several minutes of file reading or tool execution as abnormal by itself.

## 8. Prohibited Behavior

Patch 1 must not change these boundaries:

- Local CCRA does not replace Owner judgment.
- Local CCRA does not replace Web CCRA final review at key gates.
- Local CCRA must not upgrade model lifecycle status.
- Local CCRA must not edit project files other than its contracted report outputs.
- Local CCRA must not introduce LLM selector, RAG, database, frontend, backend, user system, or platform behavior.
- Local CCRA must not turn helper output into automatic judgment.

## 9. Acceptance Criteria

CCPE patch is acceptable when:

1. The updated reviewer contract explicitly requires Web-style issue mechanism diagnosis.
2. The updated reviewer contract explicitly requires patch-scope separation.
3. The updated report template can surface both product diagnosis and full-file audit findings.
4. Before/after behavior review is required when post-patch evidence exists.
5. Helper-output confidence is required and distinguishes dry-run, executed validation, skipped helper, and profile mismatch.
6. The runtime supports a two-turn same-child-session workflow: review current material first, then plan next review requirements.
7. Turn type and output paths are recorded so `review_turn`, `planning_turn`, and optional `comparison_turn` are not confused.
8. The second turn references the first-turn report and continues the same child session id.
9. The mandatory `knowledge_base_path` requirement remains intact.
10. The expected duration is documented as 5-10 minutes and client/runtime dependent.
11. No canonical CCPE artifact is copied into this product repository.

## 10. Suggested Re-Test After CCPE Patch

After CCPE completes Patch 1, rerun the Local CCRA pilot against the same Round 04 material.

Suggested run directory:

```text
local_ccra_reviews/round-04/pilot-02/
```

Use the same primary Round 04 input bundle:

```text
ccra_review_bundle/round-04_2026-06-18_blind-input-routing-evaluation/
```

Use the same mandatory knowledge base:

```text
knowledge_assets/
```

Then compare:

1. Web CCRA baseline: `2026-06-18产品交流-GPT.md` lines 1-214.
2. Old Local CCRA output: `local_ccra_reviews/round-04/pilot-01/04_LOCAL_CCRA_REVIEW_REPORT.md`.
3. New Local CCRA output: `local_ccra_reviews/round-04/pilot-02/04_LOCAL_CCRA_REVIEW_REPORT.md`.

Expected improvement:

- new Local CCRA should retain the full-file audit advantages from pilot 01;
- new Local CCRA should produce a sharper Web-style product diagnosis;
- new Local CCRA should clearly say whether a small follow-up patch round is needed, or whether the right next step is calibration / Web final review.
- the same child session should support a second planning prompt that outputs next-review requirements and required submission materials.

## 11. Human Gate

Owner approval is required before:

- accepting the patched Local CCRA behavior as the default for Round 05;
- making helper execution mandatory in formal runs;
- routing any deterministic helper improvement to `skills-vault`;
- treating Local CCRA findings as accepted project work.

## 12. Urgency And Dependency

Urgency: high before formal Round 05 Local CCRA use.

Dependency:

- Current pilot proved real child-session invocation and full-file audit value.
- Patch 1 is needed to improve product-diagnosis quality before relying on Local CCRA to reduce Web CCRA sub-rounds.
- Formal Round 05 Local CCRA should wait until CCPE either completes this patch or explicitly declines it with an alternative reviewer contract.