create-flowdular 0.2.4 → 0.2.5

package/agent-template/AGENTS.md

@@ -0,0 +1,77 @@
+<!-- Source: .ai/rules/flowdular.md. Run pnpm rules:generate; never edit generated copies. -->
+
+# Flowdular
+
+An agentic foundation that businesses extend with their own modules.
+
+## One task, one skill
+
+Choose the most specific task in `.ai/skills/README.md` and read only that
+`.ai/skills/<name>/SKILL.md`. Announce the choice briefly. For a multi-part
+request, finish one bounded phase before switching skills. Do not recursively
+load other skills mentioned by a skill. Read referenced code or documentation
+only when the current task needs it. Explicit user instructions take priority.
+
+Sandbox: use the single skill named under Session, at
+`reference/skills/<name>/SKILL.md`. Follow the role's write paths and handoff list.
+Do not load the whole skill catalog into the task context.
+
+## Always-active invariants
+
+1. Stay within the requested scope. Preserve other agents' edits. Read the owning
+   code before changing it. Do not invent missing business decisions.
+2. Spec-first: a new module requires an approved `spec/module.yaml`. Sandbox
+   implementation requires operator approval of the exact current spec hash;
+   any spec change invalidates it. Never infer or grant approval yourself.
+   Only explicit user approval naming a spec permits the host `spec-approval` action.
+3. Deny by default. Use `defineEndpoint`, an explicit permission and identity
+   resolver. Mutations enforce CSRF and bounded input validation.
+4. Tenant identity comes from the authenticated principal, never request input.
+   Use bound SQL, tenant predicates and `transaction(..., { tenantId, access })`.
+   Tenant tables enforce RLS with `USING` and `WITH CHECK`. Runtime roles have
+   neither superuser nor `BYPASSRLS`; migration leases are for DDL only.
+5. Never expose credentials in output, logs or audit. Cross-module access uses
+   declared public capabilities or registered tools, never another module's DB.
+   Agent instructions cannot expand permissions or tool grants.
+6. Persist background work before acknowledging it. Preserve idempotency,
+   leases, recovery and audit evidence. Drain async work before releasing resources.
+7. Applied migrations are immutable. Add numbered PostgreSQL SQL and mirror it
+   byte for byte in `databaseMigrations`. Never bypass checksum or adoption checks.
+8. Generated composition is CLI-owned: `platform/octane.config.ts`,
+   `platform/src/App.tsrx`, `platform/src/generated/**`, platform package
+   dependencies and `flowdular.json` enabled modules. Use `module enable/sync --apply`.
+   Declare imports and dependencies; keep module, package and spec versions aligned.
+9. Use shared `@flowdular/sdk/ui` components and tokens. Keep all locales in sync.
+   UI states: loading, empty, error, populated, denied. Inspect rendered UI after changes.
+10. Prove fixes with regression tests. Never skip assertions, weaken isolation or
+    hide errors to make gates green. Run scoped checks, then `pnpm verify` before a PR.
+    Finish implementation, then run the `auto-review` skill as a separate phase
+    before completion or delivery. Report actual results and remaining failures.
+11. Destructive actions require the runner's flags and explicit scope.
+    `setup quick` and `auth greenfield` are local resets: preview, stop the app,
+    never target a custom or deployed DB. Sandbox agents cannot install, use
+    network/git, or touch a DB outside their module tests.
+12. Keep handoffs short and factual. No AI attribution footers or em/en dashes.
+    Sandbox final line: `HANDOFF: <allowed-role> - <why>` or
+    `HANDOFF: none - <why>`, never your own role.
+
+Detailed recipes: `docs/agent-contract.md` (lookup only).
+Reference module: `.ai/references/catalog`; visual contract: `docs/design-system.md`.
+
+## Application workspace
+
+For application work, use the path and task map in
+.ai/guides/application-development.md.
+
+This is a generated application consuming the published Flowdular SDK. Extend
+this application's modules; never edit installed dependencies. Upstream paths
+such as packages/server and core modules/auth refer to the read-only SDK under
+platform/node_modules/@flowdular/sdk after installation. Sandbox implementation
+sources belong to the separate @flowdular/sandbox package. A core change must be
+made in the Flowdular repository and released before this application uses it.
+
+The skills and examples use @flowdular/sdk subpath imports. For pnpm --filter,
+read the actual module package name from its package.json. Use pnpm verify and
+pnpm build for this application. Root .ai files are editable project guidance;
+run pnpm rules:generate after changing rules or skills, then pnpm rules:check.
+AGENTS.md, CLAUDE.md, .agents/skills and .claude/skills are generated copies.

