create-flowdular 0.6.0 → 0.6.2

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

@@ -20,3 +20,5 @@ The first setting is `auth.core.allowSignUp`. The server is authoritative and re
 - 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.
+- Platform-scoped writes (amendment, 2026-10-06): every workspace owner holds `system.settings.manage`, so `POST /api/settings/update` changes a platform-scoped setting only for a principal of the operator workspace, the tenant id the deployment sets in `FD_OPERATOR_TENANT`, and refuses anyone else with 403 `PLATFORM_SETTING_OPERATOR_ONLY`; `GET /api/settings` locks those rows outside it. Unset, no workspace changes one.
+- Recorded operator workspace (amendment, 2026-10-06, 0.6.1): auth.core records the operator workspace in `auth_operator_workspace`, at most one row under forced row-level security bound to the workspace it names. Any path that creates the first workspace of an empty database records it in the same transaction, a deployment with exactly one workspace and no record records it when auth.core opens the database, and `pnpm flowdular auth operator-set` is the only way to change it. `FD_OPERATOR_TENANT` becomes an override: set, it alone decides, and a value that is not a workspace id leaves no operator. system.core resolves the operator on every settings request; while none is known every platform row is locked with `system.settings.platformOperatorUnset` and the write refusal keeps `PLATFORM_SETTING_OPERATOR_ONLY`. This supersedes "unset, no workspace changes one" above.

package/agent-template/docs/agent-contract.md

@@ -18,7 +18,7 @@ Use the already selected task skill. Consult `.ai/references/catalog` for implem
 7. Every mutation calls `sessionMutationDenial(octane, auth)` first and reads its body with `readJsonObject` plus `requiredString`, `optionalString`, `requiredInteger`. Clients send `content-type: application/json`, `x-csrf-token`, and `credentials: 'same-origin'`.
 8. Routes mount only through `src/platform.ts` exporting `createServerComposition(context)` with `platform.server: true` in `module.json` and a `./platform` export in `package.json`; the context carries `auth`, `settings`, `agentTools`, `agentDefinitions`, `capabilities` and `databases`. A database module passes `context.databases` into one runtime, which acquires and releases one provider lease lazily; `prepare` stays read-only and never opens a database. A composition may return `settings`, read-only `prepare`, `start`, background-work `stop`, and final `dispose`. Client contributions mount only through `createClientContribution(context)` in `src/client/index.ts` with `platform.client: true`. `pnpm flowdular module validate` fails on a missing entry (`PLATFORM_*`).
 9. Never edit the composition by hand: `platform/octane.config.ts`, `platform/src/App.tsrx`, `platform/src/generated/**`, `platform/package.json` dependencies and `modules.enabled` in `flowdular.json` are written by `pnpm flowdular module enable <id> --apply` and `pnpm flowdular module sync --apply`.
-10. `pnpm flowdular module enable <id> --apply` grants the spec permissions to every tenant owner as its last step; `pnpm flowdular auth sync-scopes --module <id> --apply` re-grants later (new permission, another database). Members receive scopes only through `MEMBER_SCOPES` in `modules/auth/src/acl/scopes.ts`, a core change.
+10. `pnpm flowdular module enable <id> --apply` grants the spec permissions to every tenant owner as its last step; first-run setup grants every enabled module's permissions to the owner it creates, so a module enabled before the first workspace needs no extra step; `pnpm flowdular auth sync-scopes --module <id> --apply` re-grants later (new permission, another database). Members receive scopes only through `MEMBER_SCOPES` in `modules/auth/src/acl/scopes.ts`, a core change.
 11. Declare every imported package in the module `package.json`; the sandbox `dependencies` gate and the eject fail otherwise. Every relative import carries its `.ts` or `.tsrx` extension.
 12. Use the CLI for discovery, validation and scaffolding: `doctor`, `spec validate`, `module validate`, `module new`, `module enable`, `auth sync-scopes`. Run destructive, external or production capabilities only with what the runner demands (`--apply`, `--confirm`, `--spec`) and never work around a refusal.
 13. Gates are `spec-schema`, `module-schema`, `dependencies`, `typecheck`, `tests`, `format`. The sandbox runs `dependencies` plus the ones your role lists after every turn, per draft module, and feeds a failure back to you; with a shell you may run the module's own gate commands yourself, never installs, network or git. From a checkout run them yourself and `pnpm verify` before any pull request.

package/agent-template/docs/cli-extensions.md

@@ -77,6 +77,7 @@ The CLI imports this code only after the exact command or capability is invoked.
 - External and non-local destructive module capabilities remain disabled until a signed approval verifier is configured.
 - A workspace-local destructive capability must declare `localOnly` and a typed confirmation token. It remains dry-run unless both `--apply` and the exact `--confirm` value are present, and it is blocked outside development and test.
 - `capability list`, `capability describe`, and `capability run` use the same descriptors and handlers as direct commands.
+- A command refuses by throwing. An error with a stable `code` (`^[A-Z][A-Z0-9_]{0,63}$`) and a numeric HTTP `status`, the shape of every module service error, keeps its code in the envelope and the human output. So does a coded error from a platform service the runner hands the command, such as a `DatabaseError` from `context.databases` or a refused local database. Any other error is reported as `COMMAND_FAILED`. Only the code and the message are printed, never the stack, the cause or other fields.
 - Core commands may reuse an extension: `module enable <id> --apply` runs the `auth.scopes.sync` capability of `auth.core` after regenerating the composition, so a freshly enabled module is visible to workspace owners without a second command.
 
 The complete customer example is in `.ai/examples/customer-cli-extension`. New module scaffolds include the catalog and implementation files when the approved spec declares the `cli` capability.

package/agent-template/docs/cli.md

@@ -134,6 +134,8 @@ flowdular auth sync-scopes --module <id> [--apply] # re-grant a module's scopes
 flowdular auth workspaces [--limit <n>]            # workspaces of this deployment and their owners
 flowdular auth workspace-create --name <name> --owner-email <email> --owner-name <name> [--slug <id>] [--password-env <VAR>] [--actor <label>] [--apply]
 flowdular auth member-add --workspace <slug|id> --email <email> [--role <key>] [--actor <label>] [--apply]
+flowdular auth operator                            # the recorded operator workspace and whether FD_OPERATOR_TENANT overrides it
+flowdular auth operator-set <id|slug> [--actor <label>] [--apply]
 flowdular auth secrets-rotate [--apply]              # re-seal enrolled TOTP secrets with the current MFA key
 flowdular auth greenfield                          # destructive local auth reset (setup quick)
 
@@ -197,6 +199,20 @@ Both commands append an audit row to the workspace trail whose actor is
 what exists, with each workspace's owners, so the slug or id for the other
 commands is at hand.
 
+The first workspace of an empty database is recorded as the operator
+workspace, the one whose owners change the branding and the other platform
+settings. `auth operator` shows the record and says whether
+`FD_OPERATOR_TENANT` is set in that shell, which overrides the record wherever
+the deployment sets it. `auth operator-set` names another workspace, previews
+without `--apply`, and with it releases the current operator and records the
+new one, each with an audit row in that workspace's trail. If it fails between
+the two, no workspace is the operator until the same command runs again.
+
+```bash
+flowdular auth operator
+flowdular auth operator-set northwind --apply
+```
+
 ## Workspace scripts
 
 ```bash

package/agent-template/docs/configuration.md

@@ -18,6 +18,32 @@ deployments must set the secret keys.
 | `FD_LOG_LEVEL`       | `info`                            | `debug`, `info`, `warn` or `error`                                         |
 | `FD_METRICS`         | `false`                           | Expose `GET /api/metrics`; see [operations.md](operations.md)              |
 | `FD_METRICS_TOKEN`   | none                              | Bearer token a metrics scrape must present                                 |
+| `FD_OPERATOR_TENANT` | none                              | Tenant id that overrides the recorded operator workspace                   |
+
+A platform-scoped module setting has one value for every workspace: the
+branding, sign-up and session policy, the mail relay and the platform settings
+of other modules. Only the operator workspace changes them: a principal there
+holding `system.settings.manage` edits them in Administration. Every other
+workspace sees them read-only, and a write from it is refused with 403
+`PLATFORM_SETTING_OPERATOR_ONLY`.
+
+auth.core records the operator workspace. First-run setup records the workspace
+it creates, in the transaction that creates it, and so does any other path that
+creates the first workspace of an empty database (`auth workspace-create`,
+`sandbox provision`, `setup quick`). `pnpm flowdular auth operator` shows the
+record and `pnpm flowdular auth operator-set <id|slug> --apply` moves it to
+another workspace; the next request sees the change, with no restart.
+
+`FD_OPERATOR_TENANT` is an override. Set, the workspace whose tenant id it names
+is the operator and the record is not consulted; a value that is not the id of
+an existing workspace leaves no operator rather than falling back to the record.
+Leave it empty to use the record.
+
+A deployment upgraded from 0.6.0 with exactly one workspace records that
+workspace the first time it starts. With two or more nothing is recorded, every
+platform row is locked with a reason that names `auth operator-set`, and the
+stored values keep applying until the operator runs that command or sets the
+variable.
 
 A `web` process serves HTTP only: it never starts a module worker and never
 claims queued work from a request, so a deployment of `web` processes also needs
@@ -33,7 +59,8 @@ A Vercel deployment works this way; see
 
 The name, the document title, the description, the link preview image, the
 browser icon, the theme colour and the logo are not environment variables: they
-are `system.core` settings an owner with `system.settings.manage` changes under
+are platform-scoped `system.core` settings a principal with
+`system.settings.manage` in the operator workspace changes under
 Administration, Branding, and every change is audited. One value serves the
 whole deployment, so the sign-in screen and a shared link carry it too, and a
 setting nobody changed renders the product's own.
@@ -622,9 +649,10 @@ deployment on the old names keeps working and the server logs one
 replacement. The platform name wins when both are set, and every refusal names
 the variable the deployment actually set.
 
-The relay is also five platform-scoped `auth.core` settings, edited under
-Administration, Modules: `mailTransport` (`environment`, `none` or `smtp`),
-`mailSmtpUrl` (secret, write only), `mailFrom`, `mailRequireTls` and
+The relay is also five platform-scoped `auth.core` settings, edited from the
+operator workspace under Administration, Modules: `mailTransport`
+(`environment`, `none` or `smtp`), `mailSmtpUrl` (secret, write only),
+`mailFrom`, `mailRequireTls` and
 `mailRejectUnauthorized`. `mailTransport` decides which source wins. It is
 `environment` by default, and while it stays there the `FD_MAIL_*`
 configuration above is in effect exactly as described, deprecation warnings

package/agent-template/docs/database-adapters.md

@@ -32,7 +32,12 @@ const databases = createDatabaseProvider(config, {
 });
 ```
 
-`@flowdular/sdk/database` owns no driver, so the caller supplies both. Composition
+`@flowdular/sdk/database` owns no driver, so the caller supplies both. The provider
+listens for the `error` events node-postgres emits on a pool and on a leased
+client, so a connection the server closes (a suspended compute, a failover, a
+restart) costs at most the query or transaction it interrupts, never the
+process; a factory
+needs no listener of its own. Composition
 injects the result as `PlatformServerContext.databases`, and that is the only
 way a module reaches storage. `GET /api/ready` reports the live adapter and
 answers 503 while the database is unreachable.
@@ -72,7 +77,10 @@ maximum.
 
 With the `pglite` adapter the data directory is the only setting that applies.
 Under `NODE_ENV=test` the directory is ignored and the database is held in
-memory.
+memory. A directory is open once per process: every provider on it in that
+process shares the one embedded database (a development server composes more
+than one), and another process is refused with `LOCAL_DATABASE_LOCKED` until
+the last of them closes it.
 
 ## Three roles
 

package/agent-template/docs/design-system.md

@@ -233,7 +233,10 @@ or than the narrowest table beside it; more than two actions always sit in the
 More menu, and the column then keeps the width of that one button. The menu
 opens over the page, arrows, Home and End move between items, Enter or Space
 runs one, and Escape or Tab closes it and returns focus to the button. A refused
-action stays in the menu, announced as unavailable, with its `reason`.
+action stays in the menu, announced as unavailable, with its `reason`. The
+action column stays pinned to the right edge while the table scrolls, except a
+single action, which never folds: in a card narrower than three times its
+column it scrolls with the row instead of covering the cells beside it.
 
 **Clickable rows.** A table with `onSelect` makes its first cell a button, so
 Tab reaches the row and Enter or Space opens it. That column holds text, never
@@ -442,7 +445,8 @@ Rendered by components, not written by hand: `ui-page-head*`, `ui-search`,
 `ui-table__lead` with `ui-table__toggle` and `ui-table__open` (the first cell's
 expand and open buttons), `ui-table__hide-*` (a column hidden below that width),
 `ui-table__reveal-*` (the expand button, details list and detail shown below
-that width), `ui-table--fold-*` (the action fold step),
+that width), `ui-table--fold-*` (the action fold step), `ui-table--unpin-*`
+(the step below which a single action scrolls with its row),
 `ui-table__placeholder-body` (the loading and empty row content),
 `ui-table__details` (+`-list`), `ui-table__detail`,
 `ui-table-more` (+`--always`), `ui-table-menu` (+`__scrim`, `__label`),

package/agent-template/docs/getting-started.md

@@ -33,7 +33,11 @@ workspace and owner account. Embedded PostgreSQL is already configured. Restart
 Vite HMR covers TSRX, TypeScript and styles. The launcher keeps tool warnings
 quiet; use `pnpm dev -- --verbose` for full diagnostics. `pnpm dev` runs
 `module sync` first, so a composition change is picked up without a manual
-step. The session lives in an HttpOnly cookie and carries the scopes of the
+step. Ctrl+C, SIGTERM or a closed terminal stops the server after open requests
+finish and background work drains, within six seconds. A second Ctrl+C does not
+cut that short, because pnpm already delivers every Ctrl+C more than once;
+Ctrl+\ stops it at once.
+The session lives in an HttpOnly cookie and carries the scopes of the
 selected tenant membership. A bookmark pointing at another workspace you
 belong to switches the session on load.
 

package/agent-template/docs/module-distribution.md

@@ -77,8 +77,7 @@ release. No direct registry installation path remains.
 Automation that imported `installModule` from `flowdular/distribution` must use
 the host CLI plan and apply commands; that direct install export was removed.
 
-The old `official-modules` Sandbox delivery target was removed. Change
-`sandbox.delivery.targets` to `workspace` or `git-pr`; `git-pr` points to the
+Sandbox delivery targets are `workspace` and `git-pr`; `git-pr` points to the
 platform repository configured in `flowdular.json`. A catalog publisher can
 use any Git repository and publish immutable artifacts independently. Historical
 review and RFC documents retain the old project name as provenance.

package/agent-template/docs/modules.md

@@ -2,7 +2,7 @@
 
 A module is a self-contained slice of the product: its own permissions,
 endpoints, migrations, services, screens, translations and tests, wired into the
-platform without touching a core file. `.ai/references/catalog` is the pinned reference
+platform without touching a core file. `.ai/references/catalog` is the reference
 implementation; copy its shape.
 
 ## Lifecycle
@@ -181,7 +181,9 @@ package is not linked yet, and regenerates
 grants the scopes declared by each newly enabled module to every workspace owner
 through `auth sync-scopes`; a failed grant is reported as
 `MODULE_SCOPES_SYNC_FAILED`, and when `auth.core` is unavailable the grant is
-skipped with a warning.
+skipped with a warning. That grant reaches only workspaces that already exist,
+so first-run setup grants the permissions of every enabled module to the owner
+it creates.
 
 `disable` refuses while another enabled module depends on the target, then
 removes it and regenerates. `system.core` and `auth.core` are protected.
@@ -417,4 +419,4 @@ RuleSync generates the discovery copies for supported coding agents:
 `test-hardening`, `cli-extension`, `agent-tool-design`,
 `business-agent-design`, `workflow-development`, `release-eject-pr`.
 
-Official business modules are maintained outside core. See [module distribution](module-distribution.md) for install, update, lock verification and release checks.
+Business modules kept outside this repository install through [module distribution](module-distribution.md), which covers install, update, lock verification and release checks.

