Prepare v0.9.0 unprotected-target integrity release

AGENTS.md

@@ -14,7 +14,8 @@ Use this file as the short repository map and startup workflow for Open Code Rev
 
 - `PLANS.md` - active or blocked repository work and its release classification.
 - `docs/engineering/toolkit_strategy.md` and `ROADMAP.md` - durable direction and outcome state.
-- `docs/engineering/project_principles.md` - cross-cutting engineering invariants and ownership boundaries; `docs/engineering/m5_context_contracts.md` owns the active v0.7.0 context checkpoint.
+- `docs/engineering/project_principles.md` - cross-cutting engineering invariants and ownership boundaries; `docs/engineering/m5_context_contracts.md` owns the current context and evidence contracts.
+- `docs/review-decision-flow.md` - canonical detailed Mermaid map for review, diagnostics, receipts, DLP, publication, and later-action decisions; keep it synchronized with runtime and public contracts.
 - `docs/development.md` - implementation workflow, boundary checklists, and local validation.
 - `docs/release.md` - release classification, authorization, publication, and archival lifecycle.
 - `docs/codex/TASKS_BACKLOG.md` - inactive work with activation conditions.
@@ -25,7 +26,7 @@ Use this file as the short repository map and startup workflow for Open Code Rev
 ## Work Startup
 
 1. Read `PLANS.md`. Before changing the repository, create or update the active plan and classify user-visible work as `no-release`, `release-required`, or `release-deferred`; record the target stable version when applicable.
-2. Select canonical guidance by scope: engineering invariants for runtime or trust-boundary work, development procedures for implementation and validation, release guidance for release lifecycle changes, and the relevant public contract for user-facing behavior. Consult the pitfalls catalogue only when diagnosing a matching failure class.
+2. Select canonical guidance by scope: engineering invariants for runtime or trust-boundary work, the review decision flow for execution or publication branch changes, development procedures for implementation and validation, release guidance for release lifecycle changes, and the relevant public contract for user-facing behavior. Consult the pitfalls catalogue only when diagnosing a matching failure class.
 3. Preserve the requested scope as coherent production-quality slices. Record service boundaries, trust inputs, validation, documentation, and closure gates in the plan before implementation.
 4. Use targeted tests while iterating and the boundary checklist for every changed parser, I/O, persistence, Git, subprocess, provider, or reporting boundary. Keep fixtures and public material synthetic and private-safe.
 5. Before staging or committing, update the plan and affected status/documentation to post-commit truth, inspect the complete diff, run `git diff --check`, and run the validation owned by the changed subsystem. Use `scripts/quality.sh` for the Python matrix and `scripts/gitleaks.sh` before publishing rewritten or newly committed branch history.

README.md

@@ -31,11 +31,11 @@ python -m pip install open-code-review-toolkit
 ```
 
 The toolkit does not bundle OCR. Download the platform asset for exact
-[Open Code Review 1.11.1](https://github.com/alibaba/open-code-review/releases/tag/v1.11.1),
+[Open Code Review 1.11.3](https://github.com/alibaba/open-code-review/releases/tag/v1.11.3),
 verify it before installation against the [compatibility manifest](compatibility/ocr-support.json),
 and place the verified binary on `PATH`. The current Linux amd64 digest is
-`1cdc7d1f776f1cdb69850130b930e40f64accc86ecaf09600573b3600456322f`; Darwin arm64 is
-`5fdf72e51aae021ac7bf43d7b9dcb160f04880f623c66e8ada5e6ae5a92e172c`. The manifest owns
+`9726204ac81baee153fd65b1ff357c380f73e9d8091c4a73c3c9fb541b5164cb`; Darwin arm64 is
+`515cd92ce300b62dea2bcaf53e910cdf57b681e1d58bbd0a9e8e49617bca52fa`. The manifest owns
 the other platform hashes.
 
 Verify the installation without contacting an LLM provider:
@@ -45,14 +45,14 @@ ocr --version
 ocr-ci --help
 ```
 
-`ocr --version` must report `open-code-review v1.11.1`; `ocr-ci --help` must exit
+`ocr --version` must report `open-code-review v1.11.3`; `ocr-ci --help` must exit
 successfully. `ocr-ci preflight` is an operational configuration check, not the installation
 smoke test.
 
 The exact recommended OCR release and its verified asset checksums live in the [versioned compatibility manifest](compatibility/ocr-support.json). CI should pin that release and checksum before execution.
 The [versioned compatibility policy](docs/compatibility.md) records tested assets and evidence and describes the conservative Dependabot-like qualification workflow for later upstream releases.
 Review output defaults to English. `OCR_REVIEW_LANGUAGE` accepts another explicit language name when a project needs localized review output; for example, `OCR_REVIEW_LANGUAGE=Russian`.
