CLI source workflow

The osmiron-dsl binary checks or development-applies one OSL source file. Run the check command through Cargo from the repository root:

cargo run -p osmiron-dsl -- check path/to/model.osl

A file that passes the parser and currently implemented change generation produces no output and exits successfully. A returned lexer, parser, or change generation error produces a source diagnostic on standard error and exits with a failure status.

The command does not accept a base source, inspect stored twin state, apply changes to the engine, or persist a commit.

Development commit

The commit command requires both an input and an explicit target model, then runs the same parsing, change-generation, and ordering checks before applying the ordered changes to a fresh in-memory digital twin:

cargo run -p osmiron-dsl -- commit model.osl development \
  -m "Add warehouse capacity"

The model argument and message establish the future CLI contract. They do not select remote state yet because the Osmiron API is not implemented. The in-memory twin is discarded when the command exits, so a successful development commit is not durable and must not be treated as an accepted state revision.

The development application path currently supports entity creation, deletion, and description changes. Other checked changes return an unsupported-change error instead of being persisted or silently ignored.

Standard input

Pass - to read OSL from standard input:

printf 'entity "vehicle-1" {}' | cargo run -p osmiron-dsl -- check -

Color

Use the global --color option with auto, always, or never:

cargo run -p osmiron-dsl -- --color never check model.osl

Debug output

Use --debug changes to print compact semantic changes in their original source order:

cargo run -p osmiron-dsl -- check --debug changes model.osl

Use --debug order to print dependency generations followed by a dependency tree. Change indexes in both modes refer to the original source order:

cargo run -p osmiron-dsl -- check --debug order model.osl

Repeat the option to print both views. Changes are always printed before the ordered dependency tree:

cargo run -p osmiron-dsl -- check \
  --debug changes --debug order model.osl

Debug output is developer-facing and follows the Rust semantic and dependency type names. Nested values and long generation lists use indented lines to avoid terminal wrapping. The output is not a stable machine-readable format. A dependency absent from the tree may be satisfied by stored twin state rather than another change in the current batch.

Diagnostic families

Diagnostic codes identify the stage that rejected the source:

Diagnostics include the source path and labeled source spans. Some also include help text.

What success means today

The check command is a development tool, not a complete model validator. It lexes, parses, lowers, and dependency-orders the current source, but it does not validate references or generated changes against stored twin state.

Use the command to catch supported source, lowering, and batch-ordering errors. Do not use a zero exit status as proof that the full source has valid operational meaning.