package/agent-template/docs/sandbox.md

@@ -57,7 +57,18 @@ written.
 
 An application already serving on the platform port is left alone, and no
 credential is prepared for it. `--platform` and `--platform-port` say otherwise
-explicitly; `--no-platform` never starts one.
+explicitly; `--no-platform` never starts one. An application the launcher
+started stops with it, including when the terminal closes or the launcher is
+killed. It gets eight seconds to drain before it is killed, two more than the
+six the development server gives itself; both figures live in
+`@flowdular/sdk/dev-console/shutdown`. The installs, gates and Git commands the
+sandbox runs stop with it the same way.
+
+One sandbox runs per workspace. A second launcher, or `pnpm eval`, on a
+workspace whose sandbox is running exits with the PID of the process that holds
+it. The hold is the directory `.flowdular/sandbox/workspace.lock`; it goes away
+when that process ends, and one left by a process that was killed outright is
+taken over by the next start.
 
 ## The credential is prepared, not pasted
 
@@ -325,7 +336,13 @@ and a human review remain the repository's own gate.
 ## Decisions the specialist needs
 
 A specialist that cannot continue without a business decision ends its reply
-with one fenced block tagged `questions` holding a single JSON object:
+with one fenced block tagged `questions` holding a single JSON object. An
+implementer (every role but the business manager) asks this way for anything
+the approved specification does not decide, such as a new error code, field,
+permission, state or changed behaviour, and leaves that part unbuilt instead of
+deciding it and mentioning it in prose. Every turn's instruction carries the
+format and the limits below from `questions.ts`, the module that parses the
+block.
 
 ````
 ```questions
@@ -349,9 +366,17 @@ of 1 to 120 characters, and a recommendation that must be one of those options.
 `allowFreeText` defaults to false, and a question with neither an option nor
 free text cannot be answered, so it is refused. The block has to be the last
 thing in the reply apart from the mandatory handoff line, and a reply carries at
-most one. A block the sandbox cannot read is a warning on that turn, never a
-failed turn: the words of the reply still stand and the transcript says why the
-block was ignored.
+most one. A block the sandbox cannot read is never a failed turn and never
+dropped in silence: the transcript says why it was refused, and the specialist
+gets the reason and these limits for one repair turn. A second refusal in a row
+stops for the operator, who answers in words. A turn that asks stops for the
+answers, never for approval, and the approval route refuses a module with open
+questions (`409 QUESTIONS_PENDING`). A gate that failed in the same turn waits
+too: the handoff names it, the gates run again after the answering turn, and a
+failure that remains then goes back to the specialist. Such a session is in the
+`awaiting-answers` state, so `awaiting-approval` only ever means an approval.
+`sandbox.core` has no state for open questions, so the platform record keeps
+`awaiting-approval` for it.
 
 A readable block is stored on the session as `pendingQuestions`, with the
 transcript sequence of the message that asked, the role that asked and the
@@ -370,8 +395,11 @@ POST /sandbox/api/sessions/:id/answers
 ```
 
 behind the same origin, header and ownership checks as every other mutation. It
-clears `pendingQuestions` and starts the next turn in the role that asked, in
-the module it asked about, with the decisions leading the request text:
+clears `pendingQuestions` and starts the next turn in the module the questions
+were about, with the decisions leading the request text. The business manager's
+own questions go back to it. An implementer's questions go to the business
+manager first (`answeringRole` in `planning.ts`), and so does an answer the
+operator types in the message box instead:
 
 ```
 Decisions:
@@ -387,6 +415,35 @@ INVALID_INPUT` for a body that leaves a question unanswered, names a question
 the session did not ask, exceeds 400 characters, or gives an answer that is not
 one of the offered options when the specialist allowed no free text.
 
