[M13] Establish native OSTW project and syntax frontend foundation

[Teakowa]

Parent: #90
Depends on: #115

Goal

Establish the Wright-owned OSTW frontend boundary and project-loading path needed to parse the first accepted corpus without depending on the upstream .NET runtime.

This issue owns syntax/project infrastructure only. It does not own semantic lowering or Workshop emission.

Context

#115 stabilized the pinned OSTW v3.4.0 oracle and initial corpus. The corrected evidence makes protect-ban the first accepted end-to-end reference project. Its immutable corpus contains 19 licensed files and exercises project settings, imports, rules, macros, arrays, and Workshop calls.

MOBAwatch is reference-rejected under the pinned canonical runtime and is therefore structural evidence only for this phase, not a compile-success gate.

Scope

• Add a Wright-owned wright-ostw frontend crate/module with clear lexer/parser/CST responsibilities and no dependency on upstream implementation code.
• Add SourceKind::Ostw and recognize .ostw / .del inputs through the existing driver/session source model.
• Implement the minimal ds.toml project contract evidenced by protect-ban, starting with entry_point.
• Resolve quoted OSTW imports relative to project/source location and build the complete project source graph through Wright's existing file registry/provenance model.
• Implement lexer/parser coverage for the syntax forms present in the committed protect-ban corpus, preserving exact source spans and file identity.
• Produce deterministic structured syntax/project diagnostics for malformed syntax, missing imports, invalid entry points, and unsupported project configuration.
• Add corpus-driven parse tests over the full pinned protect-ban source closure plus focused negative fixtures.

Non-goals

• Semantic/type/name resolution or HIR lowering; tracked separately.
• OSTW -> Workshop emission.
• Classes, generics, lambdas, pattern matching, or other MOBAwatch-only/advanced semantics merely for surface breadth.
• Workshop -> OSTW reconstruction.
• Copying/mechanically translating the unlicensed OSTW compiler/parser implementation.
• Requiring the pinned oracle in production workflows.
• Designing a generic plugin/content registry ([v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 remains deferred).

Acceptance criteria

• Wright can discover and load the pinned protect-ban project from its ds.toml entry point and complete import closure without upstream runtime support.
• Every committed protect-ban .ostw / .del source is lexed and parsed through the native frontend under the declared syntax boundary.
• Parser/project failures are deterministic, structured, source-located, and use Wright's existing provenance/file registry contracts.
• SourceKind::Ostw participates in the same driver/session input model as Workshop and OPY rather than introducing an OSTW-specific transport/session path.
• No semantic-support claim is made merely because syntax parses.
• Existing tests and CI remain green; the pinned [M13 baseline] Pin the OSTW oracle and acquire the initial real-world corpus #115 oracle/corpus baseline remains unchanged.

Relationships

• First implementation child of [M13] Source-language interoperability and OSTW compatibility #90 after the [M13 baseline] Pin the OSTW oracle and acquire the initial real-world corpus #115 evidence gate.
• Provides the syntax/project prerequisite for the protect-ban semantic slice.
• MOBAwatch may be used for parser robustness evidence only where doing so does not imply semantic/compile support.

[Teakowa]

Engineer implementation evidence (for PM/QA review)

Commit 76a5cd2 (feat(ostw): add the native OSTW syntax/project frontend foundation) on main.

What shipped

• crates/wright-ostw/ — first Wright-owned native OSTW frontend crate (registered in the Cargo workspace): lexer (#/////* */ comments, "..."/@"..." strings, exact spans), CST parser, and the ds.toml project model. Syntax/project infrastructure only: no semantic/type system, no HIR lowering, no emission. Upstream .NET/OSTW is reference-only and absent from the production dependency graph (the crate depends only on wright-ir).
• Driver/session integration — SourceKind::Ostw with .ostw/.del extension detection; the shared CompilerSession dispatches to the native frontend and carries the multi-file registry/provenance. wright check reports the parse/project outcome; compile/analyze/lint/inspect fail with a structured ostw-unsupported diagnostic (exit 3) until emission/semantics exist.

Acceptance evidence (all local, fresh)

• Entire pinned protect-ban closure loads and parses natively: 16/16 committed .ostw/.del files parse (real corpus files at compatibility/ostw/corpus/protect-ban/, entry main.ostw from ds.toml); zero in-closure parse errors.
• Out-of-closure imports are structured, source-located missing-import diagnostics (4 total: customGameSettings.lobby + ../OSTWUtils/{OnScreenText,Cursor,StringSorting}.del). HeroSelect.del's ../OSTWUtils/Diagnostics.del import sits inside a /* */ block comment and is correctly not an import (verified against raw corpus bytes; matches the [M13 baseline] Pin the OSTW oracle and acquire the initial real-world corpus #115 oracle evidence).
• Provenance: every diagnostic span resolves to the correct registry file (interface/HeroSelect.del:4:1, protectBanFull.ostw:1:1, ...); registry ids are deterministic (sorted paths, ds.toml at id 0).
• Determinism: two CLI launch runs on main.ostw --kind ostw are byte-identical ({SCRATCH}/ostw-launch-1.txt = ostw-launch-2.txt); the frontend outcome is also byte-identical across two in-repo runs.
• Negative fixtures (in-repo, focused): malformed syntax → ostw-parse-error with exact span; missing import → ostw-missing-import with span; invalid entry_point → ostw-entry-not-found; unsupported ds.toml key → ostw-ds-toml-unsupported-key (span at the ds.toml line); missing ds.toml → ostw-ds-toml-missing.
• Driver integration tests: extension detection (.ostw/.del → SourceKind::Ostw), shared-session load with registry/provenance in the check result, and the ostw-unsupported guard for compile/analyze.
• No semantic claim: the frontend's public contract is parse/CST/project results only.

MOBAwatch (parser-robustness evidence only, not a gate)

Probed once, not committed as a test: 21/69 files parse cleanly; failures are exactly the documented non-goal constructs (single-quote and $-interpolated strings, generics, advanced expressions) and surface as structured ostw-lex-error/ostw-parse-error. MOBAwatch is not a compile-success contract.

Regression checks

• compatibility/ostw/results.json is byte-identical to the committed [M13 baseline] Pin the OSTW oracle and acquire the initial real-world corpus #115 artifact (git diff empty).
• Compatibility harness: 11/11 tests pass.
• Full workspace: cargo test --workspace --all-targets green (49 suites), cargo fmt --check clean, clippy clean on changed crates.
• CI (run 31877888489, commit 76a5cd2): all 9 jobs success — Rust quality (stable + 1.85.0), v1 gates, OverPy oracle, adapter, differential, dist (ubuntu + macos), and the OSTW reference baseline.

Files added/changed

• Added: crates/wright-ostw/ (Cargo.toml, src/{lib,cst,diag,lexer,parser,project}.rs, tests/parse.rs).
• Changed: Cargo.toml (workspace member), crates/wright-driver/{Cargo.toml,src/config.rs,src/input.rs,src/result.rs,src/session.rs,tests/driver.rs}, crates/wright-cli/{src/main.rs,src/present.rs,src/bin/wright-serve.rs}, docs/cli.md.

Boundary: this is Engineer evidence; PM/QA verdict per the agent-team contract (independent fresh verification). No OSTW parser/type-system/emitter implementation issues were created.

[Teakowa]

PM acceptance recheck — one project-graph blocker remains

76a5cd2 establishes the intended syntax/project boundary and its 9 CI jobs are green. The lexer/parser/CST, SourceKind::Ostw, shared session/provenance integration, structured diagnostics, and parser-robustness sweep are accepted in principle.

However, the current project loader does not yet match the pinned OSTW v3.4.0 entry_point/import semantics closely enough to close #117.

Pinned-reference evidence:

• DsTomlSettings.entry_point is documented upstream as "The main OSTW file to begin analysis and compilation."
• DeltinScript resolves the configured entry point and calls Importer.FromEntryPoint(...).
• Importer.FromEntryPoint recursively adds only files reached through import statements.

Current Wright behavior in crates/wright-ostw/src/project.rs instead recursively walks every .ostw/.del under the project root, parses all of them, resolves all of their imports, and emits ostw-missing-import diagnostics even for files not reachable from entry_point.

This is visible in the Engineer evidence: protect-ban's source files all parse, but four out-of-closure imports are diagnosed. The actual main.ostw entry directly imports Credits.ostw; unreachable side files must not become compilation/project diagnostics merely because they exist under the root.

Required correction before closure

1. Separate project compilation graph from corpus/parser robustness sweep.
2. Build the project graph from ds.toml.entry_point, recursively following supported imports.
3. Emit missing-import/parse diagnostics as project diagnostics only for files reachable from that graph.
4. Keep the existing "all committed protect-ban files parse natively" coverage as an explicit parser-robustness test independent of project membership.
5. Keep deterministic file/provenance identities; do not silently drop unreachable files from any optional workspace/indexing inventory if the architecture wants to retain them, but they must not affect compilation/check correctness until reachable.
6. Add a regression proving an unreachable .ostw/.del file with a broken/missing import does not make the entry-point project fail, while the same broken import does fail when that file becomes reachable.
7. Re-run the pinned [M13 baseline] Pin the OSTW oracle and acquire the initial real-world corpus #115 baseline and current CI.

This is a project-semantics responsibility issue, not #118 type/lowering work. #118 should not start until this boundary is corrected, because its semantic input set must be the reachable entry-point graph rather than every source file in the repository.

[Teakowa]

Engineer evidence: OSTW compilation membership corrected to the entry-point import closure

Commit f8f0b75 (fix(ostw): make compilation membership the entry-point import closure) on main.

What changed

crates/wright-ostw/src/project.rs now builds the compilation graph as a breadth-first walk from ds.toml.entry_point over resolved import targets, with a visited set so cycles and duplicate imports include each file exactly once. Previously every .ostw/.del under the project root was walked and unreachable files could contribute parse/missing-import diagnostics to the entry-point project. Now:

• Only reachable files are parsed and only their imports resolved for project/check diagnostics; an unreachable source with broken syntax or a missing import cannot fail the entry-point project.
• Making that source reachable surfaces its structured, source-located diagnostic (regression-proven both ways).
• The workspace/source inventory (all 16 .ostw/.del under the root) is retained as a distinct, non-diagnostic Project.inventory for tooling; it is never compilation membership.
• Registry ids, spans, and provenance stay deterministic (ds.toml id 0, then the stable BFS walk order).

Corrected protect-ban counts (was 16 parsed / 4 diagnostics → now 7 / 3)

• Compilation closure from main.ostw: 7 files — main, Credits, interface/HeroSelect.del, interface/miscSetup.del, interface/HeroSelectConfig.del, interface/HeroSelectFunctions.del, interface/MapData.del — all parsed.
• 3 reachable missing-import diagnostics — HeroSelect.del's ../OSTWUtils/{OnScreenText,Cursor,StringSorting}.del. The 4→3 change is intentional: protectBanFull.ostw's customGameSettings.lobby import was unreachable-from-entry and no longer contributes, matching the pinned reference's entry-point semantics. The all-16-files parse coverage moved to a separate non-gating inventory-robustness test.
• Deterministic registry: two CLI launch runs on main.ostw --kind ostw are byte-identical ({SCRATCH}/ostw-graph-launch-1.txt = ostw-graph-launch-2.txt).

Regressions added (in-repo, driving the shipped frontend over real corpus files + temp fixtures)

• Entry → reachable import-closure membership.
• Unreachable broken-syntax / missing-import source does not fail the project (zero diagnostics).
• Reachability flip: making that source reachable surfaces its structured source-located diagnostic; removing the import hides it.
• Cycle/duplicate-import determinism: each file once, byte-stable across loads, no duplicate diagnostics (protect-ban's own cycles also covered).

Unchanged integration

SourceKind::Ostw, the shared CompilerSession dispatch/provenance path, and the ostw-unsupported guards for compile/analyze/lint/inspect are unchanged (driver tests assert the same behaviors).

Validation

• Full workspace cargo test --workspace --all-targets green (49 suites); fmt clean; clippy clean on changed crates.
• compatibility/ostw/results.json byte-unchanged; compatibility harness 11/11.
• CI (run 31879336880, commit f8f0b75): all 9 jobs success — Rust quality (stable + 1.85.0), v1 gates, OverPy oracle, adapter, differential, dist ×2, and the pinned OSTW reference baseline.

Boundary: no #118 semantic lowering started; MOBAwatch remains non-gating parser-robustness evidence only.

[Teakowa]

PM acceptance — #117 complete

Accepted after the project-graph correction in f8f0b75.

The final implementation now matches the pinned OSTW v3.4.0 entry-point/import ownership boundary: compilation membership is the deterministic graph reachable from ds.toml.entry_point, while the wider workspace inventory remains separate and non-diagnostic. Unreachable broken imports/syntax no longer affect project correctness; making the same source reachable surfaces structured source-located diagnostics. Parser robustness over all committed protect-ban files remains a separate evidence layer and does not expand semantic support.

The shared SourceKind::Ostw / CompilerSession / provenance architecture remains intact, no semantic lowering leaked into this issue, the #115 baseline is unchanged, and all 9 GitHub Actions jobs for f8f0b75 are green, including Rust 1.85.0 and the OSTW reference baseline.

This establishes the project/syntax prerequisite for #118.