@agent-native/core 0.141.6 → 0.144.0

package/src/templates/headless/.agents/skills/turn-into-app/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: turn-into-app
+description: >-
+  Turn a proven thread, skill, or workflow into a runnable Agent-Native app
+  with simple buttons, visible agent steps, preview, and deployment handoff.
+  Use when a user invokes `/turn-into-app` or asks to make a workflow into an
+  app.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into App
+
+## Default behavior
+
+This is an end-to-end build skill, not a request for an app proposal.
+
+- With no argument, use the current thread as the source. This is the normal
+  invocation at the end of a successful workflow.
+- With a named skill or local workflow, read that source and package it
+  immediately, even at the beginning of a thread. For example,
+  `/turn-into-app /some-skill` means “turn `/some-skill` into an app.”
+- With an attachment or path, read the supplied artifact as the source.
+- Do not ask the user to restate context that is already in the thread.
+- When invoked from an Agent-Native app, keep the current thread as the source
+  and use the available workspace/coding-agent handoff when the current runtime
+  cannot edit files. Do not claim the app exists without an actual path and
+  verification result.
+
+## Source support
+
+Supported source paths today are the current Codex thread, a named skill, or a
+local workflow/transcript supplied as a path or attachment. An exported
+ChatGPT or Claude transcript can use the same local-file path today.
+
+ChatGPT shared-conversation import and Claude web conversation/project import
+are **coming soon**. Do not claim private web access, invent an importer, add
+fake OAuth, or scrape a logged-in page without an explicit supported adapter.
+If a user gives one of those URLs before an adapter exists, ask for an export or
+transcript instead and treat it as imported source material.
+
+Deliver a fresh app in a new directory, implement the repeatable workflow with
+buttons and agent handoffs, start its dev server, verify the main path, and
+continue through build/deployment handoff. Do not stop at a plan.
+
+## Source selection guard
+
+The generated app must implement the concrete workflow found in the source. It
+must not become a generic “what app do you want to make?” intake form.
+
+- In a delegated or forked task, read the actual referenced source thread and
+  the latest explicit workflow direction in the current task. If they disagree,
+  the latest concrete workflow direction wins.
+- Do not treat a thread that merely discusses building this skill as the product
+  source unless the user explicitly asks to appify that meta-workflow.
+- If the source contains several workflows, choose the latest successful,
+  repeatable job that motivated the request and name it in the handoff. If no
+  concrete job can be identified, stop and report what is missing instead of
+  inventing an app-builder UI.
+
+## UI contract for generated apps
+
+Generated apps must follow the shared Agent-Native surface model:
+
+- Keep the domain workflow on a named route (`/workflow`, `/automations`,
+  `/block`, or the source's equivalent). Preserve the scaffold's full-page
+  chat route instead of replacing it with a domain form while leaving the
+  layout configured as a chat page.
+- Use the right `AgentSidebar` for contextual AI. Every button-triggered
+  `sendToAgentChat` handoff should open or focus that sidebar and keep the user
+  on the current domain page.
+- Use a sans-first SaaS hierarchy for the app shell. Choose a named visual
+  direction in `DESIGN.md` before styling: product mode, audience, palette
+  family, type treatment, composition, shape language, and anti-references.
+  One restrained editorial cue is welcome, but warm beige plus terracotta is
+  not the default and serif type belongs in content previews or a deliberate
+  brand moment rather than the whole tool.
+- Preserve existing brand tokens. For a new unbranded app, choose a
+  product-fitting palette family and compare sibling apps before reusing their
+  accent. Keep shared semantic tokens and Agent-Native behavior consistent
+  while varying the visual world, density, composition, and shape language.
+- Give the AgentSidebar a subtle surface or divider boundary so it is visually
+  distinct from the domain page without becoming a heavy panel wall.
+- Every AI-labeled button must actually call `sendToAgentChat` with bounded
+  context and `openSidebar: true`. Keep `submit: true` for direct execution and
+  `submit: false` only when the user should edit the staged prompt first. Label
+  deterministic local actions as local, preview, or analyze instead of AI.
+- Standalone apps that render `AgentSidebar` must keep one assistant-ui runtime
+  context. Pin the versions compatible with the installed core/toolkit peer
+  graph, and add Vite dedupe/aliases when linked or transitive packages resolve
+  duplicate assistant-ui modules. Verify a fresh AI handoff has no
+  `AssistantUiStaleIndexErrorBoundary` or stale-index console error.
+- Make the left navigation describe domain destinations. Chat is a separate
+  destination, not the label for every app page.
+- Start with one primary action and one compact state. Put setup choices,
+  advanced inputs, diagnostics, and long explanations behind progressive
+  disclosure or later workflow steps.
+- Never use sparkle, wand, magic, robot, or similar decorative AI icons. Use a
+  message or neutral action icon, or no icon when the button label is enough.
+- Before handoff, inspect the first viewport for text density, repeated cards,
+  unrelated forms, and generic helper copy. Remove what the user does not need
+  until the next decision.
+- Run a `distill`, `typeset`, `colorize`, `layout`, `polish`, and `audit` pass
+  as useful named reviews. Make one intervention at a time and commit the
+  chosen direction rather than averaging several options into generic SaaS.
+- For before/after or original/generated review, stack the source first and the
+  result second by default. Reserve side-by-side layouts for short content that
+  remains comfortable to scan at the target width.
+
+## 1. Extract the workflow
+
+Read the full available source before coding. Reduce it to a short working
+brief:
+
+- the user and repeatable job;
+- inputs and outputs;
+- the 1-3 judgment-heavy agent moments;
+- the buttons, review points, and retry states a user needs;
+- data, permissions, integrations, and failure boundaries.
+
+Preserve useful judgment from the source, but do not turn a one-off answer,
+private data, or an unverified result into a product contract. If the source is
+not available or does not contain a repeatable job, say what is missing rather
+than claiming the app is complete.
+
+## 2. Create a fresh app
+
+Choose a short slug from the workflow and create a new directory. Never
+overwrite an existing app. If the user supplied a directory, use it; otherwise
+use `apps/<slug>` inside an existing Agent-Native workspace, or a new sibling
+directory when working outside one.
+
+For a new UI-bearing standalone app, use the current Agent-Native scaffold and
+then read the generated `AGENTS.md`:
+
+```bash
+npx @agent-native/core@latest create <app-directory> --template chat
+cd <app-directory>
+pnpm install
+```
+
+When working inside an existing Agent-Native workspace, create the app from
+the workspace root instead:
+
+```bash
+pnpm exec agent-native add-app <slug> --template=chat
+```
+
+Do not use `create` for an existing workspace; it scaffolds a new standalone
+workspace rather than adding an app to the current one.
+
+Use a first-party template only when it materially fits the workflow. Keep the
+new app independent from the source thread's working tree unless the user
+explicitly asks to extend an existing app.
+
+Read the generated `DESIGN.md` before building the first screen and fill in the
+visual direction as part of the app brief. Do not copy the previous app's
+palette just because its tokens are nearby.
+
+## 3. Turn the workflow into buttons and agent work
+
+Implement the smallest useful surface around the extracted brief. The app
+should make the repeated path obvious without hiding the agent's judgment:
+
+- Give each important repeated moment a clear button, such as “Analyze,”
+  “Suggest options,” “Draft,” “Review,” or “Publish.” Use the source's actual
+  vocabulary when it is clear.
+- Put deterministic reads, writes, approvals, and publishing in `actions/`
+  with `defineAction`. The UI and agent must call the same action surface.
+- Use application state for the current screen, selected item, and focused
+  object so the agent can see where the user is.
+- Use `sendToAgentChat({ message, context, submit: true })` for intentional
+  button-triggered agent work. Use `submit: false` when the user should review
+  or edit the proposed prompt first.
+- Pass IDs, URLs, and bounded summaries in context. Do not paste large provider
+  dumps into prompts, call an LLM directly from the browser, or invent fake
+  progress.
+- Make agent results visible, editable, retryable, and attributable. Keep
+  irreversible actions behind an explicit review or confirmation point.
+
+Use the existing shadcn/ui primitives, Tabler icons, shared composer, and
+optimistic action patterns. Do not add a parallel CRUD API route for an action.
+
+## 4. Keep onboarding shared
+
+Use the framework's existing setup experience. The app should offer the normal
+“Connect Builder” and “Add your own keys” paths for AI setup. Do not create a
+second credential form or hardcode a provider key.
+
+In local-development instructions, add a brief note that a developer can set
+an environment variable such as `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` before
+starting the app; after restart, the setup prompt is no longer shown when the
+key is available. Keep real secrets out of source, examples, and generated
+content.
+
+Turn-into-app apps should commit an `agent-native.json` app configuration so a
+plain `pnpm dev` has the right first-run behavior without extra flags:
+
+```json
+{
+  "version": 1,
+  "onboarding": {
+    "firstRun": {
+      "development": "connect",
+      "production": "connect-and-integrations"
+    }
+  }
+}
+```
+
+`connect` keeps the Connect Builder / Add your own keys choice visible and
+skips only the generic “This app is an agent.” integrations catalog. The
+production value includes that catalog for a hosted app. Do not replace this
+with a local credential form or remove the shared onboarding. In development,
+the shared Connect Builder card also explains the deployment-level
+`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` fallback and links to the full
+environment-variable guide.
+
+When the onboarding default needs code rather than a static mode map, add an
+optional `agent-native.config.ts` with the same returned shape:
+
+```ts
+import { defineAgentNativeConfig } from "@agent-native/core/config";
+
+export default defineAgentNativeConfig(({ isDev }) => ({
+  version: 1,
+  onboarding: {
+    firstRun: isDev ? "connect" : "connect-and-integrations",
+  },
+}));
+```
+
+The Vite preset loads this file automatically on supported Node versions. The
+JSON file remains the portable, inspectable fallback. See the [Agent-Native
+app configuration guide](/docs/agent-native-config) for precedence, supported
+modes, and the boundary between committed config and deployment secrets.
+
+For an account-free local preview, create the ignored local `.env` file with
+`AUTH_DISABLED=1` before starting the dev server. This is only for loopback
+development; never commit or deploy this setting. AI/provider connections still
+use the normal onboarding flow or the documented environment-variable keys.
+
+## 5. Run it immediately
+
+From the new app directory:
+
+```bash
+pnpm dev
+```
+
+For a fresh local test app, use the ignored `.env` with `AUTH_DISABLED=1` so the
+domain UI opens without an account; the committed app config makes shared
+onboarding visible. Keep the process running so the user can try the app. Read
+the actual server output and report the real local URL. If the app needs installation or a setup step,
+complete it when possible and distinguish “not configured” from an unavailable
+credential store.
+
+## 6. Verify, build, and deploy
+
+Exercise the actual happy path, not only the source files:
+
+1. Load the reported URL and confirm the main route renders.
+2. Confirm the shared onboarding state or a configured local key.
+3. Click the primary workflow button and confirm the intended agent handoff.
+   Also click every other AI-labeled button and confirm it opens the same
+   contextual sidebar with the expected prompt or staged context.
+4. Confirm the result, action persistence, application state, and sync path.
+5. Check the dev output for browser/runtime errors, and capture input, result,
+   and agent-sidebar states so the complete flow is reviewable.
+
+Then run the supported build. For a standalone app, use the generated app's
+documented build and hosting path. For an app inside a workspace, use the
+workspace deploy command, for example:
+
+```bash
+npx @agent-native/core@latest build
+npx @agent-native/core@latest deploy --preset netlify
+```
+
+Use `vercel` or another supported preset when that is the configured target.
+Attempt deployment when the user requested it or the project already has the
+required provider configuration. If external authentication, a production
+secret, or a hosting decision is missing, finish local verification and report
+the exact remaining handoff without claiming a live deployment.
+
+Label evidence separately: locally running, locally verified, build-ready,
+deployed, and live-verified are different states.
+
+## Handoff
+
+End with the new app directory, local URL, visual direction, what the buttons do,
+account-free local-preview status, verification performed, deployment URL if it is real,
+and one precise pending step when something could not be completed. Keep the
+handoff short enough to use in a demo or recording.

package/src/templates/headless/.agents/skills/turn-into-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into App"
+  short_description: "Turn a thread or skill into a runnable app"
+  default_prompt: "Scan the current thread, turn the workflow into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/src/templates/headless/.agents/skills/turn-into-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: turn-into-skill
+description: >-
+  Capture a proven thread or workflow as a reusable Agent-Native skill and save
+  it as a personal or organization resource. Use when a user invokes
+  `/turn-into-skill` or asks to save a workflow for reuse.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into Skill
+
+This is a packaging-and-save workflow, not a request for a proposal. A skill
+is the lightweight path for a repeatable job that mostly needs guidance and
+existing app actions. Use `turn-into-app` when the job needs a dedicated UI,
+new persistent domain state, or a distinct app route.
+
+## Default behavior
+
+- With no argument, use the current thread as the source.
+- With a named skill, local workflow, transcript path, or attachment, read that
+  source and package it immediately.
+- Do not ask the user to restate context already present in the source.
+- Default to a personal skill unless the user explicitly asks for a team,
+  organization, or all-app skill, or passes `shared` as the scope.
+- If the current thread only discusses creating a skill, do not package that
+  meta-workflow unless the user explicitly asks for it.
+- Treat an explicit `/turn-into-skill` invocation as authorization to save the
+  resulting skill, but never overwrite an existing skill at the target path
+  unless the user clearly asks to update it.
+
+## 1. Extract the repeatable workflow
+
+Read the full source before writing. Reduce it to a concise working brief:
+
+- the repeatable job and the user outcome;
+- when the skill should trigger;
+- required inputs, context, permissions, and integrations;
+- the ordered steps and the one to three judgment-heavy decisions;
+- expected outputs, verification, retry, and failure boundaries.
+
+Preserve the useful judgment from the source, not its transcript. Do not turn
+one-off answers, private data, customer data, secrets, or unverified claims into
+the skill's contract. If no repeatable job can be identified, stop and report
+what is missing instead of inventing generic guidance.
+
+## 2. Author the skill
+
+Create a single `SKILL.md` with:
+
+- a short hyphen-case name and a description under 40 words that says what the
+  skill does and when to use it;
+- `user-invocable: true` so it can be selected from the app's `/` picker;
+- `scope: both` so the saved skill can guide the app runtime and connected
+  coding agents;
+- concise sections for purpose, trigger, inputs, workflow, verification, and
+  failure or retry behavior.
+
+Write imperative, reusable instructions. Keep exact action names, field rules,
+and decision criteria when they matter. Use placeholders for credentials and
+provider data. Do not paste the source transcript, large dumps, or ephemeral
+thread details into the saved skill.
+
+Choose a new slug when the target path already exists. Read an existing skill
+before changing it, and update it only when the user explicitly requested an
+update.
+
+## 3. Save at the requested scope
+
+Skills are resources at `skills/<slug>/SKILL.md`.
+
+| User intent | Save path |
+| --- | --- |
+| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |
+| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |
+| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |
+| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |
+
+For an all-app workspace skill, use the workspace resource action when it is
+available. If the current app does not expose it, discover or delegate to the
+configured Dispatch workspace agent. Do not silently save a personal skill and
+report it as shared. If organization approval is queued, report that the skill
+is pending approval rather than claiming it is active.
+
+Set `visibility: "workspace"` for an explicitly requested saved skill. Use
+`agent_scratch` only for temporary drafting, then promote or rewrite it before
+reporting the skill as saved.
+
+## 4. Verify and hand off
+
+After saving, read the exact `skills/<slug>/SKILL.md` resource back at the
+target scope. Confirm that the frontmatter name, trigger description, and full
+workflow body are present. If the read-back fails or the save returned an
+approval request, say so plainly and include the actual pending state.
+
+Report:
+
+- the skill name and path;
+- whether it is personal, organization-wide, or selected-app;
+- the trigger users can invoke from `/`;
+- the verification result and any approval or setup still required.
+
+## Related skills
+
+- `turn-into-app` — package the same source as a UI-bearing app with buttons,
+  agent handoffs, and a domain workflow.
+- `create-skill` — general skill format and authoring rules.
+- `capture-learnings` — lightweight memory for preferences and corrections,
+  rather than reusable workflows.
+- `self-modifying-code` — safety boundaries when the agent edits app source.

package/src/templates/headless/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into Skill"
+  short_description: "Save a proven workflow as a reusable skill"
+  default_prompt: "Read the current thread, distill the repeatable workflow into a concise user-invocable skill, save it at personal or organization scope, verify the saved resource, and report its path."

package/src/templates/workspace-core/.agents/skills/adding-workspace-apps/SKILL.md

@@ -34,6 +34,12 @@ Dispatch vault access is workspace-wide by default: every saved vault key is
 available to every workspace app. Only create or request per-app vault grants
 when Dispatch's vault access setting is switched to manual mode.
 
+When an app needs a provider credential, use the app's scoped secret or
+workspace-connection resolver so Dispatch remains the source of truth. Do not
+ask a non-admin builder to add a key to local project settings or `.env`; use
+Dispatch's vault request workflow for a missing key and keep the value out of
+app code.
+
 ## Discovery, Links, And The UI Stack
 
 Workspace apps are discovered from `apps/<app-name>/package.json`. There is no

package/src/templates/workspace-core/.agents/skills/address-feedback/SKILL.md

@@ -38,7 +38,35 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    Use web browsing only for public URLs. Auth-gated docs usually need their matching connector. For threads, read the parent and all replies; note when there are no replies, and inspect linked files or newer follow-ups when the source refers to them.
 
-2. Decompose and categorize every actionable item.
+2. Check whether this defect has already been reported.
+
+   A feedback channel holds months of reports and nobody remembers all of them,
+   so the same defect gets filed by different people weeks apart and every
+   filing reads as new. One recorded case: the same Clips recording bug was
+   filed almost word-for-word 29 days apart by the same reporter, and neither
+   message mentions the other. Another defect was reported fifteen times by
+   nine people across three months, was announced as fixed once in the middle,
+   and was reported again two weeks later.
+
+   Search before fixing, going back at least three months: the source channel
+   in the reporter's words and in your own, Sentry, and merged PR titles. Search
+   the feature name, the error text, and the surface separately — repeat reports
+   rarely share vocabulary.
+
+   - **No prior report** — proceed normally.
+   - **Prior report, no fix landed** — say how long it has been open. The person
+     forwarding it to you is likely seeing it for the second time too.
+   - **Prior report, fix landed** — this is a regression, and the bar is now
+     different. Patching it again and reporting done is exactly how it returns a
+     third time. Find why the first fix stopped holding, and leave behind
+     something that fails when it breaks again: a test that reproduces the
+     user's path, or an assertion in the flow the report names.
+
+   Report the repeat explicitly, with dates and reporters. A defect on its third
+   report is not a bug ticket, it is a missing check — and the missing check is
+   the deliverable, not the patch.
+
+3. Decompose and categorize every actionable item.
 
    Build a compact checklist before changing code. For each item, record the
    symptom, expected behavior, evidence, and owning surface: UI, action/tool,
@@ -49,7 +77,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - **Question or unclear**: Missing detail, contradictory feedback, or behavior you cannot inspect. Ask or flag it.
    - **Out of scope**: Outside this repo, already shipped, intentionally unsupported, or too low-signal. Note briefly and skip.
 
-3. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
+4. For data, permissions, or resource-lifecycle feedback, verify the whole capability boundary before calling it UX.
 
    - Check the supported create/read/update/delete lifecycle, including whether the backend/action exists when a UI control is missing.
    - Inspect both the UI and the shared action/tool surface so agent and UI behavior stay in parity.
@@ -57,7 +85,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Treat possible cross-user or cross-organization exposure as a security/correctness bug and verify it before proposing polish.
    - Keep undefined product policy separate from implementation bugs. If supported source types or scope semantics are not defined, flag the contract question instead of inventing behavior.
 
-4. Check Sentry when the feedback smells like an error.
+5. Check Sentry when the feedback smells like an error.
 
    - Use the Sentry skill/plugin if available, or the repo's Sentry scripts if documented.
    - Search by route, stack symbol, error text, and symptom keywords.
@@ -65,7 +93,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Cite issue IDs or links when you find a match.
    - If nothing matches, say that plainly.
 
-5. Fix only the clear bugs you agree with.
+6. Fix only the clear bugs you agree with.
 
    - Verify before fixing: reproduce locally, read the relevant code, inspect logs, or confirm with a stack trace.
    - Keep each fix narrow and mapped to a feedback item.
@@ -73,7 +101,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
    - Do not switch branches, stash, reset, force-push, or open a PR unless the user asks.
    - Add or update focused tests when the bug risk warrants it.
 
-6. Treat UX feedback with restraint.
+7. Treat UX feedback with restraint.
 
    Do not solve UX problems by adding more visible controls, helper text, banners, top-level nav, or always-open panels by default. Prefer cleaner interaction models:
 
@@ -85,7 +113,7 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 
    When proposing a UX change, write it as: what to change, why it helps, and the tradeoff. Keep each proposal short.
 
-7. Verify changed behavior.
+8. Verify changed behavior.
 
    - Run the smallest relevant test or typecheck command.
    - For UI fixes, inspect the actual screen with a browser tool you already
@@ -100,6 +128,9 @@ The default posture is judgment plus action: fix clear, verified bugs you agree
 Keep the final report short:
 
 ```md
+## Repeat Reports
+- [defect] - reported [N] times since [date] by [reporters]; [what now fails if it regresses]
+
 ## Bugs Fixed
 - [feedback item] - [what changed, file:line]
 

package/src/templates/workspace-core/.agents/skills/authentication/SKILL.md

@@ -204,7 +204,7 @@ For public pages (share links, embeds, marketing pages) that need anonymous view
 ```ts
 const ret = window.location.pathname + window.location.search;
 window.location.href =
-  "/_agent-native/sign-in?return=" + encodeURIComponent(ret);
+  "/sign-in?return=" + encodeURIComponent(ret);
 ```
 
 After successful sign-in (token / email-password / Google OAuth), the framework redirects to `return`. The path is validated as same-origin via the URL parser — open-redirect / header-injection inputs fall back to `/`.
@@ -230,7 +230,9 @@ will be rejected.
 
 `AppProviders` applies `RequireSession` automatically on its private branch. It
 resolves the session on the client and redirects signed-out visitors to
-`/_agent-native/sign-in?return=…` before mounting the routed shell:
+`/sign-in?return=…` before mounting the routed shell. The legacy
+`/_agent-native/sign-in` path remains supported for older generated apps and
+bookmarks:
 
 ```tsx
 import { AppProviders } from "@agent-native/core/client/hooks";

package/src/templates/workspace-core/.agents/skills/performance/SKILL.md

@@ -182,6 +182,55 @@ another visitor's shared CDN entry.
 - **Virtualize** very long rendered lists on the client so off-screen rows aren't
   parsed/rendered every update.
 
+## 8. Don't do data work at startup
+
+A server plugin's body is not "once per deploy." These apps run as serverless
+functions, so it runs **once per cold start** — on the critical path of whichever
+user's request woke the process, and again on the next cold start. An in-process
+`let done = false` memo does not help: the new isolate starts with `false`.
+
+This has already cost real outages and sustained slowness here, not hypothetical
+ones — Slides startup slowness, Analytics paying startup cost on API calls, and a
+production incident. The shape that did it:
+
+```ts
+// templates/<app>/server/plugins/db.ts — every cold start pays all of this
+export default async (nitroApp) => {
+  await migrations(nitroApp);
+  await retypeBooleanColumnsOnPostgres();   // rewrites tables on Postgres
+  await backfillLegacyTables();
+  await syncWorkspacesToOrganizations();
+  await backfillRecordingOrgId();
+};
+```
+
+Schema DDL is **not** exempt, though it reads like it should be. Measured on a
+180-table production database: the migration "fast path" (`SELECT MAX(version)`)
+took **5.5s** and the `information_schema` probe **8.3s** — paid on every cold
+start, until health checks timed out and the app was down. Bounded is not the
+same as fast, and "it short-circuits cheaply" is an assumption until someone
+measures it on the largest database you have.
+
+The same applies doubly to **work whose cost grows with the data** — backfills, retypes, aggregations, recomputes, re-syncs,
+sweeps, cache warming, index rebuilds. Those have three better homes, all of
+which already exist:
+
+- a **scheduled job** (`recurring-jobs`, `automations` skills),
+- a **one-off CLI or release-time script**, run deliberately, once,
+- **lazily behind the first caller that needs it**, memoized — accepting that
+  the memo is per-isolate, so the work must be small enough to repeat.
+
+If it truly must complete before the app can serve a correct response, it is a
+migration, not a backfill — say so on the line and keep it bounded:
+
+```ts
+await backfillOneRow(); // guard:allow-boot-data-work — single row, bounded
+```
+
+`guard:no-boot-data-work` fails on new boot-time data work, scoped to lines this
+branch adds. It cannot see everything — a helper that hides the work one call
+deeper reads as innocent — so the rule matters more than the check.
+
 ## Checklist — run before shipping a list/read or a new table
 
 - [ ] List selects only displayed columns; heavy blobs excluded or `substr`-truncated.
@@ -193,5 +242,7 @@ another visitor's shared CDN entry.
 - [ ] Unbounded lists are paginated/windowed; large blobs aren't inlined on the hot path.
 - [ ] SSR HTML/`.data` path stays session-blind and cacheable — no `private`,
       `no-store`, `Vary: Cookie`, or auth branch added to it.
+- [ ] No data work added to a server plugin body / module scope — backfills,
+      aggregations and re-syncs run on every cold start there (see §8).
 - [ ] Mutation-fresh reads go through actions + `useActionQuery`, not SSR loader
       data.