+### Answers to an implementer's questions
+
+The business manager applies the answers to `spec/module.yaml`, and the text it
+leaves behind decides what happens next:
+
+- An answer that changes what the module must do is recorded in the
+  specification, which goes back to `draft`. Its hash no longer matches the
+  approval, so the session waits in `awaiting-approval` with the implementer
+  that asked as the next role, and implementation is refused until the operator
+  approves the new hash. Approving resumes that implementer with its decisions.
+- An answer the approved text already decides leaves the file untouched. The
+  approval still holds, and the implementer that asked continues at once with
+  its decisions.
+
+The wait is read from the transcript (`specFollowUp` in `planning.ts`): the
+newest handoff that is not the business manager's own is the implementer's
+question, so the implementer still resumes when the business manager asks a
+question of its own in between. A gate the implementer left failing runs again
+on the business manager's turn. When it still fails, only a repair the business
+manager takes in that module runs first; any other waits until the implementer
+has resumed with its decisions, and the gates run again after that turn.
+
+The `module-rules` gate backs the rule for permissions: `permissions-specified`
+fails a module whose `src/acl/permissions.ts`, or an inline `permission:`
+value, names a permission the specification does not list. Error codes have no
+structured list in a specification and the shipped modules throw many codes
+their specifications never name, so a matching rule for them would fail correct
+modules; the instruction and the question card cover them.
+
 ## Operator commands
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "create-flowdular",
-	"version": "0.6.0",
+	"version": "0.6.2",
 	"type": "module",
 	"description": "Scaffold a Flowdular application: the platform, one example module and the secrets a fresh install needs.",
 	"license": "MIT",

package/template/default/.env.example

@@ -84,6 +84,11 @@ FD_AUTH_MAIL_TRANSPORT=none
 FD_AUTH_SMTP_URL=
 FD_AUTH_MAIL_FROM=
 
+# Tenant id that overrides the operator workspace, the one that changes platform
+# settings such as the branding and the mail relay. Empty, the workspace auth.core
+# recorded at first-run setup decides (pnpm flowdular auth operator shows it).
+FD_OPERATOR_TENANT=
+
 # Read by infra/docker/compose.yaml only. It builds the three URLs above from
 # these passwords and publishes the container port on FD_PORT.
 FD_POSTGRES_SUPERUSER_PASSWORD=

package/template/default/infra/docker/.env.example

@@ -61,6 +61,11 @@ FD_AUTH_PUBLIC_ORIGIN=
 # behind TLS, set true and set FD_AUTH_PUBLIC_ORIGIN to its HTTPS origin.
 FD_AUTH_SECURE_COOKIE=
 
+# Tenant id that overrides the operator workspace, the one that changes platform
+# settings such as the branding and the mail relay. Empty, the workspace auth.core
+# recorded at first-run setup decides (pnpm flowdular auth operator shows it).
+FD_OPERATOR_TENANT=
+
 # Prometheus exposition on GET /api/metrics. Leave FD_METRICS unset to keep it off.
 FD_METRICS=false
 FD_METRICS_TOKEN=

package/template/default/infra/docker/Dockerfile

@@ -18,6 +18,7 @@ RUN pnpm build
 RUN mkdir -p module-plans \
 	&& if [ ! -f flowdular.modules.lock.json ]; then printf '{"schemaVersion":1,"modules":[]}\n' > flowdular.modules.lock.json; fi \
 	&& if [ ! -f flowdular.module-sources.json ]; then printf '{"schemaVersion":1,"sources":[]}\n' > flowdular.module-sources.json; fi
+RUN mkdir -p /sdk-manifests && node infra/sdk-module-manifests.mjs . /sdk-manifests
 
 FROM node:24-bookworm-slim AS runtime
 
@@ -31,7 +32,9 @@ RUN groupadd --system --gid 1001 octane \
 	&& chown octane:octane /data
 
 # The server bundle is self-contained: platform/dist/server/entry.js imports
-# only node:* built-ins, so no node_modules (and no devDependencies) ship.
+# only node:* built-ins, so no node_modules (and no devDependencies) ship. The
+# platform does read the manifests and specs of the modules @flowdular/sdk
+# ships, so the last copy puts those files alone where platform/ resolves them.
 COPY --from=builder --chown=octane:octane /workspace/platform/dist ./platform/dist
 COPY --from=builder --chown=octane:octane /workspace/platform/package.json ./platform/package.json
 COPY --chown=octane:octane infra/docker/app-entrypoint.mjs infra/docker/database-urls.mjs ./infra/docker/
