create-flowdular 0.3.0 → 0.3.1

package/agent-template/.agents/skills/cli-extension/SKILL.md

@@ -85,7 +85,7 @@ export default cliExtension;
 
 ## 4. What the runner does with the descriptor (`packages/cli/src/runner.ts`, `runExtensionCommand`)
 
-- `risk: 'external'`: refused with `APPROVAL_VERIFIER_REQUIRED`. `risk: 'destructive'` without `localOnly`: the same.
+- `risk: 'external'`, or `'destructive'` without `localOnly`: refused with `APPROVAL_VERIFIER_REQUIRED` unless `--grant <token> --tenant <id>` carries a verified approval grant for this capability and invocation digest (`APPROVAL_GRANT_INVALID`, `APPROVAL_GRANT_EXPIRED`, `APPROVAL_GRANT_MISMATCH` otherwise).
 - `localOnly: true`: refused with `LOCAL_ONLY_CAPABILITY` unless `FD_ENV` or `NODE_ENV` is `development` or `test` (unset counts as development).
 - `requiresApprovedSpec: true`: needs `--spec <path>` to a schema-valid spec with `status: approved`, otherwise `APPROVED_SPEC_REQUIRED`, `SPEC_VALIDATION_FAILED` or `SPEC_NOT_APPROVED`.
 - `destructive` with `--apply`: needs `--confirm <confirmation>` (`CONFIRMATION_REQUIRED`).

package/agent-template/.agents/skills/deploy-operate/SKILL.md

@@ -76,9 +76,12 @@ Both are served by `platform/src/server/health.ts`. The shipped Docker and Kuber
 pnpm flowdular database backup --output <dir>                            # dry run
 pnpm flowdular database backup --output <dir> --apply
 pnpm flowdular database restore --input <dir> --apply --confirm restore-database
+pnpm flowdular database restore-production --input <dir> --target <db> --grant <token> --tenant <id> [--platform-url <origin>|--platform-stopped] --apply --confirm restore-database
 ```
 
-The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets and MFA secrets are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one. Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
+Production restores run `database.restore.production`: an approval grant bound to the exact flags, `--target` equal to the migrator DSN database, a separate migrator DSN, a key mismatch refused unless the approval included `--allow-key-mismatch`, and a refusal while the health endpoint answers. PITR for the compose stack is `infra/docker/pitr.sh` (see `infra/README.md`); in Kubernetes it is the managed provider's job.
+
+The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets, MFA secrets, stored objects and connector credentials are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one; every sealing key has a `secrets-rotate` command in the runbook's rotation table, the storage key two (`documents` and `exports`). Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
 
 ## 6. Rollback
 
@@ -87,6 +90,8 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 3. To take one module out of service without a redeploy: `pnpm flowdular module disable <id> --apply` (it is a dry run without `--apply`), then rebuild the composition and redeploy. Its tables stay.
 4. If the rollback is because of a key change, restore the previous key first; the image alone will not fix unreadable ciphertext.
 
+- For data loss between two dumps use PITR (`pitr.sh restore --target-time`), never a `.down.sql`.
+
 ## 7. Production checklist
 
 - `pnpm verify` and `pnpm build` pass on the commit being shipped (the image build runs both).
@@ -98,7 +103,7 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 - Sign-up closed (`FD_AUTH_ALLOW_SIGN_UP`) unless the deployment is public; the first owner created with `flowdular auth workspace-create` (see `docs/cli.md`).
 - Liveness on `/api/health`, readiness on `/api/ready`.
 - `pnpm flowdular migration verify` clean after rollout, and `pnpm flowdular doctor --json` reports `status: healthy`.
-- A restore has been rehearsed once, keys included.
+- A restore has been rehearsed once, keys included, and a PITR restore once from the newest base backup.
 
 ## Pitfalls
 

package/agent-template/.ai/platform-capabilities.md

@@ -50,7 +50,7 @@ Read this file before writing or implementing a spec. It replaces scanning `modu
 
 **Automations triggers.** Two mechanisms in `automations.core`. A schedule uses a cadence string in one of two forms (`modules/automations/src/domain/cadence.ts`): `every:N`, where `N` is whole minutes from 1 to 10080 and the unit is implicit, or `cron:<minute> <hour> <day of month> <month> <day of week>`, five fields with no seconds, at most 100 characters, each field `*`, a number, a three letter month or weekday name, a list, a range, or any of those with a step (`*/15`, `9-17/4`); both day fields restricted means either matches. A cron slot is a wall clock time in the workspace zone from the shared `system.core.timeZone` setting, stored in UTC; a wall time a daylight saving change removes is skipped and one that occurs twice fires at the first of the two. An expression the module cannot honour is refused at save with `INVALID_CADENCE`. Missed slots are skipped, never replayed. An inbound webhook posts to `POST /api/automations/triggers/:id/fire`, authenticated by an HMAC signature in `x-flowdular-signature` with `x-flowdular-timestamp` inside a 5 minute window and a 16 KB body cap, answering `202 { accepted, runId }`. Targets are pluggable through `automations.targets.v1`; the shipped kinds are `agent` and `workflow`.
 
