Skip to content

[M11] Rebaseline real-world compatibility from expanded corpus #82

Description

@Teakowa

Goal

Close M11 from current real-world evidence without turning reference-output parity into an open-ended product objective, then hand off to the tooling-first roadmap defined by #88.

Current reality

M11 began as an evidence-first expansion of Wright's real-world .opy compatibility corpus. That evidence has now driven several bounded corrections:

The architecture/product interpretation has also changed materially. #88 is now the authoritative rebaseline task: Wright is tooling-first, owns compiler-grade semantic frontends as enabling infrastructure, and targets observable semantics rather than compiler-output identity.

M11 compatibility rule after #88

M11 must not create implementation work from a raw reference-output difference alone.

A newly discovered divergence is an M11 blocker only when evidence shows at least one of the following:

  1. an observable semantic difference on the declared supported surface;
  2. invalid Workshop syntax or failure of Wright's declared Workshop parse/emit round-trip contract;
  3. a source identity, diagnostics, analysis, agent/source-edit, or other tooling correctness defect;
  4. violation of another explicitly documented compatibility contract.

Presentation-only or upstream-canonical spelling differences remain useful N-level evidence, but they are not automatically product-critical work. Semantic compatibility is the governing criterion.

Final gate

M11 may close after all of the following are true:

  1. [M11 correctness] Close supported-surface Workshop emission and round-trip divergences #87 independent verification

  2. Architecture contract reconciled

  3. Evidence refreshed

    • Real-world gap inventory/support matrices reflect the current implementation, including settings support and the remaining explicitly deferred source constructs.
    • Supported, deferred, reference-limited, and inconclusive cases remain distinguishable.
  4. Repository verification

    • Current main CI is green with required jobs actually executed.
    • Acceptance uses current code/tests/reports, not issue closure or implementation-agent self-report alone.

Expected gate result

accept-with-limitations is valid and expected if the declared supported surface is correct while corpus-evidenced language constructs remain explicitly deferred.

M11 does not need to make every real-world OPY project compile before closing. It must leave a trustworthy corpus-defined statement of what Wright can currently compile and analyze, which gaps block those projects, and which gaps are intentionally deferred.

Non-goals

Roadmap handoff

After M11 closes:

  1. [Architecture] Rebaseline Wright as a tooling-first semantic platform #88 — finish/accept the tooling-first architecture rebaseline if not already complete.
  2. [M12] Tooling-first lint and Workshop stability analysis platform #89 / M12 — configurable lint and Workshop stability-analysis platform; this is the next product-value milestone.
  3. [M13] Source-language interoperability and OSTW compatibility #90 / M13 — OSTW semantic compatibility and Workshop-centered source-language interoperability; keep coarse until M12 and an OSTW evidence investigation justify decomposition.

Do not mechanically continue OPY surface expansion between M11 and M12. A future OPY compatibility item should be created only when real corpus/tooling evidence shows that it blocks meaningful compilation, analysis, source tooling, or an explicit semantic compatibility claim.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions