Project Model¶

A truST project is a source tree plus a small set of config files that define authoring, runtime, I/O, simulation, and HMI behavior.

Project Files¶

project/
  src/
  trust-lsp.toml
  runtime.toml
  io.toml
  simulation.toml
  hmi/
  program.stbc

File Roles¶

Path	Role
`src/`	project-owned Structured Text sources
`trust-lsp.toml`	editor/LSP configuration, dependencies, vendor profile
`runtime.toml`	execution, control, discovery, mesh, runtime-cloud policy
`io.toml`	driver selection and safe-state I/O behavior
`simulation.toml`	deterministic virtual coupling and fault injection
`hmi/`	declarative operator pages and process graphics
`program.stbc`	compiled bytecode artifact

Reuse Model¶

Use:

[dependencies] in trust-lsp.toml for reusable truST packages that should compile with the project
[[libraries]] for vendor stubs or index-only symbol packs

Keep project logic in src/; do not mix reusable library code into the app root just because it is convenient.

Separation Of Concerns¶

trust-lsp.toml is about authoring and semantic context
runtime.toml is about executing and exposing the runtime
io.toml is about physical or simulated I/O backends
simulation.toml is about deterministic virtual plant behavior
hmi/ is about operator-facing presentation

This separation is important because it lets you change one dimension without rewriting the others. For example, you can swap an I/O backend or turn on simulation without changing the source tree layout.

Lifecycle¶

author/edit files in src/
build into program.stbc
validate config + bundle
run/reload the runtime
optionally drive HMI, tests, or harness scenarios against the same project

Good Practice¶

keep application ST sources under src/
keep reusable libraries out of the app root and model them through dependencies or explicit library entries
treat generated bytecode as a build artifact, not hand-maintained source
keep runtime configuration alongside the project so build, run, and repair loops can be automated consistently