-**CLI extensions.** A module contributes `pnpm flowdular <namespace> <action>` through `src/cli/commands.json` plus `defineCliExtension` (`packages/cli-protocol/src/index.ts`), declared in `module.json` under `cli`. The first path segment must equal the module id's first segment and may not be a reserved group (`help`, `doctor`, `capability`, `spec`, `blueprint`, `module`, `migration`, `setup`). Each command carries a `CapabilityDescriptor` with `id`, `version`, `summary`, `risk: 'read' | 'workspace-write' | 'process' | 'external' | 'destructive'`, `requiresApprovedSpec`, `supportsDryRun`, optional `localOnly` and `confirmation`. The runner refuses `external` always and non-local `destructive` always, gates `localOnly` to `development` and `test`, and treats every write command as a dry run without `--apply`.
+**CLI extensions.** A module contributes `pnpm flowdular <namespace> <action>` through `src/cli/commands.json` plus `defineCliExtension` (`packages/cli-protocol/src/index.ts`), declared in `module.json` under `cli`. The first path segment must equal the module id's first segment and may not be a reserved group (`help`, `doctor`, `capability`, `spec`, `blueprint`, `module`, `migration`, `setup`). Each command carries a `CapabilityDescriptor` with `id`, `version`, `summary`, `risk: 'read' | 'workspace-write' | 'process' | 'external' | 'destructive'`, `requiresApprovedSpec`, `supportsDryRun`, optional `localOnly` and `confirmation`. The runner refuses `external` and non-local `destructive` commands unless `--grant <token> --tenant <id>` carries a verified approval grant for the capability and the invocation digest, gates `localOnly` to `development` and `test`, and treats every write command as a dry run without `--apply`.
 
 **Translations.** The shipped locales are `en` and `pl`. A module keeps a flat bundle per locale in `translations/<locale>.json`, imports them in `src/client/contribution.tsrx` and returns `translations: { en, pl }`. Keys resolve fully qualified as `<first module segment>.<key>` through `t()`. `flowdular module validate` reports `TRANSLATION_FILE_MISSING`, `TRANSLATION_PARSE_ERROR`, `TRANSLATION_KEYS_MISMATCH` and `TRANSLATION_KEY_MISSING`.
 
