Skip to content

Compile, Validate, Reload / Hot Reload

This is the public hot-reload path for truST: diagnose first, then rebuild, then reload only when the project is clean enough to run.

For automated tools

The preferred machine-facing loop is:

  1. workspace.write
  2. lsp.diagnostics
  3. lsp.format
  4. runtime.compile_reload

runtime.compile_reload is the one-call repair loop because it:

  • collects diagnostics
  • blocks on errors
  • builds the program image program.tpi when diagnostics are clean
  • sends the image with bytecode.reload to the runtime control endpoint, which changes the running program online

Example JSON-RPC Session

cat <<'EOF' | trust-dev agent serve --project ./examples/memory_marker_counter
{"jsonrpc":"2.0","id":1,"method":"workspace.project_info","params":{}}
{"jsonrpc":"2.0","id":2,"method":"lsp.diagnostics","params":{}}
{"jsonrpc":"2.0","id":3,"method":"runtime.compile_reload","params":{}}
EOF

Important result fields:

  • errors
  • warnings
  • issues
  • runtimeStatus
  • runtimeMessage
  • optional build
  • optional reload

Current runtimeStatus values are:

  • ok
  • skipped
  • error

When reload is skipped

Reload is intentionally blocked when diagnostics contain errors. That keeps agents and editors from pushing an obviously broken program into a live runtime. In other words, hot reload is guarded by diagnostics instead of replacing the running program with a broken one.

Editor Path

Humans usually take the same loop through:

  • VS Code diagnostics
  • formatting
  • truST sidebar, Live Values, and debugger

The point is the same even when the transport differs: one consistent path from edit to validated running state.