open-code-review-toolkit 0.2.0__tar.gz → 0.2.1__tar.gz

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/CHANGELOG.md

@@ -1,3 +1,14 @@
+## 0.2.1 - 2026-07-27
+
+### Features
+
+- Target Open Code Review 1.7.17 in preflight validation and the checksum-pinned GitLab CI example. ([#12](https://github.com/xeonvs/open-code-review-toolkit/issues/12))
+
+### Documentation
+
+- Document the durable toolkit strategy, milestone roadmap, and reconciled implementation backlog. ([#13](https://github.com/xeonvs/open-code-review-toolkit/issues/13))
+
+
 ## 0.2.0 - 2026-07-21
 
 ### Features

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: open-code-review-toolkit
-Version: 0.2.0
+Version: 0.2.1
 Summary: Unofficial GitLab CI integration layer for Open Code Review
 Project-URL: Homepage, https://github.com/xeonvs/open-code-review-toolkit
 Project-URL: Repository, https://github.com/xeonvs/open-code-review-toolkit
@@ -243,7 +243,7 @@ ocr --version
 ocr-ci --help
 ```
 
-The current compatibility target is OCR `1.7.14`. CI should pin the release and verify its published checksum before execution.
+The current compatibility target is OCR `1.7.17`. CI should pin the release and verify its published checksum before execution.
 Review output defaults to English. Set `OCR_REVIEW_LANGUAGE=Russian` to use Russian consistently in both OCR configuration and generated review context.
 
 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.
@@ -256,6 +256,14 @@ Suppression uses both the GitLab diff position and a stable finding fingerprint,
 
 Project-wide accepted tradeoffs can be recorded separately in `.opencodereview/accepted-decisions.md`; the context generator supplies them to OCR only when the current merge request is not changing that file. See [Accepted project decisions](docs/configuration.md#accepted-project-decisions) for the entry format, inline marker convention, security boundary, and limitations.
 
+## Project development
+
+The project is evolving from bounded background generation toward a shared Repository Evidence Engine: one deterministic evidence model will support both a compact OCR bootstrap and a built-in read-only MCP server. Development is ordered by outcomes and dependencies rather than speculative dates.
+
+- [Toolkit strategy](docs/engineering/toolkit_strategy.md) - durable product boundaries, architecture, invariants, and non-goals.
+- [Roadmap](ROADMAP.md) - milestone status, dependencies, outcomes, and completion signals.
+- [Backlog](docs/codex/TASKS_BACKLOG.md) - inactive implementation-ready work; active execution remains in `PLANS.md`.
+
 ## GitLab CI quick start
 
 1. Configure protected/masked `GITLAB_API_TOKEN` and LLM variables in GitLab.

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/README.md

@@ -15,7 +15,7 @@ ocr --version
 ocr-ci --help
 ```
 
-The current compatibility target is OCR `1.7.14`. CI should pin the release and verify its published checksum before execution.
+The current compatibility target is OCR `1.7.17`. CI should pin the release and verify its published checksum before execution.
 Review output defaults to English. Set `OCR_REVIEW_LANGUAGE=Russian` to use Russian consistently in both OCR configuration and generated review context.
 
 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.
@@ -28,6 +28,14 @@ Suppression uses both the GitLab diff position and a stable finding fingerprint,
 
 Project-wide accepted tradeoffs can be recorded separately in `.opencodereview/accepted-decisions.md`; the context generator supplies them to OCR only when the current merge request is not changing that file. See [Accepted project decisions](docs/configuration.md#accepted-project-decisions) for the entry format, inline marker convention, security boundary, and limitations.
 
+## Project development
+
+The project is evolving from bounded background generation toward a shared Repository Evidence Engine: one deterministic evidence model will support both a compact OCR bootstrap and a built-in read-only MCP server. Development is ordered by outcomes and dependencies rather than speculative dates.
+
+- [Toolkit strategy](docs/engineering/toolkit_strategy.md) - durable product boundaries, architecture, invariants, and non-goals.
+- [Roadmap](ROADMAP.md) - milestone status, dependencies, outcomes, and completion signals.
+- [Backlog](docs/codex/TASKS_BACKLOG.md) - inactive implementation-ready work; active execution remains in `PLANS.md`.
+
 ## GitLab CI quick start
 
 1. Configure protected/masked `GITLAB_API_TOKEN` and LLM variables in GitLab.

open_code_review_toolkit-0.2.1/docs/codex/TASKS_BACKLOG.md

@@ -0,0 +1,336 @@
+# Tasks Backlog
+
+This file contains implementation-ready future work derived from the [toolkit strategy](../engineering/toolkit_strategy.md) and ordered by the [roadmap](../../ROADMAP.md). Active execution belongs in `PLANS.md`; roadmap outcomes are intentionally not repeated here.
+
+Statuses are `ready`, `planned`, `parked`, `conditional`, or `owner action`. Release classification is an expectation to be confirmed when work is activated.
+
+## Existing backlog reconciliation
+
+| Previous item | Disposition | Result |
+| --- | --- | --- |
+| Native fuzzing campaign | Retained and revised | BL-019 connects fuzzing to the future evidence/MCP parser attack surface and keeps bounded CI and corpus ownership as activation requirements. |
+| OpenSSF Best Practices registration | Retained as owner action | BL-022 remains conditional on truthful owner attestations and is not a product-roadmap priority. |
+| Additional provider adapters | Retained, clarified, and reprioritized | BL-021 is explicitly about code-hosting and review-host adapters beyond GitLab, not repository ecosystem/framework evidence. |
+| File-based user configuration | Retained and redesigned | BL-020 waits for profile, MCP, and evidence schemas while preserving environment precedence and excluding secrets. |
+
+## M0 Foundation
+
+### BL-001: Add Bandit as a repository security gate
+
+- **Status:** ready
+- **Priority:** high
+- **Roadmap theme:** M0 Foundation
+- **Dependencies:** Existing isolated quality environment and security workflow.
+- **Activation trigger:** Strategy and backlog documentation is merged.
+- **Goal:** Detect high-signal Python security defects in the toolkit without turning analyzers into a downstream product capability.
+- **Scoped deliverables:** Add a development-only pinned Bandit dependency; scan `src/ocr_toolkit`; integrate concise execution with `scripts/quality.sh` and the repository security workflow; document narrow, justified suppressions.
+- **Acceptance criteria:** Local and CI scans use identical configuration, produce no unexplained findings, keep full logs out of agent context, and add no runtime dependency.
+- **Exclusions:** Scanning downstream repositories, auto-fixing findings, broad ignore lists, or treating Bandit as evidence supplied to OCR.
+- **Validation:** Positive and negative synthetic fixtures where configuration needs proof, complete quality gate, and security workflow dry run or equivalent command.
+- **Release classification expectation:** `no-release`, unless remediation changes user-visible behavior.
+
+### BL-002: Centralize OCR compatibility in a machine-readable manifest
+
+- **Status:** ready
+- **Priority:** high
+- **Roadmap theme:** M0 Foundation
+- **Dependencies:** Current recommended/tested OCR baseline and preflight checks.
+- **Activation trigger:** The next OCR compatibility change or before evidence MCP depends on an OCR capability.
+- **Goal:** Replace scattered exact-version assumptions with one reviewed compatibility and capability source.
+- **Scoped deliverables:** Define a dependency-free manifest for recommended/tested releases and required capabilities; centralize version/capability inspection; generate or validate documentation and CI pins from it; fail closed when required contracts disappear.
+- **Acceptance criteria:** Preflight, public examples, tests, and documentation agree with the manifest; additive version output remains tolerated; unknown or missing required capabilities fail with actionable errors.
+- **Exclusions:** Automatic production upgrades, downloading OCR, or supporting arbitrary historical releases.
+- **Validation:** Contract fixtures for supported, additive, malformed, and incompatible OCR outputs plus release-pin consistency tests.
+- **Release classification expectation:** `release-required`.
+
+### BL-003: Detect and test new upstream OCR releases
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M0 Foundation
+- **Dependencies:** BL-002.
+- **Activation trigger:** Compatibility manifest and capability inspection are stable.
+- **Goal:** Detect upstream changes quickly while keeping production upgrades review-gated.
+- **Scoped deliverables:** Add scheduled latest-release detection, checksum retrieval, changelog impact classification, and contract tests across the supported release set; create an actionable report or issue when review is required.
+- **Acceptance criteria:** Automation is bounded, uses official release metadata, distinguishes compatible/additive/breaking/unknown impact, and never edits production pins or publishes a release automatically.
+- **Exclusions:** Automatic merge, automatic recommended-version changes, or relying on mutable download URLs without digest verification.
+- **Validation:** Recorded synthetic release metadata, scheduled-workflow tests, and a no-change path that creates no noise.
+- **Release classification expectation:** `no-release`; subsequent compatibility bumps are classified separately.
+
+## M1 Evidence architecture
+
+### BL-004: Define the common repository evidence model
+
+- **Status:** ready
+- **Priority:** high
+- **Roadmap theme:** M1 Evidence architecture
+- **Dependencies:** BL-002 for capability-sensitive evidence.
+- **Activation trigger:** M0 planning sources are merged.
+- **Goal:** Give all collectors and projections one deterministic representation of repository facts.
+- **Scoped deliverables:** Define dependency-free evidence types for kind/value, source path, git ref, component scope, provenance, confidence, and optional staleness; specify stable ordering, deduplication, and global/per-kind bounds.
+- **Acceptance criteria:** Existing context facts can be represented without losing trust or origin; malformed and over-limit facts degrade explicitly; serialization is deterministic.
+- **Exclusions:** MCP transport, bootstrap prose, new ecosystem parsers, or network discovery.
+- **Validation:** Unit/property tests for normalization, ordering, bounds, provenance, and round trips using synthetic facts.
+- **Release classification expectation:** `release-deferred` until a user-visible projection ships.
+
+### BL-005: Build source/target snapshots and evidence deltas
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M1 Evidence architecture
+- **Dependencies:** BL-004 and existing bounded git-ref handling.
+- **Activation trigger:** The common evidence model is merged.
+- **Goal:** Describe base and head repository state without conflating declarations, resolved versions, and changes.
+- **Scoped deliverables:** Collect target/base and source/head snapshots, map changed files to components, and compute typed dependency/runtime/container deltas while preserving absent and unknown states.
+- **Acceptance criteria:** Target content is read from trusted refs, source-only changes cannot self-authorize policy, and added/removed/changed/unknown facts are reproducible.
+- **Exclusions:** Whole-history analysis, network package resolution, installed-environment probing outside configured evidence, or framework plugins.
+- **Validation:** Synthetic two-ref repositories covering additions, removals, renames, malformed manifests, missing refs, and bounded failure.
+- **Release classification expectation:** `release-deferred`.
+
+### BL-006: Separate collection, storage, planning, and rendering
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M1 Evidence architecture
+- **Dependencies:** BL-004 and BL-005.
+- **Activation trigger:** Current context output is characterized by regression fixtures.
+- **Goal:** Decompose `context/render.py` without changing trust or fail-closed behavior.
+- **Scoped deliverables:** Move collectors behind evidence interfaces, add bounded storage, isolate bootstrap selection, and retain a renderer compatible with the current background contract during migration.
+- **Acceptance criteria:** Existing public context behavior remains covered, collectors are projection-independent, and no bootstrap/MCP-specific duplicate collector path exists.
+- **Exclusions:** New parser breadth, changing the hard output limit, or enabling built-in MCP.
+- **Validation:** Golden synthetic context fixtures, regression tests for truncation/redaction/guidance, and complete quality gate.
+- **Release classification expectation:** `release-deferred` unless output behavior changes.
+
+### BL-007: Deliver the compact OCR bootstrap
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M1 Evidence architecture
+- **Dependencies:** BL-004 through BL-006.
+- **Activation trigger:** Evidence selection is independent from rendering.
+- **Goal:** Replace large background inventories with a trusted overview that guides OCR to detailed evidence on demand.
+- **Scoped deliverables:** Implement prioritized bootstrap planning for constraints, trust, refs, ecosystems/frameworks, material deltas, reference identifiers, MCP capabilities, relevant decisions, and guidance hints; target 1,500-2,500 characters while preserving the 7,950-character hard limit.
+- **Acceptance criteria:** Detailed manifests and external contents are absent; omissions and degradation are explicit; relevant high-priority facts survive tight budgets deterministically.
+- **Exclusions:** Raising the hard limit, copying full guidance, or embedding all dependency lists.
+- **Validation:** Budget boundary tests, deterministic golden fixtures, adversarial Markdown/redaction cases, and comparison with existing context scenarios.
+- **Release classification expectation:** `release-required`.
+
+### BL-008: Add the built-in read-only evidence MCP
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M1 Evidence architecture
+- **Dependencies:** BL-004 through BL-007 and current MCP validation.
+- **Activation trigger:** Common evidence storage and compact bootstrap are stable.
+- **Goal:** Let OCR retrieve bounded derived facts without duplicating its native repository tools.
+- **Scoped deliverables:** Register a reserved `ocr_toolkit_evidence` server by default; expose `ocr_toolkit_*` tools for environment, components, dependencies/deltas, frameworks, versions, and decisions; compose with external servers; reserve names and validate collisions.
+- **Acceptance criteria:** Server is read-only, root-constrained, deterministic, network-independent, command-free, bounded, and uses the same evidence store as the bootstrap.
+- **Exclusions:** Generic file reads, shell execution, GitLab access, external URL fetches, or documentation storage.
+- **Validation:** Protocol and composition tests, traversal/collision/adversarial-input tests, and synthetic OCR configuration integration.
+- **Release classification expectation:** `release-required`.
+
+## M2 Ecosystem and framework coverage
+
+### BL-009: Resolve lockfile, runtime, and container evidence
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M2 Ecosystem and framework coverage
+- **Dependencies:** BL-004 through BL-006.
+- **Activation trigger:** Snapshot and delta semantics are stable.
+- **Goal:** Distinguish declared constraints, locked, installed, runtime-detected, container-pinned, inferred, and unknown versions.
+- **Scoped deliverables:** Strengthen actual-use formats for Python, JavaScript/TypeScript, Go, PHP, Ansible, containers, and GitLab CI; implement source/target resolution and deltas with provenance.
+- **Acceptance criteria:** Each supported format has deterministic semantics and fixtures; conflicting sources remain distinct; malformed/oversized files degrade without network access.
+- **Exclusions:** Unused ecosystems, package-registry queries, arbitrary build execution, or treating declarations as resolved versions.
+- **Validation:** Per-format source/target fixtures, conflict and limit cases, and common evidence-model contract tests.
+- **Release classification expectation:** `release-required`.
+
+### BL-010: Establish framework evidence plugins
+
+- **Status:** planned
+- **Priority:** medium
+- **Roadmap theme:** M2 Ecosystem and framework coverage
+- **Dependencies:** BL-004, BL-005, and BL-009.
+- **Activation trigger:** At least two demonstrated repository use cases can share a plugin contract.
+- **Goal:** Expose framework identity, verified version, component scope, important configuration paths, and material deltas without building code graphs.
+- **Scoped deliverables:** Define a bounded plugin protocol and implement first providers chosen from demonstrated fixtures, prioritizing pytest, Ansible collections, and Molecule before broader candidates.
+- **Acceptance criteria:** Plugins cannot run arbitrary commands or network requests, use common evidence records, and avoid whole-repository traversal when changed components are known.
+- **Exclusions:** Route/call/symbol graphs, framework-specific reviewers, or speculative detection without version evidence.
+- **Validation:** Positive/negative/multi-component fixtures, version-conflict and staleness cases, and plugin isolation tests.
+- **Release classification expectation:** `release-required`.
+
+### BL-011: Add evidence packs from demonstrated use cases
+
+- **Status:** conditional
+- **Priority:** medium
+- **Roadmap theme:** M2 Ecosystem and framework coverage
+- **Dependencies:** BL-009 and BL-010.
+- **Activation trigger:** A real repository need identifies a missing ecosystem or framework and supplies safe synthetic fixtures and deterministic semantics.
+- **Goal:** Extend coverage without accumulating shallow detectors.
+- **Scoped deliverables:** Implement one coherent ecosystem or framework pack per activation, with provenance, bounds, source/target deltas, documentation, and public synthetic examples.
+- **Acceptance criteria:** The use case and completion signal are documented before implementation; false-positive behavior and unsupported versions are explicit.
+- **Exclusions:** Checkbox coverage, network resolution, runtime code execution, or bundles spanning unrelated ecosystems.
+- **Validation:** Pack-specific fixtures plus common evidence and bootstrap/MCP projection contracts.
+- **Release classification expectation:** `release-required`.
+
+## M3 External MCP hardening
+
+### BL-012: Document and validate external read-only MCP composition
+
+- **Status:** planned
+- **Priority:** medium
+- **Roadmap theme:** M3 External MCP hardening
+- **Dependencies:** BL-008 and existing explicit external tool allowlists.
+- **Activation trigger:** Built-in evidence MCP configuration is stable.
+- **Goal:** Compose external knowledge tools with built-in evidence without prefetching content or weakening tool permissions.
+- **Scoped deliverables:** Add synthetic generic stdio, HTTP-to-stdio proxy, YouTrack read-only, Confluence read-only, and versioned-documentation MCP examples; document reserved names, allowlists, secret injection, and composition behavior.
+- **Acceptance criteria:** Examples expose narrow reads only, use synthetic hosts, keep credentials out of generated files/logs, and cannot replace the built-in server.
+- **Exclusions:** External writes, generic URL fetch, documentation mirroring, or issue/page prefetch into bootstrap.
+- **Validation:** Configuration contract tests, redaction checks, collision cases, and executable synthetic example validation.
+- **Release classification expectation:** `release-required` if configuration changes; otherwise `no-release`.
+
+### BL-013: Threat-model and constrain external references
+
+- **Status:** planned
+- **Priority:** high
+- **Roadmap theme:** M3 External MCP hardening
+- **Dependencies:** BL-004, BL-008, and canonical MR metadata handling.
+- **Activation trigger:** External references are proposed for bootstrap or MCP use.
+- **Goal:** Detect useful references without allowing untrusted metadata or retrieved content to control policy or tools.
+- **Scoped deliverables:** Define configured project-key patterns, host/space allowlists, canonical parsing, reference and traversal bounds, audit metadata, narrow tool contracts, and prompt-injection instructions.
+- **Acceptance criteria:** External content cannot change policy, suppress findings, authorize actions, modify permissions, or trigger writes; rejected and truncated references are auditable without leaking secrets.
+- **Exclusions:** Content prefetch, recursive browsing, generic web access, or external-system mutation.
+- **Validation:** Threat model, adversarial MR/issue/page fixtures, Unicode/URL canonicalization, bound tests, and attack-path review.
+- **Release classification expectation:** `release-required`.
+
+## M4 Policy and project guidance
+
+### BL-014: Evolve accepted decisions into tolerant structured Markdown
+
+- **Status:** planned
+- **Priority:** medium
+- **Roadmap theme:** M4 Policy and project guidance
+- **Dependencies:** BL-004, BL-005, and current target-branch self-whitelisting guard.
+- **Activation trigger:** Evidence model can preserve decision scope and provenance.
+- **Goal:** Add optional Scope, Category, Review after, and Owner metadata without breaking existing decision documents.
+- **Scoped deliverables:** Parse heading/rationale entries and optional bullet metadata; tolerate unknown fields; filter by target branch and component scope; place summaries in bootstrap and full rationale in evidence MCP.
+- **Acceptance criteria:** Existing files remain valid, malformed optional metadata cannot invalidate unrelated decisions, and source-branch edits never affect the current review.
+- **Exclusions:** YAML, unconditional finding suppression, policy authorization, or mandatory metadata.
+- **Validation:** Backward-compatibility, unknown/malformed field, scope, date, target/source, and size-bound fixtures.
+- **Release classification expectation:** `release-required`.
+
+### BL-015: Simplify project guidance after an upstream OCR contract exists
+
+- **Status:** conditional
+- **Priority:** medium
+- **Roadmap theme:** M4 Policy and project guidance
+- **Dependencies:** BL-004, BL-005, BL-007, and documented/tested upstream OCR automatic guidance behavior.
+- **Activation trigger:** A supported OCR release proves the required guidance contract in compatibility tests.
+- **Goal:** Replace large excerpts with target-branch paths and short non-authoritative hints while preserving fail-closed handling.
+- **Scoped deliverables:** Discover applicable `AGENTS.md`/`CLAUDE.md`, exclude files changed by the merge request, supply paths/hints, and permit OCR native tools to read target versions on demand.
+- **Acceptance criteria:** Source changes cannot self-instruct, missing upstream capability retains current bounded behavior, and guidance never overrides system policy.
+- **Exclusions:** Removing safeguards before the trigger, copying full guidance into bootstrap, or toolkit-specific instruction execution.
+- **Validation:** Multi-scope target/source fixtures, changed-guidance attacks, capability fallback tests, and bootstrap budget tests.
+- **Release classification expectation:** `release-required`.
+
+## M5 Review profiles and quality measurement
+
+### BL-016: Add explicit run-level review profiles
+
+- **Status:** planned
+- **Priority:** medium
+- **Roadmap theme:** M5 Review profiles and quality measurement
+- **Dependencies:** Stable compatibility manifest and evidence/bootstrap contracts.
+- **Activation trigger:** Profile model and limit differences can be documented without changing per-tool routing.
+- **Goal:** Offer `economy`, `standard`, and `strong` choices for one OCR review run.
+- **Scoped deliverables:** Define explicit profile configuration selecting a run-level model and existing OCR limits; validate supported values, environment precedence, and rendered effective configuration.
+- **Acceptance criteria:** One model remains active per run, defaults preserve current behavior, secrets remain environment-only, and unsupported profiles fail before OCR execution.
+- **Exclusions:** Per-file/per-tool model routing, hidden heuristics, multi-agent orchestration, or full-repository scan profiles.
+- **Validation:** Profile matrix, precedence, preflight, configuration-rendering, and compatibility tests.
+- **Release classification expectation:** `release-required`.
+
+### BL-017: Measure review cost and quality signals
+
+- **Status:** planned
+- **Priority:** medium
+- **Roadmap theme:** M5 Review profiles and quality measurement
+- **Dependencies:** BL-016 and stable discussion/fingerprint lifecycle.
+- **Activation trigger:** Explicit profiles can label comparable runs.
+- **Goal:** Produce privacy-safe evidence for profile tuning and any future routing decision.
+- **Scoped deliverables:** Define bounded metrics for latency, token use when available, evidence/MCP use, findings, repeats, suppression, resolution, and human ownership; document retention and export boundaries.
+- **Acceptance criteria:** Metrics contain no source, prompts, secrets, or external contents; missing provider telemetry is explicit; repeated runs are comparable without changing review behavior.
+- **Exclusions:** User surveillance, ranking developers, automatic routing, or mandatory external telemetry.
+- **Validation:** Synthetic lifecycle aggregation, redaction/privacy tests, missing-data behavior, and deterministic export fixtures.
+- **Release classification expectation:** `release-required` if exposed publicly; otherwise `no-release`.
+
+### BL-018: Evaluate conservative automatic profile routing
+
+- **Status:** conditional
+- **Priority:** low
+- **Roadmap theme:** M5 Review profiles and quality measurement
+- **Dependencies:** BL-016, BL-017, and an owner-approved quality/cost decision policy.
+- **Activation trigger:** Representative metrics demonstrate a stable deterministic rule that improves an explicit objective without reducing review safety.
+- **Goal:** Select one run-level profile conservatively from trusted bounded inputs.
+- **Scoped deliverables:** Document the decision rule, inputs, fallback, observability, and opt-out; implement only after replay evaluation and owner approval.
+- **Acceptance criteria:** Routing is deterministic and explainable, never uses untrusted content as authority, never selects `ocr scan`, and falls back to `standard` on uncertainty.
+- **Exclusions:** Learned online routing, per-tool models, multiple agents, or silent policy changes.
+- **Validation:** Offline replay, boundary/adversarial cases, fallback tests, and quality regression thresholds.
+- **Release classification expectation:** `release-required`.
+
+## M6 Later and conditional work
+
+### BL-019: Run a native fuzzing campaign
+
+- **Status:** parked
+- **Priority:** medium
+- **Roadmap theme:** M6 Later and conditional work
+- **Dependencies:** Stable evidence/MCP parser interfaces from M1 and selected Python 3.10-3.14-compatible fuzzing backend.
+- **Activation trigger:** Reproducible local execution, bounded CI resources, corpus ownership, and high-value parser targets are agreed.
+- **Goal:** Find crashes and invariant violations at untrusted evidence, MCP, result, GitLab payload, and registry-metadata boundaries.
+- **Scoped deliverables:** Compare Atheris and property-based alternatives; define synthetic seeds; fuzz selected parsers; minimize and retain regressions; evaluate public service integration only after useful local results.
+- **Acceptance criteria:** Targets are deterministic and bounded, minimized failures become tests, corpora contain no repository/provider secrets, and ownership is explicit.
+- **Exclusions:** Unbounded CI, production data, low-value blanket fuzzing, or a runtime dependency.
+- **Validation:** Reproducible smoke campaign across supported Python boundaries and replay of minimized corpus.
+- **Release classification expectation:** `no-release`, except user-visible fixes found by the campaign.
+
+### BL-020: Design file-based non-secret configuration
+
+- **Status:** parked
+- **Priority:** low
+- **Roadmap theme:** M6 Later and conditional work
+- **Dependencies:** Stable profile, MCP composition, and evidence configuration schemas.
+- **Activation trigger:** Environment-only configuration is a demonstrated operational constraint and one coherent schema can cover the affected non-secret settings.
+- **Goal:** Improve maintainability without weakening environment precedence, validation, or secret handling.
+- **Scoped deliverables:** Decide format/versioning, precedence, migration, allowed non-secret fields, unknown-key behavior, target/source trust, and schema evolution before implementation.
+- **Acceptance criteria:** Environment values retain explicit precedence, secrets are rejected from files, source-branch files cannot self-authorize, and migration is documented and tested.
+- **Exclusions:** Credentials on disk, implicit repository configuration, multiple overlapping formats, or implementation before the design decision.
+- **Validation:** Threat model, schema/precedence fixtures, migration compatibility tests, and secret-rejection tests.
+- **Release classification expectation:** `release-required`.
+
+### BL-021: Add code-hosting and review-host adapters beyond GitLab
+
+- **Status:** conditional
+- **Priority:** low
+- **Roadmap theme:** M6 Later and conditional work
+- **Dependencies:** Stable provider-neutral core contracts and a funded non-GitLab use case.
+- **Activation trigger:** A named forge has an owner, synthetic fixtures, and explicit parity requirements for CI orchestration, positioning, deduplication, discussion ownership, and safe publication.
+- **Goal:** Add one coherent host adapter without leaking forge semantics into evidence or core result handling.
+- **Scoped deliverables:** Specify adapter contract gaps, implement one provider boundary, add synthetic API fixtures and public setup documentation, and preserve fail-closed write behavior.
+- **Acceptance criteria:** Core remains provider-neutral, GitLab behavior does not regress, and the new host meets explicit lifecycle and security parity.
+- **Exclusions:** Repository ecosystem/framework detection, partial adapters, legacy namespace shims, or multi-host abstractions without a real second provider.
+- **Validation:** Shared adapter contract suite, provider-specific synthetic integration tests, redaction/write-bound tests, and documentation validation.
+- **Release classification expectation:** `release-required`.
+
+### BL-022: Register for OpenSSF Best Practices
+
+- **Status:** owner action
+- **Priority:** low
+- **Roadmap theme:** M6 Later and conditional work
+- **Dependencies:** Public repository and owner access to `bestpractices.dev`.
+- **Activation trigger:** The owner is ready to authenticate and attest every passing-level criterion truthfully.
+- **Goal:** Create an evidence-backed public badge record without guessing governance or usage answers.
+- **Scoped deliverables:** Complete the questionnaire with current public evidence links, leave unsupported criteria unmet, add the badge only after readback confirms the record.
+- **Acceptance criteria:** Record and repository badge agree, every affirmative answer has current evidence, and owner-only statements are owner-confirmed.
+- **Exclusions:** Automated attestations, aspirational answers, or treating badge work as a product feature.
+- **Validation:** Public record readback, repository link check, and badge target verification.
+- **Release classification expectation:** `no-release`.

open_code_review_toolkit-0.2.1/docs/engineering/toolkit_strategy.md

@@ -0,0 +1,145 @@
+# Toolkit Strategy
+
+This document is the durable source of truth for the product and architecture direction of Open Code Review Toolkit. It describes boundaries and intended outcomes, not execution order; see [the roadmap](../../ROADMAP.md) for sequencing and [the backlog](../codex/TASKS_BACKLOG.md) for implementation-ready work.
+
+## Product purpose
+
+Open Code Review Toolkit is a provider-neutral GitLab CI control and integration layer around Alibaba Open Code Review (OCR). Its purpose is to make OCR review predictable and safe in real pipelines: configuration is validated, project evidence is deterministic and bounded, and model-controlled results are normalized before GitLab publication.
+
+The toolkit does not replace OCR. OCR owns diff review, file selection and bundling, codebase exploration, rule matching, its agent tool loop, finding generation, and initial finding positioning. The toolkit owns GitLab CI orchestration, OCR/provider/MCP configuration, deterministic project evidence, compact trusted bootstrap generation, project-policy overlays, OCR compatibility validation, safe result publication, and the discussion deduplication, suppression, ownership, and resolution lifecycle.
+
+```mermaid
+flowchart LR
+    CI[GitLab CI] --> CT[Toolkit control layer]
+    CT -->|validated config and bounded bootstrap| OCR[Alibaba OCR]
+    OCR -->|review findings| CT
+    CT -->|normalized bounded writes| GL[GitLab discussions]
+    OCR -->|native repository tools| REPO[Repository]
+```
+
+### Non-goals
+
+The toolkit will not:
+
+- modify or fork OCR, build a second review engine, agent loop, or per-tool model router;
+- build a full repository scanner, symbol graph, call graph, or run full-repository `ocr scan` for merge-request review;
+- add CodeGraph as a runtime dependency or project linters as a toolkit product capability;
+- store versioned library documentation or prefetch issue and page contents into the bootstrap;
+- add write tools for external systems or give OCR or an LLM direct GitLab write credentials.
+
+Repository-maintenance analyzers such as Bandit remain valid quality controls for this codebase. They are not evidence providers or features offered to downstream repositories.
+
+## Current state
+
+The current context implementation is a bounded Markdown generator rather than an evidence engine. It already detects changed-file categories, reads selected manifests, extracts Python, JavaScript, Go, PHP, Ansible, container, and GitLab CI facts, and includes target-branch-safe project guidance and accepted decisions. It redacts sensitive values, limits reads and output, and degrades explicitly when evidence is incomplete.
+
+These capabilities are partial foundations: most facts are rendered directly, dependency versions primarily reflect declarations rather than resolved source/target state, and `context/render.py` still combines collection, prioritization, and presentation. MCP configuration currently validates and installs external stdio servers with explicit tool allowlists; the toolkit does not yet provide a built-in evidence MCP.
+
+GitLab result normalization and posting are implemented behind provider-oriented modules. They bound and neutralize model-controlled text, use stable finding fingerprints, preserve human-owned discussions, and keep GitLab credentials outside OCR. The current recommended and tested OCR baseline belongs in the operational compatibility contract, not this durable strategy.
+
+## Repository Evidence Engine
+
+The target architecture is one Repository Evidence Engine that analyzes source/head and target/base repository states, detects components affected by changed files, and records structured facts. Bootstrap and MCP must project the same stored evidence; they must not grow separate collectors.
+
+```mermaid
+flowchart LR
+    SNAP[Source and target snapshots] --> COL[Bounded collectors]
+    COL --> MODEL[Common evidence model]
+    MODEL --> PLAN[Bootstrap planner]
+    PLAN --> BOOT[Compact OCR bootstrap]
+    MODEL --> MCP[Built-in evidence MCP]
+    EXT[External read-only MCP] --> COMPOSE[MCP composition]
+    MCP --> COMPOSE
+    COMPOSE --> OCR[OCR tool loop]
+    BOOT --> OCR
+```
+
+Every evidence record should preserve its kind and value together with source path, git ref, component scope, provenance, confidence, and staleness where meaningful. Collection is deterministic and network-independent. Storage has explicit bounds and stable ordering. Rendering never upgrades inferred or untrusted material into authoritative policy.
+
+The engine separates four responsibilities now concentrated in rendering code:
+
+1. collectors parse repository material into structured evidence;
+2. bounded storage normalizes and indexes that evidence;
+3. bootstrap planning selects the smallest useful trusted overview;
+4. renderers produce stable text or read-only MCP responses.
+
+The evidence model is the main extension point. Ecosystem and framework plugins may contribute typed facts, but cannot run arbitrary commands, fetch the network, mutate the repository, or introduce a second review workflow.
+
+## Compact bootstrap and built-in evidence MCP
+
+The OCR background should become a compact bootstrap, normally around 1,500-2,500 characters and always below the existing toolkit/OCR hard limit. It contains only authoritative constraints and trust instructions, base/head identity, detected ecosystems and frameworks, material runtime or dependency changes, normalized external reference identifiers, available MCP capabilities, relevant accepted decisions, and short project-guidance hints.
+
+Complete manifests, dependency inventories, guidance documents, and external issue/page contents do not belong in the bootstrap. Detailed repository facts are available on demand through a built-in server registered under a reserved namespace such as `ocr_toolkit_evidence`, with tools prefixed `ocr_toolkit_`. Candidate tools expose review environment, changed components, dependency state and deltas, framework state, version evidence, and accepted decisions.
+
+The server is read-only, repository-root constrained, bounded, deterministic, network-independent, and incapable of arbitrary command execution. External MCP configuration is composed with this server rather than replacing it. Reserved names prevent downstream configuration from shadowing built-in tools.
+
+## Evidence domains
+
+### Dependencies, runtimes, and components
+
+Evidence distinguishes declared constraints, locked versions, installed versions, runtime-detected versions, container/image pins, and inferred or unknown values. Source and target snapshots produce explicit deltas rather than an unlabelled merged inventory.
+
+Expansion follows demonstrated repository use. Initial work strengthens formats already represented in the current collectors: Python manifests, requirements and lockfiles; JavaScript package metadata and npm, pnpm, Yarn, or Bun locks; Go modules and toolchains; Composer manifests, locks, platform configuration and installed metadata; Ansible requirements, collections and execution environments; containers and GitLab CI images. Every format requires synthetic fixtures, deterministic semantics, size bounds, and explicit behavior for malformed or missing files.
+
+### Framework evidence
+
+Framework support is plugin-oriented structured extraction, not a code graph or framework-specific review engine. Useful facts are framework identity, verified version, component scope, important configuration paths, and material source/target changes. Initial plugins are selected from demonstrated repositories and testable fixtures; candidates include common Python, Go, PHP, JavaScript, test, and Ansible frameworks.
+
+The design borrows useful CodeGraph principles without adopting CodeGraph: deterministic extraction precedes rendering, work is component-scoped, facts retain provenance and staleness, and OCR retrieves surgical evidence on demand. Route, symbol, and call graphs remain out of scope.
+
+### Versioned documentation
+
+Version-specific library documentation belongs to a separate future documentation MCP. The evidence MCP establishes which package and version are present; the documentation MCP supplies matching documentation; OCR combines them. The toolkit does not mirror or store that documentation.
+
+## External MCP and references
+
+YouTrack, Confluence, documentation, and other external sources connect directly to OCR through narrowly scoped read-only MCP tools. While OCR lacks stable native remote MCP support, the toolkit may support the existing HTTP-to-stdio proxy pattern. It composes configurations, validates explicit tool allowlists, detects candidate references in merge-request metadata, and adds only normalized identifiers and usage instructions to the bootstrap. It does not prefetch or duplicate external content.
+
+All merge-request metadata and external MCP responses are untrusted evidence. Safe integration requires configured project-key patterns, allowed hosts or spaces, canonical parsing, bounded reference counts and link traversal, narrow tools instead of generic URL fetch, explicit prompt-injection guidance, and audit metadata for detected and retrieved references. External content cannot change review policy, suppress findings, authorize actions, modify tool permissions, or grant write access.
+
+Public examples use only synthetic services and cover generic stdio MCP, HTTP-to-stdio proxying, read-only YouTrack, read-only Confluence, and composition with the built-in evidence MCP. External-system writes remain outside the generic toolkit scope.
+
+## Project policy and guidance
+
+### Accepted decisions
+
+`.opencodereview/accepted-decisions.md` evolves into tolerant semi-structured Markdown while preserving the existing heading-and-rationale format:
+
+```markdown
+## generated-client-timeout
+The generated client retains its provider timeout so regeneration stays reproducible.
+
+- Scope: `src/client/generated/**`
+- Category: performance
+- Review after: 2026-12-01
+- Owner: client-platform
+```
+
+Metadata is optional and unknown fields do not invalidate the document. Only target-branch decisions may affect a review. Scoped summaries enter the bootstrap only when relevant; complete rationale may be exposed through evidence MCP. Decisions remain contextual evidence, not unconditional suppression or permission to ignore unrelated findings.
+
+### AGENTS.md and CLAUDE.md
+
+The existing bounded, fail-closed guidance handling remains until upstream OCR documents and tests an automatic project-guidance contract. The intended simplification discovers applicable files, uses target-branch versions, excludes guidance modified by the current merge request, and passes paths plus short hints. Guidance is non-authoritative repository evidence; OCR may read the full target-branch files with its native repository tools when needed.
+
+## Review profiles and quality measurement
+
+OCR uses one configured model per review run. A lightweight explicit profile abstraction may select that run-level model and existing OCR limits: `economy`, `standard`, or `strong`. Profiles do not dispatch individual files or tools to different models.
+
+Automatic routing is conditional on stable evidence, latency, token, and review-quality metrics. If activated, it is deterministic, conservative, observable, and never routes a merge request to a full-repository scan.
+
+## OCR compatibility policy
+
+Fast-moving upstream compatibility is a product capability, not an ad hoc version string update. One machine-readable manifest should define recommended and tested OCR releases and known capabilities. Version and capability inspection is centralized, additive output fields are parsed tolerantly, and required contract removal fails closed.
+
+Contract tests cover the supported release set. Scheduled automation detects new upstream releases, records changelog impact, and runs compatibility checks, but never upgrades production pins automatically. Updating the recommended version remains a reviewed, checksum-pinned change with release classification based on user-visible impact.
+
+## Architectural invariants
+
+- Repository and external content are untrusted, bounded, redacted, and rendered safely.
+- Evidence retains origin and trust level; content cannot promote itself into policy.
+- Core evidence behavior is provider-neutral; forge-specific orchestration and publication stay behind adapters.
+- OCR remains the only review and agent engine, and GitLab credentials remain toolkit-only.
+- Bootstrap and MCP use one evidence model and one collector path.
+- Built-in and external MCP tools are explicit, read-only, bounded, and auditable.
+- Runtime dependencies remain zero unless a documented package or process boundary justifies one.
+- Public documentation, fixtures, and examples remain synthetic.

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/docs/gitlab.md

@@ -4,7 +4,7 @@ The toolkit's first provider adapter posts review results to GitLab merge reques
 
 ## Installation
 
-Install `open-code-review-toolkit` from PyPI. The example obtains the expected toolkit wheel digest from the matching immutable GitHub Release, then uses pip hash-checking and a local install. Install Open Code Review separately and pin `v1.7.14`; verify the release checksum before making the binary executable. The package never downloads OCR.
+Install `open-code-review-toolkit` from PyPI. The example obtains the expected toolkit wheel digest from the matching immutable GitHub Release, then uses pip hash-checking and a local install. Install Open Code Review separately and pin `v1.7.17`; verify the release checksum before making the binary executable. The package never downloads OCR.
 
 Copy and adapt [the synthetic CI example](../examples/gitlab/ocr-review.gitlab-ci.yml). Keep the lint stage before the AI review stage so failed project checks block review. The example downloads a pinned toolkit wheel with bounded retries/timeouts, verifies its SHA-256 before a local `--no-deps` install, generates one background file, and passes it once with `--background-file`.
 

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/docs/security.md

@@ -18,7 +18,7 @@ The toolkit bridges four trust domains: repository content, OCR and its LLM/MCP
 
 Use a dedicated bot identity and least-privilege `GITLAB_API_TOKEN`. Protect and mask credentials. Do not expose secrets to pipelines for untrusted forks. Begin with manual execution for trusted contributors, review generated notes, and enable automatic posting only after the repository's threat model is accepted.
 
-Pin Open Code Review `v1.7.14` and verify its checksum. Pin Python dependencies through `uv.lock` and GitHub Actions by immutable commit SHA. MCP servers are privileged child processes; allow only reviewed commands and tools.
+Pin Open Code Review `v1.7.17` and verify its checksum. Pin Python dependencies through `uv.lock` and GitHub Actions by immutable commit SHA. MCP servers are privileged child processes; allow only reviewed commands and tools.
 
 ## Repository security posture
 

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/examples/gitlab/ocr-review.gitlab-ci.yml

@@ -6,10 +6,10 @@ default:
   image: python:3.12-slim
 
 variables:
-  OCR_VERSION: "v1.7.14"
+  OCR_VERSION: "v1.7.17"
   OCR_TOOLKIT_VERSION: "0.1.0"
   OCR_TOOLKIT_CHECKSUMS_URL: "https://github.com/xeonvs/open-code-review-toolkit/releases/download/v0.1.0/SHA256SUMS"
-  OCR_SHA256: "f5ee3118b72fe702c94457aa466ebad82b8d4bf6ced6e0347534f4cfdbcc5f8b"
+  OCR_SHA256: "ab2fae81796a00dda292def8261bec2203d03f3909673c08219e7c5df5f4feee"
   OCR_POST_MODE: "draft"
   OCR_STRICT_POSTING: "true"
   OCR_LLM_VALIDATE_MODEL: "false"

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/src/ocr_toolkit/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.2.0'
-__version_tuple__ = version_tuple = (0, 2, 0)
+__version__ = version = '0.2.1'
+__version_tuple__ = version_tuple = (0, 2, 1)
 
 __commit_id__ = commit_id = None

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/src/ocr_toolkit/preflight.py

@@ -24,7 +24,7 @@ DEFAULT_REQUEST_HEADERS = {
     "Accept": "application/json",
     "User-Agent": "open-code-review-ci-preflight/1.0",
 }
-EXPECTED_OCR_VERSION = "1.7.14"
+EXPECTED_OCR_VERSION = "1.7.17"
 
 
 class PreflightError(Exception):

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/tests/test_context_helpers.py

@@ -1775,11 +1775,11 @@ class DocumentationConsistencyTests(unittest.TestCase):
         ci = (HELPER_DIR / "ocr-review.gitlab-ci.yml").read_text(encoding="utf-8")
         internals = (HELPER_DIR.parents[1] / "docs" / "security.md").read_text(encoding="utf-8")
 
-        self.assertIn('OCR_VERSION: "v1.7.14"', ci)
-        self.assertIn("v1.7.14", docs)
-        self.assertIn("v1.7.14", internals)
+        self.assertIn('OCR_VERSION: "v1.7.17"', ci)
+        self.assertIn("v1.7.17", docs)
+        self.assertIn("v1.7.17", internals)
         self.assertIn(
-            'OCR_SHA256: "f5ee3118b72fe702c94457aa466ebad82b8d4bf6ced6e0347534f4cfdbcc5f8b"',
+            'OCR_SHA256: "ab2fae81796a00dda292def8261bec2203d03f3909673c08219e7c5df5f4feee"',
             ci,
         )
         configuration = (HELPER_DIR.parents[1] / "docs" / "configuration.md").read_text(

open_code_review_toolkit-0.2.1/tests/test_project_strategy.py

@@ -0,0 +1,109 @@
+"""Contracts for the durable strategy, roadmap, and regenerated backlog."""
+
+from __future__ import annotations
+
+import re
+from pathlib import Path
+
+ROOT = Path(__file__).parents[1]
+PLANNING_DOCUMENTS = (
+    "AGENTS.md",
+    "README.md",
+    "ROADMAP.md",
+    "docs/engineering/toolkit_strategy.md",
+    "docs/codex/TASKS_BACKLOG.md",
+)
+
+
+def read(path: str) -> str:
+    return (ROOT / path).read_text(encoding="utf-8")
+
+
+def test_canonical_strategy_and_roadmap_are_linked() -> None:
+    agents = read("AGENTS.md")
+    readme = read("README.md")
+    assert "docs/engineering/toolkit_strategy.md" in agents
+    assert "ROADMAP.md" in agents
+    assert "[Toolkit strategy](docs/engineering/toolkit_strategy.md)" in readme
+    assert "[Roadmap](ROADMAP.md)" in readme
+    assert "[Backlog](docs/codex/TASKS_BACKLOG.md)" in readme
+
+
+def test_local_markdown_links_resolve() -> None:
+    link_pattern = re.compile(r"(?<!!)\[[^]]+\]\(([^)]+)\)")
+
+    for document in PLANNING_DOCUMENTS:
+        path = ROOT / document
+        for target in link_pattern.findall(path.read_text(encoding="utf-8")):
+            if target.startswith(("http://", "https://", "#")):
+                continue
+            relative_path = target.split("#", 1)[0]
+            assert (path.parent / relative_path).resolve().exists(), (document, target)
+
+
+def test_durable_planning_does_not_pin_an_ocr_release() -> None:
+    durable_planning = (
+        read("docs/engineering/toolkit_strategy.md")
+        + read("ROADMAP.md")
+        + read("docs/codex/TASKS_BACKLOG.md")
+    )
+    assert re.search(r"\bOCR [`v]*\d+\.\d+\.\d+", durable_planning) is None
+
+
+def test_backlog_contains_complete_numbered_items() -> None:
+    backlog = read("docs/codex/TASKS_BACKLOG.md")
+    item_ids = re.findall(r"^### (BL-\d{3}):", backlog, flags=re.MULTILINE)
+    assert item_ids == [f"BL-{number:03d}" for number in range(1, 23)]
+    fields = (
+        "Status",
+        "Priority",
+        "Roadmap theme",
+        "Dependencies",
+        "Activation trigger",
+        "Goal",
+        "Scoped deliverables",
+        "Acceptance criteria",
+        "Exclusions",
+        "Validation",
+        "Release classification expectation",
+    )
+    for field in fields:
+        assert backlog.count(f"**{field}:**") == 22
+
+
+def test_every_previous_backlog_item_has_an_explicit_disposition() -> None:
+    backlog = read("docs/codex/TASKS_BACKLOG.md")
+    previous_items = (
+        "Native fuzzing campaign",
+        "OpenSSF Best Practices registration",
+        "Additional provider adapters",
+        "File-based user configuration",
+    )
+    for previous_item in previous_items:
+        assert f"| {previous_item} |" in backlog
+
+
+def test_roadmap_defines_every_backlog_theme() -> None:
+    roadmap = read("ROADMAP.md")
+    backlog = read("docs/codex/TASKS_BACKLOG.md")
+    themes = set(re.findall(r"\*\*Roadmap theme:\*\* (M\d [^\n]+)", backlog))
+    assert themes == {
+        "M0 Foundation",
+        "M1 Evidence architecture",
+        "M2 Ecosystem and framework coverage",
+        "M3 External MCP hardening",
+        "M4 Policy and project guidance",
+        "M5 Review profiles and quality measurement",
+        "M6 Later and conditional work",
+    }
+    roadmap_theme_names = {
+        "M0 Foundation",
+        "M1 Evidence architecture",
+        "M2 Ecosystem and framework coverage",
+        "M3 External MCP hardening",
+        "M4 Policy and project guidance",
+        "M5 Profiles and quality measurement",
+        "M6 Later and conditional work",
+    }
+    for theme in roadmap_theme_names:
+        assert theme in roadmap

{open_code_review_toolkit-0.2.0 → open_code_review_toolkit-0.2.1}/tests/test_runtime_helpers.py

@@ -485,7 +485,7 @@ class MCPConfigTests(unittest.TestCase):
 class PreflightTests(unittest.TestCase):
     def test_validate_ocr_binary_accepts_supported_version(self) -> None:
         completed = subprocess.CompletedProcess(
-            args=["ocr", "--version"], returncode=0, stdout="ocr 1.7.14\n", stderr=""
+            args=["ocr", "--version"], returncode=0, stdout="ocr 1.7.17\n", stderr=""
         )
         with (
             patched_attr(preflight.shutil, "which", lambda _name: "/usr/bin/ocr"),
@@ -513,7 +513,7 @@ class PreflightTests(unittest.TestCase):
 
     def test_validate_ocr_binary_rejects_version_prefix_collision(self) -> None:
         completed = subprocess.CompletedProcess(
-            args=["ocr", "--version"], returncode=0, stdout="ocr 1.7.140\n", stderr=""
+            args=["ocr", "--version"], returncode=0, stdout="ocr 1.7.170\n", stderr=""
         )
         with (
             patched_attr(preflight.shutil, "which", lambda _name: "/usr/bin/ocr"),

open_code_review_toolkit-0.2.0/docs/codex/TASKS_BACKLOG.md

@@ -1,87 +0,0 @@
-# Tasks Backlog
-
-This file tracks future work that is not active. Active extraction work is owned by `PLANS.md`.
-
-## Backlog Item: Native fuzzing campaign
-
-Status: parked
-Priority: medium
-
-### Activation Trigger
-
-- A supported Python fuzzing backend is selected with reproducible local execution, bounded CI resources, and corpus ownership.
-
-### Goal
-
-Fuzz the untrusted-input boundaries with meaningful targets for result normalization, context rendering, GitLab payload parsing, and registry metadata validation. Integrate a public fuzzing service only after the targets demonstrate useful coverage and stable crash minimization.
-
-### Next Safe Action
-
-1. Compare Atheris with property-based alternatives across Python 3.10-3.14 and design a small synthetic seed corpus without adding a runtime dependency.
-
-### Exit Criteria
-
-- Native targets run locally and in bounded CI, retain minimized synthetic regressions, publish no repository or provider secrets, and are recognized by the selected fuzzing service.
-
-## Backlog Item: OpenSSF Best Practices registration
-
-Status: owner action
-Priority: low
-
-### Activation Trigger
-
-- The owner is ready to authenticate at `bestpractices.dev` and attest every passing-level criterion truthfully.
-
-### Goal
-
-Register the public repository for an OpenSSF Best Practices badge without guessing owner-only governance or project-usage answers.
-
-### Next Safe Action
-
-1. Complete the passing-level questionnaire with evidence links to the public repository and leave unsupported criteria unmet.
-
-### Exit Criteria
-
-- The public badge record exists, all answers have current evidence, and the README displays only the earned status.
-
-## Backlog Item: Additional provider adapters
-
-Status: parked
-Priority: low
-
-### Activation Trigger
-
-- A provider-neutral core has shipped and a concrete provider integration has an owner and testable API contract.
-
-### Goal
-
-Add another code-hosting adapter without weakening the provider-neutral core or GitLab behavior.
-
-### Next Safe Action
-
-1. Write an adapter contract proposal based on the shipped GitLab boundary and validate it against synthetic fixtures.
-
-### Exit Criteria
-
-- The new adapter has isolated tests, documentation, and no provider-specific leakage into core modules.
-
-## Backlog Item: File-based user configuration
-
-Status: parked
-Priority: low
-
-### Activation Trigger
-
-- Environment-only configuration becomes a demonstrated usability constraint after v0.1.
-
-### Goal
-
-Evaluate a versioned user configuration file without silently changing environment precedence or secret handling.
-
-### Next Safe Action
-
-1. Draft a schema and threat model; do not implement until compatibility and migration behavior are agreed.
-
-### Exit Criteria
-
-- Schema, precedence, migration, secret handling, and validation behavior are documented and tested.