@@ -66,7 +66,7 @@ Read this file before writing or implementing a spec. It replaces scanning `modu
 
 **Connectors.** `connectors.core` (optional) is the governed way out to an external system. A module ships a connector definition through the public capability `connectors.definitions.v1` (`modules/connectors/src/domain/definitions.ts`): `register({ key, moduleId, label, authKinds, operations: [{ key, label, method, path, inputSchema, outputSchema }], defaultAllowedHosts, allowedPorts? })` (ports default to 443 only), and the platform ships `http-json`. An owner creates an instance behind `connectors.instances.manage` with a base URL, sealed credentials under `FD_CONNECTORS_SECRET_KEY`, a host allowlist and two consent flags, `allowWorkflows` and `allowAgents`, both off. A call goes through `connectors.calls.v1`: `call({ tenantId, instanceId, operation, input, caller: 'test' | 'workflow' | 'agent', callerRef? })`, which enforces status, consent for that caller kind, the egress policy (https, no private addresses, no redirects, timeout and size caps) and logs the call without any body; `consented(tenantId, instanceId, caller)` answers admission alone. The agent tool `connectors.call` is declared `workspace-write` with the harness consent gate `connectors.instance-consent` (`AgentToolConsent` in `packages/harness/src/runtime.ts`), carries the full action contract (`idempotency: 'required'` backed by a per-call key ledger) so workflows may use it, has no HTTP route of its own, and dials only the addresses the egress policy verified, so the ceiling is raised per instance by the owner's consent, never by a declaration.
 
-**Approvals.** `approvals.core` (optional) turns a policy's `requiresApproval` into a request people decide. A module opens one through the public capability `approvals.requests.v1` (`modules/approvals/src/domain/capability.ts`): `open({ tenantId, subjectModule, subjectRef, permission, action, title, summary?, requesterAccountId, requirement, onResolved? })`, plus `get`, `list` and `cancel`. Eligible deciders are resolved at open from the requirement's role key and scope (both, when both are named; the requester never decides), re-read at decision time, and a request needs `decisions` approvals before `expiresInDays` runs out. Open is idempotent per subject while a request is pending, and a requirement that resolves to nobody, to too few or to more than 200 deciders is refused with a stable code. Decisions are an append-only ledger behind `approvals.requests.read`, `approvals.requests.decide` and `approvals.requests.manage`; deciders and requesters are notified through the kinds `approval-requested` and `approval-decided`. The subject module learns the outcome from `onResolved`, which runs once per terminal state after the deciding transaction commits, or by reading the request back.
+**Approvals.** `approvals.core` (optional) turns a policy's `requiresApproval` into a request people decide. A module opens one through the public capability `approvals.requests.v1` (`modules/approvals/src/domain/capability.ts`): `open({ tenantId, subjectModule, subjectRef, permission, action, title, summary?, requesterAccountId, requirement, onResolved? })`, plus `get`, `list` and `cancel`. Eligible deciders are resolved at open from the requirement's role key and scope (both, when both are named; the requester never decides), re-read at decision time, and a request needs `decisions` approvals before `expiresInDays` runs out. Open is idempotent per subject while a request is pending, and a requirement that resolves to nobody, to too few or to more than 200 deciders is refused with a stable code. Decisions are an append-only ledger behind `approvals.requests.read`, `approvals.requests.decide` and `approvals.requests.manage`; deciders and requesters are notified through the kinds `approval-requested` and `approval-decided`. The subject module learns the outcome from `onResolved`, which runs once per terminal state after the deciding transaction commits, or by reading the request back. A request whose `subjectRef` is `encodeCapabilitySubjectRef({ capabilityId, inputDigest })` yields, once approved, a signed token through `grant(tenantId, id, subjectModule)`, handed only to the module that opened it; the CLI runner takes it as `--grant` (valid until expiry) and the harness as `AgentExecutionRequest.grants` (one tool call per grant), both bound to the tenant, the capability id and `approvalInputDigest` of the input.
 
 **Documents.** `documents.core` (optional) owns file attachments of any record. A screen uploads through `POST /api/documents/upload` with the raw body and the headers `x-document-filename`, `x-document-owner-module`, `x-document-record-ref` and `x-document-description`, lists with `GET /api/documents?ownerModule=&recordRef=`, opens through `POST /api/documents/read-url` (a short-lived storage URL) and deletes through `POST /api/documents/delete`, all behind `documents.files.read` or `documents.files.manage` with CSRF first. A module reads its own records' attachments through the public capability `documents.attachments.v1` (`modules/documents/src/domain/attachments.ts`): `list(tenantId, ownerModule, recordRef)`, `open(tenantId, ownerModule, recordRef, id)` answering `{ contentType, bytes, filename, body }` or null for anything not readable (unknown, another pair, deleted, infected) and `delete(tenantId, ownerModule, recordRef, id)`; the reference pair is a scope, the caller's permission on its own record is the authorization, and the storage key never leaves documents.core. Checksums, scan verdicts and the object limits come from the storage port.
 

package/agent-template/.ai/policies/capabilities.yaml

@@ -84,6 +84,12 @@ core:
     confirmation: restore-database
     supportsDryRun: true
     effect: 'replaces the configured database with the backup in <dir> (pg_restore --clean --if-exists, or a staged replacement of the embedded data directory); refuses BACKUP_ADAPTER_MISMATCH across adapters and warns BACKUP_KEY_MISMATCH when the running environment holds keys the backup was not taken with'
+  database.restore.production:
+    command: pnpm flowdular database restore-production --input <dir> --target <database> --grant <token> --tenant <id> [--allow-key-mismatch] [--platform-url <origin>|--platform-stopped] --apply --confirm restore-database
+    risk: destructive
+    confirmation: restore-database
+    supportsDryRun: true
+    effect: 'the same restore without localOnly, so it runs in any environment but only under a verified approval grant (see approvals.destructive-not-local; the grant binds --input, --target and every other capability flag); --target must repeat the database of the migrator DSN (the embedded data directory for pglite) or RESTORE_TARGET_MISMATCH; MIGRATOR_ROLE_REQUIRED when FD_DATABASE_MIGRATOR_URL is absent or equals FD_DATABASE_URL; a key divergence is a BACKUP_KEY_MISMATCH refusal unless --allow-key-mismatch is part of the approved invocation; with --apply, PLATFORM_RUNNING while <origin>/api/health (from --platform-url, else http://127.0.0.1:$FD_PORT) answers, and PLATFORM_STATE_UNKNOWN when no endpoint is named or the probe times out unless --platform-stopped attests the platform is down'
   workspace.state.migrate:
     command: pnpm flowdular setup migrate-state [--apply --confirm migrate-legacy-state]
     risk: destructive
@@ -146,6 +152,24 @@ modules:
       risk: process
       supportsDryRun: true
       note: re-seals stored trigger secrets with the current encryption key; batches of 200 rows in one tenant-scoped transaction each, idempotent, and never prints a secret
+  documents.core:
+    documents.storage.rotate:
+      command: pnpm flowdular documents secrets-rotate [--apply]
+      risk: process
+      supportsDryRun: true
+      note: re-seals stored document objects in place with the current storage encryption key; batches of 200 rows in one tenant-scoped transaction each, idempotent, leaves an object under an unknown key or one that fails authentication as it is, and never prints object content
+  exports.core:
+    exports.storage.rotate:
+      command: pnpm flowdular exports secrets-rotate [--apply]
+      risk: process
+      supportsDryRun: true
+      note: re-seals stored export files in place with the current storage encryption key; batches of 200 rows in one tenant-scoped transaction each, idempotent, leaves a file under an unknown key or one that fails authentication as it is, and never prints file content
+  connectors.core:
+    connectors.secrets.rotate:
+      command: pnpm flowdular connectors secrets-rotate [--apply]
+      risk: process
+      supportsDryRun: true
+      note: re-seals stored connector credentials with the current encryption key and recomputes their fingerprints under it; batches of 200 rows in one tenant-scoped transaction each, idempotent, leaves a row under an unknown key as it is, and never prints a credential
   notifications.core:
     notifications.secrets.rotate:
       command: pnpm flowdular notifications secrets-rotate [--apply]
@@ -240,14 +264,18 @@ modules:
 
 # packages/cli/src/runner.ts, runExtensionCommand, in evaluation order.
 approvals:
-  external: refused with APPROVAL_VERIFIER_REQUIRED (no signed approval verifier exists)
-  destructive-not-local: refused with APPROVAL_VERIFIER_REQUIRED
+  external: the same grant check as destructive-not-local; APPROVAL_VERIFIER_REQUIRED without a token or key
+  destructive-not-local: needs --grant <token> --tenant <id>, an approval grant verified under FD_APPROVAL_GRANT_KEY against the tenant, the capability id and the invocation digest (positional arguments plus every flag except --root, --json, --confirm, --grant and --tenant, so --apply is bound and an approval names the applied run, never a dry run); APPROVAL_VERIFIER_REQUIRED without a token or key, APPROVAL_GRANT_INVALID, APPROVAL_GRANT_EXPIRED or APPROVAL_GRANT_MISMATCH otherwise; the runner records no use, so a grant replays until it expires
   localOnly: refused with LOCAL_ONLY_CAPABILITY unless FD_ENV or NODE_ENV is development or test (unset counts as development)
   requiresApprovedSpec: needs --spec <path>; APPROVED_SPEC_REQUIRED, SPEC_VALIDATION_FAILED or SPEC_NOT_APPROVED otherwise
   destructive-apply: --apply needs --confirm <descriptor.confirmation>; CONFIRMATION_REQUIRED otherwise
   non-read-without-dry-run: EXPLICIT_APPLY_REQUIRED without --apply
   dry-run: non-read with supportsDryRun and no --apply runs with apply=false and warns "Dry run only. No writes were authorized."
 
+harnessGate:
+  localOnlyTools: CLI tools whose capability is localOnly are refused by the harness with TOOL_LOCAL_ONLY outside development and test, grant or not
+  grantedTools: external tools and non-local destructive CLI tools are offered only when the run carries a grant verified for the tool id and the input digest; one tool call per grant (APPROVAL_GRANT_CONSUMED afterwards); the consent gate still applies
+
 moduleExtensions:
   discovery: module.json cli.catalog (src/cli/commands.json), schema-validated without executing code
   loadImplementation: module.json cli.entry imported only when the command runs (packages/cli/src/extensions.ts loadCliCommand)
@@ -259,6 +287,5 @@ moduleExtensions:
 planned:
   - migration.plan (served by "migration apply" without --apply, which is a read-only dry run)
   - migration.apply.remote
-  - destructive.execute (signed approval receipts)
   - redaction of *_TOKEN, *_SECRET, *_PASSWORD, DATABASE_URL in a shared logger (only packages/ai-provider/src/errors.ts redactSecrets exists)
   - persisted CLI audit (CommandEnvelope carries a random auditId and evidence per invocation; nothing stores it)

package/agent-template/.ai/references/catalog/module.json

@@ -3,7 +3,7 @@
 	"schemaVersion": 1,
 	"id": "catalog.core",
 	"package": "@flowdular/module-catalog",
-	"version": "0.7.0",
+	"version": "0.7.1",
 	"profile": "full",
 	"capabilities": ["api", "database", "client", "translations"],
 	"platform": {

package/agent-template/.ai/references/catalog/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@flowdular/module-catalog",
-	"version": "0.7.0",
+	"version": "0.7.1",
 	"type": "module",
 	"exports": {
 		".": "./src/index.ts",
@@ -16,7 +16,7 @@
 	"dependencies": {
 		"octane": "0.1.51",
 		"segment-state": "0.2.0",
-		"@flowdular/sdk": "0.2.4"
+		"@flowdular/sdk": "0.3.0"
 	},
 	"devDependencies": {
 		"@tsrx/typescript-plugin": "0.3.120",

package/agent-template/.ai/references/catalog/spec/module.yaml

@@ -1,6 +1,6 @@
 schemaVersion: 1
 id: catalog.core
-specVersion: 0.7.0
+specVersion: 0.7.1
 status: approved
 name: Product Catalog Core
 description: Provides tenant-scoped products and services with stable SKUs, units, prices, currencies, and lifecycle state.

package/agent-template/.ai/references/catalog.provenance.json

@@ -1,9 +1,9 @@
 {
 	"id": "catalog.core",
-	"version": "0.7.0",
+	"version": "0.7.1",
 	"repository": "Flowdular/official-modules",
-	"sourceCommit": "b8281b38498b1e3164e6619ec9e8fe922ad7dc10",
-	"artifactSha256": "6c98785c10fac14cb1a913c6462cb42e18fe824a7d0dd7620746605fd351441d",
+	"sourceCommit": "be391ac460e53e06a812fc9f0ea1260e2daa058f",
+	"artifactSha256": "7c645f660f44bb4c4540d32dd188d643aafb067f4c505a2722a7f2605a7b54b8",
 	"files": {
 		"LICENSE": "155d722071bad9d0d832482e06fd5a47f7034389cb63aabcb39f4282aa3499fc",
 		"migrations/0001_catalog_core.down.sql": "0962a1edf0bde959cd4facccf77bd5b634d6cc25f125a0c79a61770c8871093f",
@@ -15,9 +15,9 @@
 		"migrations/0004_catalog_idempotency_ledger.down.sql": "8ba72d8edc4d25ecf6d041888cf321690c25afdaf3723812ddd7d391d75370aa",
 		"migrations/0004_catalog_idempotency_ledger.up.sql": "41e86ba2051159c6cc9672bfae17c1d02051da975f1c43c566a2b66592673cb0",
 		"migrations/README.md": "2a15fd001713c2552a3c82b186246aa5fec136f43143cc2d9aa15bd491a09d41",
-		"module.json": "1b512c9b97bdec2155103f521a6545e558e50491f90c74a93d33cc74511d2125",
-		"package.json": "67d50dc95723d21bb44bbab54ae14fe89641c52b9f62ba065908f67ebcf0ed7a",
-		"spec/module.yaml": "ec931c78f351c7fc53f43fdd5ec9cd1a46db485f642648329bf1612883a3c958",
+		"module.json": "f2c66d18e3d54ef1ad8dcc3d26d1ee39a2982463dd3bc3fb26b159039933ed86",
+		"package.json": "3e05cf299b5cc5d948e4b3569bd93f2648a30b22f4f14d26bb31548a79529092",
+		"spec/module.yaml": "633a719d765d9779e2bf4ae0a608251767a62cbb4e15305dc13afcb1e52f14c9",
 		"src/acl/permissions.ts": "3375521a5a229736ffac5a948140ec347dc7a7e4fba80e778c0baaf9e0622590",
 		"src/agent/tools.ts": "3204d20886d2b864482adc1ed3303c653aebd207e16c4fce0c67a4979ea8db07",
 		"src/api/endpoints.ts": "34f1036e759353550be2acf67c6fa254afc790942d09489db2e76a082df5c3a3",

package/agent-template/.ai/skills/cli-extension/SKILL.md

@@ -91,7 +91,7 @@ export default cliExtension;
 
 ## 4. What the runner does with the descriptor (`packages/cli/src/runner.ts`, `runExtensionCommand`)
 
-- `risk: 'external'`: refused with `APPROVAL_VERIFIER_REQUIRED`. `risk: 'destructive'` without `localOnly`: the same.
+- `risk: 'external'`, or `'destructive'` without `localOnly`: refused with `APPROVAL_VERIFIER_REQUIRED` unless `--grant <token> --tenant <id>` carries a verified approval grant for this capability and invocation digest (`APPROVAL_GRANT_INVALID`, `APPROVAL_GRANT_EXPIRED`, `APPROVAL_GRANT_MISMATCH` otherwise).
 - `localOnly: true`: refused with `LOCAL_ONLY_CAPABILITY` unless `FD_ENV` or `NODE_ENV` is `development` or `test` (unset counts as development).
 - `requiresApprovedSpec: true`: needs `--spec <path>` to a schema-valid spec with `status: approved`, otherwise `APPROVED_SPEC_REQUIRED`, `SPEC_VALIDATION_FAILED` or `SPEC_NOT_APPROVED`.
 - `destructive` with `--apply`: needs `--confirm <confirmation>` (`CONFIRMATION_REQUIRED`).

package/agent-template/.ai/skills/deploy-operate/SKILL.md

@@ -81,9 +81,12 @@ Both are served by `platform/src/server/health.ts`. The shipped Docker and Kuber
 pnpm flowdular database backup --output <dir>                            # dry run
 pnpm flowdular database backup --output <dir> --apply
 pnpm flowdular database restore --input <dir> --apply --confirm restore-database
+pnpm flowdular database restore-production --input <dir> --target <db> --grant <token> --tenant <id> [--platform-url <origin>|--platform-stopped] --apply --confirm restore-database
 ```
 