@@ -40,6 +43,7 @@ COPY --from=builder --chown=octane:octane /workspace/flowdular.modules.lock.json
 COPY --from=builder --chown=octane:octane /workspace/flowdular.module-sources.json ./flowdular.module-sources.json
 COPY --from=builder --chown=octane:octane /workspace/module-plans ./module-plans
 COPY --from=builder --chown=octane:octane /workspace/modules ./modules
+COPY --from=builder --chown=octane:octane /sdk-manifests/ ./
 
 USER octane
 EXPOSE 3000

package/template/default/infra/docker/compose.yaml

@@ -124,6 +124,10 @@ services:
       FD_APPLICATION_PATH: ${FD_APPLICATION_PATH:-/app}
       FD_SETUP_AUTO_RESTART: 'true'
       FD_AUTH_ALLOW_SIGN_UP: 'false'
+      # Tenant id that overrides the operator workspace, the one that changes
+      # platform settings such as the branding and the mail relay. Empty, the
+      # workspace auth.core recorded at first-run setup decides.
+      FD_OPERATOR_TENANT: ${FD_OPERATOR_TENANT:-}
       # TLS terminates in front of this container. Only a plain-HTTP run on a
       # workstation may set FD_AUTH_SECURE_COOKIE=false in .env.
       FD_AUTH_SECURE_COOKIE: ${FD_AUTH_SECURE_COOKIE:-true}

package/template/default/infra/kubernetes/deployment.yaml

@@ -61,6 +61,11 @@ spec:
                   key: backgroundUrl
             - name: FD_AUTH_ALLOW_SIGN_UP
               value: 'false'
+            # Tenant id that overrides the operator workspace, the one that
+            # changes platform settings such as the branding and the mail relay.
+            # Empty, the workspace auth.core recorded at first-run setup decides.
+            - name: FD_OPERATOR_TENANT
+              value: ''
             - name: FD_AUTH_SECURE_COOKIE
               value: 'true'
             # With none, invitations and password resets are refused. The smtp

package/template/default/infra/sdk-module-manifests.mjs

