# Web CCRA And Local CCRA Comparison Notes

## Scope

- comparison_target: Round 04 / Round 04.1 planning and review-quality comparison
- web_source: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md`
- web_source_range: lines 1-214 only
- local_source: `local_ccra_reviews/round-04/pilot-01/04_LOCAL_CCRA_REVIEW_REPORT.md`
- comparison_date: 2026-06-19

This note compares the first two Web CCRA/GPT exchanges with the Local CCRA pilot report. It does not use later Web exchanges after line 214.

## High-Level Judgment

The Web review is stronger at product diagnosis and next-action framing. It quickly identifies the actual Round 04 issue class, selects the four cases that should define Round 04.1, and says exactly what the post-patch review bundle must contain.

The Local CCRA report is stronger at full-file evidence coverage, auditability, runtime/helper risk discovery, lifecycle guard review, and before/after evidence preservation. Its main weakness is that it reviewed from the already-built Round 04.1 evidence set, so it reads more like a local governance and readiness audit than the original Web-style product diagnosis that decided what Round 04.1 should be.

## Where Web Was Better

### 1. Product Diagnosis

Web CCRA immediately classifies `R04-BI-002` as a rule-based selector no-call coverage problem, not an LLM understanding failure.

It also names the real mechanism: the selector did not distinguish instruction from payload, so words inside a translation payload triggered QPI.

Local CCRA agrees with the final outcome, but it does not reconstruct this diagnosis with the same sharpness. It mainly records that `R04-BI-002` moved from QPI selection to no-call after Round 04.1.

### 2. Repair Scope Selection

Web identifies the right repair set:

- `R04-BI-002`: translation should become no-call.
- `R04-BI-024`: explicit refusal of Intellectual Archaeology should reject IA.
- `R04-BI-035` and `R04-BI-036`: depth-limited requests should allow lightweight QPI, not hard no-call.

Local CCRA confirms these four target cases and verifies that Round 04.1 did not broaden QPI too aggressively. But Web is better at explaining why these four, and not the broader governance/capacity cases, should define the patch.

### 3. Review Package Requirements

Web is clearer that Round 04.1 must include a post-patch routing verification report, not only rule diffs.

It specifies three verification layers:

- targeted regression for the four cases;
- full Round 04 rerun as post-patch comparison;
- existing selector regression / calibration smoke / unit tests.

Local CCRA notices that this evidence exists and points out that routing diff automation should consume it. But Web gives the better owner-facing instruction before the materials are prepared.

## Where Local Was Better

### 1. Evidence Coverage

Local CCRA read the project rules, knowledge assets, Round 04 and Round 04.1 bundles, reports, selector rules, tests, scripts, helper outputs, and model status directly.

This gives Local CCRA a broader review surface than the Web exchange, especially for checking whether the produced Round 04.1 materials actually match the earlier Web instructions.

### 2. Non-Target Behavior Tracking

Local CCRA explicitly identifies `R04-BI-022` as a non-target behavior change after Round 04.1:

- before: no-call;
- after: QPI selected, IA rejected;
- assessment: documented collateral behavior and regression-covered.

This is a strong local advantage. Web lines 1-214 define the need for before/after comparison, but they do not yet see or judge this collateral behavior because that evidence appears only after Round 04.1 is produced.

### 3. Runtime And Helper Quality

Local CCRA finds process-level issues that Web does not cover in the first two exchanges:

- generic `review-bundle-audit` profile does not recognize versioned manifests;
- gate runner was dry-run only;
- `routing-behavior-diff-audit` was skipped even though before/after routing evidence existed;
- lifecycle/status scan requires triage rather than automatic blocking;
- context manifest contains cache/binary noise.

These findings matter for making Local CCRA useful in Round 05, because they affect repeatability and the trustworthiness of future local reports.

### 4. Lifecycle And Authority Discipline

Both Web and Local preserve the rule that Round 04 / 04.1 do not upgrade QPI or Intellectual Archaeology.

Local CCRA adds stronger file-backed checks: model JSON, model index, lifecycle guard, knowledge assets, and project workflow docs all keep the status boundary visible.

## Key Difference

Web CCRA acted like the product reviewer at the moment of deciding what to fix next.

Local CCRA acted like a file-first auditor after the fix existed.

That difference is acceptable for this pilot, but for Round 05 the Local CCRA should be tuned to include both modes:

1. diagnose the next product decision as sharply as Web CCRA;
2. audit the full file evidence more thoroughly than Web CCRA can.

## Local CCRA Tuning Implications

For the next pilot or formal Round 05 run, tune `ccra-local-reviewer` to require:

1. A Web-style "issue mechanism" section:
   - what failed;
   - why it failed;
   - why it is not a different category of failure.

2. A "patch scope" section:
   - must-fix cases;
   - same-class boundary cases;
   - calibration-only cases;
   - cases explicitly not patched.

3. A mandatory before/after behavior section when post-patch evidence exists:
   - target behavior changes;
   - non-target behavior changes;
   - accepted collateral changes;
   - unexpected regressions.

4. A helper-output confidence section:
   - helper output used as evidence;
   - helper false positive or profile mismatch;
   - dry-run versus executed validation;
   - missing helper that should have run.

5. A final recommendation shape that mirrors Web CCRA:
   - fix now;
   - document only;
   - defer to calibration;
   - do not open another small patch round.

## Practical Conclusion

Local CCRA is not worse than Web CCRA, but its current prompt/report shape is biased toward governance audit. Web CCRA is better at the early product-review judgment that decides what the next repair round should be.

The target for Round 05 should be:

- Web remains the planning and final review partner.
- Local CCRA performs the deep local first review with full file access.
- Local CCRA must include a Web-style diagnosis and repair-scope judgment so it can reduce small follow-up rounds instead of only auditing them after they happen.
