The versioned support contract lives in compatibility/ocr-support.json. Schema v2 records the recommended OCR version, every tested or observed release, exact upstream asset digests, normalized evidence hashes, and a rolling runtime window. The newest two qualified major/minor lines are supported; the preceding line is deprecated and emits a warning. Earlier lines and patches absent from the qualified manifest are rejected. monitoring_floor controls release discovery only and never grants runtime support. The toolkit package never downloads OCR; deployments keep using an explicitly pinned, checksum-verified binary.
Live qualification runs one forward-only probe implementation and validates its
observations against the consumed review contract owned by the candidate epoch.
Historical evidence before the suite boundary uses frozen expectations from
scripts/ocr_compat_history.py. Fresh qualification of a frozen epoch is refused
before downloads or binary execution; frozen readback never supplies executable code. Generic promotion tests
use a frozen baseline. See
qualification maintenance.
Historical readback is not promotion authority: every newly promoted candidate
must provide the current evidence schema and its complete version-selected
consumed contract. The current epoch includes explicit reasoning wire capture and
the current built-in language/test-exclusion inventory.
The OCR compatibility workflow qualifies stable upstream releases newer than
the manifest monitoring floor. Exact-tag manual dispatch is the
single-candidate path. A manual
through_tag instead qualifies the complete contiguous unseen
chain only through that exact stable release, preventing a scoped maintenance
run from absorbing a newer upstream release. The two inputs are mutually
exclusive. Drafts, prereleases, non-semantic tags, missing ceilings, unexpected
asset sets, oversized metadata or downloads, redirects outside the reviewed
GitHub origins, and checksum disagreement fail closed. Every binary digest must
agree with both GitHub release metadata and the upstream sha256sum.txt.
Candidate execution uses the verified Linux amd64 binary on an Ubuntu runner. The harness checks the reported version, the CLI flags consumed by the GitLab integration, range preview behavior, an actual JSON review through a deterministic local gateway, an aggregate-budget review that must preserve completed findings and emit budget-attributed partial coverage, and the additive JSON fields consumed by posting. Toolkit-managed numeric OCR options are also exercised at omitted/default, sentinel, invalid-below-boundary, minimum minus one, minimum, representative, and maximum edges when bounded. The evidence records closed outcomes, recognized diagnostics, normalization, ownership, and effective values observed through real loop behavior; CLI help text is not accepted as runtime evidence. The harness also requires JSON preview without a session-store side effect and proves that additive comment thinking is accepted but not published to GitLab. Upstream source review separately verifies how OCR derives that field; the toolkit probe does not claim to reproduce a provider's private reasoning channel. Evidence permits unknown new fields but requires the fields the toolkit reads. Legacy result statuses and the versioned ocr.run-manifest/v1 outcome are normalized through one shared toolkit contract; manifest coverage sets, failure classifications, terminal state, and budget attribution must agree before a result can be published.
Built-in MCP qualification follows the protocol revisions supported by the recommended OCR release's exact MCP SDK. The current recommended release uses Go MCP SDK v1.7.0 and initiates revision 2025-11-25; the evidence server also retains 2025-06-18, 2025-03-26, and 2024-11-05 for qualified older clients. For an unknown client revision the server follows MCP negotiation semantics by returning its current supported revision, leaving acceptance or termination to the client. Qualification exercises initialize, the initialized notification, ping, tool discovery, and bounded summary/list/get calls through the exact SDK rather than relying only on handcrafted JSON-RPC fixtures.
The built-in stdio entry uses the toolkit's current absolute Python executable in isolated mode. OCR therefore does not depend on PATH lookup, and untrusted repository modules cannot shadow the installed toolkit when the MCP subprocess starts.
Candidates then take one of two lanes:
Before selecting a lane, classify every upstream changelog item as a toolkit-consumed contract change, a demonstrated future-backlog impact, or release-note-only context. For each added capability, record whether the toolkit consumes it, which runtime or CI boundary it can affect, whether adaptation is required, and which source/probe supports that conclusion. Only consumed contracts justify toolkit code or release scope; a new upstream capability does not create roadmap work unless the toolkit has a demonstrated need for it. If qualification requires a CI behavior change beyond version and checksum pins, record that impact in its own Towncrier fragment rather than hiding it inside the compatibility-version entry.
Classify a pin-only promotion and its machine or human qualification evidence as Maintenance. If the qualification exposes an existing toolkit incompatibility and the delivery corrects it, classify that outcome as a Bug Fix. If the toolkit begins exposing or consuming an upstream capability, classify that outcome as a Feature. Effective built-in rule or reviewable-file changes remain Rules even when they arrive with an otherwise maintenance-only OCR promotion.
automatic-safe: only an adjacent patch in the already-tested major/minor line, with every probe passing and maintenance-only release notes containing no material compatibility signal. When several releases are discovered together, each keeps the manifest recommendation as its tested baseline but is classified against its adjacent predecessor. The aggregation job prepares one cumulative compatibility patch only when the complete sequence is contiguous and every member is automatic-safe. The patch covers the manifest, evidence, runtime preflight version, and GitLab example version/checksum. It never writes directly tomain.human-review-required: every minor/major release, skipped or non-increasing patch, changed or failed contract, feature-bearing release, material/security/deprecation/config/provider signal, or ambiguous release notes. The workflow creates or refreshes one qualification issue with machine evidence, a bounded plain-text release-change excerpt, and a human checklist.
Each OCR version owns one stable HTML marker and one qualification issue. The workflow performs a single upsert through bounded direct issue listing rather than GitHub's eventually consistent search index. Historical issues closed with the duplicate label remain as incident evidence but do not compete for canonical identity. Any other duplicate state fails closed instead of creating another issue; after operators select and reconcile the canonical issue, reruns update it in place.
The qualification step writes evidence, public issue text, and its closed status through same-directory atomic replacements. The step outcome is authoritative: a successful step publishes validated evidence, while a failed step publishes only the closed failure status even if retained evidence exists from work completed before the failure. Status-based recovery validates no support manifest because it does not consume support metadata. The workflow publishes the issue and diagnostic artifact before restoring the failed job outcome; dependent aggregation and promotion jobs therefore remain blocked. Raw exceptions and subprocess output stay in the private job log and never enter the status or issue projection.
Evidence records optional capabilities separately from required compatibility. OCR 1.8.7 and later expose per-run provider/model overrides and additive llm result identity; older tested releases remain valid without these fields. OCR 1.9.4 additionally prints its session ID only in human-readable terminal summaries; JSON output and the toolkit-consumed result contract are unchanged. OCR 1.9.5 makes the existing aggregate budget flag visible in scan JSON, while the toolkit remains on review and separately qualifies that review's partial manifest, completed findings, and budget-attributed coverage. OCR 1.9.8 adds Bedrock as an upstream provider, moves human-audience JSON/SARIF progress to stderr, and changes only upstream skill guidance to consume native severity. The toolkit configures none of the Bedrock credential boundary, invokes review with agent audience, and already consumes the same tolerant structured severity/category result fields. Session identity and scan-only output remain OCR-owned signals rather than toolkit metrics. Profile or telemetry work must require the capability it consumes rather than treating the recommended version alone as proof.
OCR 1.9.9 was adopted and qualified for toolkit 0.7.1. It makes file background override inline background and names each static main-loop stop trigger in the failed-item reason. The toolkit therefore rejects caller --background and --background-file inputs and supplies only its own evidence bootstrap file. The new reason literals remain bounded data inside the existing ocr.run-manifest/v1 failed-item contract: retention, publication projection, DLP, and posting diagnostics already preserve or redact that field without deriving authority from its prose. Expanded upstream provider tool_choice tests do not change a consumed wire contract. Its evidence remains historical and does not require an intermediate 1.9.9 installation when deploying toolkit 0.8.0.
OCR 1.9.10 is the historical exact toolkit 0.8.0 and 0.8.1 dependency. Its terminal retry summary groups noteworthy requests by review stage, but JSON retains the unchanged structured ocr.llm-retry-report/v1; the OCR result and ocr.run-manifest/v1 contracts are unchanged. The report remains private OCR diagnostics and is not toolkit telemetry, a DLP or receipt input, finding evidence, a severity input, an outcome signal, or an automatic-approval signal. The upstream background-compression join and safe resume-checkpoint changes apply to ocr scan; the toolkit invokes ocr review. The VS Code merge-file change is outside the toolkit contract. With no toolkit completion-cap override, the qualified OpenAI wire request used max_completion_tokens=58888.
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 was the only version accepted by toolkit 0.8.2 and 0.8.3 preflight and pinned by their published 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.
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. Qualification also proved that an explicit positive override reaches the wire; operators must select its value from their provider/model contract rather than a toolkit recommendation.
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 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.
OCR 1.10.1 is the historical version accepted by toolkit 0.8.4 preflight and pinned by its published GitLab example. Hosted Linux and independent Darwin arm64 qualification preserve the OCR result and ocr.run-manifest/v1 contracts, inherited OpenAI completion cap 16384, explicit 4096 override, default-medium two-round behavior, and effective max-tools values from 1.10.0. The --max-tools help text advertises a lower minimum, but actual CLI behavior still normalizes 49 to 50, the embedded template keeps effective 100, and explicit 101 raises it; the toolkit uses those behaviorally observed values and keeps the example on sentinel 0.
Toolkit 0.8.4 reduces an exact accepted soft background diagnostic to the private numeric ocr.toolkit-advisory/v1 projection after publication DLP. It is rendered only with a valid receipt v5 in GitLab Technical details and does not enter OCR warnings, coverage, DLP counts, telemetry, or automatic-approval inputs. Raw OCR output cannot supply the reserved field; duplicate, extended, unknown, malformed, or unbound forms fail closed.
The release bounds private session task/cache keys to 64 characters. Those values remain OCR-owned private routing data and do not enter toolkit telemetry, receipt v5, findings, fingerprints, lifecycle commands, or approval. OCR also adds .m to its reviewable allowlist and resolves MATLAB versus Objective-C from file content so the corresponding built-in rules can be selected. The upstream repository-local providers.go rule is not part of the toolkit-wide rules contract.
The upstream GitHub Action, delegate skill, npm launcher, and built-in provider preset are not consumed. The toolkit downloads the native binary in its GitLab example and writes an explicit protocol and provider configuration, so these changes add no implicit provider selection or CI execution path.
Deploy toolkit 0.8.4 directly with OCR 1.10.1. The public Linux amd64 example verifies SHA-256 8b806c221d409727a21611b4a7952d8e15edadbbc25f5affccaeb8f677e4055c; the local Darwin arm64 artifact verifies 8fc24bd825c9d918b894be05c0cf27fac8d30bc549257c812d87337167c7563c, and the upstream sha256sum.txt verifies ec72bda51f1227f412ee00602d952868efc57d847cce0ae1586fb97069d4139d.
OCR 1.10.2 is the historical version accepted by toolkit 0.8.5 preflight and pinned by its published GitLab example. Hosted run 33055459209, canonical issue #151, adjacent source review, and checksum-verified isolated Darwin checks preserve the OCR result, ocr.run-manifest/v1, default-medium two-round review, effective max-tools, completion-cap override, DLP, receipt v5, telemetry ownership, and approval contracts.
OCR now records grouping tasks and grace-round requests in its private session/retry state. The grouping request uses the review template's inherited OpenAI completion cap 16384 instead of the separate 4096 used by the predecessor; an explicit positive OCR_LLM_MAX_COMPLETION_TOKENS still overlays every protocol request. Its value remains deployment-owned. These private task records and group/path values do not enter toolkit findings, GitLab text, receipts, DLP signals, telemetry, or approval inputs.
Solidity (.sol) and Vyper (.vy) join the effective built-in Rules and reviewable-file contract. The upstream session-comparison command is not invoked by the toolkit. Upstream reusable GitHub Action checkpoint ranges cover only that Action's range selection; the GitLab toolkit keeps its own immutable range/snapshot and publication lifecycle, so the change only partially overlaps BL-021 and does not activate or complete a second forge adapter.
The hosted qualification initially labelled the patch automatic-safe because maintenance keywords masked the Features section. Human review overrode that result, and the classifier now treats feature-bearing patch notes as material so they require the human lane.
Deploy toolkit 0.8.5 directly with OCR 1.10.2. The public Linux amd64 example verifies SHA-256 e9205614f80e009ee7b1f444c9da08486fb9ff6db022954fe9203d923ab720b2; the independently checked Darwin arm64 artifact verifies 74fc7bcc0e6d0790c5ca033fd82a5474b6f05d443ed51a26a6f61c0cac6589fd, and the upstream sha256sum.txt verifies b5176aaa04a7f00bd84dd61556ca29e6cbdfcfe64cc50af6653163d9be4e7654.
OCR 1.11.0 is the only runtime version accepted by toolkit 0.8.6 preflight and pinned by its GitLab example. OCR 1.10.2 remains a strict comparison baseline for the grouping-inventory transition and is not a supported fallback. Hosted run 33158664020, canonical issue #155, adjacent source review, and checksum-verified evidence preserve the OCR result, ocr.run-manifest/v1, inherited OpenAI completion cap 16384, support for an operator-selected positive completion-cap override, default-medium two-round review, receipt v5, DLP, toolkit telemetry, summary, and approval contracts. The toolkit leaves that override unset and does not recommend a provider-specific value.
The private grouping and other-files prompts now use status-first STATUS path (+N/-M) inventory entries. Repeatable qualification accepts the old path (STATUS, +N/-M) shape only for historical OCR 1.10.0 through 1.10.2 and the new shape from OCR 1.11.0 onward; the 1.11.0 promotion compares the adjacent 1.10.2 and 1.11.0 evidence. Mixed, duplicate, reordered, malformed, status-inconsistent, truncated, or churn-losing evidence fails closed. Production toolkit code consumes neither format. file_find now supports repository-relative subpaths and both slash styles. The built-in allowlist and Rules add Handlebars (.hbs) and Mustache (.mustache). OCR's base subtask timeout is now 15 minutes and scales linearly with low/medium/high review rounds to 15/30/45 minutes, so the GitLab job allows 45 minutes.
OCR 1.11.0 preserves provider-native reasoning across assistant turns, removes the filter's forced tool_choice, and retains readable reasoning plus signed or encrypted native replay payloads inside the OCR session. The toolkit does not consume that state: its isolated session home is removed before publication, and reasoning, native payloads, and request controls cannot enter findings, GitLab notes, receipt v5, DLP counters, toolkit telemetry, tool/token summary, or approval inputs. Explicit operator-owned OCR_LLM_EXTRA_BODY.tool_choice remains distinct from OCR's removed forced filter value and is not published.
The release corrects stale --max-tools help text; max-tools runtime behavior is unchanged from the behaviorally qualified 1.10.2 baseline. Omitted and sentinel 0 select template default 100; 1-49 reports normalization to 50, while normalized 50 and explicit 50 remain effectively 100; only a value above 100 raises the effective cap. The toolkit's closed normalization notice remains diagnostics-only and cannot affect findings, completeness, receipt, DLP, telemetry, lifecycle, or approval.
Upstream GitHub Action, OpenCode plugin, npm launcher, Korean documentation, built-in provider presets, and interactive provider-validation changes are not toolkit execution paths and are not claimed as toolkit behavior.
Deploy toolkit 0.8.6 directly with OCR 1.11.0; do not install 1.10.2 as an intermediate version. The public Linux amd64 example verifies SHA-256 13f68cc2eca1a36d42140e9d37797b68fea5cbbf4b6345ec01ec1b06910fab60; the independently verified Darwin arm64 artifact uses ac8bf5a0fcd176bb9dcc15b169e90f4b52bf32787adef17a850489dbed97fb78, and the upstream sha256sum.txt verifies 9dff050ec859882bef26037415b8bd9e5db70c5a7d960e5eb3989385372311ee.
OCR 1.11.1 is the only runtime version accepted by toolkit 0.8.7 preflight and pinned by its GitLab example. OCR 1.11.0 is an adjacent historical comparison, not a supported fallback. Hosted run 33400677367, issues #158/#163, strict schema-v3 evidence, source review, and an independent checksum-verified Darwin no-LLM probe preserve the OCR result and manifest, inherited completion cap 16384, explicit positive completion-cap transport, default medium effort, effective max-tools, private reasoning/session boundary, DLP, receipts, summary, and approval authority. The toolkit default remains unset; qualification does not recommend a provider-specific cap.
Small change sets now skip the grouping LLM. A single file stays per-file; two below-threshold low-churn files use one local small change set group; two files above the 200-line aggregate threshold stay per-file. Four files cross the default file threshold and retain the status-first grouping inventory and semantic grouping request. Qualification proves these paths separately so a local bundle cannot silently weaken the three-item partial-budget test. The local grouping decision is OCR telemetry only; path-derived group keys and model labels do not become toolkit telemetry or public data.
OCR still labels review-filter survivors as Previously Confirmed Findings in a later round even though survival is not independent validation. Toolkit 0.8.7 therefore states in its mandatory, unclippable background prefix that prior/filter-surviving findings remain unverified and must be re-checked against current code, tests, and trusted evidence. Exact-binary qualification proves that instruction is present in every main request across the two default rounds. The toolkit does not parse finding prose, invent a validation status, or let survival change severity, suppression, lifecycle, or approval; external configured qualification remains responsible for demonstrating model correction when trusted evidence contradicts an earlier report.
The project rule.json layer now confines the file itself and referenced rule files to the canonical repository root after symlink resolution. Operator-supplied global or explicit rule files keep their existing trusted boundary. Built-in review coverage adds Pug (.pug), Verilog/SystemVerilog (.v, .vh, .sv), and VHDL (.vhd, .vhdl) allowlist and Rules behavior. OCR 1.11.1 does not select .svh; qualification records that boundary explicitly. Selected session files now come from immutable manifest coverage rather than internal pseudo-sessions. Viewer, upstream Action/skills/site documentation, and presentation-only telemetry documentation changes do not create toolkit runtime behavior.
Deploy toolkit 0.8.7 directly with OCR 1.11.1. The public Linux amd64 example verifies SHA-256 1cdc7d1f776f1cdb69850130b930e40f64accc86ecaf09600573b3600456322f; Darwin arm64 verifies 5fdf72e51aae021ac7bf43d7b9dcb160f04880f623c66e8ada5e6ae5a92e172c; and upstream sha256sum.txt verifies 8760d31184c12f947c182fcb00114730707892524ddf1beac78fc415cb61b37b.
OCR 1.11.2 was the initial runtime qualified during toolkit 0.9.0 development and is the adjacent predecessor for final 1.11.3 qualification. It is not accepted by the final 0.9.0 preflight. Hosted workflow 33508349494, issue #170, strict schema-v3 evidence, direct adjacent source review, and an independent checksum-verified Darwin arm64 no-LLM probe preserved the then-current OCR result and manifest schemas, inherited completion cap 16384, explicit positive completion-cap transport, default medium effort, effective max-tools, private reasoning/session boundary, receipt v7, DLP, toolkit telemetry ownership, and approval authority. The toolkit default remained unset; qualification did not recommend a provider-specific cap.
Built-in language selection now routes JavaScript modules (.mjs, .cjs) through exact pattern **/*.{ts,js,tsx,jsx,mjs,cjs} and C++ sources and headers (.cxx, .hxx) through exact pattern **/*.{cpp,cc,cxx,hpp,hxx}. Qualification proves all four files are selected, resolves their Rules from System built-in, and preserves the established Pug, Verilog/SystemVerilog, and VHDL coverage. .svh remains excluded as unsupported_ext rather than being inferred from the SystemVerilog name.
The viewer URL-opening change is outside the toolkit execution path. Remote-MCP setup and localization changes are documentation-only, and the nested pages/go.mod boundary only excludes documentation-site node_modules from upstream Go package enumeration. None changes the toolkit's MCP composition, provider transport, publication, receipt, or approval contract.
The historical 1.11.2 Linux amd64 evidence verifies SHA-256 fad3c62314478822c1e90f858f3e06b3f8dc5ff0034933927c3ecd7faa5d3731; Darwin arm64 verifies 8c1a58cacca6d82d4616f121e07bd7c586a2e6c88d5b6688e3bfedf135d17ff4; and upstream sha256sum.txt verifies 1d997d5ced335750e50df8af0d8a0ec8b9978937d1f26047b0a2114b7a8fa9e1. Use the final 1.11.3 section below for toolkit 0.9.0 deployment.
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.
An automatic-safe result is not an automatic stable release. It must still pass a normal protected compatibility PR and a separate signed stable-release PR. If a dedicated OCR update bot credential is not configured, the workflow publishes the exact patch as an artifact and records the resume action in the issue; the default GITHUB_TOKEN is intentionally not used to create a PR that would fail to trigger the full protected workflow set.
OCR 1.11.3 supersedes 1.11.2 as the sole runtime accepted by toolkit 0.9.0 preflight and pinned by its GitLab example. Hosted workflow 33725971286, issue #172, checksum-verified schema-v3 evidence, adjacent v1.11.2...v1.11.3 source review, independent Darwin arm64 checksum/version readback, and deterministic toolkit boundary tests preserve the qualified result, manifest, language-selection, inherited completion cap 16384, explicit positive completion-cap transport, effort, max-tools, and immutable-range contracts. The toolkit default remains unset and qualification does not recommend a provider-specific cap. No additional semantic OCR run was used for this promotion.
The new opt-in upstream raw-traffic capture is never inherited by a toolkit-owned OCR preview or review child: OCR_RAW_LOGGING is removed while the remaining validated provider environment is preserved. OCR's new failure, failure_by_tool, and failure_details fields are additive diagnostics rather than review authority. The toolkit validates their complete bounded shape, renders valid details only to credential-redacted control-safe local/CI stderr, and never persists dynamic details or per-tool failure maps in the finalized result, receipt, GitLab comments, or toolkit telemetry. Absent, malformed, non-zero, hostile, or action-receipt-conflicting diagnostics cannot discard a valid manifest, findings, summary, or posting transaction. Receipt v8 retains only a closed absent|verified|invalid|conflicting state plus a bounded aggregate count for verified; action receipt v3 remains authoritative for completed evidence. Uncertain or non-zero diagnostics can block a separate later action without suppressing publication. The canonical branches are shown in the review decision flow.
Upstream SIGTERM handling is compatible with the toolkit's termination masking and cleanup boundary. Untracked-file listing error propagation affects OCR workspace discovery, while the production GitLab path supplies immutable explicit --from/--to refs. VS Code dependency updates are not consumed. Built-in language routing remains the exact ten-extension set qualified for 1.11.2, with .svh still excluded.
Deploy toolkit 0.9.0 directly with OCR 1.11.3. The public Linux amd64 example verifies SHA-256 9726204ac81baee153fd65b1ff357c380f73e9d8091c4a73c3c9fb541b5164cb; Darwin arm64 verifies 515cd92ce300b62dea2bcaf53e910cdf57b681e1d58bbd0a9e8e49617bca52fa; and upstream sha256sum.txt verifies 472a3ce64834f4909bc9fac50e6de08a3c8ef5c0489b755dd1d2b19c14c8792e.
OCR 1.11.4 adds raw arguments to failed-tool details. The toolkit accepts that
optional field only as an opaque string up to 32768 characters and 131072 UTF-8
bytes, then omits it from normalized diagnostics before publication DLP. It cannot
enter toolkit console output, finalized results, receipts, GitLab notes, or toolkit
telemetry. Raw OCR stderr remains a private artifact. Invalid diagnostic shape or
bounds preserve a valid review publication and only affect the independent
later-action decision under existing receipt v8 rules.
The native code_comment parser can recover serialized batches with damaged
escaping. Controlled real-binary probes verify native arrays, serialized arrays,
intact repaired comments/anchors/suggestions, rejection of suspect truncation,
and the ordinary comment_args_repaired warning. The toolkit does not implement
another repair parser or treat a repair as independent finding validation.
Objective-C++ .mm files use Objective-C rules; .m retains content-dependent
MATLAB/Objective-C routing. Documentation-site headings and plugin distribution
guardrails are upstream-only changes.
Deploy toolkit 0.9.1 directly with exact OCR 1.11.5; an intermediate 1.11.4
installation is unnecessary. The two releases retain separate adjacent source
audits and evidence. Assets were verified by hosted run 33962853525; expanded
contract evidence explicitly identifies checksum-verified Darwin arm64 probes.
Final hosted qualification and configured external model qualification remain
distinct proofs.
The grouped-review refactor preserves runtime behavior: concurrency counts groups,
the conversation prompt ceiling applies per group, and large-diff preselection
still checks each file separately. A diagnostic file_path may be a group key;
it is not a validated GitLab file location. The inherited completion cap remains
16384, an explicit positive override is still supported, default effort stays
medium, and max-tools retains template-default semantics. No public environment,
receipt v8, action receipt v3, summary, or approval contract is added.
The binary updates grpc to 1.83.1; fast-uri and browserslist changes belong to the upstream VS Code extension. Viewer fixed/ignored marks are browser-local state and do not resolve or suppress GitLab findings. No viewer state is consumed by toolkit.
Linux amd64 SHA-256: 53a4ab7c8ce6dc07d5362c7c4984bf8d98b55e4e8d4c01b9399d488a2a983d95.
Darwin arm64: c041b03cc840957b52df28514e8dbb51f798e6cb1259d97555a41a2e3e3ccaf9.
Upstream checksum file: 0519c13b03d69dd6c4aa5470a8eb52727f5e3fd2ce43e5887d8a67cdf107aa1a.
Toolkit 0.10.0 recommends exact OCR 1.11.6. Hosted qualification
34218232310
verified every platform asset and the upstream checksum file, then passed the
complete current Linux amd64 suite. Independent checksum-verified Darwin arm64
probes passed the same consumed contracts. The committed evidence adds reasoning
wire checks for unset, explicit none and high in both OpenAI protocols,
including preserved Responses siblings. The capture peer rejects requests without
model execution: provider acceptance and actual application remain untested.
The adjacent eight-commit review identifies consumed OCaml/ReasonML allowlist and built-in Rules additions plus Kotlin script routing and default test exclusions. They are separately classified as Rules. Native HTTP header timeout changes retain the request timeout plus upstream margin without a new toolkit API. The toolkit does not execute the upstream Action, Node/editor launcher or viewer; its reasoning and progress controls are owned by the shared toolkit execution path.
Historical 1.11.4/1.11.5 evidence remains unchanged. New promotions require the complete version-selected contract even when historical evidence is still readable. This qualification does not establish stable toolkit delivery or configured GitLab/local/debug model quality; those remain separate gates.
The qualification validator freezes the unchanged OCR 1.11.6/1.11.7 contract as
one historical epoch. From OCR 1.11.8 onward, the live language/Rules probe also
requires a representative policies/authz.rego file to select exact built-in
pattern **/*.rego. Both manifest validation and cumulative promotion use this
version-selected owner, so missing Rego proof fails before any evidence or pin is
written. The historical live probe also keeps the next-epoch Rego path as an
explicit unsupported control, so the frozen projection cannot hide unexpected
early admission.
Toolkit 0.10.1 recommends exact OCR 1.11.9. Bounded hosted run
34710401633
qualified the adjacent 1.11.7, 1.11.8 and 1.11.9 chain from the exact feature
head. Every platform asset and upstream checksum file matched; Linux amd64 passed
the complete no-model deterministic suite. OCR 1.11.7 retained the frozen
pre-Rego contract, including an explicit unsupported Rego control. OCR 1.11.8
and 1.11.9 selected policies/authz.rego through exact built-in pattern
**/*.rego and passed the current 17-language contract.
OCR 1.11.7 atomic output, bounded MCP shutdown, second-signal exit and
timeout_sec changes do not alter toolkit-owned output, subprocess or
configuration boundaries. OCR 1.11.8 adds the consumed Rego rule; its stream
usage override remains operator-owned, while scan preview is outside the
toolkit review path. OCR 1.11.9 aligns review preview with execution selection;
the DeepSeek model and viewer comparison page are not consumed. The result,
manifest, budget, reasoning, comment, DLP, posting, receipt and approval
contracts remain compatible. Stable toolkit delivery and configured model
quality remain separate release gates.
Toolkit 0.11.0 recommends exact OCR 1.12.7. The complete adjacent chain from
1.12.0 through 1.12.7 has checksum-verified manifest entries and current
version-selected evidence. OCR 1.12.0 changed semantic-grouping exchange from
paths to integer file indices; the toolkit qualification parser and deterministic
gateway validate those indices and preserve final path/group membership. Later
patches retain the consumed range, preview, manifest, suggestion, provider,
language and result contracts recorded in their evidence. OCR 1.12.7 adds the
default **/test_*.py exclusion; qualification proves the exact pytest-style
path is excluded while neighboring contest_*.py and test_*.go controls remain
reviewable.
Toolkit 0.11.1 recommends exact OCR 1.12.9. Bounded hosted run
35831453766
qualified the adjacent 1.12.8–1.12.9 chain with verified upstream assets and
deterministic Linux probes. OCR 1.12.8 adds built-in F# Rules for .fs, .fsi,
and .fsx; its default selection excludes paths matching *Test.fs and more
dependency and generated-output paths. The qualification probes cover those
selection contracts. OCR 1.12.9 retains the toolkit-consumed invocation,
selection, result, and manifest contracts. Source review and hosted probes do
not establish configured provider/model finding quality.
At toolkit 0.11.1, runtime support was rolling and exact-patch-only. Qualified 1.11.x and 1.12.x
entries are supported, qualified 1.10.x entries are accepted with a deprecation
warning, and earlier or unqualified patches fail preflight. Historical evidence
remains readable without widening current execution support. For toolkit 0.11.1, the manifest's
monitoring_floor: 1.12.9 made release discovery start above that tag; it is
not a minimum accepted runtime and cannot silently admit an unseen patch.
The toolkit 0.11.1 GitLab example pinned v1.12.9 and its Linux amd64 SHA-256. Deployments
must still verify the exact platform asset against the matching manifest entry.
The compatibility chain establishes deterministic toolkit boundaries, not
configured provider/model quality or stable toolkit delivery.
Toolkit 0.11.2 recommends OCR 1.12.11 and advances discovery above that qualified tag. The GitLab example pins its exact Linux amd64 checksum. Qualified runtime lines and the deprecation window remain unchanged.
The adjacent 1.12.10 evidence reuses successful hosted qualification. OCR 1.12.11
passed deterministic Linux amd64 qualification and independent Darwin arm64
probes. Its consumed change adds Jinja .jinja2 and .j2 file selection and the
built-in Rules pattern; qualification checks both. Earlier evidence remains
unchanged. OCR 1.12.10's removal of its legacy configuration-path environment
override does not change the toolkit integration, which does not set it. These checks establish deterministic toolkit
contracts rather than configured provider/model finding quality.
Toolkit 0.11.3 recommended OCR 1.12.13 after the bounded hosted
qualification chain
passed for both adjacent patches. Source review found provider/model and timeout
signals that the earlier classifier missed. The corrected classifier marks both
candidates human-review-required; their hosted probe observations are unchanged
and the manifest records explicit reviewed conclusions. These signals now block
automatic patch preparation until reviewed. Verified assets, required runtime contracts,
MCP, language selection and Rules remain compatible; the rolling support window
and historical evidence are unchanged.
OCR 1.12.12 allows unlisted per-run models for built-in providers, with a warning,
while preserving custom-provider constraints. The toolkit supplies an isolated
explicit llm configuration and retains its own model preflight, so this does
not relax toolkit configuration or model admission.
OCR 1.12.13 distinguishes request timeouts from task deadlines in diagnostic
reasons; both retain the structured timeout failure class. The toolkit preserves
these reasons as data, keeps partial/failed coverage semantics, and never treats
the prose as publication or approval authority. Focused regression cases verify
that neither reason implies clean or aggregate-budget completion. Scan-path
normalization and the README badge change are outside toolkit review execution.
No CI behavior, MCP SDK, public API or Rules adaptation is required. Hosted
qualification establishes deterministic contracts, not configured model quality.
Toolkit 0.12.0 recommends OCR 1.13.2 after one local Linux amd64 Docker qualification of each adjacent candidate, with verified upstream assets and the reviewed locked runtime graph. All three candidates require human review; the manifest records their source conclusions. Qualified 1.12.x and 1.13.x patches are supported, 1.11.x patches warn, and older or unqualified patches fail preflight. Historical evidence remains unchanged.
The shared max-tools probe observes the incomplete grace verdict in 1.13.0.
From 1.13.1, a successful grace-round task_done completes coverage and retains
the review_limit_reached warning; a no-task_done negative control stays
incomplete. OCR 1.13.2 adds PowerShell, Nushell, shader and OpenTofu selection
and built-in Rules, including exact extension/pattern checks. Earlier candidates
retain the previously allowed PowerShell script with the default rule.
The toolkit retains isolated explicit provider configuration. Optional native
ChatGPT authentication is separately enabled only for local review with OCR
1.13.2; the default local and GitLab API paths remain unchanged. See
local authentication. ACP is not adopted.
Deleted-file diff lookup remains bound
to the reviewed path. Scan-only prompt overflow, token-budget state and path
changes do not alter the toolkit's consumed review path.
A separate checksum-verified OCR 1.13.2 test reads synthetic MR intent through the production internal evidence MCP before using the real federation gateway to read a controlled tracker. Its deterministic model peer derives the lookup argument from returned MR data. This proves availability and routing, not natural model selection, private deployment behavior or configured model finding quality.
Hosted qualification run 39773385483
verified every upstream asset against its checksum list and passed the consumed
Linux amd64 preview, review, JSON result, budget, MCP, provider and numeric probes.
The adjacent source review confirms that OCR now follows all tools/list pages
for built-in and remote MCP discovery and reports an empty code_comment batch
as a tool failure so the model can retry. The toolkit still freezes its own
allowlists, admits tool use through its gateway, and validates the resulting
receipt; neither upstream fix grants a new toolkit authority or changes the
published result format. NixPkgs pkgs/ provider-directory detection affects
upstream selection only; the PR checkout policy fix affects upstream CI only.
There is no toolkit CI adaptation beyond version and checksum pins. The hosted
probe does not claim configured-model review quality. Native ChatGPT remains
local-only; final release review uses the checksum-verified Darwin arm64 binary.
Toolkit 0.13.1 uses this same qualified OCR 1.13.3 as a narrower changed-gitlink boundary. It verifies process-local Git projection, the full preview selection, and native manifest/source-artifact fingerprints against the original immutable range. This does not extend OCR review to submodule contents or qualify a later OCR version for partial repository coverage; other versions retain the no-model stop until separately proven.
Promotion changes recommended_version, advances monitoring_floor, adds the tested release and evidence, and updates every machine-readable or executable version/checksum pin. Never edit only one copy. Human-qualified candidates must record the compatibility conclusion and release-note impact; an automatic-safe candidate may also record a reviewed conclusion when it is delivered with a human-reviewed chain instead of using the generic machine conclusion. Conclusions may name only versions present in that promotion. A reviewed promotion may cross only one adjacent semantic-version boundary at a time: the next patch, the next minor at .0, or the next major at .0.0; minor and major transitions always require an explicit human conclusion. Automatic-safe preparation remains limited to adjacent patches in the already-tested major/minor line and retains the same protected review boundary even though the patch itself is mechanical.
Rollback selects a previously tested manifest entry, restores its runtime and executable-example pins, and travels through the same release-required path. Do not delete historical evidence: it explains the prior support decision and lets future qualification distinguish a rollback from an unseen release.