Skip to content

Roadmap: ship Owen Alpha and complete the Rust production vertical after #214 #250

Open
Open
Roadmap: ship Owen Alpha and complete the Rust production vertical after #214#250
Labels
enhancementNew feature or request

Description

@PhysShell
PhysShell
opened on Jul 13, 2026

Status

Master roadmap after the completion of P-022 step 4 in #214 / PR #249.

Reconciled at 0738d29 (PR #325), in the same move as the P-022 and index reconciliation — per this issue's own status-drift rule, the surfaces change together. Previous reconciliations: 984de7d (PR #324) and fdcb222 (PR #322). Statuses are checkpoint-level: each step names its completed checkpoints, its remaining acceptance, its normative blocker (what its acceptance actually requires) and this roadmap's preferred sequencing (what order is cheapest). Conflating the last two is what made the P-022 table drift twice.

How to keep parity work from drifting again is now written down: P-022 § Parity-work discipline. It is the single home for those rules — deliberately not copied elsewhere, because two copies of one law drift.

Two independent outcomes must now be delivered:

  1. Owen Alpha is actually published and verified from clean external consumers.
  2. Rust participates in the real C# → OwnIR → verdict path, first in shadow mode and then through an explicit cutover gate.

The release track must not wait for the full Rust migration. The Rust track must not use the release as permission to weaken parity.

Current baseline

Completed:

Still missing:

Explicitly not missing, because it was struck rather than deferred: a Rust .ownreport.json. See the #256 entry below.

Non-negotiable migration rules

  • Python remains the oracle until a separate cutover decision.
  • A Rust/Python divergence is a Rust bug unless behavior changes in a separate Python-first PR.
  • Migration PRs do not add diagnostic rules, change severity, broaden Roslyn heuristics, or weaken fixtures.
  • Every layer owns a frozen Python-authored parity surface; steady-state Rust tests run with zero Python.
  • Production crate edges remain CI-enforced.
  • own-codegen remains independent of own-analysis and own-diagnostics.
  • own-bridge feeds facts and maps verdicts; it must not duplicate analysis algorithms.
  • Owen Alpha publication does not depend on Rust-default cutover.
  • Parity work follows P-022 § Parity-work discipline — oracle over reviewer prose, mutation over plausible tests, no fail-fast during mutation campaigns, insertion-stable generated goldens.

Child issues and execution order

A. Owen Alpha release

Release DAG:

#252
├─> #253
└─> #254

The release track is independent of the Rust-default cutover.

B. P-022 Rust production vertical

Each entry states its normative blocker first; preferred ordering is marked as such and is advisory.

Rust DAG (unchanged — normative dependencies only):

#251
├─> #255 ─> #256 ───────────────┐
├─> #257 │
└─> #258 ─> #259 ─> #260 ───────┼─> #262
└─> #261 ────┘

Preferred queue:#259 cp4 → cp5 → #260/#269.

The defensive limits that used to head this queue landed in #326, and their position was load-bearing rather than tidy: they changed what the reference accepts, so they had to land Python-first and cp1 had to be re-measured against them rather than merged beside them.

C. IDE/incremental path

IDE DAG:

#263 ──────────────┬─> #264
└─> #265
#255/#256 ───────────> #264
#259/#260 ───────────> #265

D. P-034

Production implementation remains blocked until the runtime marker/helper/escape-hatch contract is finalized. Do not duplicate call-site use-after-dispose rules.

Recommended agent allocation

Strong agent

#259 cp4 -> cp5

#255, #256, #258 and #259 cp1–cp3 are complete and drop out of this chain. #259 is already in flight — do not restart it from the top.

Separate strong or medium-strong agent

#257

Keep codegen isolated from analysis.

Medium agent

#252 verification packet
#253/#254 release evidence and external checks

Local/corpus-capable agent

#263 measurements
#260 infrastructure slices, five-repository compare sweeps and reproduction artifacts

Status-drift rule

A step is never described by a single Implemented/Missing bit. Any status edit to this issue or to docs/proposals/P-022-rust-core-migration.md must state, per step: completed checkpoints, remaining acceptance, normative blocker, and preferred sequencing. Both surfaces are updated in the same change — a reconciliation that touches only one of them replaces a stale pair with a contradictory pair. The proposals index row counts as a third surface for the same fact.

A child issue's own body is a fourth surface when its acceptance turns out to be wrong. #256 is the worked example: its requirements described a .ownreport.json the project does not have and had already refused to build, so the correction belongs in the issue, in this roadmap, in P-022 and in the index — together, or not at all.

Acceptance-evidence surface (parity checkpoints only)

Parity checkpoints carry one more surface, and it is not a status surface: the frozen ledger. A checkpoint whose acceptance is "two implementations agree" is proved by an artifact that can share the implementation's blind spots, and a green matrix over an incomplete ledger is indistinguishable from a green matrix over a complete one. #259 cp1 is the worked example, three times over — 0/0/0 over 77 controls, then 58 permissive documents and 9 category mismatches once the ledger was rebuilt from the reference instead of from the author's reading of it, then 7 more permissive documents and 8 more category mismatches once the two deliberately excluded families were admitted.

The third round added a second failure mode worth naming separately: a ledger can carry the right controls and still take its category from the wrong place. _check_column raises one message for five distinct mechanisms, and the ledger inherited one message as one category — so the classification was correct about accept/reject and wrong about why, for a year, in a file whose entire purpose is to be right about why.

The distinction matters: a ledger cannot report a normative blocker, a preferred sequencing or a remaining acceptance. It carries no project state at all. It is evidence for a claim the status surfaces make, so it is reviewed as evidence — is it derived from the reference or from the port, can it express absence, does every category have a control, and is any family excluded — and when it turns out to be incomplete, the correction is a further census with every result on the record, not a fix to the port.

For how to keep parity work honest — not just its status — see P-022 § Parity-work discipline.

Global PR acceptance packet

Every substantive child PR must state:

Scope:
Explicit non-goals:
Python source of truth:
Frozen fixture:
Fixture regeneration command:
Steady-state test command:
Production dependency changes:
Behavior changes:
Acceptance changes:
Local commands:
GitHub Actions links:
Known deferred cases:

Migration PRs additionally report:

Python-only verdict count:
Rust-only verdict count:
Changed verdict count:
Ordering-only difference count:
Unexplained difference count:

The final value must be 0.

Stop conditions

Stop and redesign the child scope if any of these occur:

  1. A fixture or acceptance must be weakened to make parity green.
  2. Rust intentionally differs without a separate Python-first change.
  3. own-bridge reimplements ownership/lifetime/effect/DI algorithms.
  4. own-codegen starts consuming analysis verdicts.
  5. Release smoke tests use project references/rebuilds instead of the packed .nupkg.
  6. Python and Rust receive different OwnIR bytes in compare mode.
  7. SARIF normalization deletes semantic fields merely to remove a diff.
  8. Performance work begins without a baseline/profile.
  9. A new abstraction layer has no vertical consumer.
  10. Schema, semantics, output and packaging are mixed into one supposedly small PR.
  11. A parity result is reported as complete while known divergence families sit outside the measured set. Excluding them is legitimate; calling the remainder "parity" is not.
  12. A parity category is taken from where the reference raises its error rather than from the mechanism the document violated. One diagnostic covering several mechanisms is normal in a reference written for humans; inheriting it as one category makes the taxonomy decorative.

Note on (1) versus a corrected acceptance: striking a requirement because the tree proves it describes something that does not exist is not weakening it. The distinction is evidence — #256's strikes each carry a measurement, and the surfaces that stated the old acceptance were all corrected in the same move.

Milestone completion

This roadmap reaches its next major milestone when all are true:

Owen Alpha

  • installable from nuget.org on a clean machine;
  • owen check works on Windows and Linux;
  • immutable GitHub Action tag works from an external repository;
  • SARIF is accepted by GitHub Code Scanning.

Rust vertical

IDE foundation

  • measured latency/memory budgets exist;
  • .own LSP proves cancellation and stale-result correctness;
  • the C# hybrid host has an approved protocol/ADR and a working full-snapshot vertical before delta optimization.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions