Make current-directory targets first-class and delegate automatic entry discovery to source owners

[Teakowa]

Goal

Make project-oriented Wright workflows usable without requiring an explicit entry file when the current directory or another directory is the intended source target.

The product contract should support:

wright check
wright check .
wright check path/to/project
wright compile

while preserving explicit file targets and stdin. Wright identifies the user-selected filesystem target and source language; the owning source implementation determines the effective entry, project root, and source closure according to that language's rules.

Context

#40 implemented extension-based input-kind detection, explicit file/root handling, and stdin/stdout workflows. #243 later established the source-owner boundary for an explicitly selected entry target. Both contracts are complete, but real-project validation exposed a remaining product gap: omitting INPUT still means stdin, and Wright cannot treat the current directory as a project target.

This matters for the next real-product stage: OWBastion/Bastion and Teakowa/Overwatch-AI-PVE are ready to migrate their OverPy compiler gates to Wright, and that migration should exercise the normal project UX rather than depend permanently on wrapper-specific explicit entry/root arguments.

Automatic entry discovery must not become a generic Wright project loader. The source forms have different ownership and project semantics:

• raw Workshop is single-source and has no language-level multi-file project model;
• OPY owns #!mainFile, #!include, preprocessing/macros, project/root discovery, and source closure;
• DEL/OSTW owns ds.toml, file/directory project discovery, imports, and source closure.

Approved product contract

Input target semantics

For project-oriented workflows such as check, lint, analyze, inspect, and compile where applicable:

• omitted INPUT means the current working directory;
• . or another directory is a directory/project target;
• an explicit file remains an explicit source target;
• - explicitly selects stdin;
• --kind remains the explicit source-kind override when automatic detection is ambiguous;
• --root remains an explicit escape hatch where a source owner/workflow still requires it, but ordinary project use should not require it merely to compensate for missing directory-target support.

Changing omitted input from implicit stdin to current-directory targeting is intentional. Stdin remains available through explicit -.

Wright ownership

Wright may perform only the minimum filesystem inspection needed to identify the source owner for a directory target. It must not recursively collect source-language files or interpret source-language project semantics.

If a directory clearly contains multiple incompatible source-language project candidates and no owner can be selected unambiguously, fail explicitly and require --kind or an explicit target. Do not establish a hidden source-language precedence.

Raw Workshop

Raw Workshop remains a single-source in-process workshop-rs workflow.

For a directory target, Wright may select a raw Workshop source only when there is one unambiguous eligible source under the declared discovery contract. Multiple plausible raw Workshop entries must fail as ambiguous rather than inventing a multi-file Workshop project model.

OPY

For an OPY directory target, Wright delegates effective entry/root/source-closure discovery to opy-rs.

Wright must not parse or interpret #!mainFile, #!include, preprocessing directives, or OPY project structure. Multiple product-specific OPY entries remain distinct build targets: automatic discovery chooses only the language owner's default project entry; alternate entries such as development/external profiles are still selected explicitly by the caller.

DEL/OSTW

For a DEL/OSTW directory target, deltin-rs owns effective project/entry resolution, including ds.toml, its entry_point, imports, and default project conventions.

Directory-target support must not be interpreted as a claim that the full DEL/OSTW compile surface is product-ready; engine readiness remains independently evidence-gated.

Provider/LPP boundary

The existing LPP entry/project-loading contract is file-entry based. If provider-backed directory targets cannot be represented without Wright selecting a language-specific entry file, evolve the owning LPP contract to carry a filesystem/project target that may be a file or directory.

Any protocol change must remain language-neutral and limited to target handoff. Do not add generic workspace synchronization, package/project models, source-closure discovery, or source-language semantics to LPP.

Scope

• Make omitted workflow input resolve to the invocation current directory instead of stdin.
• Preserve explicit stdin through -.
• Represent file and directory targets distinctly through the Wright product/driver boundary where needed.
• Add minimal automatic source-owner selection for directory targets with explicit ambiguity failures.
• Delegate OPY and future DEL/OSTW entry/project discovery to their owning implementations.
• Keep raw Workshop discovery single-source and in-process.
• Preserve explicit file targets, absolute/relative path behavior, --kind, locale, output, renderer, and machine-result contracts.
• Add the smallest LPP/adapter dependency required to pass a provider-owned directory/project target if the current wire contract is insufficient.
• Verify the default current-directory path against real OPY projects before treating the feature as complete.

Non-goals

• A generic Wright workspace scanner or project graph.
• Recursive OPY/DEL file collection in Wright.
• Parsing #!mainFile, #!include, ds.toml, imports, or other source-language project semantics in Wright.
• Selecting among application-specific build profiles such as Bastion development/external entries or AI-PVE ARAM entries.
• A Wright project manifest, package manager, dependency solver, or source-language precedence table.
• General LSP workspace/document synchronization.
• Expanding DEL/OSTW compiler support merely to complete automatic entry discovery.
• Migrating Bastion or Overwatch-AI-PVE CI in this issue; those migrations follow once a released Wright build proves this contract.

Acceptance criteria

• From a supported project root, wright check behaves as wright check . and does not read stdin implicitly.
• wright <workflow> - continues to provide explicit stdin behavior where that workflow supports stdin.
• Explicit relative and absolute file targets remain compatible.
• Directory source-kind detection either selects one justified owner or fails explicitly with actionable --kind/target guidance; no hidden language precedence is introduced.
• Raw Workshop directory discovery remains single-source and fails on ambiguous multiple entries.
• OPY directory targets reach opy-rs without Wright interpreting #!mainFile, includes, preprocessing/macros, project root, or source closure.
• DEL/OSTW directory targets are representable through the same product boundary and remain owned by deltin-rs; no DEL project semantics are added to Wright.
• The provider/LPP path can represent an owner-resolved directory/project target without requiring Wright to preselect a language-specific source entry; any required wire change is implemented in the owning protocol repository and consumed here.
• Bastion's default OPY project entry can run through the zero-argument/current-directory workflow while alternate entries remain explicit.
• Overwatch-AI-PVE's default OPY project entry can run through the zero-argument/current-directory workflow without a Wright-side OPY project loader.
• Ambiguous/missing-entry cases return structured, deterministic user errors rather than silently choosing an arbitrary source file.
• Existing explicit-entry real-project workflows and machine-readable result/exit-code contracts remain regression-green.
• Independent implementation ablation removes/disables directory-target resolution and demonstrates that the zero-argument real-project regression evidence fails again.

Dependencies / ownership

• [M6] Add source/project discovery and stdin/stdout workflows #40 — completed historical input-kind/stdin/root discovery contract; do not reopen.
• Converge source-language workflows on an explicit provider boundary #243 — completed explicit entry-based source-owner/product boundary; this issue extends the user target from explicit entry files to directory/current-directory targets without changing ownership.
• language-provider-protocol#16 — existing provider-owned project-loading contract from a selected file entry; protocol evolution belongs in LPP if directory targets require a wider wire contract.
• wright: CLI/default-target UX, source-owner selection, product/driver seam, ambiguity handling, provider adapter/orchestration.
• opy-rs: OPY effective entry/root/project/source-closure discovery and semantics.
• deltin-rs: DEL/OSTW effective entry/project/import discovery and semantics.
• workshop-rs: canonical raw Workshop parsing/validation/WIR/emission used by the single-source in-process path.

After this contract is released and independently verified, migrate Bastion and Overwatch-AI-PVE compiler CI gates to Wright in their owning repositories and use those migrations as the next production evidence layer.

[Teakowa]

Current-reality reconciliation: PR #318 is merged. The directory/current-directory target contract is implemented through Wright, LPP 1.2/1.3, and the OPY owner; released OPY evidence covers zero-argument checks for Overwatch and Bastion, plus Bastion compile/source identity, with independent ablation for omitted-input behavior. Downstream migration of Bastion and Overwatch-AI-PVE CI remains a separate product-adoption step after the Wright release and is not part of this issue's implementation contract. Closing as completed.