package/agent-template/CLAUDE.md

@@ -0,0 +1,77 @@
+<!-- Source: .ai/rules/flowdular.md. Run pnpm rules:generate; never edit generated copies. -->
+
+# Flowdular
+
+An agentic foundation that businesses extend with their own modules.
+
+## One task, one skill
+
+Choose the most specific task in `.ai/skills/README.md` and read only that
+`.ai/skills/<name>/SKILL.md`. Announce the choice briefly. For a multi-part
+request, finish one bounded phase before switching skills. Do not recursively
+load other skills mentioned by a skill. Read referenced code or documentation
+only when the current task needs it. Explicit user instructions take priority.
+
+Sandbox: use the single skill named under Session, at
+`reference/skills/<name>/SKILL.md`. Follow the role's write paths and handoff list.
+Do not load the whole skill catalog into the task context.
+
+## Always-active invariants
+
+1. Stay within the requested scope. Preserve other agents' edits. Read the owning
+   code before changing it. Do not invent missing business decisions.
+2. Spec-first: a new module requires an approved `spec/module.yaml`. Sandbox
+   implementation requires operator approval of the exact current spec hash;
+   any spec change invalidates it. Never infer or grant approval yourself.
+   Only explicit user approval naming a spec permits the host `spec-approval` action.
+3. Deny by default. Use `defineEndpoint`, an explicit permission and identity
+   resolver. Mutations enforce CSRF and bounded input validation.
+4. Tenant identity comes from the authenticated principal, never request input.
+   Use bound SQL, tenant predicates and `transaction(..., { tenantId, access })`.
+   Tenant tables enforce RLS with `USING` and `WITH CHECK`. Runtime roles have
+   neither superuser nor `BYPASSRLS`; migration leases are for DDL only.
+5. Never expose credentials in output, logs or audit. Cross-module access uses
+   declared public capabilities or registered tools, never another module's DB.
+   Agent instructions cannot expand permissions or tool grants.
+6. Persist background work before acknowledging it. Preserve idempotency,
+   leases, recovery and audit evidence. Drain async work before releasing resources.
+7. Applied migrations are immutable. Add numbered PostgreSQL SQL and mirror it
+   byte for byte in `databaseMigrations`. Never bypass checksum or adoption checks.
+8. Generated composition is CLI-owned: `platform/octane.config.ts`,
+   `platform/src/App.tsrx`, `platform/src/generated/**`, platform package
+   dependencies and `flowdular.json` enabled modules. Use `module enable/sync --apply`.
+   Declare imports and dependencies; keep module, package and spec versions aligned.
+9. Use shared `@flowdular/sdk/ui` components and tokens. Keep all locales in sync.
+   UI states: loading, empty, error, populated, denied. Inspect rendered UI after changes.
+10. Prove fixes with regression tests. Never skip assertions, weaken isolation or
+    hide errors to make gates green. Run scoped checks, then `pnpm verify` before a PR.
+    Finish implementation, then run the `auto-review` skill as a separate phase
+    before completion or delivery. Report actual results and remaining failures.
+11. Destructive actions require the runner's flags and explicit scope.
+    `setup quick` and `auth greenfield` are local resets: preview, stop the app,
+    never target a custom or deployed DB. Sandbox agents cannot install, use
+    network/git, or touch a DB outside their module tests.
+12. Keep handoffs short and factual. No AI attribution footers or em/en dashes.
+    Sandbox final line: `HANDOFF: <allowed-role> - <why>` or
+    `HANDOFF: none - <why>`, never your own role.
+
+Detailed recipes: `docs/agent-contract.md` (lookup only).
+Reference module: `.ai/references/catalog`; visual contract: `docs/design-system.md`.
+
+## Application workspace
+
+For application work, use the path and task map in
+.ai/guides/application-development.md.
+
+This is a generated application consuming the published Flowdular SDK. Extend
+this application's modules; never edit installed dependencies. Upstream paths
+such as packages/server and core modules/auth refer to the read-only SDK under
+platform/node_modules/@flowdular/sdk after installation. Sandbox implementation
+sources belong to the separate @flowdular/sandbox package. A core change must be
+made in the Flowdular repository and released before this application uses it.
+
+The skills and examples use @flowdular/sdk subpath imports. For pnpm --filter,
+read the actual module package name from its package.json. Use pnpm verify and
+pnpm build for this application. Root .ai files are editable project guidance;
+run pnpm rules:generate after changing rules or skills, then pnpm rules:check.
+AGENTS.md, CLAUDE.md, .agents/skills and .claude/skills are generated copies.

