Apps and revisions

For agents: Inspect current Account authority, exact revisions and native capabilities before acting.

An app belongs to one Userland Account and has a stable app ID. Each environment has an admission epoch, serving state and active deployment pointer. Use the address returned by inspection; do not derive it from the app ID.

Source, configuration, build artifacts, deployments, migration state and binding revisions are separate identities. Save them when an operation completes. Fresh conversations inspect current saved state before modifying it.

An apply operation reserves its intent durably, builds or accepts an executable, resolves resources, runs declared migrations and activates through current authority and revision guards. A pending or failed candidate does not replace the active deployment. A changed request needs a new idempotency key; a lost response requires inspection of the original operation.

Promotion can reuse an exact owned executable, but target bindings and migrations are resolved anew. Restoring data creates isolated resources and does not silently switch the active deployment. Stopping execution revokes new admission and preview authority; it does not delete retained source or data.