-The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets and MFA secrets are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one. Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
+Production restores run `database.restore.production`: an approval grant bound to the exact flags, `--target` equal to the migrator DSN database, a separate migrator DSN, a key mismatch refused unless the approval included `--allow-key-mismatch`, and a refusal while the health endpoint answers. PITR for the compose stack is `infra/docker/pitr.sh` (see `infra/README.md`); in Kubernetes it is the managed provider's job.
+
+The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets, MFA secrets, stored objects and connector credentials are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one; every sealing key has a `secrets-rotate` command in the runbook's rotation table, the storage key two (`documents` and `exports`). Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
 
 ## 6. Rollback
 
@@ -92,6 +95,8 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 3. To take one module out of service without a redeploy: `pnpm flowdular module disable <id> --apply` (it is a dry run without `--apply`), then rebuild the composition and redeploy. Its tables stay.
 4. If the rollback is because of a key change, restore the previous key first; the image alone will not fix unreadable ciphertext.
 
+- For data loss between two dumps use PITR (`pitr.sh restore --target-time`), never a `.down.sql`.
+
 ## 7. Production checklist
 
 - `pnpm verify` and `pnpm build` pass on the commit being shipped (the image build runs both).
@@ -103,7 +108,7 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 - Sign-up closed (`FD_AUTH_ALLOW_SIGN_UP`) unless the deployment is public; the first owner created with `flowdular auth workspace-create` (see `docs/cli.md`).
 - Liveness on `/api/health`, readiness on `/api/ready`.
 - `pnpm flowdular migration verify` clean after rollout, and `pnpm flowdular doctor --json` reports `status: healthy`.