package/agent-template/docs/adr/0001-development-reload.md

@@ -0,0 +1,16 @@
+# ADR 0001: Development reload boundaries
+
+- Status: accepted
+- Date: 2026-08-31
+
+## Decision
+
+The application shell uses Vite HMR during development. TSRX, styles, and ordinary client modules update without restarting the full application server.
+
+`platform/scripts/dev.mjs` owns the developer-facing startup output. The default view shows the application URL, authentication adapter, and reload status while suppressing repeated tool warnings. `--verbose` exposes native Vite and plugin diagnostics. File-change messages use the stable `[octane:reload]` framework prefix, and persistence under `.flowdular/data` is excluded from the watcher.
+
+`platform/index.html` includes a small critical splash outside the hydration root. It is visible from the first HTML frame and remains through session resolution, workspace selection, module loading, and workspace preparation. The authenticated or anonymous root dispatches `flowdular:ready` only when the first stable application state is ready. The splash then leaves after a minimum display interval, respects reduced-motion preferences, and is disabled when JavaScript is unavailable. This prevents an unstyled workspace-selection frame and removes white transitions before authentication or the application shell.
+
+State-preserving HMR is deferred. Segment already provides dehydration and hydration primitives, but preserving state across code changes needs an explicit compatibility contract for schema versions, invalid snapshots, module disposal, and server-rendered state. Until that contract exists, a full module replacement may reset local shell state.
+
+The sandbox preview runtime will own the future state-preserving behavior because it can isolate one module, fixture, and state schema without affecting the full ERP runtime.

package/agent-template/docs/adr/0002-durable-agent-execution.md

@@ -0,0 +1,21 @@
+# ADR 0002: Durable agent execution
+
+- Status: accepted; the storage paragraph is superseded (2026-09)
+- Date: 2026-08-31
+
+> Superseded in part (2026-09): `agents.core` no longer owns a SQLite file. It
+> holds the same data in the shared platform PostgreSQL database through a
+> provider lease. Everything else here, including the rule that this data is not
+> an integration path, is unchanged.
+
+## Decision
+
+`agents.core` owns tenant-scoped agent definitions, a durable execution queue, run history, execution events, and module-local audit evidence. An enqueue request commits a queued run before it returns `202 Accepted`. A background worker claims work with an expiring lease, renews the lease while active, and recovers queued or expired claims after runtime restart.
+
+The browser and session that requested a run do not own its lifecycle. Closing the page, navigating away, or signing out after the enqueue commit does not cancel the run. The run stores an immutable snapshot of the agent revision, provider, model, limits, input, initiating subject, tool grants, and permission evidence used to authorize the request.
+
+Agent instructions are data, not authority. The harness exposes only tools registered by the platform composition root. Each tool records either an approved API endpoint identifier or an approved CLI capability identifier, declares required permissions, and receives a trusted tenant and subject context. Agent code must not import business repositories, open another module's database, execute arbitrary shell commands, or load executable code at runtime.
+
+The local simulation provider is deterministic and performs no network request. Production providers and business tools must be registered explicitly and receive separate specifications, secret handling, budgets, rate limits, and operational monitoring.
+
+`agents.core` may use its own SQLite database for agent definitions, queue state, events, and audit records. That database is not an integration path to ERP business data.

package/agent-template/docs/adr/0003-module-settings.md

