Skip to content

[M12] Tooling-first lint and Workshop stability analysis platform #89

Description

@Teakowa

Goal

Make Wright's tooling-first product direction concrete by turning the existing Workshop analyses into a configurable lint/analysis platform and validating high-value server-stability rules against real projects.

M12 should deliver developer value before further broad source-language compatibility expansion.

Context

wright-analyzer already has a small hard-coded analysis set (min-wait-loop, duplicate-condition, expensive-loop-check) over WIR/CFG. The current analyze() path constructs a fixed array of analyses. That is sufficient evidence for a rule framework, but not for a large plugin architecture.

Workshop stability guidance is also not universally safe: an "anti-crash" rewrite or rule can itself create load or semantic regressions. Wright should therefore provide evidence-backed findings with explicit confidence/limits rather than encode community advice as unquestionable correctness rules.

ADR-0008 / #88 is the architecture authority. M11/#82 and #88 are complete, so M12 is now the active product-value milestone.

A post-#88 review identified useful future work around Workshop content data, extension boundaries, and independent version identities. That work is recorded in #96 and is explicitly non-blocking/deferred for M12 unless new implementation evidence proves otherwise.

Work items

Scope

  • Define a Wright-owned lint/rule contract over WIR/CFG/semantic services with stable rule IDs, severity, finding metadata, source provenance, and documentation/known-limit fields.
  • Move the current hard-coded analyses behind the rule registry without changing their observable findings unintentionally.
  • Add deterministic configuration for enabling/disabling rules, severity overrides, and bounded rule options where actually required.
  • Add a first-class wright lint workflow backed by the same compiler/session and structured-result contracts as check/analyze.
  • Expose lint findings through existing embedding/tool/agent APIs rather than creating a separate semantic service.
  • Build a small first-party Workshop stability/performance rule set chosen from real corpus evidence, including repeated/expensive evaluation and hot-loop/timing patterns where false-positive risk is acceptable.
  • Reuse the existing cost/resource model where a rule makes resource claims; distinguish exact counts, static indicators, heuristics, and runtime-validated evidence.
  • Preserve an extension-friendly core contract, but defer third-party rule loading/plugin-host implementation and broader extension/version architecture to [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 until concrete evidence justifies it.

Non-goals

  • Treating community "anti-crash" guidance as guaranteed-safe transformations.
  • Claiming precise Overwatch server CPU/runtime cost without runtime evidence.
  • Automatically applying risky performance rewrites.
  • A large ESLint-compatible JavaScript runtime.
  • Implementing or freezing a Rust/WASM/process plugin ABI in M12.
  • Implementing [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 Workshop content-pack/hot-update/versioning work.
  • Expanding OPY/OSTW language syntax merely to increase lint coverage.
  • Implementing OSTW support or Workshop -> source-language conversion in this milestone.

Deliverables

  • Rule registry/configuration contract.
  • wright lint CLI + machine-readable result integration.
  • Existing analyses migrated to the registry.
  • A bounded, corpus-validated first-party stability rule set.
  • Agent/tool API exposure for lint queries/findings.
  • Independent QA/Architect acceptance evidence.

Acceptance criteria

  • The existing three analyzer findings run through the new rule framework and retain regression coverage.
  • Users can enable/disable rules and override severity deterministically without source changes.
  • wright lint works for supported OPY and raw Workshop inputs through the shared driver/session pipeline.
  • Findings preserve original source identity/spans where available and expose structured rule IDs through CLI JSON and tool APIs.
  • Every newly shipped stability rule has positive/negative fixtures plus at least one real-project evidence case or an explicit reason why only synthetic validation is possible.
  • Heuristic findings are labeled as heuristics and do not masquerade as guaranteed runtime behavior.
  • No rule or fixer is justified solely because a wiki/community source calls it "anti-crash".
  • M12 does not require a third-party rule loader, content registry, or other [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 implementation to ship.
  • [M12 acceptance] Verify tooling-first lint and stability platform #100 independently verifies the current implementation and CI before M12 closes.
  • PM records a post-M12 reassessment before decomposing [M13] Source-language interoperability and OSTW compatibility #90/M13.

Planning notes

Keep implementation focused on #97 -> #98 -> #99 -> #100. #97 may begin immediately; #98 follows the registry contract; #99 should use the proven registry/tooling surface rather than designing around hypothetical plugins. Do not mechanically expand OPY compatibility or begin OSTW work during M12 unless a concrete tooling blocker is demonstrated.

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