-- A restore has been rehearsed once, keys included.
+- A restore has been rehearsed once, keys included, and a PITR restore once from the newest base backup.
 
 ## Pitfalls
 

package/agent-template/.claude/skills/cli-extension/SKILL.md

@@ -85,7 +85,7 @@ export default cliExtension;
 
 ## 4. What the runner does with the descriptor (`packages/cli/src/runner.ts`, `runExtensionCommand`)
 
-- `risk: 'external'`: refused with `APPROVAL_VERIFIER_REQUIRED`. `risk: 'destructive'` without `localOnly`: the same.
+- `risk: 'external'`, or `'destructive'` without `localOnly`: refused with `APPROVAL_VERIFIER_REQUIRED` unless `--grant <token> --tenant <id>` carries a verified approval grant for this capability and invocation digest (`APPROVAL_GRANT_INVALID`, `APPROVAL_GRANT_EXPIRED`, `APPROVAL_GRANT_MISMATCH` otherwise).
 - `localOnly: true`: refused with `LOCAL_ONLY_CAPABILITY` unless `FD_ENV` or `NODE_ENV` is `development` or `test` (unset counts as development).
 - `requiresApprovedSpec: true`: needs `--spec <path>` to a schema-valid spec with `status: approved`, otherwise `APPROVED_SPEC_REQUIRED`, `SPEC_VALIDATION_FAILED` or `SPEC_NOT_APPROVED`.
 - `destructive` with `--apply`: needs `--confirm <confirmation>` (`CONFIRMATION_REQUIRED`).

package/agent-template/.claude/skills/deploy-operate/SKILL.md

@@ -76,9 +76,12 @@ Both are served by `platform/src/server/health.ts`. The shipped Docker and Kuber
 pnpm flowdular database backup --output <dir>                            # dry run
 pnpm flowdular database backup --output <dir> --apply
 pnpm flowdular database restore --input <dir> --apply --confirm restore-database