@@ -0,0 +1,118 @@
+import {
+	cp,
+	lstat,
+	mkdir,
+	readFile,
+	realpath,
+	writeFile,
+} from 'node:fs/promises';
+import { createRequire } from 'node:module';
+import { dirname, isAbsolute, join, relative, resolve } from 'node:path';
+
+/* A deployment ships no node_modules, yet the platform lists the modules
+   @flowdular/sdk ships by resolving the SDK's module index from platform/. This
+   copies what that lookup reads (the index, each indexed module.json and its
+   spec/module.yaml, and a package.json exporting the index) to the same place
+   under the deployment root. A workspace without the SDK copies nothing.
+
+   Usage: node infra/sdk-module-manifests.mjs <workspace> <deployment root> */
+
+/* The platform refuses a larger index, so the copy does too. */
+const INDEX_LIMIT = 256;
+const UNRESOLVED = new Set([
+	'MODULE_NOT_FOUND',
+	'ERR_PACKAGE_PATH_NOT_EXPORTED',
+]);
+
+const [workspaceArgument, deploymentArgument] = process.argv.slice(2);
+if (!workspaceArgument || !deploymentArgument) {
+	throw new Error(
+		'Usage: node infra/sdk-module-manifests.mjs <workspace> <deployment root>',
+	);
+}
+const workspace = resolve(workspaceArgument);
+const destination = join(
+	resolve(deploymentArgument),
+	'platform/node_modules/@flowdular/sdk',
+);
+
+function sdkIndexPath() {
+	try {
+		return createRequire(join(workspace, 'platform/package.json')).resolve(
+			'@flowdular/sdk/modules.json',
+		);
+	} catch (error) {
+		if (UNRESOLVED.has(error.code)) return null;
+		throw error;
+	}
+}
+
+function insidePath(root, path) {
+	const fromRoot = relative(root, path);
+	return (
+		Boolean(fromRoot) && !fromRoot.startsWith('..') && !isAbsolute(fromRoot)
+	);
+}
+
+/* Copies a file the index names, refusing one that leaves the SDK lexically or
+   through a link. An absent optional file is skipped. */
+async function copyFromSdk(sdkRoot, path, optional = false) {
+	const lexical = resolve(sdkRoot, path);
+	if (!insidePath(sdkRoot, lexical)) {
+		throw new Error(`SDK module file escapes the package: ${path}`);
+	}
+	let source;
+	try {
+		source = await realpath(lexical);
+	} catch (error) {
+		if (optional && error.code === 'ENOENT') return;
+		throw error;
+	}
+	if (!insidePath(sdkRoot, source) || !(await lstat(source)).isFile()) {
+		throw new Error(
+			`SDK module file must be a regular file inside the package: ${path}`,
+		);
+	}
+	const target = join(destination, relative(sdkRoot, lexical));
+	await mkdir(dirname(target), { recursive: true });
+	await cp(source, target);
+}
+
+const indexPath = sdkIndexPath();
+if (indexPath) {
+	const sdkRoot = await realpath(dirname(indexPath));
+	const indexSource = await readFile(indexPath, 'utf8');
+	const index = JSON.parse(indexSource);
+	if (
+		index.schemaVersion !== 1 ||
+		!Array.isArray(index.modules) ||
+		index.modules.length > INDEX_LIMIT
+	) {
+		throw new Error('Invalid SDK module index.');
+	}
+	await mkdir(destination, { recursive: true });
+	for (const entry of index.modules) {
+		if (typeof entry?.manifest !== 'string') {
+			throw new Error('Invalid SDK module manifest path.');
+		}
+		await copyFromSdk(sdkRoot, entry.manifest);
+		await copyFromSdk(
+			sdkRoot,
+			join(dirname(entry.manifest), 'spec/module.yaml'),
+			true,
+		);
+	}
+	await writeFile(join(destination, 'modules.json'), indexSource);
+	await writeFile(
+		join(destination, 'package.json'),
+		`${JSON.stringify(
+			{
+				name: '@flowdular/sdk',
+				private: true,
+				exports: { './modules.json': './modules.json' },
+			},
+			null,
+			'\t',
+		)}\n`,
+	);
+}

package/template/default/infra/vercel/build.mjs

@@ -160,6 +160,15 @@ async function writeFunction(directory, runtimeRole) {
 			);
 		}
 	}
+	const sdkManifests = spawnSync(
+		process.execPath,
+		[join(repositoryRoot, 'infra/sdk-module-manifests.mjs'), root, directory],
+		{ stdio: 'inherit' },
+	);
+	if (sdkManifests.error) throw sdkManifests.error;
+	if (sdkManifests.status !== 0) {
+		throw new Error('Copying the SDK module manifests failed.');
+	}
 	await copyRegular(
 		join(repositoryRoot, 'infra/vercel/handler.mjs'),
 		join(directory, 'handler.mjs'),

package/template/default/modules/example/package.json

@@ -16,7 +16,7 @@
 	"dependencies": {
 		"octane": "0.9.1",
 		"segment-state": "0.4.0",
-		"@flowdular/sdk": "0.6.0"
+		"@flowdular/sdk": "0.6.2"
 	},
 	"devDependencies": {
 		"@tsrx/typescript-plugin": "0.3.120",

package/template/default/package.json

@@ -15,7 +15,6 @@
 		"format": "prettier --write .",
 		"format:check": "prettier --check .",
 		"flowdular": "flowdular",
-		"cl": "flowdular",
 		"doctor": "flowdular doctor",
 		"verify": "pnpm rules:check && pnpm typecheck && pnpm test && flowdular spec validate --all && flowdular module validate && pnpm format:check",
 		"rules:generate": "rulesync generate",
@@ -23,10 +22,10 @@
 		"build": "flowdular module sync --apply && pnpm --filter @app/platform build"
 	},
 	"devDependencies": {
-		"@flowdular/sandbox": "0.6.0",
+		"@flowdular/sandbox": "0.6.2",
 		"@tsrx/prettier-plugin": "0.3.120",
 		"prettier": "3.6.2",
-		"flowdular": "0.6.0",
+		"flowdular": "0.6.2",
 		"rulesync": "16.21.0"
 	}
 }