[M12 acceptance] Verify tooling-first lint and stability platform

[Teakowa]

Parent: #89
Depends on: #97, #98, #99

Goal

Independently verify that M12 delivers a coherent tooling-first lint/stability platform across supported Wright inputs and public tool surfaces.

QA scope

• Verify the rule registry/configuration contract from [M12] Establish lint rule registry and configuration contract #97 against current code and tests.
• Verify wright lint and structured results from [M12] Add first-class lint CLI and shared structured results #98 on supported OPY and raw Workshop inputs.
• Verify source identity/spans, stable rule IDs, severity configuration, and CLI/API consistency.
• Verify the first-party rule set from [M12] Ship a bounded evidence-backed Workshop stability rule set #99 using positive/negative fixtures plus linked real-project/corpus evidence.
• Independently verify [M12] Detect no-yield loops with bounded evidence classification #103 no-yield-loop behavior, including distinct treatment of obviously unbounded, statically bounded, and boundedness-unknown cases.
• Confirm heuristic/static/exact evidence classifications are represented accurately and do not overclaim runtime certainty.
• Verify existing check/analyze/tool APIs remain compatible or that intentional changes are documented.
• Verify current CI and required jobs at the accepted commit.

Architect confirmation

Confirm:

• lint reuses Wright's shared compiler/session/semantic services rather than creating a parallel semantic stack;
• rule contracts remain language/transport neutral enough for future OPY/Workshop/OSTW and agent consumers;
• [M12] Detect no-yield loops with bounded evidence classification #103 derives severity/risk from explicit evidence rather than hard-coding every no-yield loop as an equivalent crash condition;
• M12 did not introduce an unjustified plugin host, content registry, or source-language extension;
• deferred architecture [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 remains non-blocking unless new implementation evidence justifies reopening that decision.

Acceptance criteria

• [M12] Establish lint rule registry and configuration contract #97, [M12] Add first-class lint CLI and shared structured results #98, and [M12] Ship a bounded evidence-backed Workshop stability rule set #99 are independently verified from current repository evidence rather than issue state alone.
• [M12] Detect no-yield loops with bounded evidence classification #103 is covered by acceptance evidence and its boundedness/evidence distinctions behave as documented.
• Supported OPY and raw Workshop inputs produce deterministic lint findings through the shared pipeline.
• Stable rule IDs, configured severity, and source provenance are visible through structured CLI/tool results.
• First-party stability rules have bounded evidence, explicit limitations, and acceptable false-positive behavior for their declared defaults.
• No shipped rule is justified solely by community "anti-crash" advice.
• Current CI is green with required jobs actually executed.
• PM records a post-M12 roadmap reassessment before decomposing [M13] Source-language interoperability and OSTW compatibility #90/M13.

Non-goals

• Implementing [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96.
• Requiring third-party rule/plugin loading for M12 acceptance.
• Expanding OPY compatibility or beginning OSTW implementation as part of this gate, except verifying compatibility fixes that are independently required by real consumer blockers.

[Teakowa]

PM record: post-M12 roadmap reassessment and #106/#90 priority decision

Recorded per the M12 acceptance criteria (#89 / #100: "PM records a post-M12 roadmap reassessment before decomposing #90/M13"). This is a PM roadmap decision, not the QA verdict for this gate; #100 remains open until QA records independent verification.

M12 status snapshot (repository + issue evidence)

• [M12] Establish lint rule registry and configuration contract #97 (rule registry, c5b46f3), [M12] Add first-class lint CLI and shared structured results #98 (wright lint, a54433b, QA-recorded), [M12] Ship a bounded evidence-backed Workshop stability rule set #99 (stability rule set, SPEC-99 accepted at 666d68d), [M12] Detect no-yield loops with bounded evidence classification #103 (no-yield boundedness evidence, f3665e4) are closed.
• M12-era distribution/docs work (Establish automated binary releases and the Wright v0.1 distribution contract #101/wright analyze findings omit span.path; lint path form is inconsistent (basename vs path-as-given) #102/[Docs] Reorganize README and documentation around durable contracts and historical evidence #107/Add first-class installation and package-manager distribution #108) is closed.
• [M12 acceptance] Verify tooling-first lint and stability platform #100 gate and parent [M12] Tooling-first lint and Workshop stability analysis platform #89 remain open pending QA acceptance.
• CI: the last three commits are green on all core jobs (Rust quality stable + 1.85.0, v1 gates, differential, oracle, adapter, ubuntu distribution); the only failure is Distribution validation (macos-15) → Run installer functional tests → archive missing wright-lsp fails cleanly. This is a Add first-class installation and package-manager distribution #108-era distribution item, not an M12 lint/analyzer defect; it should be fixed or confirmed environmental before this gate closes.

Evidence driving the reassessment

1. M12 delivered the tooling platform; its value is gated by the semantic surface the frontend can process.
2. The first real consumer integration (agent-lab#68 → Fix real-world OPY receiver/member call compatibility (eventPlayer.setMoveSpeed and peers) #104/Add corpus-backed OPY builtin enum coverage for ChaseTimeReeval.NONE and nearby real-world gaps #105) demonstrated that the current OPY surface is corpus-accidental: predictable generic constructs (receiver/member calls, builtin enums) fail serially and force consumers to fall back to OverPy. This is exactly the "concrete tooling/consumer blocker" condition under which Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106 said baseline compatibility becomes milestone-critical.
3. [M13] Source-language interoperability and OSTW compatibility #90's own planning notes require an OSTW reference/corpus investigation before decomposition and state that M12 tooling evidence may change which source-level semantics provide the highest product value. That evidence points at the OPY baseline first.
4. Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106's deliverables (pinned upstream-reference doc, tiered compatibility policy, machine-readable support contract, systematic builtin/enum catalog path, differential strategy) are the same substrate OSTW needs; the reference doc is explicitly extensible to OSTW.
5. [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96's revisit trigger "OSTW interoperability exposes duplicated/inconsistent Workshop content knowledge across frontends" argues for landing the systematic catalog data path before the second frontend.

Priority decision

#106 precedes #90 and is a prerequisite for decomposing/implementing #90.

Sequencing:

1. Close Fix real-world OPY receiver/member call compatibility (eventPlayer.setMoveSpeed and peers) #104 and Add corpus-backed OPY builtin enum coverage for ChaseTimeReeval.NONE and nearby real-world gaps #105 (small, evidence-backed, remove the real consumer fallback; they are the concrete instances Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106 cites).
2. Execute Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106: pinned upstream inventory → tiered policy → centralized upstream-reference doc → machine-readable support contract → systematic builtin/enum catalog path → prioritized child issues grouped by semantic category.
3. [M13] Source-language interoperability and OSTW compatibility #90: the read-only OSTW reference/corpus investigation may proceed in parallel once Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106's upstream-reference doc and support contract exist (it extends the same document); [M13] Source-language interoperability and OSTW compatibility #90 decomposition/implementation is gated on that investigation plus the Establish a proactive OPY compatibility baseline from the pinned upstream language surface #106 baseline being in place. Direct OPY↔OSTW conversion remains a non-goal (ADR-0008 decision 6 unchanged).

Guardrails: #106's own non-goals bound scope (no full-parity inside one issue, no language fork, semantic compatibility over output identity); child issues are prioritized by corpus/consumer evidence (tier C) with legacy quirks kept demand-driven (tier D); the catalog path uses generation + reference validation rather than manual enumeration. #106's catalog is language-compatibility metadata, not a runtime content registry, so #96 remains deferred (no revisit trigger fired).