-The current OCR 1.11.1 integration defaults `OCR_REVIEW_EFFORT` to `medium` for two review rounds. `low` and `high` are explicit one- and three-round alternatives; see the [configuration reference](docs/configuration.md#review-effort) for cost, budget, and precedence boundaries.
+The current OCR 1.11.3 integration defaults `OCR_REVIEW_EFFORT` to `medium` for two review rounds. `low` and `high` are explicit one- and three-round alternatives; see the [configuration reference](docs/configuration.md#review-effort) for cost, budget, and precedence boundaries.
 
 Stable distributions are published to [PyPI](https://pypi.org/project/open-code-review-toolkit/) and mirrored as checksum-listed, provenance-attested assets in the corresponding [GitHub Release](https://github.com/xeonvs/open-code-review-toolkit/releases). Development snapshots are published only to TestPyPI.
 
@@ -62,7 +62,7 @@ On a successful rerun, the toolkit replaces untouched OCR-only notes instead of
 
 Suppression uses both the GitLab diff position and a stable finding fingerprint, so ordinary line shifts do not normally bring the same bug back. A materially changed finding can still receive a new discussion. See [GitLab review operations](docs/operations.md) for the complete lifecycle, posting modes, permissions, failure behavior, and Mermaid state diagram.
 
-After every current review note publishes, the GitLab adapter can add a conservative approval bound to receipt v6's exact reviewed source SHA and merge-request author. This write is enabled by default; set `OCR_AUTO_APPROVE=false` when the bot must remain comment-only. DLP-clean metadata, generic discussions, protected same-revision CI outcomes, and adapter records do not independently block approval, while degraded metadata, DLP rejection, required context degradation, admitted remediation history, legacy receipts, publication filtering, any direct external MCP, author movement, or bot self-authorship prevents an approval write. A CI status is review context, never approval authority. GitLab approval rules and protected-branch policy remain authoritative. The toolkit only adds an eligible approval; it never removes an existing approval when a later review is ineligible or disabled.
+After every current review note publishes, the GitLab adapter can add a conservative approval bound to receipt v8's exact reviewed source SHA, target SHA/protection state, and merge-request author. This write is enabled by default; set `OCR_AUTO_APPROVE=false` when the bot must remain comment-only. DLP-clean metadata, generic discussions, protected same-revision CI outcomes, and adapter records do not independently block approval, while an unprotected target, degraded metadata, DLP rejection, required context degradation, admitted remediation history, legacy receipts, publication filtering, any direct external MCP, author movement, or bot self-authorship prevents an approval write. A CI status is review context, never approval authority. GitLab approval rules, Code Owners, and protected-branch policy remain authoritative merge policy. They are not prerequisites for OCR execution. The toolkit only adds an eligible approval; it never removes an existing approval when a later review is ineligible or disabled.
 
 Accepted tradeoffs can be recorded in `.opencodereview/accepted-decisions.md`; the evidence collector supplies only applicable target-ref decisions and never lets a source change self-authorize its review. Root and nested target `AGENTS.md`/`CLAUDE.md` guidance is similarly exposed through the existing evidence MCP with deterministic scope and precedence, while any guidance touched by the merge request is excluded. See [Accepted project decisions](docs/configuration.md#accepted-project-decisions) and [Target project guidance](docs/configuration.md#target-project-guidance) for formats and trust boundaries.
 
@@ -79,8 +79,10 @@ The shipped Repository Evidence Engine reads immutable base/head Git objects, st
 
 1. Configure protected/masked `GITLAB_API_TOKEN` and LLM variables in GitLab.
 2. Pin and checksum the OCR binary.
-3. Install this package.
-4. Run the four public helper stages around `ocr review`:
+3. Keep `OCR_GITLAB_TARGET_PROTECTION_MODE=required` unless the project deliberately permits an unprotected target in limited, comment-only mode.
+4. Merge repository review configuration, including the Rules path, into the target branch.
+5. Enable the CI review job in a later merge request and install this package.
+6. Run the four public helper stages around `ocr review`:
 
 ```console
 ocr-ci preflight
@@ -91,6 +93,8 @@ ocr-ci post --result /tmp/ocr-result.json --stderr /tmp/ocr-stderr.log
 
 See the [GitLab mode matrix](examples/gitlab/README.md), the complete [`ocr-review.gitlab-ci.yml`](examples/gitlab/ocr-review.gitlab-ci.yml) pipeline, the [GitLab setup guide](docs/gitlab.md), and [GitLab review operations](docs/operations.md).
 
+The two-merge-request setup is recommended because repository Rules are loaded only from the captured target commit. On the default protected-target path, a supported one-merge-request alternative may add the Rules and CI job together when that integration merge request does not need review: its first run stops before OCR with a setup-pending note, retrying the same merge request cannot change the captured target Rules, and later merge requests work after it merges. An actually unprotected target with missing target Rules fails closed without promoting the source copy or promising setup-pending status. If the status identity is missing or mismatched, the toolkit likewise uses the generic fail-closed failure note. A green advisory job or pipeline does not prove that OCR or its model executed.
+
 ## Configuration and safety
 
 Configuration is environment-driven. The [configuration reference](docs/configuration.md) documents supported `OCR_*`, `CI_*`, `GITLAB_*`, and MCP inputs. Posting requires `GITLAB_API_TOKEN`; job tokens and legacy aliases are deliberately unsupported.

ROADMAP.md

@@ -22,8 +22,7 @@ flowchart LR
     classDef planned fill:#57606a,stroke:#424a53,color:#ffffff
     classDef conditional fill:#9a6700,stroke:#7d4e00,color:#ffffff
 
-    class M0,M1,M2,M3,M4 established
-    class M5 next
+    class M0,M1,M2,M3,M4,M5 established
     class M6 planned
     class M7 conditional
 ```
@@ -35,7 +34,7 @@ flowchart LR
 | M2 Ecosystem and framework coverage | Established | Supply framework and template evidence selected from demonstrated use without creating framework-specific review engines. | Established evidence, snapshot/delta, scoped-completeness, and built-in MCP contracts. | Selected static plugins and template review rules have deterministic fixtures, bounds, provenance, component ownership, completeness, first-class source/target delta queries, installed-artifact validation, verified use through the existing built-in MCP, and independently read-back stable delivery. |
 | M3 External MCP hardening | Established | Qualify and document the safe-use envelope and residual limits of the shipped generic external-MCP composition boundary. | Existing external MCP and built-in composition plus BL-011 real-OCR qualification. | Canonical security and configuration guidance records the direct-composition trust boundaries, tool-name allowlist limits, server-owned object authorization, shared plan/main exposure, response/session persistence, failure degradation, and receipt non-claims observed with checksum-verified OCR and a real synthetic stdio peer. Managed OAuth remains conditional. |
 | M4 Policy and project guidance | Established | Supply relevant target-branch decisions and guidance without allowing self-whitelisting. | Evidence scoping and target/source snapshots. | Stable delivery independently proves backward-compatible structured decisions, bounded target-derived guidance, one read-only MCP lifecycle, and closure of the tracked release work. |
-| M5 Bounded review-context enrichment | Established | Extend invocation evidence with bounded forge discussions, verified remediation history, protected same-revision CI outcomes, and optional external records through one provider-neutral, capability-constrained context lifecycle, without a second review engine. | Established M1, M3, and M4 boundaries plus the v0.7.0 BL-023 delivery. | v0.7.0 establishes bounded discussion/reference acquisition. The v0.8.0 release tree adds policy-v2 remediation selection, context-store v2 and fixed MCP projection, live bot-root/mention identity, DLP isolation, comment-only remediation, and provider-neutral reuse boundaries. v0.8.7 adds policy-v3 exact-head CI outcomes as scoped review evidence without suppression or approval authority. The owner waived the separate enriched OCR+LLM qualification, so no receipt proves model-time `context_list`/`context_get`, still-present/evidence-resolved scenarios, or receipt-level raw-data leakage inspection. Protected release publication and independent external readback remain mandatory delivery evidence but do not replace that absent qualification. |
+| M5 Bounded review-context enrichment | Established | Extend invocation evidence with bounded forge discussions, verified remediation history, protected same-revision CI outcomes, and optional external records through one provider-neutral, capability-constrained context lifecycle, without a second review engine. | Established M1, M3, and M4 boundaries plus the v0.7.0 BL-023 delivery. | v0.7.0 establishes bounded discussion/reference acquisition. The v0.8.0 release tree adds policy-v2 remediation selection, context-store v2 and fixed MCP projection, live bot-root/mention identity, DLP isolation, comment-only remediation, and provider-neutral reuse boundaries. v0.8.7 adds policy-v3 exact-head CI outcomes as scoped review evidence without suppression or approval authority. Toolkit 0.9.0 adds receipt-v8 source/target/protection binding and a separate comment-only path for explicitly allowed unprotected targets; that path rejects protected policy, enrichment, adapters, external MCP, accepted decisions, and structured target guidance rather than claiming protected-policy equivalence. The owner waived the separate enriched OCR+LLM qualification, so no receipt proves model-time `context_list`/`context_get`, still-present/evidence-resolved scenarios, or receipt-level raw-data leakage inspection. Protected release publication and independent external readback remain mandatory delivery evidence but do not replace that absent qualification. |
 | M6 Profiles and quality measurement | Established / conditional | Keep the completed review-signal ownership audit current; add model-profile aliases only after demonstrated operational need. | The BL-017 audit establishes OCR/provider telemetry and toolkit lifecycle-signal ownership; a demonstrated alias need and owner-approved matrix are required only for profile implementation. | The audit concludes `no-new-layer`; any later model profiles remain conditional and independent from explicit coverage and budget controls. |
 | M7 Later and conditional work | Conditional | Activate routing, more ecosystems, fuzzing, configuration, forge adapters, or governance work only from demonstrated need. | Milestone-specific activation signals and stable preceding contracts. | Each item meets its own trigger and ships as a coherent validated slice without weakening core invariants. |
 
@@ -46,7 +45,7 @@ flowchart LR
 - M2 is established through independently verified stable delivery of its framework plugins, template rules, scoped evidence, deltas, and built-in MCP projection. Conditional future ecosystem packs remain in M7 and do not reopen M2.
 - M4 is established through independently verified v0.6.0 artifacts and later protected-target identity improvements. M5 consumes but does not reopen its policy boundary.
 - M5's foundation is established by the v0.7.0 BL-023 release content; the v0.8.0 release tree completes its remediation/provider-neutral extension under an explicit owner waiver for the separate enriched OCR+LLM receipt. The waiver is a permanent evidence limitation, not a successful qualification: model-time `context_list`/`context_get`, still-present/evidence-resolved scenarios, and receipt-level raw-data leakage inspection remain unproven. Direct provider-specific MCP enforcement is not a second M5 path: external records stay behind the broker, while generic direct MCP retains the established M3 operator boundary. Its dependency graph is exactly `M1 -> M5`, `M3 -> M5`, and `M4 -> M5`; it is not a gate for M6 or M7. The protected release workflow, immutable receipt, and independent registry/GitHub readback remain mandatory external delivery closure and do not erase the waiver.
-- The completed M6 BL-017 audit maps receipt v5, privacy-safe normalized token buckets, reconciled MCP/evidence-action counts, and OCR 1.10.0 grouping/round telemetry to their existing owners and concludes `no-new-layer`. M5 does not create a second telemetry implementation or exporter. BL-016 remains parked because OCR already exposes direct run-level selection; BL-018 remains conditional.
+- The completed M6 BL-017 audit maps the versioned toolkit receipt, privacy-safe normalized token buckets, reconciled MCP/evidence-action counts, and OCR 1.10.0 grouping/round telemetry to their existing owners and concludes `no-new-layer`. Current receipt v8 adds immutable target/protection identity and exact action-receipt-v3 reconciliation without creating telemetry. M5 does not create a second telemetry implementation or exporter. BL-016 remains parked because OCR already exposes direct run-level selection; BL-018 remains conditional.
 - Versioned documentation remains a separate MCP integration: the toolkit supplies package/version evidence but does not store documentation.
 - Additional code-hosting adapters remain conditional and GitLab-first M5 does not depend on them.
 - Historical roadmap names, release plans, changelog entries, closed issues/PRs, and receipts retain their original identities. BL-022 is historical and is not reused.

changelog.d/169.bugfix.md

@@ -0,0 +1 @@
+Reconcile OCR 1.11.2's attempted built-in evidence tool counts with private action receipt v3 while retaining completed actions as the only source of successful evidence use and approval authority; failed or malformed calls cannot satisfy the mandatory summary. Local reviews remain receipt-less instead of emitting receipt v8 with a non-GitLab protection state, while every present invalid receipt still fails closed.

changelog.d/170.maintenance.md

@@ -0,0 +1,7 @@
+Target checksum-verified Open Code Review 1.11.2 as the sole accepted runtime for toolkit 0.9.0.
+
+Changed: built-in language routing admits `.mjs` and `.cjs` under JavaScript Rules and `.cxx` and `.hxx` under C++ Rules; `.svh` remains excluded. Hosted Linux and independent Darwin qualification use checksum-verified release artifacts.
+
+Unchanged: result and manifest schemas, inherited completion cap `16384`, explicit positive completion-cap transport, default `medium` effort, effective max-tools, private reasoning/session data, receipt v8, DLP, telemetry ownership, and approval authority.
+
+Deployment: install OCR 1.11.2 directly and verify the platform checksum from the compatibility manifest; OCR 1.11.1 is historical comparison evidence, not a runtime fallback.

changelog.d/170.rules.md

@@ -0,0 +1 @@
+Route `.mjs` and `.cjs` through OCR 1.11.2's built-in JavaScript Rules and `.cxx` and `.hxx` through its C++ Rules; `.svh` remains excluded.