You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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".
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.
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-analyzeralready has a small hard-coded analysis set (min-wait-loop,duplicate-condition,expensive-loop-check) over WIR/CFG. The currentanalyze()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
wright lintworkflow backed by the same compiler/session and structured-result contracts ascheck/analyze.Non-goals
Deliverables
wright lintCLI + machine-readable result integration.Acceptance criteria
wright lintworks for supported OPY and raw Workshop inputs through the shared driver/session pipeline.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.