xeonvs · xeonvs · Aug 26, 2026 · Aug 26, 2026
@@ -1 +1 @@
-0.8.3
+0.8.4
@@ -1,9 +1,10 @@
 {
   "issues": [
-    135,
-    136,
-    137
+    139,
+    140,
+    142,
+    143
   ],
   "schema_version": "ocr-toolkit.release-authorization/v1",
-  "version": "0.8.2"
+  "version": "0.8.3"
 }
@@ -1 +1 @@
-1787648187
+1787732180
@@ -1 +1 @@
-0.8.2
+0.8.3
@@ -1,3 +1,24 @@
+## 0.8.3 - 2026-08-26
+
+### 🚀 Features
+
+- GitLab technical details now make OCR review activity easier to explain without implying unsupported token attribution.
+
+  - **Added:** the existing inline `all OCR tool calls` line shows every non-zero counter from the closed OCR inspection, review-output, and toolkit context/evidence set instead of collapsing entries after the six most frequent tools.
+  - **Unchanged:** aggregate input/output/cache token usage remains separate because OCR does not report per-tool token consumption; raw call arguments, results, dynamic external MCP tool names, receipt v5, DLP, findings, severity, and automatic approval are unchanged.
+
+  ([#142](https://github.com/xeonvs/open-code-review-toolkit/issues/142))
+
+### 🐛 Bug Fixes
+
+- Made OCR compatibility failure publication authoritative and recoverable. The workflow now selects closed status or evidence from the actual qualification outcome, atomically replaces output handoffs, and can publish a failure status without loading unrelated support metadata. It still publishes the bounded issue and diagnostic artifact before returning a red job, while aggregate promotion remains blocked and raw diagnostics remain private. ([#139](https://github.com/xeonvs/open-code-review-toolkit/issues/139))
+- Fixed the GitLab example's stale positive `OCR_MAX_TOOLS` default by delegating with sentinel `0`. Added exact parsing for OCR's supported max-tools normalization notice and behavior-based compatibility evidence for numeric CLI boundaries, including the effective template-owned tool-loop value. The notice remains operator-only: raw OCR stderr, findings, result warnings, receipts, DLP, telemetry, lifecycle commands, and automatic-approval semantics are unchanged. ([#140](https://github.com/xeonvs/open-code-review-toolkit/issues/140))
+
+### 🛠 Maintenance
+
+- Keep both macOS endpoint CI jobs as visible best-effort compatibility diagnostics while retaining Linux, coverage, quality, security, dependency, package, and CodeQL checks as release-blocking gates. ([#143](https://github.com/xeonvs/open-code-review-toolkit/issues/143))
+
+
 ## 0.8.2 - 2026-08-25
 
 ### 🚀 Features

@@ -37,17 +37,17 @@ OCR 1.9.10 is the historical exact toolkit 0.8.0 and 0.8.1 dependency. Its termi
 
 Deploy toolkit 0.8.0 or 0.8.1 directly with OCR 1.9.10. The historical public Linux amd64 example verified SHA-256 `359e5bafda1438a47ef389399f4994350e1016371eac1dc17a2c428acb228e6c`; its manifest entry and evidence remain unchanged.
 
-### OCR 1.10.0 — toolkit 0.8.2 target
+### OCR 1.10.0 — toolkit 0.8.2 and 0.8.3 target
 
-OCR 1.10.0 is the only version accepted by toolkit 0.8.2 preflight and pinned by its GitLab example. It groups related changed files before review, uses path-aware findings, and supports one, two, or three review rounds through `effort=low|medium|high`. Toolkit 0.8.2 writes an explicit `medium` default, so a normal run permits two rounds; operators may select `low` for one round or `high` for three. Grouping, filtering, and additional rounds can add provider requests, latency, and token cost. Aggregate budget and manifest completeness remain authoritative, and incomplete or budget-stopped reviews remain ineligible for automatic approval.
+OCR 1.10.0 is the only version accepted by toolkit 0.8.2 and 0.8.3 preflight and pinned by the current GitLab example. It groups related changed files before review, uses path-aware findings, and supports one, two, or three review rounds through `effort=low|medium|high`. The toolkit writes an explicit `medium` default, so a normal run permits two rounds; operators may select `low` for one round or `high` for three. Grouping, filtering, and additional rounds can add provider requests, latency, and token cost. Aggregate budget and manifest completeness remain authoritative, and incomplete or budget-stopped reviews remain ineligible for automatic approval.
 
 Group labels are model-produced and group keys contain sorted changed paths. Additive group/round result fields remain untrusted private diagnostics: the toolkit sanitizes them when needed but excludes them from findings, GitLab text, receipt v5, fingerprints, severity, lifecycle commands, toolkit telemetry, and approval. OCR's own opt-in telemetry can include these repository-derived high-cardinality values; see the [signal-ownership audit](engineering/review_signal_ownership.md).
 
 OCR 1.10.0 also adds `--output`; `ocr-ci review` rejects `--output`, `--output=...`, `-o`, and attached short forms before preview because the toolkit retains sole ownership of the private result descriptor and atomic validation/cleanup. Improved upstream git errors remain private OCR stderr and do not widen GitLab diagnostics. With no toolkit completion-cap override, the qualified OpenAI wire request now uses `max_completion_tokens=16384`, down from 58,888 in OCR 1.9.10. `OCR_LLM_MAX_COMPLETION_TOKENS=4096` remains an explicit operator workaround for gateways that reserve spending against the requested output cap.
 
 Its max-tools CLI reports a minimum and normalization target of `50`, while the embedded review template owns `100` rounds and the CLI only raises that value. Exact-binary behavioral probes therefore observe effective `100` for omitted, sentinel `0`, `49`, and `50`, and effective `101` for explicit `101`; `--max-tools 49` still prints the `50` normalization target. Toolkit preview accepts only that exact diagnostic shape and emits a closed operator notice. It does not copy raw stderr into the OCR result or derive finding, receipt, DLP, telemetry, lifecycle, or approval authority from the notice. The public example now passes sentinel `0` instead of a stale release-specific positive value.
 
-Deploy toolkit 0.8.2 directly with OCR 1.10.0; do not install OCR 1.9.10 as an intermediate step. The public Linux amd64 example verifies SHA-256 `f8f99ea071bed77dbcaa15fdd2083287bb8ae408d5928b3943ebe0788d191b6b`; the manifest records the complete hosted asset set and qualification evidence.
+Deploy toolkit 0.8.2 or 0.8.3 directly with OCR 1.10.0; do not install OCR 1.9.10 as an intermediate step. The public Linux amd64 example verifies SHA-256 `f8f99ea071bed77dbcaa15fdd2083287bb8ae408d5928b3943ebe0788d191b6b`; the manifest records the complete hosted asset set and qualification evidence.
 
 The contiguous 1.9.7 through 1.9.8 promotion combines the repository-owned hosted Linux qualification with adjacent upstream source review. It also repeats the required 1.9.8 contract probes through the checksum-verified Darwin arm64 artifact. Multi-tool MCP initialization, fixed tool discovery and dispatch, and owner-only session persistence remain compatible with the M5 design: the toolkit may expose several fixed tools from its one built-in process, while an isolated `HOME` contains OCR's `.opencodereview/sessions` state for deterministic cleanup. Gemini and Bedrock are optional upstream provider capabilities that the toolkit neither selects nor configures; mirror-aware installation is outside the toolkit-owned download path; native severity retains the structured result fields already consumed; and human-audience progress routing does not affect the toolkit's agent-audience invocation. Therefore this promotion requires no toolkit CI behavior adaptation beyond version and checksum pins. These source observations establish capability only; the M5 production-path tests remain responsible for proving the toolkit's composition and containment.
 

@@ -58,7 +58,7 @@ Since 0.8.0, `OCR_USE_ANTHROPIC` is not a compatibility alias. Any presence fail
 
 If `OCR_LLM_EXTRA_BODY` already owns that field, an exactly equal JSON integer is deduplicated. A different value, or a boolean, string, float, or null at that field, fails configuration with a migration error; remove the duplicate field or keep the same integer in both places. Other `OCR_LLM_EXTRA_BODY` members are preserved. For example, set `OCR_LLM_MAX_COMPLETION_TOKENS=4096` when a gateway accepts short probes but rejects a full review before generation because it reserves spending against the requested output cap.
 
-Toolkit 0.8.2 does not derive this value from `/models.max_completion_tokens`. That metadata is a model capability boundary, not an account spending limit or proof of how a gateway reserves request cost.
+The toolkit does not derive this value from `/models.max_completion_tokens`. That metadata is a model capability boundary, not an account spending limit or proof of how a gateway reserves request cost.
 
 The inherited value is version-owned and therefore changes with a qualified OCR upgrade. The toolkit observed `max_completion_tokens=58888` from OCR 1.9.10 and `16384` from OCR 1.10.0 when the variable was unset. Deployments that require an invariant gateway-specific cap must set `OCR_LLM_MAX_COMPLETION_TOKENS` explicitly rather than depending on either OCR default.
 
@@ -92,9 +92,9 @@ These names belong to `examples/gitlab/ocr-review.gitlab-ci.yml`; they are shell
 
 | Variable | Source / owner | Required | Exact default | Behavior |
 | --- | --- | --- | --- | --- |
-| **`OCR_VERSION`** | Example pipeline | Yes | `v1.10.0` | Checksum-pinned recommended OCR binary release for toolkit 0.8.2. |
+| **`OCR_VERSION`** | Example pipeline | Yes | `v1.10.0` | Checksum-pinned recommended OCR binary release for toolkit 0.8.3. |
 | **`OCR_SHA256`** | Example pipeline | Yes | `f8f99ea071bed77dbcaa15fdd2083287bb8ae408d5928b3943ebe0788d191b6b` | Expected Linux AMD64 OCR binary digest. |
-| **`OCR_TOOLKIT_VERSION`** | Example pipeline | Yes | `0.8.2` | Exact toolkit wheel release installed by the current published example. |
+| **`OCR_TOOLKIT_VERSION`** | Example pipeline | Yes | `0.8.3` | Exact toolkit wheel release installed by the current published example. |
 | **`OCR_TOOLKIT_CHECKSUMS_URL`** | Example pipeline | Yes | Release URL derived from `OCR_TOOLKIT_VERSION` | Toolkit `SHA256SUMS` URL. |
 | `OCR_TOOLKIT_WHEEL` | Example shell | Computed | `open_code_review_toolkit-${OCR_TOOLKIT_VERSION}-py3-none-any.whl` | Exact wheel filename selected from the release. |
 | `OCR_TOOLKIT_WHEEL_SHA256` | Example shell | Computed | Matching value from `SHA256SUMS` | Digest checked before installing the toolkit wheel. |

@@ -6,6 +6,7 @@
 
 | Stable tag | Primary archived plan | Related context in the same archive |
 | --- | --- | --- |
+| `v0.8.3` | [OCR boundaries and review tool-usage visibility](releases.md#plan-toolkit-0-8-3) | Authoritative compatibility failure publication, installed-OCR numeric boundary ownership, complete bounded review tool-activity counters, advisory macOS endpoint checks, feature merge, development artifact verification, explicit local-LLM non-claim, and stable-delivery handoff. |
 | `v0.8.2` | [OCR 1.10.0, review effort, and compatibility failure recovery](releases.md#plan-toolkit-0-8-2) | Exact OCR 1.10.0 promotion, medium review effort, private grouping/round data, toolkit-owned output/DLP/approval boundaries, failed-qualification retention, BL-017 ownership audit, feature merge, development artifact verification, explicit local-LLM non-claim, and stable-delivery handoff. |
 | `v0.8.1` | [Completion cap, safe provider failures, and validation ownership](releases.md#plan-toolkit-0-8-1) | Protocol-aware completion cap, canonical provider configuration, bounded provider-failure projection, privacy and approval invariants, protected validation deduplication, feature merge, development artifact verification, and stable-delivery handoff. |
 | `v0.8.0` | [Remediation threads, GitLab commands, and documentation](releases.md#plan-toolkit-0-8-0) | Policy-v2 verified remediation history, context-store v2, provider-neutral forge views, exact live-username commands, environment cleanup, mode-oriented examples, OCR 1.9.10, 85% coverage and risk-group gates, protected feature merge, explicit enriched-qualification waiver, and stable-delivery handoff. |

@@ -2,6 +2,82 @@
 
 This archive preserves completed execution plans moved out of the active registry; the release index associates each plan with the stable tag or release cycle it supported. `PLANS.md` remains the source for active or blocked repository work; historical receipts here remain part of the audit trail.
 
+<a id="plan-toolkit-0-8-3"></a>
+
+## Toolkit 0.8.3 — OCR boundaries and review tool-usage visibility
+
+Status: repository complete; external stable delivery pending
+Release classification: `release-required`
+Target stable version: `0.8.3`
+Repository completion date: 2026-08-26
+
+### Goal and delivered scope
+
+Deliver the priority 0.8.3 hotfix without changing OCR 1.10.0, DLP, receipt v5,
+posting transactions, severity, findings, telemetry ownership, or automatic
+approval. Compatibility publication now follows the actual qualification
+outcome, recovers through a closed status independently of invalid support
+metadata, and publishes its bounded issue/artifact before restoring a red job.
+The GitLab example delegates max-tools ownership to installed OCR with sentinel
+`0`; exact behavior-based qualification distinguishes OCR's reported
+normalization target `50` from its template-owned effective loop value `100`.
+
+The existing GitLab `all OCR tool calls` line now shows every non-zero admitted
+counter from the fixed nine-tool review set, sorted by count and name. Those
+counts describe activity only: OCR 1.10.0 does not report per-tool token use,
+and raw arguments, results, paths, IDs, unknown names, and dynamic external MCP
+tool names remain private. Both macOS endpoint jobs continue to run as advisory
+diagnostics; all Linux, coverage, quality, security, dependency, package, and
+CodeQL gates remain release-blocking.
+
+### Decisions and non-claims
+
+- Issues #139, #140, #142, and #143 are the complete tracked release set.
+- OCR remains checksum-pinned to 1.10.0; current numeric behavior belongs to the
+  installed OCR and is qualified behaviorally rather than copied into toolkit
+  configuration constants.
+- A recognized max-tools normalization becomes a toolkit-authored operator
+  notice only. Raw stderr and the notice do not enter results, DLP, receipts,
+  telemetry, lifecycle commands, findings, severity, or approval decisions.
+- No local real-LLM/provider review or separate qualification receipt was run or
+  claimed. Deterministic exact-OCR no-model probes and a controlled local peer
+  cover the process boundary; protected hosted and release gates cover delivery.
+- macOS support metadata is unchanged. Advisory endpoint failures remain visible
+  for follow-up but cannot delay a Linux-priority hotfix release.
+
+### Repository and hosted evidence
+
+- Final feature head `6520a53db6b4f9d907735456be43e0b17ec296af`
+  passed all 13 hosted checks with no review threads. PR #141 was squash-merged
+  as verified commit `74b3f46f72f1d6231c44cc39ca12f732a46da706`;
+  reviewed and merged tree are both
+  `6ab22194ecb44329a7b89be918c4c5afb8f8daf7`.
+- The final local gate passed 1,275 tests plus 324 subtests at 86.35% combined
+  branch coverage. Risk groups passed at 84%, 82%, 86%, and 87% against floors
+  80%, 80%, 85%, and 85%; Ruff, strict MyPy, Bandit, Gitleaks, lock validation,
+  OCR manifest validation, Towncrier draft, and diff review also passed.
+- Development workflow run 32946899220 published `0.8.3.dev72`. Independent
+  TestPyPI readback matched wheel SHA-256
+  `892c8662a1e797940b1fd7587fcde7ba8e2c0e8bee437f71c3592bdafdce745a`
+  and sdist SHA-256
+  `920264937ba787341e468121d52e83cd945f669c4995eb72f1612d0adb49df00`;
+  provenance and clean wheel/sdist installs passed.
+- The live protected-main ruleset retains ten required Linux/non-platform
+  contexts and omits only the two macOS endpoint contexts. Workflow source keeps
+  three Linux jobs blocking and both macOS endpoint jobs running with explicit
+  advisory status.
+
+### Stable delivery handoff
+
+The release PR is the final repository mutation. External closure remains
+pending until its exact reviewed head is squash-merged and the stable workflow
+is independently reconciled across TestPyPI, PyPI, workflow artifacts, and the
+immutable GitHub Release. Closure requires byte/hash equality, PEP 740
+provenance and GitHub attestations, annotated `v0.8.3` tag readback, Python
+3.12-3.14 wheel/sdist install and CLI smoke, Actions-owned receipt comments,
+closed #139/#140/#142/#143, closed milestone `v0.8.3`, and clean synchronized
+local `main`.
+
 <a id="plan-toolkit-0-8-2"></a>
 
 ## Repository-Complete Plan: v0.8.2 OCR 1.10.0 and review effort

@@ -7,7 +7,7 @@ default:
 
 variables:
   OCR_VERSION: "v1.10.0"
-  OCR_TOOLKIT_VERSION: "0.8.2"
+  OCR_TOOLKIT_VERSION: "0.8.3"
   OCR_TOOLKIT_CHECKSUMS_URL: "https://github.com/xeonvs/open-code-review-toolkit/releases/download/v${OCR_TOOLKIT_VERSION}/SHA256SUMS"
   OCR_SHA256: "f8f99ea071bed77dbcaa15fdd2083287bb8ae408d5928b3943ebe0788d191b6b"
   OCR_POST_MODE: "draft"

@@ -473,10 +473,10 @@ def test_ocr_compatibility_workflow_is_bounded_and_protected() -> None:
     for contract in (
         "OCR 1.9.9 — inherited predecessor",
         "OCR 1.9.10 — toolkit 0.8.0 target and 0.8.2 predecessor",
-        "OCR 1.10.0 — toolkit 0.8.2 target",
+        "OCR 1.10.0 — toolkit 0.8.2 and 0.8.3 target",
         "ocr.llm-retry-report/v1",
         "not toolkit telemetry",
-        "Deploy toolkit 0.8.2 directly with OCR 1.10.0",
+        "Deploy toolkit 0.8.2 or 0.8.3 directly with OCR 1.10.0",
         "max_completion_tokens=16384",
         "do not install OCR 1.9.10 as an intermediate step",
     ):