+pnpm flowdular database restore-production --input <dir> --target <db> --grant <token> --tenant <id> [--platform-url <origin>|--platform-stopped] --apply --confirm restore-database
 ```
 
-The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets and MFA secrets are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one. Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
+Production restores run `database.restore.production`: an approval grant bound to the exact flags, `--target` equal to the migrator DSN database, a separate migrator DSN, a key mismatch refused unless the approval included `--allow-key-mismatch`, and a refusal while the health endpoint answers. PITR for the compose stack is `infra/docker/pitr.sh` (see `infra/README.md`); in Kubernetes it is the managed provider's job.
+
+The trap: **the encryption keys live outside the database.** Agent provider credentials, agent run grants, workflow payloads and cursors, automation secrets, MFA secrets, stored objects and connector credentials are all stored as ciphertext, and the keys are environment variables (`FD_AGENT_CREDENTIAL_KEY`, `FD_AGENT_RUN_GRANT_KEY`, `FD_WORKFLOWS_PAYLOAD_KEY`, `FD_WORKFLOWS_CURSOR_KEY`, `FD_AUTOMATIONS_CREDENTIAL_KEY`, `FD_AUTH_MFA_KEY`, `FD_NOTIFICATIONS_SECRET_KEY`, `FD_STORAGE_ENCRYPTION_KEY`, `FD_CONNECTORS_SECRET_KEY`, `FD_AUDIT_ANCHOR_KEY`). A database backup without the matching keys restores rows nobody can read, and rotating a key without re-encrypting orphans everything encrypted under the old one; every sealing key has a `secrets-rotate` command in the runbook's rotation table, the storage key two (`documents` and `exports`). Back the keys up separately, restore them together with the dump, and record which key version a dump belongs to.
 
 ## 6. Rollback
 
@@ -87,6 +90,8 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 3. To take one module out of service without a redeploy: `pnpm flowdular module disable <id> --apply` (it is a dry run without `--apply`), then rebuild the composition and redeploy. Its tables stay.
 4. If the rollback is because of a key change, restore the previous key first; the image alone will not fix unreadable ciphertext.
 
+- For data loss between two dumps use PITR (`pitr.sh restore --target-time`), never a `.down.sql`.
+
 ## 7. Production checklist
 
 - `pnpm verify` and `pnpm build` pass on the commit being shipped (the image build runs both).
@@ -98,7 +103,7 @@ The trap: **the encryption keys live outside the database.** Agent provider cred
 - Sign-up closed (`FD_AUTH_ALLOW_SIGN_UP`) unless the deployment is public; the first owner created with `flowdular auth workspace-create` (see `docs/cli.md`).
 - Liveness on `/api/health`, readiness on `/api/ready`.
 - `pnpm flowdular migration verify` clean after rollout, and `pnpm flowdular doctor --json` reports `status: healthy`.
-- A restore has been rehearsed once, keys included.
+- A restore has been rehearsed once, keys included, and a PITR restore once from the newest base backup.
 
 ## Pitfalls
 

package/agent-template/docs/cli.md

@@ -92,6 +92,8 @@ once the restored copy is staged. Being destructive, it needs
 `--apply --confirm restore-database` and, like `database reset`, runs only when
 `FD_ENV` or `NODE_ENV` is `development` or `test`.
 
+`database restore-production` is the same restore without the local gate: it runs only under an approval grant (`--grant <token> --tenant <id>`) bound to the exact flags, needs `--target` equal to the database the migrator DSN names, a separate migrator DSN, and either a health probe that finds the platform down (`--platform-url` or `FD_PORT`) or `--platform-stopped`; a key mismatch is refused unless the approved invocation carried `--allow-key-mismatch`. See docs/operations.md, "Restore in production".
+
 The full procedure, the key trap and the rotation status are in
 [operations.md](operations.md).
 
@@ -117,6 +119,9 @@ flowdular agents secrets-rotate [--apply]          # re-seal stored provider cre
 flowdular automations secrets-rotate [--apply]     # re-seal stored trigger secrets
 flowdular workflows secrets-rotate [--apply]       # re-seal stored run payloads
 flowdular notifications secrets-rotate [--apply]   # re-seal stored webhook signing secrets
+flowdular connectors secrets-rotate [--apply]      # re-seal stored connector credentials
+flowdular documents secrets-rotate [--apply]       # re-seal stored document objects with the storage key
+flowdular exports secrets-rotate [--apply]         # re-seal stored export files with the storage key
 
 flowdular sandbox access --tenant <tenant>         # grants and eligible members
 flowdular sandbox grant --email <email> --tenant <tenant> [--apply]

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

@@ -8,8 +8,8 @@ release artifacts. The landing is in [Flowdular/landing](https://github.com/Flow
 ```sh
 pnpm flowdular module search expenses
 pnpm flowdular module info expenses.core
-pnpm flowdular module install expenses.core@0.6.1
-pnpm flowdular module install expenses.core@0.6.1 --apply
+pnpm flowdular module install expenses.core@0.7.1
+pnpm flowdular module install expenses.core@0.7.1 --apply
 pnpm flowdular module enable expenses.core --apply
 pnpm flowdular module validate --locked
 ```

package/agent-template/docs/operations.md

@@ -135,11 +135,58 @@ is in place, so a failed copy leaves the running database untouched.
 
 `database restore` is a destructive capability, gated exactly like
 `database reset`: the runner refuses it with `LOCAL_ONLY_CAPABILITY` unless
-`FD_ENV` or `NODE_ENV` is `development` or `test`. Production restores therefore
-run `pg_restore --clean --if-exists` by hand with the migrator credentials, and
-the dry run on a staging copy of the same backup is what proves the archive and
-the keys are good. Lifting that restriction waits on the signed approval
-verifier listed under `planned` in `.ai/policies/capabilities.yaml`.
+`FD_ENV` or `NODE_ENV` is `development` or `test`. The dry run on a staging
+copy of the same backup is what proves the archive and the keys are good.
+
+### Restore in production
+
+```bash
+flowdular database restore-production --input <dir> --target flowdular --grant <token> --tenant <id>            # plan
+flowdular database restore-production --input <dir> --target flowdular --grant <token> --tenant <id> \
+  --platform-url https://erp.example.com --apply --confirm restore-database
+```
+
+`database.restore.production` is the same restore without the local gate. It
+runs only under an approval grant from an approved `approvals.core` request,
+verified against `FD_APPROVAL_GRANT_KEY`, the tenant, the capability and the
+exact flags: the request has to name `--input`, `--target`, `--apply` and any
+override (an approval names the applied run, and a dry run is a different
+invocation), and a token issued for another invocation is refused with
+`APPROVAL_GRANT_MISMATCH`. Open the request with `approvals.requests.v1` and a
+`subjectRef` of `capability:<id>:<sha256 of the invocation input>`, read the
+approved request back through `grant(tenantId, id, subjectModule)` for the
+token, and pass it as `--grant <token> --tenant <id>`. `--target` must repeat
+the database the migrator DSN names (`RESTORE_TARGET_MISMATCH` otherwise),
+`FD_DATABASE_MIGRATOR_URL` must be set and distinct from `FD_DATABASE_URL`
+(`MIGRATOR_ROLE_REQUIRED`), and a key divergence is a refusal
+(`BACKUP_KEY_MISMATCH`) unless `--allow-key-mismatch` was part of the approved
+invocation. With `--apply` the command probes `<--platform-url>/api/health`,
+or `http://127.0.0.1:$FD_PORT/api/health`, and refuses with
+`PLATFORM_RUNNING` while anything answers; when no endpoint is named or the
+probe times out it refuses with `PLATFORM_STATE_UNKNOWN` unless
+`--platform-stopped` attests the platform is down. Grants are HMAC-SHA256
+under `FD_APPROVAL_GRANT_KEY` (rotate with `FD_APPROVAL_GRANT_KEY_PREVIOUS`)
+and expire one hour after the approving decision; the runner records no use,
+so a grant replays until it expires and the approval window should stay short.
+`database reset` and `database restore` keep their local-only gate.
+
+### Point-in-time recovery
+
+A dump restores one moment; the compose stack also archives WAL so any moment
+after a base backup can be recovered. See `infra/README.md`, "Backups and
+PITR": `infra/docker/pitr.sh base-backup` after every rollout,
+`pitr.sh restore --base <stamp> --target-time '<ts>' --confirm replace-cluster`
+to recover, and the limits of the plain-copy archive. In Kubernetes the
+managed provider owns PITR; the dump remains the portable copy.
+
+### Rehearsal
+
+Quarterly, on a scratch host: restore the newest dump into an empty database
+with `database restore-production --platform-stopped`, read the key
+comparison, start the app, check `migration verify` and `/api/ready`, then run
+`pitr.sh restore` from the newest base backup to a time between two dumps and
+confirm a row written after the dump is present. Record the date and the
+elapsed time.
 
 ## Key rotation
 