@@ -0,0 +1,22 @@
+# ADR 0003: Namespaced module settings
+
+- Status: accepted, runtime implemented 2026-09-01
+- Date: 2026-08-31
+
+## Decision
+
+Every setting is declared and owned by one module. Its stable key is the module identifier plus a module-local key, such as `auth.core.allowSignUp`. A declaration fixes the value type, default value, visibility, client exposure, and secret status.
+
+A module may read another module's setting only when its manifest declares a direct dependency on the owner and the setting is explicitly marked shared. Private or secret settings never cross that boundary. Secret settings cannot be included in a client snapshot.
+
+The first setting is `auth.core.allowSignUp`. The server is authoritative and rejects sign-up when it is disabled. The client configuration endpoint exposes only the client-safe boolean so the public authentication screen can hide the sign-up action. The environment variable `FD_AUTH_ALLOW_SIGN_UP` supplies the initial deployment value.
+
+## Runtime (amendment, 2026-09-01)
+
+- `@flowdular/sdk/kernel` exports `ModuleSettingsRuntime` (`declare`, `get`, `list`, `set`, `onChange`) and `createModuleSettingsRuntime(store)`. Values live in `module_settings` in auth.db (`tenant_id`, `module_id`, `key`, `value_json`, `updated_at`, `updated_by`); `auth.core` provides the store and exposes the runtime as `authRuntime.moduleSettings`.
+- A setting is tenant-scoped by default. `scope: 'platform'` stores one value for the whole deployment (tenant id `''`); auth uses it for knobs that apply before a tenant is known (sign-up, session policy, password length, sign-in providers).
+- Environment variables only supply the declared default. A stored value wins at read time; reads are live, never snapshotted at boot.
+- A module declares settings by returning `settings` from `createServerComposition`; the platform registers every declaration after composing, then calls each composition's `start()`.
+- Administration: `GET /api/settings` (`system.settings.read`) lists every declaration with its current tenant value and metadata; `POST /api/settings/update` (`system.settings.manage`, session only) validates against the declaration, stores or clears the value, and appends `settings.updated` to the auth audit trail. Secrets are write-only: the API returns whether a value is set, never the value. Administration > Modules renders the selected module's declarations in its Settings drawer section. Administration > Settings contains only workspace and organization settings.
+- `emailConfirmation` cannot be enabled while no mail transport is composed; the API refuses with `MAIL_TRANSPORT_REQUIRED` and the screen shows the setting as locked.
+- The cross-module read rule (declared dependency, shared, non-secret) is not enforced by `get`; it is a review rule until a requester-aware read exists.

package/agent-template/docs/adr/0004-enterprise-access-and-audit.md

