[lanyue-llk]

Change

Add repository-wide OCR guidance in six titled steps: goals and constraints, regressions, design and reuse, upstream and cross-repository dependencies, validation, and complete coverage. Each step has one question and short action items. Keep object-oriented design and avoidance of report-instance coupling explicit; put repository-specific checks in one short section.

Use merge_system_rule: true to preserve OCR's built-in rules, severity thresholds, output format and execution policy. The rules take effect for subsequent reviews after merging into the target branch (main).

Validation

• Verified the repository-wide additive configuration and rule target; the configuration is unchanged by the follow-up prose edits.
• Verified local references and additive configuration; only the two OCR rule files are included. Read the six titled steps in order and checked their coverage against the intended review requirements.
• git diff --check passed.
• make check on the initial rule-only commit: 2772 passed, 1 skipped; 321 subtests passed; all five suite validations passed.

[lexmount-ocr]

✅ Review complete · 7082ed4

No findings in this review.

[lanyue-llk]

Reviewed 7082ed4 against the changed rules, README, AGENTS.md, CONTRIBUTING.md and the evaluation/version protocols. The additive configuration matches OCR's resolver implementation. Repository-specific checks below follow the current protocol and contribution guide. I found no configuration defect that warrants blocking this PR. I would tighten the following review questions.

1. Make question 4 neutral about implementation style. Its safeguards against unnecessary hierarchies are useful, but the opening still treats object-oriented design as the expected form of shared code. Ask whether responsibilities, state and invariants are clear and whether the existing owner can handle the change simply. A class or interface should solve a demonstrated caller or lifecycle problem. Pure scoring and input transformations should not need an architectural rewrite to satisfy a review rule.

2. Ask the reviewer to execute the focused reproduction and passing control when the environment permits it. Questions 6–7 currently ask whether such a reproduction is possible. Also check that validation refers to the reviewed revision. For this PR, an OCR resolver smoke check should show the repository supplement plus the appropriate system rule for root, nested Python and non-Python paths. The reported test suite and JSON checks do not test rule consumption, and the current bot review cannot establish adoption because the PR says rules are read from the target branch.

3. Expand question 9 to name the repository's actual scoring distinctions. The protocol separates score_attempt, the shared task_passed predicate, text-quality diagnostics and delivered-file byte acceptance. A correction can improve a diagnostic while accidentally changing binary acceptance, or accept declared file metadata without testing the delivered bytes. Ask for accepted/rejected controls through the public scoring entry and final task predicate, with missing reference coverage remaining unavailable. Select controls for the affected contract: page shell versus required body, equivalent serialization, complete versus incomplete records, or valid versus corrupt file bytes.

4. Distinguish frozen-input integrity from source validity and correction scope. Question 10 preserves hashes and editions, but the protocol explicitly says matching frozen hashes does not prove a live page still satisfies the reference. Question 9's independent support should cover task-relevant reference scope rather than a provider's own answer. A scoring correction also needs a complete rescore of the affected saved outputs under one scorer, preserving earlier results; a changed request needs new calls. Ask the reviewer to verify those obligations at the benchmark/harness handoff without moving provider execution into this package.

Keep the supplement short by referring to the existing protocols. Their ownership boundaries are already sound. Local structural checks passed for all three PR snapshots; the OCR CLI was not installed, so rule loading was inspected in its published resolver source rather than reported as an executed smoke test.

[lexmount-ocr]

✅ Review complete · 12d8716

No findings in this review.

[lexmount-ocr]

✅ Review complete · 41b4393

No findings in this review.

[lexmount-ocr]

✅ Re-review complete · 3116863

No findings in this incremental review.