Debugging declarative applications

Documentation status: guide — see Maturity and evidence.

Debugging starts from the model dependency chain, not from the script body.

Diagnostic order

Use this order because each layer depends on the previous one:

application configuration
  -> package activation
  -> manifest membership
  -> model compilation
  -> concept registration
  -> object creation
  -> collection provider
  -> action binding
  -> event routing
  -> view cursor and datasets
  -> persistence
  -> publication/service mapping

Common symptoms map to specific layers. If a model never appears in compile logs, inspect configuration, package activation, schema paths, and manifest membership. If there is no Entity record, inspect the conceptual Entity declaration rather than only type: Entity. If no polyadic map can be built, verify semantic registration and compatible positive roles. For duplicate classId, inspect every active package and manifest. If the source used at runtime differs from the edited file, inspect the resolved physical package/model path.

Smoke test

A generic runtime smoke test is:

sclgc -c <path-to-application.lgc>

Then read the log in order: application, package, manifest, model, collections, semantic initialization, runtime start. Stop at the first layer where the expected module disappears.

Useful runtime options include long/short pairs such as --debug / -dbg, --log-level / -ll, --test / -t, --test-out / -to, --modules / -m, and --services / -sg. Verify availability on the target runtime before automating a command surface.