# Web / Local CCRA Three-Way Comparison

## Scope

This note compares three review outputs for the same Round 04 source problem:

1. Web CCRA / GPT baseline: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md`, lines 1-214 only.
2. Local CCRA pilot-01: `local_ccra_reviews/round-04/pilot-01/04_LOCAL_CCRA_REVIEW_REPORT.md` and `local_ccra_reviews/round-04/pilot-01/05_WEB_LOCAL_CCRA_COMPARISON.md`.
3. Local CCRA pilot-02 after CCPE Patch 1:
   - `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/returned-output.md`

This comparison does not use Web baseline material after line 214, because later content belongs to the Round 04.1 review and closeout.

## High-Level Judgment

Pilot-02 is materially better than pilot-01 and is now close enough to Web CCRA's first-review quality for formal local first-review use in this project, with explicit limits.

The important improvement is not only format. Pilot-02 now performs the same core judgment Web made:

- `R04-BI-002` is a rule-based selector no-call / instruction-payload boundary failure, not an LLM understanding failure.
- `R04-BI-024` is an explicit Intellectual Archaeology refusal / model-level exclusion failure.
- `R04-BI-035` and `R04-BI-036` are depth-limiting override failures: "do not go deep" should not become global no-call when the user asks for lightweight QPI.
- governance, capacity, and natural IA boundary cases should be calibration work, not another small keyword patch.
- Round 04.1 must include post-patch verification, not only a rule diff.

Pilot-02 also adds local-only strengths that Web cannot reliably provide from a limited upload: file-first evidence coverage, helper-output confidence classification, lifecycle / authority guard checks, and same-child-session continuation into a planning turn.

## Outcome Matrix

| Dimension | Web Baseline | Pilot-01 | Pilot-02 |
|---|---|---|---|
| Product mechanism diagnosis | Strong. Immediately identifies selector boundary failure and no LLM involvement. | Weaker. Mostly audits already-produced Round 04.1 evidence. | Strong. Reconstructs the same mechanism from initial Round 04 evidence. |
| Patch scope judgment | Strong. Selects 002, 024, 035, 036 and keeps wider cases for calibration. | Partial. Confirms later target set but less useful before the fix. | Strong. Separates must-fix, same-class boundary, calibration-only, and explicitly-not-patched cases. |
| Next review requirements | Strong. Requires targeted regression, full rerun, existing regression, and command logs. | Partial. Notes missing helper/runtime risks. | Strong. Produces `next-review-requirements.md` with submitted-material checklist and evidence requirements. |
| Local file audit | Limited by upload and conversation context. | Strong. Reads broad local evidence and helper outputs. | Strong. Reads required knowledge base, Round 04 evidence, helper outputs, and runtime contract. |
| Helper confidence | Not covered in baseline. | Finds helper/runtime risks, but this dominates the report. | Better balanced. Classifies helper outputs as evidence with confidence limits. |
| Conversation persistence | Not applicable. | One review child session. | Verified two-turn same-child workflow: `review_turn` then `planning_turn`. |
| Formal readiness | Web remains final reviewer. | Needs more local tuning before formal use. | Ready for formal local first review under listed conditions. |

## Where Pilot-02 Now Matches Web

Pilot-02 matches the Web baseline on the central Round 04 diagnosis. It says the initial failures are selector rule-boundary failures:

- direct transformation / translation requests can leak payload terms such as `模型` into QPI routing;
- IA refusal variants must hard-exclude IA;
- depth-limiting language should suppress IA depth, not suppress lightweight QPI.

It also matches Web on the next-step shape: do not introduce an LLM selector, do not upgrade QPI or Intellectual Archaeology, do not broaden governance / capacity cases by keyword, and do require a Round 04.1 post-patch verification pass.

This fixes the main pilot-01 gap. Pilot-01 acted like a file-first auditor after the fix existed. Pilot-02 acts like a product reviewer before the fix, then a local planning reviewer after the first judgment.

## Where Pilot-02 Is Better Than Web

Pilot-02 is stronger in evidence discipline:

- It records the exact child session id: `019edcde-24be-7593-99b2-5cf014467340`.
- It reads the mandatory project knowledge base path.
- It explicitly excludes Round 04.1 post-patch evidence from `review_turn`, preserving fair historical comparison.
- It detects that current files may contain later Round 04.1 language and avoids using that as initial Round 04 proof.
- It separates helper outputs from reviewer judgment and labels confidence limits.
- It produces a second-turn package plan instead of leaving the Owner to convert findings into review materials manually.

The `planning_turn` output is especially useful for reducing small Web sub-rounds. It requires a rule patch summary, target labels / Owner decisions, full 38-case frozen-pool before/after comparison, targeted regression, existing selector regression, calibration smoke, executed command logs, bundle manifest, and carry-forward Owner/Web calibration questions.

## Remaining Weaknesses

Pilot-02 still has operational limits:

- `review-bundle-audit` used a generic profile and misclassified the versioned Round 04 manifest pattern.
- `regression-validation-gate-runner` evidence was dry-run only in this setup.
- `lifecycle-status-guard-scan` produced broad whole-repo noise that requires human or reviewer triage.
- `routing-behavior-diff-audit` was correctly skipped for the initial no-hindsight review, but must be required when before/after evidence exists.
- The report is long. It is good as an audit artifact, but formal routine use should keep the short returned summary visible for the Owner.

These are not blockers for using Local CCRA as a formal local first-review lane. They are helper/runtime maturity issues that should remain documented and be improved as the workflow repeats.

## Readiness Recommendation

Recommendation: `ready_for_formal_local_first_review_with_conditions`.

Local CCRA v0.1.1 is ready to use for this project as the formal local first review before Web final review. It should not replace Owner judgment or Web CCRA final review.

Conditions for formal use:

1. Always run a real child session and record `child_session_id`.
2. Use the two-turn pattern by default: `review_turn` for findings, then same-child `planning_turn` for next review requirements and submitted-material guidance.
3. Keep `knowledge_base_path` mandatory and point it to `knowledge_assets/`.
4. Treat helper outputs as evidence only, with explicit confidence / noise classification.
5. Require before/after routing diff evidence whenever the reviewed material includes a patch or post-patch verification.
6. Keep Local CCRA reports local by default; include them in Web CCRA upload only when Owner explicitly decides to.
7. Do not claim lifecycle promotion, Round 05 acceptance, or Web approval from Local CCRA alone.

## Further Tuning

CCPE Patch 2 is recommended as a non-blocking hardening patch. It is not required before the next Owner/Web-defined local first-review run if Patch 1 behavior remains intact.

Recommended Patch 2 improvements:

- add a project-aware or CCRA-aware bundle audit profile for versioned manifests;
- decide when gate runner should execute rather than dry-run;
- make routing behavior diff mandatory for patch verification turns;
- tune lifecycle scan scope so broad historical findings do not dominate current review;
- add a short Owner-facing executive summary template on top of the long audit report.

## Final Conclusion

Pilot-02 achieved the intended Patch 1 target. It preserves Local CCRA's file-first advantages while recovering the Web-style mechanism diagnosis and repair-scope judgment that pilot-01 lacked.

The practical path is to start using Local CCRA for formal local first review in the current project after the Owner and Web CCRA define the next round's work, keep Web as planning / final review partner, and use the first real run as live validation of Patch 2 hardening if CCPE updates it.