@@ -0,0 +1,36 @@
+# ADR 0004: Enterprise access and audit boundaries
+
+- Status: proposed; first increment landed in auth.core on 2026-09-01
+- Date: 2026-08-31
+
+## Context
+
+The current authentication core provides tenant membership roles and explicit scopes. Module endpoints deny missing scopes, Development is owner-only, and agent runs snapshot the initiating subject and authorization evidence. This is a secure first phase, but it is not the complete enterprise RBAC and audit model.
+
+## Proposed direction
+
+`access.core` should own custom roles, permission grants, user and group assignments, resource constraints, temporary grants, segregation-of-duties policies, and an authorization decision API. Business modules should depend on this API instead of interpreting role names.
+
+`audit.core` should own a central append-only event contract, tenant and actor indexing, integrity verification, retention policy, redaction, export, and external sink delivery. Module-local audit writers should publish into that contract. Sensitive values, credentials, raw session tokens, and unrestricted request bodies must never enter audit metadata.
+
+Background agents should receive a bounded execution grant at enqueue time. Every API or CLI tool invocation must still pass through the target capability's server-side authorization and audit boundary. Revocation policy for queued work, approval workflows, privileged access, and emergency access require explicit acceptance scenarios before implementation.
+
+Until those modules are approved and implemented, the platform must describe its current model as scope-based authorization with module-local audit evidence, not full enterprise RBAC or centralized compliance audit.
+
+## First increment in auth.core (amendment, 2026-09-01)
+
+Custom roles and the auth audit trail now live in `auth.core`, sized to what a workspace administrator needs today and shaped so `access.core` and `audit.core` can take them over without a data migration of meaning:
+
+- `auth_roles` holds one row per tenant role. The built-in `owner` and `member` rows are seeded per tenant from the static scope lists and are read-only; custom roles carry a subset of the scopes the workspace can grant (`AuthService.listGrantableScopes`). `auth_memberships.role_id` points at the row and the legacy `role` string stays in sync. Assigning a role replaces the membership scopes with the role's scopes; changing a role's scopes updates every holder; a role in use cannot be deleted. Endpoints: `/api/auth/roles` (`auth.roles.read`, `auth.roles.manage`).
+- Member administration goes through the auth administration port with the acting principal: only an owner may create, promote, or change an owner; a non-owner may only hand out scopes it holds; a tenant always keeps one active owner; nobody edits their own membership from the directory.
+- `auth_audit` is an append-only, tenant-indexed table (`tenant_id, actor, action, subject_type, subject_id, metadata_json, occurred_at`) written for sign-in success, failure, and lockout, sign-out, session revocation, password change and reset, token issue and revoke, member create, update, status, scopes, role, and removal, role create, update, and delete, workspace rename, and settings updates. It is readable per tenant through `GET /api/auth/audit` (`auth.audit.read`) with a cursor on `(occurred_at, id)`. Metadata never carries credentials, raw tokens, or request bodies. Unauthenticated failures for unknown addresses are not attributed to any tenant. Hash chaining, retention, export, and sinks remain with `audit.core`.
+
+## Unified audit history (amendment, 2026-09-01)
+
+The three module-local trails are now readable from one screen without merging their storage. `auth.core`'s Administration > Audit view carries a source selector (Platform, Agents, Sandbox), derived from the reader's scopes, and renders any source in one table (time, actor, action, subject, details).
+
+- Agents: `GET /api/agent-audit` and `GET /api/agent-audit/verify`, both behind `agents.runs.read`.
+- Sandbox: `GET /api/sandbox/audit` and `GET /api/sandbox/audit/verify`, both behind `sandbox.sessions.read` (the list moved off `sandbox.access.manage` so a read scope guards a read).
+- Auth: `GET /api/auth/audit` (`auth.audit.read`), unchanged.
+
+Every list endpoint is tenant-scoped from the principal and pages on `(occurred_at, id)`. For the hash-chained agent and sandbox trails the second half of the cursor is the append `sequence`, which is the row's position in the chain and the order the `(tenant_id, occurred_at, sequence)` index keeps. Those two trails are hash-chained; their verify endpoint recomputes the chain and returns `{ verified, brokenAt }` from the same repository walk the `flowdular <module> audit-verify` CLI uses, so the CLI and the endpoint cannot drift. The platform trail is append-only but not chained, so it shows no integrity indicator. Central hash chaining across trails, retention, export, and sinks still belong to `audit.core`.

package/agent-template/docs/adr/0005-sandbox-runtime-and-coding-agents.md