@@ -151,15 +198,15 @@ this section.
 Every module reads one current key plus an optional comma-separated list of
 retired keys (up to eight):
 
-| Key                             | Protects                   | Retired keys                             | Re-sealing the stored rows                              |
-| ------------------------------- | -------------------------- | ---------------------------------------- | ------------------------------------------------------- |
-| `FD_AGENT_CREDENTIAL_KEY`       | Agent provider credentials | `FD_AGENT_CREDENTIAL_KEY_PREVIOUS`       | `pnpm flowdular agents secrets-rotate [--apply]`        |
-| `FD_AUTOMATIONS_CREDENTIAL_KEY` | Automation trigger secrets | `FD_AUTOMATIONS_CREDENTIAL_KEY_PREVIOUS` | `pnpm flowdular automations secrets-rotate [--apply]`   |
-| `FD_WORKFLOWS_PAYLOAD_KEY`      | Workflow run payloads      | `FD_WORKFLOWS_PAYLOAD_KEY_PREVIOUS`      | `pnpm flowdular workflows secrets-rotate [--apply]`     |
-| `FD_STORAGE_ENCRYPTION_KEY`     | Stored objects             | `FD_STORAGE_ENCRYPTION_KEY_PREVIOUS`     | No re-sealing pass yet; see the storage note below      |
-| `FD_NOTIFICATIONS_SECRET_KEY`   | Webhook signing secrets    | `FD_NOTIFICATIONS_SECRET_KEY_PREVIOUS`   | `pnpm flowdular notifications secrets-rotate [--apply]` |
-| `FD_CONNECTORS_SECRET_KEY`      | Connector credentials      | `FD_CONNECTORS_SECRET_KEY_PREVIOUS`      | No re-sealing pass yet; the ring reads the previous key |
-| `FD_AUDIT_ANCHOR_KEY`           | Audit chain anchors (HMAC) | `FD_AUDIT_ANCHOR_KEY_PREVIOUS`           | `pnpm flowdular audit secrets-rotate [--apply]`         |
+| Key                             | Protects                   | Retired keys                             | Re-sealing the stored rows                                                                                                            |
+| ------------------------------- | -------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `FD_AGENT_CREDENTIAL_KEY`       | Agent provider credentials | `FD_AGENT_CREDENTIAL_KEY_PREVIOUS`       | `pnpm flowdular agents secrets-rotate [--apply]`                                                                                      |
+| `FD_AUTOMATIONS_CREDENTIAL_KEY` | Automation trigger secrets | `FD_AUTOMATIONS_CREDENTIAL_KEY_PREVIOUS` | `pnpm flowdular automations secrets-rotate [--apply]`                                                                                 |
+| `FD_WORKFLOWS_PAYLOAD_KEY`      | Workflow run payloads      | `FD_WORKFLOWS_PAYLOAD_KEY_PREVIOUS`      | `pnpm flowdular workflows secrets-rotate [--apply]`                                                                                   |
+| `FD_STORAGE_ENCRYPTION_KEY`     | Stored objects             | `FD_STORAGE_ENCRYPTION_KEY_PREVIOUS`     | `pnpm flowdular documents secrets-rotate [--apply]` and `pnpm flowdular exports secrets-rotate [--apply]`; see the storage note below |
+| `FD_NOTIFICATIONS_SECRET_KEY`   | Webhook signing secrets    | `FD_NOTIFICATIONS_SECRET_KEY_PREVIOUS`   | `pnpm flowdular notifications secrets-rotate [--apply]`                                                                               |
+| `FD_CONNECTORS_SECRET_KEY`      | Connector credentials      | `FD_CONNECTORS_SECRET_KEY_PREVIOUS`      | `pnpm flowdular connectors secrets-rotate [--apply]`                                                                                  |
+| `FD_AUDIT_ANCHOR_KEY`           | Audit chain anchors (HMAC) | `FD_AUDIT_ANCHOR_KEY_PREVIOUS`           | `pnpm flowdular audit secrets-rotate [--apply]`                                                                                       |
 
 These commands run the same re-sealing pass over their own table, so the
 procedure is the same for each. The credential key is the worked example;
@@ -227,6 +274,10 @@ Sources: `modules/audit/src/services/{anchor-key,anchor-rotation}.ts`,
 `modules/automations/src/services/{secret-vault,secret-rotation}.ts`,
 `modules/workflows/src/services/{payload-codec,payload-rotation,cursors}.ts`,
 `modules/notifications/src/services/{secret-vault,secret-rotation}.ts`,
+`modules/connectors/src/services/{credential-vault,credential-rotation}.ts`,
+`packages/storage/src/reseal.ts`,
+`modules/documents/src/services/storage-rotation.ts`,
+`modules/exports/src/services/storage-rotation.ts`,
 `modules/auth/src/services/totp.ts`.
 
 ## Storage
@@ -243,12 +294,42 @@ no longer holds leaves dangling references, and the reverse leaves orphans.
   `.flowdular/data/storage`; stop the application before copying it.
 
 Every object is sealed with AES-256-GCM under `FD_STORAGE_ENCRYPTION_KEY`, and
-the key id is stored with the object, so a rotation runs like the four above:
-put the retired key in `FD_STORAGE_ENCRYPTION_KEY_PREVIOUS`, deploy, and every
-object written earlier still opens while new ones use the current key. There is
-no re-sealing pass yet, so keep the retired key in the ring until every object
-written under it has been rewritten or deleted. Dropping it makes those objects
-unreadable, exactly as a lost database key makes a credential unreadable.
+the key id is stored with the object, so the rotation follows the six steps
+above with two commands instead of one, because the object store has no
+listing and the rows that name the objects belong to two modules:
+
+1. Generate the new key: `openssl rand -base64 32`.
+2. Set `FD_STORAGE_ENCRYPTION_KEY=<new>` and
+   `FD_STORAGE_ENCRYPTION_KEY_PREVIOUS=<old>` in the secret store.
+3. Deploy. Every new object is sealed with the new key and every stored one
+   still opens under the old one.
+4. Dry run both passes and read the counts per key id:
+   `pnpm flowdular documents secrets-rotate --json` walks the stored document
+   rows, `pnpm flowdular exports secrets-rotate --json` the completed export
+   jobs. `stale` is the number of objects still sealed with a retired key;
+   `unknown` names objects under a key neither variable holds, and the pass
+   leaves those alone.
+5. Run both again with `--apply`. Each object is re-sealed in place: the frame
+   is opened under the key it names, which authenticates its header, and the
+   same content type, size, checksum, scan verdict and creation time are
+   written back under the current key. Nothing else changes, not the object
+   key and not the row. A frame that fails authentication is counted under
+   `refused` and left as it is; restore it from the object store backup.
+6. Repeat the dry runs until both report `stale: 0`, then remove
+   `FD_STORAGE_ENCRYPTION_KEY_PREVIOUS` and deploy again.
+
+The application may stay up: the pass locks a row while it rewrites the
+object, and both delete paths (a document removal and the export retention
+sweep) lock the row before they remove the object and then the row, so a delete
+that lands mid-pass waits for the rewrite and removes the re-sealed object
+rather than racing it. A frame that fails to parse is counted under `refused`
+like one that fails authentication. Do not snapshot the object store and the database apart while a
+pass runs: a bucket snapshot taken mid-pass holds objects under both keys, and
+restoring it beside a database from another moment leaves rows that name
+objects a ring without the retired key cannot open. Take both after the pass,
+or both before it. Dropping the retired key while `stale` is above zero makes
+those objects unreadable, exactly as a lost database key makes a credential
+unreadable.
 
 ## Logs
 

package/agent-template/platform/scripts/build.mjs

@@ -25,6 +25,7 @@ const environment = {
 	FD_DATABASE_PGLITE_DIRECTORY: join(stateDirectory, 'pglite'),
 	FD_AGENT_CREDENTIAL_KEY: buildSecret(),
 	FD_AGENT_RUN_GRANT_KEY: buildSecret(),
+	FD_APPROVAL_GRANT_KEY: buildSecret(),
 	FD_AUTOMATIONS_CREDENTIAL_KEY: buildSecret(),
 	FD_NOTIFICATIONS_SECRET_KEY: buildSecret(),
 	FD_WORKFLOWS_PAYLOAD_KEY: buildSecret(),

package/dist/bin.js

@@ -355,6 +355,7 @@ import { randomBytes } from "node:crypto";
 var SECRET_KEYS = [
   "FD_AGENT_CREDENTIAL_KEY",
   "FD_AGENT_RUN_GRANT_KEY",
+  "FD_APPROVAL_GRANT_KEY",
   "FD_AUTOMATIONS_CREDENTIAL_KEY",
   "FD_NOTIFICATIONS_SECRET_KEY",
   "FD_WORKFLOWS_PAYLOAD_KEY",

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "create-flowdular",
-	"version": "0.3.0",
+	"version": "0.3.1",
 	"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

@@ -35,6 +35,8 @@ FD_TRUST_PROXY=false
 # production without their key.
 FD_AGENT_CREDENTIAL_KEY=
 FD_AGENT_RUN_GRANT_KEY=
+FD_APPROVAL_GRANT_KEY=
+FD_APPROVAL_GRANT_KEY_PREVIOUS=
 FD_AUTOMATIONS_CREDENTIAL_KEY=
 FD_NOTIFICATIONS_SECRET_KEY=
 FD_WORKFLOWS_PAYLOAD_KEY=

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

@@ -16,7 +16,7 @@
 	"dependencies": {
 		"octane": "0.1.51",
 		"segment-state": "0.2.1",
-		"@flowdular/sdk": "0.3.0"
+		"@flowdular/sdk": "0.3.1"
 	},
 	"devDependencies": {
 		"@tsrx/typescript-plugin": "0.3.120",

package/template/default/package.json

@@ -25,7 +25,7 @@
 	"devDependencies": {
 		"@tsrx/prettier-plugin": "0.3.120",
 		"prettier": "3.6.2",
-		"flowdular": "0.3.0",
+		"flowdular": "0.3.1",
 		"rulesync": "16.21.0"
 	}
 }

package/template/default/platform/package.json

@@ -15,7 +15,7 @@
 		"@octanejs/vite-plugin": "0.1.51",
 		"octane": "0.1.51",
 		"pg": "8.23.0",
-		"@flowdular/sdk": "0.3.0"
+		"@flowdular/sdk": "0.3.1"
 	},
 	"devDependencies": {
 		"@octanejs/app-core": "0.0.47",