@@ -0,0 +1,81 @@
+# ADR 0005: Sandbox runtime, coding agents, and sandbox access
+
+- Status: accepted
+- Date: 2026-08-31
+
+## Context
+
+Part 2 of the architecture describes an agentic sandbox that builds one module in isolation and previews it without booting the complete platform. Three questions were left open: how the sandbox is distributed, which agent writes the module source, and how a person is authorized to use it.
+
+The platform already ships `agents.core` and `@flowdular/sdk/harness`. That runtime is a shared in-product capability: business modules use it to run bounded agents against registered API and CLI tools. It is deliberately not a coding agent. It cannot open a workspace, edit source files, or run gates, and it must not gain those powers.
+
+## Decision
+
+### Distribution and runtime modes
+
+The sandbox is an independently executable package, `@flowdular/sandbox`, with a `flowdular-sandbox` binary. It is started from a Flowdular workspace and discovers that workspace by walking up to `flowdular.json`. Its first-class launch path is `npx @flowdular/sandbox`.
+
+It runs in one of two modes.
+
+- `loopback`: the default for a developer machine. It binds a loopback interface only and may offer locally installed coding agent binaries.
+- `self-hosted`: a deployed sandbox. It binds a configured interface, requires the same session and grant checks, and never offers local binaries. Bring-your-own-key providers are the only coding agent backends.
+
+The mode is explicit configuration, not inference. A sandbox that cannot prove it is loopback treats itself as self-hosted.
+
+### Coding agent adapter
+
+Coding agents are a separate contract in `@flowdular/coding-agent`. A driver receives a session workspace, a bounded instruction, and a turn input, and returns an ordered stream of normalized events: assistant text, reasoning summary, tool activity, file change, error, and turn completion with usage.
+
+Three drivers are bundled.
+
+- `claude-code`: the locally installed `claude` binary in print mode with a streamed JSON protocol, restricted tools, and the session workspace as its only writable directory. It uses the operator's existing subscription login. Loopback only.
+- `codex`: the locally installed `codex` binary in `exec` mode with JSONL events and a workspace-write sandbox. Loopback only.
+- `byok`: the Vercel AI SDK with Anthropic, OpenAI, Azure OpenAI, and OpenAI-compatible kinds, driving the sandbox's own bounded file and gate tools. Available in both modes and required in `self-hosted`.
+
+A driver is offered only after a capability probe succeeds. Local drivers are probed by executing the binary's version command; the byok driver is probed by an existing credential. The driver is chosen when the session is created, next to the brief, and is recorded in the session's audit trail. Roles are never chosen by hand at that point: the planner picks the first specialist and the handoff decides every later one.
+
+The two agent systems stay separate. The sandbox never uses `@flowdular/sdk/harness` to write code, and `agents.core` never gains file system or process tools. A draft module that uses `agents.core` is previewed through the normal module contract.
+
+### Turn handoff
+
+A turn ends with a decision about who continues, never with silence. Each role closes its final message with one handoff line naming the next specialist or `none`. The orchestrator validates that line against the registered roles and falls back to the deterministic state routing when it is missing or unknown, so a driver that ignores the instruction still produces a usable next step.
+
+The resulting plan is durable, written into the transcript with the turn that produced it, and has five shapes: `continue` (a specialist takes over with a prompt carrying the original brief), `approval` (a new module's draft specification waits for the operator, who approves it with one click that moves only the `status` line), `question` (the turn changed nothing and needs an answer), `review` (the work is ready to inspect and eject), and `blocked` (the driver errored).
+
+A `continue` runs by itself while the session's auto handoff is on, bounded to a small number of chained turns per operator message, and otherwise waits behind a button. A failed gate is its own handoff back to the specialist that caused it, so a broken change never travels down the chain.
+
+### Preview and data
+
+A session owns an isolated workspace directory and an ephemeral database. The sandbox composes the draft module's server routes at their declared paths and renders its client contribution inside a preview host that supplies the platform's identity, tenant, locale, and ACL contracts.
+
+Preview data has two modes. `fixtures` is the default and is fully offline. `bridge` forwards any API path the draft does not own to a running full platform, using a server-held session for the signed-in account, so a draft screen can read real records from other enabled modules under the platform's own authorization. The bridge is refused when the session lacks the data scope, when the target origin is not configured, or when the sandbox runs without an authenticated principal.
+
+### Access
+
+`sandbox.core` is a normal module of the full platform. It owns sandbox scopes, tenant-scoped access grants, session metadata, and its audit evidence. Access is created and assigned either from the full application, by an owner with the management scope, or from the CLI with `flowdular sandbox` commands. Both paths write the same grant records.
+
+Signing in to the sandbox requires an active `auth.core` account, the `sandbox.access.use` scope on the selected tenant membership, and a grant that is neither revoked nor expired. The sandbox issues its own cookie and never accepts the platform cookie as a sandbox session.
+
+Ejecting a draft into `modules/` is a separate scope and a separate CLI capability with a dry run by default. Eject never writes the platform composition by hand: it copies the module, validates it, and calls the existing `module enable` capability.
+
+## Amendments
+
+- 2026-09-01: A session workspace is a pnpm workspace of its own. Draft
+  modules are its projects, every other workspace package is linked to the live
+  checkout through `overrides`, the host lockfile seeds the resolution, and
+  gates run with the module's own installed binaries. A session may carry
+  several modules (`modules[]` in the record, primary first); they are
+  materialized, diffed, gated, previewed and delivered together.
+- 2026-09-01: Turns are detached from the request that starts them and
+  automatic handoffs are chained server-side (limit four per operator message).
+  A declared handoff is honoured only when it names a role the finishing role
+  may hand to.
+- 2026-09-01: Delivery is a target behind `DeliveryTarget`
+  (`available`, `plan`, `apply`); the `workspace` target hard-fails on any step,
+  removes files an edit deleted, and records the eject on the platform. A
+  pull-request target is the next implementation of the same interface.
+- 2026-09-01: The sandbox API requires same-origin plus a custom header on every
+  mutation, validates session ids as UUIDs, authenticates the state,
+  configuration and preview routes, never accepts a mode change over HTTP, and
+  reads capabilities from the acting principal. Sessions can be archived,
+  restored and deleted, from the sandbox and from `flowdular sandbox` commands.