@desplega.ai/agent-swarm 1.172.0 → 2.0.0

package/dist/{index-6ksewd5y.js → index-s2wxgzr0.js}

@@ -3,44 +3,50 @@ import {
 } from "./cli-ep19k3mb.js";
 import {
   agentFsProvisionSeeder
-} from "./cli-gj81e47t.js";
+} from "./cli-r2pnvj8g.js";
 import {
   extractArgsJsonSchema,
   extractScriptSignature,
+  parseSkillContent,
   require_dist,
   typecheckScript,
   validateScriptImports
-} from "./cli-j6kpj9az.js";
+} from "./cli-ee9gtz70.js";
 import"./cli-epan13p1.js";
 import"./cli-zt3w1cn1.js";
-import"./cli-388egyf6.js";
+import"./cli-6razj6t4.js";
 import {
   validateDefinition
-} from "./cli-aspcaef3.js";
-import"./cli-xczpdp9e.js";
-import"./cli-7jykv7ef.js";
-import"./cli-cceskcvt.js";
-import"./cli-h6vtvt5c.js";
+} from "./cli-v1yb0rqb.js";
+import"./cli-se8w6wny.js";
+import"./cli-e6mpjhed.js";
 import"./cli-2x0e561b.js";
+import"./cli-txqb9s38.js";
+import"./cli-h6vtvt5c.js";
 import"./cli-bsakbbkm.js";
 import"./cli-zxg80zs9.js";
 import"./cli-ydt3zkwv.js";
-import"./cli-9xsmdpdt.js";
-import"./cli-q51yprfq.js";
+import"./cli-skxvvpap.js";
+import"./cli-n2wq4j7m.js";
+import"./cli-wmgrkscj.js";
 import"./cli-3er6gcsn.js";
-import"./cli-yatxqynm.js";
+import"./cli-hjwmhcg1.js";
+import"./cli-rhs9pz33.js";
+import"./cli-9ha6hs2d.js";
+import"./cli-k3dp5tpf.js";
 import"./cli-61625k3x.js";
-import"./cli-btbzvq95.js";
 import"./cli-1m2e086m.js";
+import"./cli-btbzvq95.js";
 import"./cli-p7z6q2m6.js";
 import"./cli-wnb9b2g3.js";
-import"./cli-bd957dgb.js";
+import"./cli-f527ce74.js";
 import"./cli-pzxba7gw.js";
 import {
   computeContentHash,
   createScheduledTask,
   createSkill,
   createWorkflow,
+  deleteSkill,
   deleteSkillFile,
   getDbClient,
   getScheduledTaskByName,
@@ -55,28 +61,30 @@ import {
   updateWorkflow,
   upsertScriptByName,
   upsertSkillFiles
-} from "./cli-tgpfnm6r.js";
-import"./cli-ywm1azg9.js";
-import"./cli-hsem16hb.js";
-import"./cli-nyhb1r6x.js";
-import"./cli-7mm2r1kp.js";
+} from "./cli-ef1hg1wv.js";
+import"./cli-hnmhtzvh.js";
+import"./cli-cgtksawx.js";
+import"./cli-s2sp957d.js";
 import"./cli-dmtrxqhg.js";
+import"./cli-7mm2r1kp.js";
+import"./cli-5hkm7whv.js";
 import"./cli-mvzyxwg3.js";
-import"./cli-tadfgd0t.js";
 import"./cli-fdvbjtbw.js";
 import"./cli-ywybs5as.js";
 import"./cli-f9w1semm.js";
 import"./cli-1a2j50m0.js";
 import"./cli-a35hzdve.js";
-import"./cli-014vns2y.js";
+import"./cli-stfs0k5s.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-esnpehf5.js";
+import"./cli-p0sg24zp.js";
+import"./cli-k382tshb.js";
 import"./cli-zf8jjwex.js";
 import"./cli-gd4favx9.js";
 import"./cli-ej6gbxfb.js";
 import"./cli-a1b9b32n.js";
-import"./cli-d161g69q.js";
+import"./cli-p1x85d2t.js";
+import"./cli-e3g5mbkz.js";
 import {
   __toESM
 } from "./cli-bc05qbss.js";
@@ -3968,7 +3976,7 @@ const CONTRADICTORY_RE =
   /\\b(do not|don't|never)\\b[\\s\\S]{0,240}\\b(always|must|required)\\b|\\b(always|must|required)\\b[\\s\\S]{0,240}\\b(do not|don't|never)\\b/i;
 
 const CODE_REGISTRY_EVENTS =
-  "agentmail.email.followup agentmail.email.mapped_lead agentmail.email.mapped_worker agentmail.email.no_agent agentmail.email.unmapped common.command_suggestions.github_comment_issue common.command_suggestions.github_comment_pr common.command_suggestions.github_issue common.command_suggestions.github_pr common.command_suggestions.gitlab_issue common.command_suggestions.gitlab_mr common.delegation_instruction common.delegation_instruction.gitlab github.check_run.failed github.check_suite.failed github.comment.mentioned github.issue.assigned github.issue.labeled github.issue.mentioned github.pull_request.assigned github.pull_request.closed github.pull_request.labeled github.pull_request.mentioned github.pull_request.review_requested github.pull_request.review_submitted github.pull_request.synchronize github.workflow_run.failed gitlab.comment.mentioned gitlab.issue.assigned gitlab.merge_request.opened gitlab.pipeline.failed heartbeat.boot-triage heartbeat.checklist jira.issue.assigned jira.issue.commented jira.issue.followup kapso.message.received linear.issue.assigned linear.issue.followup linear.issue.reassigned slack.assistant.greeting slack.assistant.offline slack.assistant.suggested_prompts slack.message.attachment_failed slack.message.thread_context system.agent.communication system.agent.lead system.agent.memory system.agent.memory.remote system.agent.outputs system.agent.outputs.no_agent_fs system.agent.repository system.agent.role system.agent.secrets system.agent.slack system.agent.tools_skills system.agent.worker system.agent.worker.remote system.agent.workspace system.agent.workspace.remote system.session.lead system.session.lead.managed system.session.worker system.session.worker.managed system.session.worker.remote task.budget.refused task.requester.profile task.worker.completed task.worker.failed".split(
+  "agentmail.email.followup agentmail.email.mapped_lead agentmail.email.mapped_worker agentmail.email.no_agent agentmail.email.unmapped chat.message.thread_context common.command_suggestions.github_comment_issue common.command_suggestions.github_comment_pr common.command_suggestions.github_issue common.command_suggestions.github_pr common.command_suggestions.gitlab_issue common.command_suggestions.gitlab_mr common.delegation_instruction common.delegation_instruction.gitlab github.check_run.failed github.check_suite.failed github.comment.mentioned github.issue.assigned github.issue.labeled github.issue.mentioned github.pull_request.assigned github.pull_request.closed github.pull_request.labeled github.pull_request.mentioned github.pull_request.review_requested github.pull_request.review_submitted github.pull_request.synchronize github.workflow_run.failed gitlab.comment.mentioned gitlab.issue.assigned gitlab.merge_request.opened gitlab.pipeline.failed heartbeat.boot-triage heartbeat.checklist jira.issue.assigned jira.issue.commented jira.issue.followup kapso.message.received linear.issue.assigned linear.issue.followup linear.issue.reassigned slack.assistant.greeting slack.assistant.offline slack.assistant.suggested_prompts slack.message.attachment_failed slack.message.thread_context system.agent.communication system.agent.lead system.agent.memory system.agent.memory.remote system.agent.outputs system.agent.outputs.no_agent_fs system.agent.repository system.agent.role system.agent.secrets system.agent.slack system.agent.tools_skills system.agent.worker system.agent.worker.remote system.agent.workspace system.agent.workspace.remote system.session.lead system.session.lead.managed system.session.worker system.session.worker.managed system.session.worker.remote task.budget.refused task.requester.profile task.worker.completed task.worker.failed".split(
     " ",
   );
 
@@ -5735,7 +5743,7 @@ var config_default = `{
 `;
 
 // templates/skills/agent-browser/content.md
-var content_default = '# agent-browser\n\n`agent-browser` (vercel-labs) is the swarm\'s browser-automation CLI. It drives a headless Chromium over CDP and returns accessibility-tree snapshots with compact `@eN` refs. Use it for any browser task: verify a UI change, take a screenshot, walk a page, fill a form, extract page text, reproduce a frontend bug, or attach UI evidence to a PR, issue, Linear comment, or Slack thread.\n\nDo not use `qa-use`. It is not installed in the worker image any more.\n\n## Step 0: check that the CLI is present\n\nThe full worker image (`agent-swarm-worker:latest`) ships `agent-browser` and a headless Chromium. The slim image (`:slim`) has neither. The first command of any browser work is:\n\n```bash\ncommand -v agent-browser\n```\n\nIf it prints nothing, you are on the slim image. Say so in your progress report ("agent-browser is not available on this worker image") and fall back to manual QA: write the exact steps a human should run and mark the browser test cases as **Blocked**, not failed. Do not install a browser or the CLI yourself.\n\n## Step 1: load the version-matched guide\n\nThe CLI bundles its own usage guide. Load it once per task before the first browser command. Do not guess flags from memory.\n\n```bash\nagent-browser skills get core          # overview + common patterns\nagent-browser skills get core --full   # adds the full command reference\nagent-browser skills list              # specialized guides (dogfood, electron, slack, ...)\n```\n\n## Step 2: the core loop\n\n```bash\nagent-browser open <url>\nagent-browser snapshot -i              # accessibility tree, interactive elements only, @eN refs\nagent-browser click @e12               # act on refs from the snapshot\nagent-browser fill @e7 "text"\nagent-browser screenshot /tmp/<name>.png\nagent-browser close\n```\n\n- Re-run `snapshot` after every navigation or state change. Refs are only valid for the snapshot that produced them.\n- Run one browser session at a time. Call `store-progress` between page batches so the heartbeat watchdog sees you.\n- The browser is headless. Local servers inside the worker container are reachable at `http://localhost:<port>`.\n- The image launches Chromium with `--no-sandbox,--disable-dev-shm-usage` through `AGENT_BROWSER_ARGS`. If you pass your own `--args`, include `--no-sandbox` again or Chrome will not start.\n\n## Recording\n\nPass `record start` an absolute path (`/tmp/<topic>/raw.webm`). A relative path resolves against the agent-browser daemon\'s cwd, not yours, and fails with `ffmpeg write failed: Broken pipe` while `doctor` stays green.\n\nDefault: record with `--cursor`, drive every supported pointer action (`click`, `mouse move`, `drag`) with `--human`, and ship the **1.5x video**. Keep the 1x original only if a reviewer asks for it. Human pointer movement follows an eased curve; use `--seed <n>` on `mouse move` to make the take reproducible instead of using a bare move.\n\nOpen the page first, then record the interaction:\n\n```bash\nagent-browser record start ./in.mp4 --cursor\nagent-browser snapshot -i\nagent-browser mouse move 600 400 --human --seed 42 --duration 1400\nagent-browser click @e3 --human          # use a ref from the current snapshot\n# Perform the remaining QA steps; use --human for drag actions too.\nagent-browser record stop\nffmpeg -y -i in.mp4 -filter:v "setpts=PTS/1.5,fps=30" -an \\\n  -c:v libx264 -preset veryfast -crf 23 -pix_fmt yuv420p out-1.5x.mp4\n```\n\nSpeed-up is a post-process step: `record start` has no speed or human flag. Keep `fps=30` to preserve a steady 30 fps output rather than uneven frame drops at an inferred rate. `-an` disables audio because agent-browser recordings carry no audio track. The worker ships only `ffmpeg`, not `ffprobe`; inspect duration with `ffmpeg -i out-1.5x.mp4 2>&1 | grep Duration`.\n\nAdd `--contact-sheet` to the start command for a timestamped PNG summary of visual changes. Recording needs `ffmpeg` on PATH; check `agent-browser doctor` before starting. Stop the recording before closing the browser so the video is saved. Keep the 1.5x file on the same agent-fs QA path as screenshots below. In a PR, upload it as a GitHub user attachment and put the URL on its own line, so GitHub plays it inline.\n\n## Step 3: share the screenshot through agent-fs\n\nScreenshots on the worker disk disappear with the task. Upload them to agent-fs under the qa path convention: that copy is the durable original. Use `share-create` when a person needs to open the file. `--file` is binary-safe. `--content` is text-only and mangles PNGs.\n\n```bash\nagent-fs write thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png \\\n  --file /tmp/<name>.png -m "<what it shows>"\nagent-fs stat thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png --json        # confirm size > 0\nagent-fs share-create thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png --json\n```\n\n- **GitHub PR body or comment**: upload the PNG, GIF or mp4 as a GitHub user attachment with the `github-attach` skill and embed `![caption](https://github.com/user-attachments/assets/<uuid>)`. Attachments never expire and mp4s play inline. A UI PR puts a before (main) and after pair in the `## Before / after` table. Fallback for images only, when the GitHub token is an App token (`ghu_`/`ghs_`): `agent-fs signed-url <path> --inline --json` (expires in 7 days). Never a presigned URL for an mp4 or a doc: it downloads.\n- **Linear comment or Slack message**: paste the `share-create` link.\n- In `store-progress`, list the upload in the `attachments` field with `kind: "agent-fs"` and the path, and paste the `share-create` link for people who need to open the file.\n- If `agent-fs auth whoami` fails, report the local path, say the upload was skipped, and continue.\n\nThe `artifacts` skill holds the full agent-fs recipe and the naming conventions.\n\n## Gotchas\n\n- `wait <selector>` waits for a VISIBLE match. When the first match is hidden it times out (about 25 s) even though the element exists. Wait on rendered text instead: `wait --text "<rendered text>"`.\n- Never run `pkill -f <pattern>` inside a Bash call: the pattern also matches the calling shell\'s command line and kills it. Record the PID when you start a background server (`echo $!`) and `kill <pid>`.\n';
+var content_default = '# agent-browser\n\n`agent-browser` (vercel-labs) is the swarm\'s browser-automation CLI. It drives a headless Chromium over CDP and returns accessibility-tree snapshots with compact `@eN` refs. Use it for any browser task: verify a UI change, take a screenshot, walk a page, fill a form, extract page text, reproduce a frontend bug, or attach UI evidence to a PR, issue, Linear comment, or Slack thread.\n\nDo not use `qa-use`. It is not installed in the worker image any more.\n\n## Step 0: check that the CLI is present\n\nThe full worker image (`agent-swarm-worker:latest`) ships `agent-browser` and a headless Chromium. The slim image (`:slim`) has neither. The first command of any browser work is:\n\n```bash\ncommand -v agent-browser\n```\n\nIf it prints nothing, you are on the slim image. Say so in your progress report ("agent-browser is not available on this worker image") and fall back to manual QA: write the exact steps a human should run and mark the browser test cases as **Blocked**, not failed. Do not install a browser or the CLI yourself.\n\n## Step 1: load the version-matched guide\n\nThe CLI bundles its own usage guide. Load it once per task before the first browser command. Do not guess flags from memory.\n\n```bash\nagent-browser skills get core          # overview + common patterns\nagent-browser skills get core --full   # adds the full command reference\nagent-browser skills list              # specialized guides (dogfood, electron, slack, ...)\n```\n\n## Step 2: the core loop\n\n```bash\nagent-browser open <url>\nagent-browser snapshot -i              # accessibility tree, interactive elements only, @eN refs\nagent-browser click @e12               # act on refs from the snapshot\nagent-browser fill @e7 "text"\nagent-browser screenshot /tmp/<name>.png\nagent-browser close\n```\n\n- Re-run `snapshot` after every navigation or state change. Refs are only valid for the snapshot that produced them.\n- Run one browser session at a time. Call `store-progress` between page batches so the heartbeat watchdog sees you.\n- The browser is headless. Local servers inside the worker container are reachable at `http://localhost:<port>`.\n- The image launches Chromium with `--no-sandbox,--disable-dev-shm-usage` through `AGENT_BROWSER_ARGS`. If you pass your own `--args`, include `--no-sandbox` again or Chrome will not start.\n\n## Recording\n\nPass `record start` an absolute path (`/tmp/<topic>/raw.webm`). A relative path resolves against the agent-browser daemon\'s cwd, not yours, and fails with `ffmpeg write failed: Broken pipe` while `doctor` stays green.\n\nDefault: record with `--cursor`, drive every supported pointer action (`click`, `mouse move`, `drag`) with `--human`, and ship the **1.5x video**. Keep the 1x original only if a reviewer asks for it. Human pointer movement follows an eased curve; use `--seed <n>` on `mouse move` to make the take reproducible instead of using a bare move.\n\nOpen the page first, then record the interaction:\n\n```bash\nagent-browser record start ./in.mp4 --cursor\nagent-browser snapshot -i\nagent-browser mouse move 600 400 --human --seed 42 --duration 1400\nagent-browser click @e3 --human          # use a ref from the current snapshot\n# Perform the remaining QA steps; use --human for drag actions too.\nagent-browser record stop\nffmpeg -y -i in.mp4 -filter:v "setpts=PTS/1.5,fps=30" -an \\\n  -c:v libx264 -preset veryfast -crf 23 -pix_fmt yuv420p out-1.5x.mp4\n```\n\nSpeed-up is a post-process step: `record start` has no speed or human flag. Keep `fps=30` to preserve a steady 30 fps output rather than uneven frame drops at an inferred rate. `-an` disables audio because agent-browser recordings carry no audio track. The worker ships only `ffmpeg`, not `ffprobe`; inspect duration with `ffmpeg -i out-1.5x.mp4 2>&1 | grep Duration`.\n\nAdd `--contact-sheet` to the start command for a timestamped PNG summary of visual changes. Recording needs `ffmpeg` on PATH; check `agent-browser doctor` before starting. Stop the recording before closing the browser so the video is saved. Keep the 1.5x file on the same agent-fs QA path as screenshots below. In a PR, upload it as a GitHub user attachment and put the URL on its own line, so GitHub plays it inline.\n\n## Step 3: share the screenshot through agent-fs\n\nScreenshots on the worker disk disappear with the task. Upload them to agent-fs under the qa path convention: that copy is the durable original. Use `share-create` when a person needs to open the file. `--file` is binary-safe. `--content` is text-only and mangles PNGs.\n\n```bash\nagent-fs write thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png \\\n  --file /tmp/<name>.png -m "<what it shows>"\nagent-fs stat thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png --json        # confirm size > 0\nagent-fs share-create thoughts/<agent-id>/qa/<topic>-screenshots/<name>.png --json\n```\n\n- **GitHub PR body or comment**: upload the PNG, GIF or mp4 as a GitHub user attachment with the `github-attach` skill and embed `![caption](https://github.com/user-attachments/assets/<uuid>)`. Attachments never expire and mp4s play inline. A UI PR puts a before (main) and after pair in the `## Before / after` table. Fallback for images only, when the GitHub token is an App token (`ghu_`/`ghs_`): `agent-fs signed-url <path> --inline --json` (expires in 7 days). Never a presigned URL for an mp4 or a doc: it downloads.\n- **Linear comment or Slack message**: paste the `share-create` link.\n- In `store-progress`, list the upload in the `attachments` field with `kind: "agent-fs"` and the path, and paste the `share-create` link for people who need to open the file.\n- If `agent-fs auth whoami` fails, report the local path, say the upload was skipped, and continue.\n\nThe `agent-fs` skill holds the full agent-fs recipe.\n\n## Gotchas\n\n- `wait <selector>` waits for a VISIBLE match. When the first match is hidden it times out (about 25 s) even though the element exists. Wait on rendered text instead: `wait --text "<rendered text>"`.\n- Never run `pkill -f <pattern>` inside a Bash call: the pattern also matches the calling shell\'s command line and kills it. Record the PID when you start a background server (`echo $!`) and `kill <pid>`.\n';
 
 // templates/skills/apps/config.json
 var config_default2 = `{
@@ -5755,374 +5763,10 @@ var config_default2 = `{
 `;
 
 // templates/skills/apps/content.md
-var content_default2 = "# Swarm Apps\n\nSwarm Apps are persistent, agent-authored internal applications: a schema-backed row store, named queries, custom script/task actions, and a validated json-render interface served at `/apps/<id>`. Use an app when people need to view and change live records; use `create_page` for a static snapshot and `artifacts` for custom server logic or a UI outside this catalog.\n\n> **Capability gate**: app tools are available when the server's `CAPABILITIES` includes `pages` (for example `CAPABILITIES=core,task-pool,pages`). There is no separate `apps` capability. If these tools are absent from your MCP list, this is why.\n\n## Tools and iteration loop\n\n| Tool | Use it for |\n|---|---|\n| `app-list` | Discover apps by id, name, description, and timestamps. Definitions are omitted. |\n| `app-get` | Read one complete stored definition before changing it. |\n| `app-upsert` | Create an app, or replace an existing app's entire definition when you intentionally have the full desired state. |\n| `app-patch` | Make a focused change while preserving everything not mentioned in the patch. Prefer this for iteration. |\n| `app-query` | Run one declared named query and return its rows. Use this when an agent or saved script needs to consume app data rather than render the app UI. |\n| `app-history` | List definition snapshots and their compact model/column digests before choosing a restore point. |\n| `app-diff` | Show a unified definition diff; defaults to newest snapshot → CURRENT. |\n| `app-rollback` | Restore a snapshot through the normal schema-migration engine. |\n\nFor every edit: `app-get` -> modify the smallest coherent subtree -> `app-patch` -> if rejected, fix every returned `issues[]` entry (`path` + `message`) and retry. Validation happens before storage, so a rejected update leaves the saved app unchanged. Do not guess at the current definition or use `app-upsert` with a partial definition.\n\n`app-patch` can also change `name`; omit `description` to preserve it or pass `description: null` to clear it.\n\n### Reading an app's callable surface\n\nOne `app-get` returns everything needed to drive an app you did not write: `definition.queries` are runnable with `app-query` (supply every `$param` the query references), and `definition.actions` are invocable with `POST /api/apps/<id>/actions/<name>` (a `script` action runs its script, a `task` action spawns a task, a `sync` action refreshes sources). Read a query's `$param` placeholders and an action's kind/args from the definition before calling — do not guess parameter names.\n\n## Safe schema evolution and rollback\n\nPrefer **hiding** a column over deleting it. A hidden column's values stay on every existing row, so an unhide or rollback can make it visible again. Hiding is metadata-only: hidden columns cannot be used in queries, page bindings, `app.mutate` values, or new row writes, and `required` is ignored while hidden. Row GETs still expose the historical value for backward compatibility.\n\nDo not reuse a hidden column name. The name remains held until you either unhide it or explicitly purge its stored values. To permanently remove a column, delete its declaration with `null` and include `{ \"columnName\": { \"purge\": true } }` in the same `migration` object. That is deliberately one-shot and irreversible for row data.\n\nSchema-changing writes can carry this sibling `migration` object:\n\n```json\n{\n  \"migration\": {\n    \"priority\": { \"from\": \"flag\", \"map\": { \"urgent\": \"high\", \"watch\": \"low\" }, \"else\": \"none\" },\n    \"status\": { \"from\": \"flag\", \"map\": { \"watch\": \"watching\", \"done\": \"done\" }, \"else\": \"open\" },\n    \"oldColumn\": { \"purge\": true },\n    \"count\": { \"coerce\": true, \"else\": 0 },\n    \"owner\": { \"set\": \"unassigned\" }\n  }\n}\n```\n\nUse `set` to backfill a changed column, `from` with optional `map`/`else` to derive it from one existing (including hidden) column, `coerce` for a kind change, and `purge` only for explicit destruction. Non-purge directives target a column changed in that same write. The server fails loudly before writing when a lossy change needs a directive: inspect every returned `issues[]` item, including its per-value row counts, then choose an explicit policy and retry. Never guess a migration just to get a 200.\n\n**Source lifecycle** rides the same engine with the same all-or-nothing guarantees. Free: adding a source, adding a NEW column with a `source` binding, binding an existing column that holds zero values, changing a binding's `field`/`transform`, and changing a source's `args`/`config`/`connection`/`scriptId` (window changes churn staleness on the next pass — expect `stale` flips when narrowing). Rejected with a path-bearing issue: changing `joinKey` (immutable — remove the source and add it again), changing `connector` while the source owns rows (row count in the message), and binding an existing column that already holds values (purge it — or add a fresh column — and bind that instead; a sync pass would otherwise overwrite the data). Removing a source **detaches** its rows: values survive as ordinary columns, the `source`/`syncedAt`/`stale` envelope is stripped, and the report counts them in `detachedRows`. A patch removing a source must drop its column bindings in the same call — a dangling `source.of` is rejected before anything is written.\n\nSync never adopts rows it does not own: a pulled record whose join key matches an unowned row creates a second, source-owned row. Adding a source over a join-key column that already holds values therefore duplicates those records on the first pass — and remove-source → re-add duplicates for the same reason, because detached rows keep their values. To convert a hand-maintained model into a synced one, purge the old rows first or use a fresh join-key column.\n\nFor example, split a legacy `flag` into `priority` and `status` without losing data in one patch: add the two columns, map both from `flag`, update every affected query/page binding, then hide `flag`.\n\n```json\n{\n  \"appId\": \"<app-id>\",\n  \"definition\": {\n    \"models\": {\n      \"ticket\": {\n        \"columns\": {\n          \"priority\": { \"kind\": \"enum\", \"enum\": [\"none\", \"low\", \"high\"] },\n          \"status\": { \"kind\": \"enum\", \"enum\": [\"open\", \"watching\", \"done\"] },\n          \"flag\": { \"kind\": \"string\", \"hidden\": true }\n        }\n      }\n    }\n  },\n  \"migration\": {\n    \"priority\": { \"from\": \"flag\", \"map\": { \"urgent\": \"high\", \"watch\": \"low\" }, \"else\": \"none\" },\n    \"status\": { \"from\": \"flag\", \"map\": { \"watch\": \"watching\", \"done\": \"done\" }, \"else\": \"open\" }\n  }\n}\n```\n\nEvery schema migration returns `{ scanned, backfilled, coerced, mapped, elsed, purgedValues, idxRebuilt, detachedRows, orphanFields }`. Read `orphanFields`: it reports extra row fields that predate or no longer appear in the definition; they are preserved until an explicit purge. `schemaVersion` is server-managed: never set it in an input patch or try to use it as application data.\n\nEvery successful definition write snapshots the previous definition. Use `app-history` to select a version, `app-diff({ appId, from: <version> })` to inspect it against CURRENT, then `app-rollback({ appId, version: <version>, migration? })` to restore it. Rollback is a forward migration over live rows, not row-level time travel: it creates a new pre-rollback snapshot and may reject a lossy restore with the same migration directives and counts. A rejected rollback changes nothing.\n\n### Per-user configuration\n\n`userConfig` declares up to 20 typed settings in the versioned definition; its values are deliberately stored outside the definition, separately for each user (and the operator dashboard). Each field is `{ \"kind\": \"string\" | \"number\" | \"boolean\" | \"date\" | \"enum\", \"default\"?: ..., \"enum\"?: [...], \"label\"?: \"...\" }`. Defaults follow column rules, including enum membership; `required` is not allowed. A missing or obsolete stored value reads as its default, or `null` when no default is declared.\n\nUse `{ \"$state\": \"/user/<field>\" }` on a page for the read-only current-user binding; the field must be declared and the path cannot continue below it. Pure and bound reusable elements cannot bind `/user` directly — pass the value through an element prop from the consuming page. An agent acting on an owned user-requested task reads and edits that requester's preferences. `userConfig` schema changes are always migration-compatible and appear in migration reports; no migration directives are needed. Rollback restores the historical schema but never alters saved per-user values, so values can resurface when a field returns.\n\n### Theming\n\nAn optional top-level `\"theme\"` sets the preset the dashboard applies to the app's rendered canvas — a lowercase slug validated by shape only. The preset catalog ships with the dashboard (`apps/ui/src/lib/themes.ts` + `theme-classics.ts` — update this list and the `app-upsert` tool description when it changes); current ids: `hive` (the stock look), the accent/field presets `meadow`, `iris`, `rose`, `cobalt`, `ember`, `carbon`, and the classic editor/platform presets `github`, `vscode`, `material`, `solarized`, `tokyo`, `monokai`, `gruvbox`, `catppuccin`. Action and destructive tones are never themed; status tones are themed ONLY by the classic presets (their identity includes a status palette — hue semantics stay fixed, success reads green and error reads red everywhere). An id the viewer's dashboard build does not know degrades to the dashboard's own theme, so unknown slugs are safe but pointless. Omit `theme` to inherit whatever theme the viewer runs; `\"hive\"` is an explicit reset to the stock look even inside a themed dashboard.\n\nViewers can override the preset per app from the app's settings drawer; the override rides the reserved `$theme` key of the user-config values (accepted on every app, even without a declared `userConfig` schema, and never visible at `/user/...`). A present override always beats the definition's `theme` — even an unrecognized one, which degrades to the dashboard theme — so treat `theme` as the app's default styling, not a guarantee.\n\nDistinguish the two rollback 400s. A lossy-migration 400 is fixable: copy the required `migration` entries from the message and retry. A target-snapshot validation 400 explicitly says that directives cannot repair that historical definition; use `app-history` and choose a different version.\n\nWhen a schema patch reports stale page/query bindings, repair them in that same patch. Page elements are atomic: replace the complete `pages.<page>.elements.<id>` declaration, removing any reference to a hidden or deleted column, instead of sending only the changed nested prop. This is also the repair move for older apps whose stored page already references an undeclared column; full-definition validation otherwise blocks every patch.\n\n## Definition reference\n\n```json\n{\n  \"models\": {\n    \"modelName\": {\n      \"columns\": {\n        \"externalId\": { \"kind\": \"string\" },\n        \"title\": { \"kind\": \"string\" }\n      }\n    }\n  },\n  \"queries\": { \"queryName\": { \"model\": \"modelName\" } },\n  \"actions\": { \"actionName\": { \"kind\": \"task\", \"prompt\": \"Review the current rows and report\" } },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"root\",\n      \"elements\": { \"root\": { \"type\": \"Container\", \"props\": {} } }\n    }\n  },\n  \"defaultPage\": \"main\",\n  \"theme\": \"ember\"\n}\n```\n\nModel, reusable-element, element-prop, query, action, column, page, and page-param names start with a lowercase letter, contain only letters, numbers, or underscores, and are at most 40 characters. A definition has 0-10 models and at most 20 reusable elements; each declared model has 1-40 columns. Zero-model apps are valid for pure UI utilities as long as their pages and reusable elements validate.\n\n### Reusable elements\n\nTop-level `elements` are versioned inside the app definition and can be reused from the app's own pages or, when explicitly exported, from another app. They are private by default. Each entry declares a `mode`, optional typed `props`, one `root`, and a flat `elements` node map using the same validated tree vocabulary as a page:\n\n```json\n{\n  \"elements\": {\n    \"statCard\": {\n      \"mode\": \"pure\",\n      \"export\": true,\n      \"props\": {\n        \"label\": { \"kind\": \"string\", \"required\": true },\n        \"value\": { \"kind\": \"number\", \"default\": 0 }\n      },\n      \"root\": \"card\",\n      \"elements\": {\n        \"card\": { \"type\": \"Card\", \"props\": {}, \"children\": [\"label\", \"slot\"] },\n        \"label\": { \"type\": \"Metric\", \"props\": { \"label\": { \"$state\": \"/props/label\" }, \"value\": { \"$state\": \"/props/value\" } } },\n        \"slot\": { \"type\": \"ElementSlot\", \"props\": {} }\n      }\n    }\n  }\n}\n```\n\n- `pure` elements may read only their declared `/props/<name>` state; `$item` and `$index` are also legal inside repeated nodes. They cannot invoke any action step. A pure tree may contain at most one leaf `ElementSlot` where consumer children are inserted.\n- `bound` elements may additionally read the defining app's declared queries and actions and use its models. Those references are validated against the defining app, including hidden-column rules. Exported bound elements cannot use `app.navigate`; private bound elements may navigate within their defining app.\n- Prop kinds are `string`, `number`, `boolean`, `date`, or `enum`. An enum prop requires a non-empty `enum: [\"value\", ...]` values array. A literal default and each literal consumer value must match the kind and, for enums, be one of those values. A required prop without a default must be supplied.\n\nReference an element with an `ElementRef` node. Omit `app` for same-app reuse; cross-app references name the defining app id and require `export: true`. `instanceKey` is optional. Consumer `children` are accepted only when the target has an `ElementSlot`:\n\n```json\n{\n  \"type\": \"ElementRef\",\n  \"props\": {\n    \"app\": \"<defining-app-id>\",\n    \"element\": \"statCard\",\n    \"props\": { \"label\": \"Open issues\", \"value\": 12 },\n    \"instanceKey\": \"openIssues\"\n  },\n  \"children\": [\"details\"]\n}\n```\n\nElement references float to the defining app's current definition. `app` and `element` must be literal strings; dynamic references are not supported. The server rejects reference cycles and expansion deeper than five, missing/private targets, invalid props, and a breaking write to an exported element that other apps reference. Removing or unexporting an exported element, changing its mode, removing a declared prop, changing a prop kind, or adding a required prop without a default is breaking; publish the new contract under a new element name. If consumers are abandoned intentionally, retry the PUT, PATCH, or rollback with `\"forceElementBreak\": [\"elementName\"]`. The named consumers will then render an error once element rendering is available; deleting an entire app is deliberately not compatibility-gated.\n\n### Models\n\nEach column is `{ \"kind\": ..., \"required\"?: boolean, \"default\"?: ..., \"index\"?: boolean, \"enum\"?: string[], \"hidden\"?: boolean }`.\n\n| `kind` | Values and indexing |\n|---|---|\n| `string` | String value; set `index: true` only when equality lookups need it. |\n| `number` | Finite number; never indexed. |\n| `boolean` | Boolean; set `index: true` only when equality lookups need it. |\n| `date` | ISO-8601 string; never indexed. |\n| `enum` | String from the non-empty unique `enum` list; always indexed, without `index: true`. |\n\n`default` must match the column kind (and be one of the enum values). `required: true` rejects missing/null values unless a default supplies the value. `id`, `createdAt`, `updatedAt`, `createdBy`, `updatedBy` — and the sync envelope `source`, `syncedAt`, `stale` — are system columns and reserved names. An app created before the sync envelope that declared ordinary columns with these names surfaces `definitionError` after upgrade until they are renamed: patch in a fresh column with a `{from}` migration directive, then purge the old one. Rows always expose `id`/`createdAt`/`updatedAt`; `createdBy`/`updatedBy` record the acting principal (`user:<id>`, `agent:<id>`, `operator`, or `sync:<source>` for engine writes) and are system-managed on every row write.\n\n### Sources and sync\n\nA model may declare up to 4 named `sources` — one-way inbound projections of an external system into its rows. The `script` connector is THE way to bring external data in (GitHub, Linear, any API): a saved script owns the fetch, its auth placeholders, and its paging. `swarm-tasks` is the one native connector, projecting this swarm's own task pool (`config`: `status`/`tags` comma-lists, `agentId`, `assetKey` namespace prefix, `limit` up to 200 — default 100, `includeHeartbeat`). Synced rows are readable by EVERY principal with `app.use` on the app; an unscoped `swarm-tasks` source publishes task prompts (truncated, secret-scrubbed) to all of them, so scope it with `config.assetKey`/`config.agentId` unless that exposure is intended. A user-invoked sync only ever pulls the invoking user's own requested tasks. Script sources run with their run-as identity's credentials — an agent-owned script runs as its owner and only the owner may wire it; an owner-less catalog (global) script runs as the LEAD, so only the lead or the operator can wire or alter such a source (stored references stay valid with their args and connection pinned).\n\n```json\n{\n  \"models\": {\n    \"issue\": {\n      \"columns\": {\n        \"issueKey\": { \"kind\": \"string\" },\n        \"title\": { \"kind\": \"string\", \"source\": { \"of\": \"gh\", \"field\": \"title\" } },\n        \"openedAt\": { \"kind\": \"date\", \"source\": { \"of\": \"gh\", \"field\": \"created_at\", \"transform\": \"date-parse\" } },\n        \"note\": { \"kind\": \"string\" }\n      },\n      \"sources\": {\n        \"gh\": { \"connector\": \"script\", \"scriptId\": \"<script-uuid>\", \"joinKey\": \"issueKey\", \"args\": { \"repo\": \"owner/name\" }, \"connection\": \"github\" }\n      }\n    }\n  }\n}\n```\n\n- **Join key**: each source names a `joinKey` — an owned, non-hidden `string` column carrying the external identity. It must not be `required`, must not declare a `default`, and cannot itself be source-bound. A row belongs to at most ONE source (`row.source`).\n- **Column bindings**: `{ \"of\": \"<sourceName>\", \"field\": \"user.login\", \"transform\"? }` projects a (dotted-path) field of the pulled record into the column on every pass. Transforms and their required column kinds: `slug`/`lower`/`upper` → `string`, `cents` → `number` (×100, rounded), `date-parse` → `date` (ISO). A failed transform nulls that one column and warns; it never fails the pass.\n- **Read-only contract**: source-bound columns and the join key reject every direct write (row create/patch/bulk) with a path-bearing issue — mutate them via the source or a sync refresh. Owned columns on the same model stay writable. Every `required` owned column on a sourced model must declare a `default`, because sync-created rows cannot supply it.\n- **Provenance**: synced rows carry `source` (owner), `syncedAt` (last confirmed presence — sortable), and `stale` (true when a complete pull no longer returned the record; clears on reappearance). `syncedAt` advances on every confirmed row WITHOUT touching `updatedAt`; `updatedAt` moves only when projected data actually changed.\n- **`connection`** (optional, script sources): names a connections-system slug the source depends on. It buys write-time validation plus a preflight before every pull; it does not by itself gate egress. Credentials resolve for the sync run-as identity — the script's owner when it has one, else the lead agent — so global connections always work and agent-scoped ones need matching script ownership. The slug is injected into the script's args as `connection`, letting one generic script serve N connections.\n\n**The canonical sync-script contract** (every sync script, always):\n\n```ts\nexport default async function run(args, ctx) {\n  // args = { ...source.args, app: { id }, model: \"<model>\", source: \"<sourceName>\", connection?: \"<slug>\" }\n  const records = [{ key: \"42\", fields: { title: \"…\", created_at: \"…\" } }];\n  return { records, complete: true }; // or return the bare array — a bare array IS a complete snapshot\n}\n```\n\nReturn `Array<{ key, fields }>` or `{ records, complete? }`. `key` is the external identity the engine joins on `joinKey` (numbers are coerced to strings); `fields` is the bag bindings project from. Return `complete: false` whenever the pull window may have missed records — a paged fetch, a hit `limit`, or client-side filtering of a full page. An incomplete pull skips the stale sweep, so rows outside a narrow window are not falsely marked stale; compute `complete` BEFORE any client-side filtering. Hard cap 500 records per pull (over-cap pulls truncate and count as incomplete). An invalid return shape, thrown error, or non-zero exit fails the pass with zero row churn.\n\nThe seeded catalog script `github-issues-pull` is the worked example (placeholder auth via `[REDACTED:GITHUB_TOKEN]`, PR filtering, `complete` computed before filtering). For scheduled refreshes, point a `targetType: \"script\"` schedule at the seeded `app-sync-run` with `scriptArgs: { \"appId\": \"<id>\", \"model\"?, \"source\"? }`.\n\n**Three refresh doors, one engine**: `POST /api/apps/<id>/sync` (body `{ \"model\"?, \"source\"? }`), a `sync` action kind, and the `app-sync` MCP tool (`ctx.swarm.app_sync` from scripts). `{model?, source?}` fans out to every matching (model × source) pair; each pass reports `{ pulled, created, updated, refreshed, unchanged, markedStale, warnings }`. A pair already syncing in this API process short-circuits with `alreadyRunning: true` instead of pulling twice. Each pair's last-pass status (`lastFinishedAt`, counts, `error?`) comes back as `syncStatus` — keyed `\"<model>:<source>\"` — on `GET /api/apps/<id>` and in `app-get` data, so UI and agents can render \"last synced / last error\" without extra calls.\n\n### Freshness and the refresh button\n\nFreshness renders with the existing column kinds — no special components. Give the table `{ \"key\": \"syncedAt\", \"kind\": \"date\" }` and `{ \"key\": \"stale\", \"kind\": \"badge\", \"tones\": { \"true\": \"warning\" } }` columns, declare a `sync` action, and wire a Button to it:\n\n```json\n{\n  \"actions\": { \"refresh\": { \"kind\": \"sync\" } },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"root\",\n      \"elements\": {\n        \"root\": { \"type\": \"Container\", \"props\": {}, \"children\": [\"refreshBtn\", \"issuesTable\"] },\n        \"refreshBtn\": {\n          \"type\": \"Button\",\n          \"props\": { \"label\": \"Refresh\" },\n          \"on\": { \"press\": [{ \"action\": \"app.action\", \"params\": { \"name\": \"refresh\" } }] }\n        },\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [\n              { \"key\": \"title\", \"label\": \"Issue\" },\n              { \"key\": \"syncedAt\", \"label\": \"Synced\", \"kind\": \"date\" },\n              { \"key\": \"stale\", \"label\": \"Stale\", \"kind\": \"badge\", \"tones\": { \"true\": \"warning\" } }\n            ]\n          }\n        }\n      }\n    }\n  }\n}\n```\n\nA `sync` action answers the script-action state shape (`/actions/refresh` → `running` → `ok`/`error`, result under `result.passes`), so the page's queries refetch when it completes. Use `app-query` to READ rows (named queries may filter on `stale`/`source` and sort by `syncedAt`); use `app-sync` to REFRESH sources; never poll a sync door in a loop — schedule it or give people the button.\n\n### Queries\n\nA named query is:\n\n```json\n{\n  \"model\": \"idea\",\n  \"filter\": { \"status\": \"open\" },\n  \"sort\": { \"column\": \"createdAt\", \"dir\": \"desc\" },\n  \"limit\": 100\n}\n```\n\n`filter` is a strict AND of equality checks. A filter may target a declared model column or a system column (`id`, `createdAt`, `updatedAt`, `createdBy`, `updatedBy`, and on synced models `source`, `syncedAt`, `stale`) — filtering on `id` is the universal way to select one row for a detail view, and `{ \"stale\": true }` selects rows a complete pull stopped confirming. A literal value must match the column's kind; date filters compare the stored raw ISO string, not parsed instants. Omit `limit` for the default 200 rows, or set an integer from 1 through 1000. `sort.column` is a model column, `createdAt`, `updatedAt`, or `syncedAt`; `dir` is `asc` or `desc`. Query runtime state is `{ data, loading, error }` under `/queries/<queryName>`.\n\nA filter value may instead be exactly `{ \"$param\": \"<name>\" }`. At execution, the caller supplies that name and the server coerces its value to the filtered column's kind before equality matching:\n\n```json\n{\n  \"queries\": {\n    \"issueDetail\": { \"model\": \"issue\", \"filter\": { \"issueId\": { \"$param\": \"issueId\" } }, \"limit\": 1 }\n  }\n}\n```\n\nThe placeholder object must contain only `$param`. Missing caller values fail loudly rather than returning unfiltered rows: HTTP reports 400 and `app-query` returns a tool error listing every missing name. Supplying a param name the query does not reference is also an error. The app UI supplies current declared route params automatically. Direct calls use `app-query({ appId, query: \"issueDetail\", params: { issueId: 42 } })` or `ctx.swarm.app_query({ appId, query: \"issueDetail\", params: { issueId: 42 } })`.\n\n### Custom actions\n\nActions are optional (maximum 20) and are invoked from the page with the `app.action` runtime action.\n\n```json\n{\n  \"actions\": {\n    \"recalculate\": {\n      \"kind\": \"script\",\n      \"scriptId\": \"00000000-0000-4000-8000-000000000000\",\n      \"args\": { \"mode\": \"fast\" }\n    },\n    \"triage\": {\n      \"kind\": \"task\",\n      \"prompt\": \"Triage this idea and report a recommendation\"\n    }\n  }\n}\n```\n\n| Kind | Contract |\n|---|---|\n| `script` | `scriptId` must identify an existing script; optional `args` are defaults. Invocation input overrides same-named defaults, and the runtime also supplies `app: { id }`. |\n| `task` | `prompt` must be non-empty; omit `agentId` to use default (lead) assignment. Only set `agentId` to a real agent UUID. Invocation `input` is included as context for the task prompt. Spawned tasks carry asset key `shared/app:<appId>/action:<name>/`, so a `swarm-tasks` source with `config.assetKey: \"shared/app:<appId>/\"` pulls back the tasks this app spawned. |\n| `sync` | Optional `model` and `source` narrow which (model × source) pairs refresh; omitting both syncs every pair the app declares. At least one pair must exist. Answers the script-kind state shape with per-pass results under `result.passes`. |\n\n- Invocation state lands at `/actions/<name>` as `{ status, result?, error?, taskId?, taskStatus? }`, where `status` is `\"running\"`, `\"ok\"`, or `\"error\"`.\n\nUse a task action named Tackle when a person should hand one issue row to the swarm. Pass the complete current row under `input.issue`; `{ \"$row\": \"\" }` resolves to the whole row and that context lands in the task prompt.\n\n```json\n{\n  \"actions\": {\n    \"tackle\": { \"kind\": \"task\", \"prompt\": \"Tackle this issue. Inspect the supplied issue context, do the work, and report the outcome.\" }\n  },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"issuesTable\",\n      \"elements\": {\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [{ \"key\": \"title\", \"label\": \"Issue\" }],\n            \"rowActions\": [{\n              \"label\": \"Tackle\",\n              \"actions\": [{\n                \"action\": \"app.action\",\n                \"params\": { \"name\": \"tackle\", \"input\": { \"issue\": { \"$row\": \"\" } } }\n              }]\n            }]\n          }\n        }\n      }\n    }\n  },\n  \"defaultPage\": \"main\"\n}\n```\n\nFor direct MCP calls, `app-query` accepts `{ appId, query, params? }` and returns rows from that declared named query; every supplied param must be referenced by a `$param` filter in that query. Use it when an agent needs to read app state without scraping the UI.\n\nSaved scripts use the generated SDK name `ctx.swarm.app_query({ appId, query, params? })`. Use `app_query` in scripts or workflows that turn current app rows into reports, digests, or follow-up work. Saved scripts also get generated per-app types automatically: each app contributes an `App_<Name>` namespace with one row interface per model (enum columns as literal unions) and a typed `app_query` overload per named query, all visible via `script-query-types`. Actions stay REST-only from scripts — there is no SDK method to invoke them.\n\n### Pages, routes, and page trees\n\n`pages` is a map of independently validated page trees and `defaultPage` must name one entry. Each page may also declare a display `title` and typed route `params`. On every non-default page the runtime automatically renders breadcrumbs (`<default page title> › <current page title>`, first crumb navigates back) — including in chromeless embeds — so a detail page does NOT need its own back button; give pages good `title`s instead. This complete pattern connects a table row to a typed detail route and its parameterized query:\n\n```json\n{\n  \"models\": {\n    \"issue\": {\n      \"columns\": {\n        \"issueId\": { \"kind\": \"number\" },\n        \"title\": { \"kind\": \"string\" },\n        \"status\": { \"kind\": \"string\" }\n      }\n    }\n  },\n  \"queries\": {\n    \"allIssues\": { \"model\": \"issue\" },\n    \"issueDetail\": {\n      \"model\": \"issue\",\n      \"filter\": { \"issueId\": { \"$param\": \"issueId\" } },\n      \"limit\": 1\n    }\n  },\n  \"pages\": {\n    \"issues\": {\n      \"title\": \"Issues\",\n      \"root\": \"issuesTable\",\n      \"elements\": {\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [\n              { \"key\": \"title\", \"label\": \"Issue\" },\n              { \"key\": \"status\", \"label\": \"Status\", \"kind\": \"badge\" }\n            ],\n            \"rowActions\": [{\n              \"label\": \"Open\",\n              \"actions\": [{\n                \"action\": \"app.navigate\",\n                \"params\": {\n                  \"page\": \"detail\",\n                  \"params\": { \"issueId\": { \"$row\": \"issueId\" } }\n                }\n              }]\n            }]\n          }\n        }\n      }\n    },\n    \"detail\": {\n      \"title\": \"Issue detail\",\n      \"params\": { \"issueId\": { \"kind\": \"number\", \"required\": true } },\n      \"root\": \"detail\",\n      \"elements\": {\n        \"detail\": {\n          \"type\": \"DetailList\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/issueDetail/data/0\" },\n            \"fields\": [{ \"key\": \"title\", \"label\": \"Issue\" }]\n          }\n        }\n      }\n    }\n  },\n  \"defaultPage\": \"issues\"\n}\n```\n\nDrawer variant: declare a route param on the containing page, set the Drawer `props.param` to that literal param name, and use the same `app.navigate` shape targeting that page with the row id assigned to the Drawer's param. The Drawer then opens from route state without a separate action contract.\n\nParam `kind` is `string` by default, or `number` / `boolean`; `required` defaults to false. The names `mode`, `apiUrl`, `apiKey`, `email`, and `name` are reserved. `/apps/<id>` renders `defaultPage`; `/apps/<id>/p/<page>?issueId=42` is the shareable deep link for another page. Browser navigation is client-side, so app state and polled data stay warm across page changes.\n\nWithin each page, `root` names one entry in its non-empty `elements` map. Elements are a flat, single-parent tree: ids are map keys, `children` contains ids (not nested elements), all elements must be reachable from `root`, and cycles, missing children, or shared children are invalid. Element and Form/UI ids are page-local. Element keys are `type`, `props`, `children`, `on`, `visible`, `repeat`, and `watch`; only components with a `default` child slot accept `children` (Stack, Grid, Split, Tabs, Container, Card, and Drawer). `watch` maps state paths to an action step or chain.\n\n## Component catalog (all 23)\n\nProps reject unknown keys. A `{\"$state\":\"...\"}` binding may replace a literal prop value at any depth.\n\n| Component | Required props | Optional props / values |\n|---|---|---|\n| `Stack` | none | Primary layout; `direction: \"column\", \"row\"`, `gap`, `padding: \"none\", \"xs\", \"sm\", \"md\", \"lg\", \"xl\"`; `align: \"start\", \"center\", \"end\", \"stretch\"`, `justify: \"start\", \"center\", \"end\", \"between\"`, `wrap`; has the `default` child slot. |\n| `Grid` | none | Responsive `columns`: integer 1 through 6, or `{ base, sm, md, lg }` counts 1 through 6; `gap` uses the Stack spacing values; has the `default` child slot. |\n| `Split` | none | `ratio: \"1-1\", \"1-2\", \"2-1\", \"1-3\", \"3-1\"`, `gap`, `collapseBelow: \"sm\", \"md\", \"lg\"`, `reverse`; has the positional `default` child slot. |\n| `Divider` | none | `label`; no children. |\n| `Tabs` | `id`, `tabs` | `tabs` entries are `{ key, label? }`; `defaultTab`; has the positional `default` child slot. |\n| `Container` | none | Legacy layout primitive; prefer Stack. `direction: \"row\", \"column\"`, `gap: \"none\", \"sm\", \"md\", \"lg\"`; has the `default` child slot. |\n| `Card` | none | `title`, `description`; has the `default` child slot. |\n| `Heading` | `text` | `level: \"h1\", \"h2\", or \"h3\"`. |\n| `Text` | `content` | `tone: \"default\" or \"muted\"`. |\n| `Markdown` | `content` | Rendered Markdown for help, instructions, and rich prose; no children. |\n| `SearchInput` | `id` | `placeholder`, `label`; writes debounced text to `/ui/<id>/value`; no children. |\n| `Select` | `id`, `options` | `options` are strings or `{ value, label? }`; `placeholder`, `label`, `clearable`; writes a string or null to `/ui/<id>/value`; no children. |\n| `Button` | `label` | `variant: \"default\", \"secondary\", \"outline\", \"ghost\", \"destructive\", or \"destructive-outline\"` (use `destructive-outline` for standalone deletes); `disabled` (constant or bound boolean); `busyWith: \"<actionName>\"` disables and spins while that custom action's `/actions/<name>/status` is `\"running\"`; dispatch with element-level `on.press`. |\n| `Metric` | `label`, `value` | `value` is string or number; bind `loading` to `/queries/<name>/loading` for a skeleton while the query loads. |\n| `Alert` | `message` | `title`, `tone: \"info\", \"success\", \"warning\", or \"error\"`. |\n| `Badge` | `text` | `text` is string or number; `tone: \"neutral\", \"success\", \"active\", \"error\", \"info\", \"pending\", \"warning\", or \"paused\"`. |\n| `Table` | `columns` | `data`, `loading`, `error`, `emptyMessage`, `rowActions`, `search`, `filters`; see below. |\n| `Form` | `id`, `fields`, `onSubmit` | `title`, `submitLabel`; see below. |\n| `Drawer` | `param` | `title`, `description`, `side: \"right\" or \"left\"`, `size: \"sm\", \"md\", \"lg\", or \"xl\"`; has the `default` child slot. |\n| `DetailList` | `fields` | `data`, `emptyMessage`, `columns: 1 or 2`, `loading` (bind `/queries/<name>/loading` for skeleton fields while loading); renders one record without edit controls. |\n| `Kanban` | `columnField`, `columns`, `titleField` | `data`, `loading`, `cardFields`, `idField` (default `id`), `onMove`, `onCardClick`; see below. |\n| `Calendar` | `startField`, `titleField` | `data`, `loading`, `endField`, `idField`, `onSelect`; read-only month grid; see below. |\n| `ContributionGraph` | none | `data`, `loading`, `dateField` (default `date`), `countField`, `days` (7-730, default 365); read-only activity heatmap. |\n\nTable details:\n\n- `columns[]`: `{ key, label?, kind?, tones?: {value: badgeTone}, width?: number, pinned?: \"left\" or \"right\" }`. `kind` is `text`, `string`, `enum`, `number`, `boolean`, `date`, or `badge`; `string` and `enum` render as text. Pin id/actions columns so they survive horizontal scroll on narrow viewports.\n- `pagination`: boolean; defaults to auto-enabling past 200 rows (set `false` to force one scroll region). `density: \"compact\"` tightens row height for dense readouts.\n- `rowActions[]`: `{ label, variant?, confirm?, actions }`. Variants add `destructive-outline` to the Button variants. `destructive` and `destructive-outline` confirm by default; customize with `{ \"title\": ..., \"description\": ..., \"confirmLabel\": ... }`, or use a bare `confirm` string as the dialog description (use `confirm: false` only for a reversible action).\n- `search`: optional string; case-insensitive substring matching across the listed string and number columns. Bind a SearchInput value for client-side search.\n- `filters`: optional record of per-column string, number, boolean, or null values. Null, empty, or absent values disable one filter. Bind Select values for client-side equality filters.\n\nKanban details:\n\n- One card per `data` row, grouped by the row's `columnField` value. `columns[]` are plain strings or `{ id, label? }`, in display order; rows matching no column are hidden.\n- `cardFields[]` uses the DetailList field shape (`{ key, label?, kind?, tones? }`) for extra lines under the title.\n- `onMove` is an action chain run when a card is dropped in another column. `$row` is the moved row with `columnField` already set to the new column: `[{ \"action\": \"app.mutate\", \"params\": { \"model\": \"deal\", \"op\": \"update\", \"rowId\": { \"$row\": \"id\" }, \"values\": { \"stage\": { \"$row\": \"stage\" } } } }]`. Without `onMove`, cards cannot be dragged.\n- `onCardClick` is an action chain with `$row`; pair it with `app.navigate` and a `Drawer` to open a card.\n\nCalendar details:\n\n- `startField` / `endField` hold ISO dates, ISO datetimes, or epoch ms. An event shows on every day from start to end; without `endField` it shows on its start day.\n- Each Calendar keeps its own visible month (prev/next controls in its header). `onSelect` is an action chain with `$row`, run when an event is clicked.\n\nContributionGraph details:\n\n- Buckets `data` rows by the calendar day of `dateField` over the trailing `days`. Each row counts 1, or adds its numeric `countField` when set.\n\nForm details:\n\n- `fields[]`: `{ name, label?, kind?, options?: string[], placeholder?, required? }`; `kind` is `string`, `text`, `number`, `boolean`, `date`, or `enum`, and enum fields need `options`.\n- Values live at `/forms/<formId>/<fieldName>`. `onSubmit` is an action chain.\n- The submit button shows a pending spinner while the chain runs, and `app.mutate` failures in the chain render inline under the fields (not the page banner) — no extra wiring needed.\n\nDrawer details:\n\n- `param` must name a param declared on the containing page. The drawer is open exactly when `/route/params/<param>` has a non-empty value, so its open state survives refresh and is shareable. Its children mount only while open; closing it clears that param with history replacement.\n\nDetailList details:\n\n- `fields[]`: `{ key, label?, kind?, tones? }`. Kinds reuse Table formatting (`text`, `string`, `number`, `boolean`, `date`, `badge`, `enum`) and add `code` for monospace raw or JSON values. Bind `data` to one record, commonly `/queries/<detailQuery>/data/0`.\n\n## Layout & interactivity\n\nUse `Stack` as the primary page and section layout; `Container` is the legacy two-prop primitive retained for existing pages. Stack supports vertical or horizontal flow, shared spacing, alignment, justification, wrapping, and padding; row Stacks (filter bars, button rows) should set `collapseBelow: \"sm\"|\"md\"|\"lg\"` so they stack vertically on phones. Use `Grid` for responsive card or metric strips: a bare column count is responsive shorthand (1 column on phones, 2 from `sm`, the count from `md` up), or pin breakpoints explicitly with `{ \"base\": 1, \"md\": 2, \"lg\": 3 }`. `Grid` and `Split` also accept `padding` on the shared spacing scale.\n\n`Split` and `Tabs` children are positional. For Split, `children[0]` is the first pane, `children[1]` is the second, and extra children append inside the second pane. Below `collapseBelow`, panes stack; `reverse` changes only that narrow-layout stacking order. For Tabs, `children[i]` is the body for `tabs[i]`; keep both arrays in the same order and with the same count. Inactive tab children stay mounted but hidden, so Tables keep polling. Use `Divider` to separate sections and `Markdown` for richer explanatory content.\n\nSearchInput and Select are client-side controls: each needs a literal `id` and writes state under `/ui/<id>/value`; Tabs writes its active key to `/ui/<id>/tab`. Bind those values into a Table's `search` and `filters` props. This filters already-polled rows locally; it does not alter or re-run the named query.\n\n```json\n{\n  \"filters\": { \"type\": \"Stack\", \"props\": { \"gap\": \"sm\" }, \"children\": [\"query\", \"status\"] },\n  \"query\": { \"type\": \"SearchInput\", \"props\": { \"id\": \"ideaSearch\", \"placeholder\": \"Search ideas\" } },\n  \"status\": { \"type\": \"Select\", \"props\": { \"id\": \"ideaStatus\", \"options\": [\"open\", \"done\"] } },\n  \"ideas\": {\n    \"type\": \"Table\",\n    \"props\": {\n      \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n      \"columns\": [{ \"key\": \"title\" }, { \"key\": \"status\" }],\n      \"search\": { \"$state\": \"/ui/ideaSearch/value\" },\n      \"filters\": { \"status\": { \"$state\": \"/ui/ideaStatus/value\" } }\n    }\n  }\n}\n```\n\n`visible` accepts a boolean, a `$state` truthiness binding, comparisons, and logical groups. Put exactly one comparison key in each condition object. The renderer evaluates the first matching key in fixed priority order (`eq`, `neq`, `gt`, `gte`, `lt`, `lte`; otherwise truthiness), so additional comparison keys in the same object are ignored. Use `$and` / `$or` arrays to combine conditions. `not` is a negation FLAG inside a condition object (`\"not\": true`), never a wrapper around one — `{ \"not\": { \"$state\": … } }` is invalid and the validator rejects it. The absent-record pattern (e.g. an alert when a detail query matched nothing) is `{ \"$state\": \"/queries/<q>/data/0/id\", \"not\": true }`:\n\n```json\n[\n  { \"$state\": \"/route/params/issueId\", \"gt\": 0 },\n  {\n    \"$and\": [\n      { \"$state\": \"/route/page\", \"eq\": \"detail\" },\n      { \"$state\": \"/route/params/panel\", \"neq\": \"hidden\" }\n    ]\n  }\n]\n```\n\n## Bindings, sentinels, and action chains\n\nUse this exact query binding shape; do not invent `$query`, `$item`, or template strings:\n\n```json\n{\n  \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n  \"loading\": { \"$state\": \"/queries/allIdeas/loading\" },\n  \"error\": { \"$state\": \"/queries/allIdeas/error\" }\n}\n```\n\nValid `$state` roots are:\n\n- `/queries/<declaredQuery>/...`\n- `/forms/<formId>/...`, where a `Form` element has that literal `props.id`\n- `/ui/<id>/...`, where a SearchInput, Select, or Tabs element has that literal `props.id` (SearchInput and Select use `/value`; Tabs uses `/tab`)\n- `/actions/<declaredAction>/...`\n- `/route/page` for the active page name\n- `/route/params/<declaredParam>` for a param declared on the current page\n\n`/route` is mirrored as `{ page, params }`. Only declared params appear. Values are coerced by their declared kind: `number` becomes a number when possible; boolean strings `true`/`1` become true; failed number coercion remains the raw string.\n\nOnly inside action-chain `params` (`on.<event>`, `Table.rowActions[].actions`, or `Form.onSubmit`) these scoped sentinels are valid, recursively inside objects and arrays:\n\n| Sentinel | Resolves to |\n|---|---|\n| `{ \"$row\": \"id\" }` | Current Table row's `id`; another column name selects that field. |\n| `{ \"$row\": \"\" }` | Entire current Table row. |\n| `{ \"$rowIndex\": true }` | Current Table row index. |\n| `{ \"$form\": \"title\" }` | One current Form value. |\n| `{ \"$form\": \"\" }` | All current Form values. |\n| `{ \"$state\": \"/queries/allIdeas/data\" }` | Current value at a valid app state path, including action state such as `/actions/refreshIssues/status`. |\n\nEach sentinel object must contain exactly the single key shown.\n\nAn action-chain step is `{ \"action\": \"<type>\", \"params\": {...} }`. Available action types:\n\n- `app.mutate`: `{ model, op, rowId?, values?, formId? }`, where `op` is `\"create\"`, `\"update\"`, or `\"delete\"`. `update`/`delete` require `rowId` (usually `{ \"$row\": \"id\" }`); literal `values` keys must be model columns. Successful mutation refetches all queries on that model.\n- `app.refresh`: `{ query? }`; omit `query` to refetch all, or name a declared query.\n- `app.action`: `{ name, input? }`; `name` must be declared in definition `actions`. For a task-kind row action, pass whole-row context with `input: { issue: { \"$row\": \"\" } }`.\n- `app.navigate`: `{ page, params? }`; `page` must be declared, supplied keys must be params of the target page, and every required target param must be supplied. `params` replace the current route params wholesale and may contain action sentinels. Navigation pushes history, so browser Back returns to the previous page/params; only `mode` is preserved automatically.\n- `swarm.sdk`: `{ sdk, args? }`; invokes a catalog-supported Swarm browser SDK method with the viewer's bearer.\n- `swarm.call`: `{ method, endpoint: \"/api/...\", body? }`, where `method` is `\"GET\"`, `\"POST\"`, `\"PUT\"`, `\"DELETE\"`, or `\"PATCH\"`; raw authenticated API call.\n\n## Patch semantics\n\n`app-patch.definition` is RFC 7396 JSON Merge Patch applied to the stored definition:\n\n- omitted keys stay unchanged;\n- object keys merge recursively;\n- arrays and scalar values replace;\n- `null` deletes a key;\n- reusable-element disambiguation: a patch value for `elements.<name>` containing ONLY the `elements` key merges node-by-node; any other key present (`mode`, `root`, `props`, or `export`) makes it a full element replace — restate every field you want kept. In that node-by-node form, `elements.<name>.elements.<id>: null` deletes one node. Literal null nodes are rejected in a full element replace so they cannot be mistaken for deletions.\n- otherwise every supplied `pages.<page>.elements.<id>`, `pages.<page>.params.<param>`, `actions.<name>`, `models.<name>.columns.<col>`, and `models.<name>.sources.<src>` value is atomic and replaces that complete declaration; `null` deletes it (deleting a source detaches its rows — see the source lifecycle above).\n\n`pages.<page>: null` deletes a page, except the current `defaultPage` cannot be deleted. `root`, `title`, and top-level `defaultPage` use ordinary merge semantics. A top-level `page` patch is rejected with guidance to patch `pages.<name>` instead.\n\nBecause elements, param declarations, actions, and columns are atomic, include the complete desired object when changing one. For example, changing only a Table's `emptyMessage` requires sending its full `{ \"type\": \"Table\", \"props\": ... }` element. The merged result is validated as a whole; on failure, read `issues[]`, correct the paths, and retry without assuming anything was written.\n\n```json\n{\n  \"appId\": \"<app-id>\",\n  \"description\": null,\n  \"definition\": {\n    \"models\": {\n      \"idea\": {\n        \"columns\": {\n          \"priority\": { \"kind\": \"enum\", \"enum\": [\"low\", \"high\"], \"default\": \"low\" }\n        }\n      }\n    },\n    \"queries\": { \"openIdeas\": null },\n    \"pages\": {\n      \"main\": {\n        \"elements\": {\n          \"title\": { \"type\": \"Heading\", \"props\": { \"text\": \"Prioritized ideas\", \"level\": \"h1\" } }\n        }\n      }\n    }\n  }\n}\n```\n\n## Worked example: ideas tracker\n\nCreate this with `app-upsert`:\n\n```json\n{\n  \"name\": \"Ideas Tracker\",\n  \"description\": \"Collect and manage product ideas\",\n  \"definition\": {\n    \"models\": {\n      \"idea\": {\n        \"columns\": {\n          \"title\": { \"kind\": \"string\", \"required\": true },\n          \"status\": { \"kind\": \"enum\", \"enum\": [\"open\", \"done\"], \"default\": \"open\" }\n        }\n      }\n    },\n    \"queries\": {\n      \"allIdeas\": { \"model\": \"idea\", \"sort\": { \"column\": \"createdAt\", \"dir\": \"desc\" } }\n    },\n    \"actions\": {\n      \"triage\": { \"kind\": \"task\", \"prompt\": \"Review current ideas and recommend the next one to pursue\" }\n    },\n    \"pages\": {\n      \"main\": {\n        \"root\": \"root\",\n        \"elements\": {\n          \"root\": {\n            \"type\": \"Container\",\n            \"props\": { \"direction\": \"column\", \"gap\": \"lg\" },\n            \"children\": [\"heading\", \"formCard\", \"ideasCard\", \"triage\"]\n          },\n          \"heading\": { \"type\": \"Heading\", \"props\": { \"text\": \"Ideas\", \"level\": \"h1\" } },\n          \"formCard\": {\n            \"type\": \"Card\",\n            \"props\": { \"title\": \"Add an idea\" },\n            \"children\": [\"ideaForm\"]\n          },\n          \"ideaForm\": {\n            \"type\": \"Form\",\n            \"props\": {\n              \"id\": \"newIdea\",\n              \"fields\": [{ \"name\": \"title\", \"label\": \"Title\", \"required\": true }],\n              \"submitLabel\": \"Add\",\n              \"onSubmit\": [{\n                \"action\": \"app.mutate\",\n                \"params\": { \"model\": \"idea\", \"op\": \"create\", \"values\": { \"$form\": \"\" } }\n              }]\n            }\n          },\n          \"ideasCard\": {\n            \"type\": \"Card\",\n            \"props\": { \"title\": \"All ideas\" },\n            \"children\": [\"ideasTable\"]\n          },\n          \"ideasTable\": {\n            \"type\": \"Table\",\n            \"props\": {\n              \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n              \"loading\": { \"$state\": \"/queries/allIdeas/loading\" },\n              \"error\": { \"$state\": \"/queries/allIdeas/error\" },\n              \"columns\": [\n                { \"key\": \"title\", \"label\": \"Title\" },\n                { \"key\": \"status\", \"label\": \"Status\", \"kind\": \"badge\", \"tones\": { \"open\": \"info\", \"done\": \"success\" } }\n              ],\n              \"rowActions\": [{\n                \"label\": \"Delete\",\n                \"variant\": \"destructive-outline\",\n                \"actions\": [{ \"action\": \"app.mutate\", \"params\": { \"model\": \"idea\", \"op\": \"delete\", \"rowId\": { \"$row\": \"id\" } } }]\n              }]\n            }\n          },\n          \"triage\": {\n            \"type\": \"Button\",\n            \"props\": { \"label\": \"Ask swarm to triage\", \"variant\": \"secondary\" },\n            \"on\": { \"press\": [{ \"action\": \"app.action\", \"params\": { \"name\": \"triage\" } }] }\n          }\n        }\n      }\n    },\n    \"defaultPage\": \"main\"\n  }\n}\n```\n\nThe tool returns `{ appId, url: \"/apps/<id>\" }`. Open that URL to verify the live UI, then continue with the read-patch-validate loop above.\n";
-
-// templates/skills/artifacts/config.json
-var config_default3 = `{
-  "kind": "skill",
-  "name": "artifacts",
-  "displayName": "Artifacts",
-  "slug": "artifacts",
-  "title": "Artifacts",
-  "description": "Store durable task outputs (reports, screenshots, exports, logs) in agent-fs or the shared workspace, and serve interactive web content to a public auth-protected URL via localtunnel. Use when asked to save evidence for a PR/ticket, share a file, \\"create an artifact for X\\", \\"host this for me\\", \\"spin up a web server\\", or \\"give me a live link\\". Covers agent-fs writes and verification, binary uploads, naming and attachment conventions, the \`agent-swarm artifact\` CLI, Hono apps, PM2 daemonization, HTTP Basic auth, and the injected browser SDK.",
-  "version": "2.0.0",
-  "category": "skills",
-  "placeholders": [],
-  "runAllSeedersCandidate": true,
-  "systemDefault": false,
-  "tags": ["artifacts", "evidence", "qa", "agent-fs", "serving", "tunnel"]
-}
-`;
-
-// templates/skills/artifacts/content.md
-var content_default3 = `# Artifacts
-
-An artifact is any output that should outlive the session — a report,
-screenshot, recording, log, data export, dashboard. There are two things you
-can do with one, and this skill covers both:
-
-- **Store it** — write it to agent-fs or the shared workspace so humans and
-  other agents can find it later. This is the common case.
-- **Serve it** — run a real web server behind a public, auth-protected URL so a
-  human can *interact* with it (custom routes, form posts, live data).
-
-| You need… | Use |
-|---|---|
-| A file, report, screenshot, or export someone will read later | **Store** (agent-fs) |
-| A file another agent needs during *this* session | **Store** (\`/workspace/shared/\`) |
-| A static HTML/JSON report shared by URL | The **\`pages\`** skill — cheaper, no process to babysit |
-| Custom routes, websockets, file uploads, per-request computation | **Serve** (below) |
-
-Rule of thumb: if the content is a *snapshot*, store it or make a page. If it's
-a *running program*, serve it.
-
----
-
-# Part 1 — Storing artifacts
-
-Two stores: **agent-fs** (structured, searchable, shareable, survives restarts)
-and the **shared workspace filesystem** (\`/workspace/shared/\`, fast, same-session).
-
-## When to create one
-
-- Your task produces a deliverable humans should review.
-- Another agent or future session needs to pick up where you left off.
-- You want to attach evidence to a PR, Linear ticket, or Slack message.
-- The output is too large for \`store-progress.output\`.
-
-## agent-fs (preferred for anything human-shareable)
-
-\`\`\`bash
-# Write to your personal drive
-agent-fs write thoughts/research/2026-05-28-topic.md --content "..." -m "description"
-
-# Write to the shared drive (humans + other agents can see it)
-agent-fs --org <org-id> write \\
-  thoughts/<agent-id>/research/2026-05-28-topic.md \\
-  --content "..." -m "research findings"
-\`\`\`
-
-Your org and drive context is already configured — you only need \`--org\` when
-writing somewhere other than your default. Read the id from
-\`agent-fs stat <path> --json\` rather than hardcoding one you saw in an example.
-
-Always verify the write landed — agent-fs writes can fail silently with an
-empty payload:
-
-\`\`\`bash
-agent-fs stat <path> --json | jq '.size'
-# If size < 200 bytes on a non-trivial artifact, the write FAILED — re-do it.
-\`\`\`
-
-### Sharing agent-fs files with humans
-
-The deployment configures the live viewer host through \`AGENT_FS_LIVE_URL\`; the
-documented fallback is \`https://live.agent-fs.dev\`. Resolve it in the shell and
-combine it with the \`orgId\` and \`driveId\` returned by \`agent-fs stat\`:
-
-\`\`\`bash
-FILE_PATH='thoughts/<agent-id>/research/<file>.md'
-AGENT_FS_HOST=\${AGENT_FS_LIVE_URL:-https://live.agent-fs.dev}
-FILE_STAT=$(agent-fs stat "$FILE_PATH" --json)
-ORG_ID=$(printf '%s' "$FILE_STAT" | jq -r '.orgId')
-DRIVE_ID=$(printf '%s' "$FILE_STAT" | jq -r '.driveId')
-SHARE_URL="\${AGENT_FS_HOST%/}/file/~/$ORG_ID/$DRIVE_ID/$FILE_PATH"
-printf '%s\\n' "$SHARE_URL"
-\`\`\`
-
-Paste the printed concrete URL into Markdown or a message. Markdown does not
-expand environment variables.
-
-## Shared filesystem
-
-For non-text artifacts or files other agents need during the same session:
-
-- \`/workspace/shared/downloads/<agent-id>/\` — downloaded files
-- \`/workspace/shared/misc/<agent-id>/\` — other shared files
-
-It does **not** survive container restarts. Anything that must outlive the
-session goes to agent-fs.
-
-## Binary artifacts (PNG, MP4)
-
-\`agent-fs write --content\` is text-only and mangles binaries. Upload binaries
-with \`--file\` (or piped stdin), which uses the binary-safe raw route
-(agent-fs CLI >= 0.7.1):
-
-\`\`\`bash
-agent-fs write thoughts/<agent-id>/qa/<topic>-screenshots/login.png \\
-  --file /tmp/login.png -m "login page after fix"
-agent-fs stat thoughts/<agent-id>/qa/<topic>-screenshots/login.png --json | jq '.size'
-\`\`\`
-
-Capture with \`agent-browser screenshot <path>\` when it is installed, otherwise
-Playwright, ffmpeg, or a system screenshot tool. The agent-fs copy is the
-durable original. Where each kind of content goes:
-
-| Content | Use | Why |
-|---|---|---|
-| Image or GIF in GitHub | GitHub user attachment (\`github-attach\` skill) | Permanent, renders inline, short URL |
-| Video (mp4) in GitHub | GitHub user attachment, else an \`agent-fs share-create\` link | GitHub plays it inline. A presigned link downloads it |
-| Doc (plan, research, report) | \`agent-fs share-create <path> --expires-in 604800\` | Preview page, no download |
-| Durable pointer | \`live.agent-fs.dev\` path, in a PR only under \`## Swarm provenance\` | Share links die after 7 days, this one does not (needs login) |
-| Presigned \`signed-url\` | Image fallback only, with \`--inline\` | Downloads and expires after 7 days. Never for docs or mp4s |
-
-\`\`\`bash
-agent-fs signed-url thoughts/<agent-id>/qa/<topic>-screenshots/login.png --inline --json   # fallback only; 24h default, --expires-in up to 7d
-\`\`\`
-
-## Naming conventions
-
-Name paths predictably by task, date, and artifact type:
-
-\`\`\`
-thoughts/<agent-id>/research/YYYY-MM-DD-<topic>.md
-thoughts/<agent-id>/plans/YYYY-MM-DD-<topic>.md
-thoughts/<agent-id>/qa/<topic>-screenshots/<filename>.png
-misc/<agent-id>/<task-id>-<description>.ext
-\`\`\`
-
-## Attaching artifacts
-
-- **PR body** — embed images and mp4s as GitHub user attachments
-  (\`![caption](https://github.com/user-attachments/assets/<uuid>)\`), and link docs
-  with \`share-create\`. Never embed a \`share-create\` link as an image: it is an
-  HTML preview page. Swarm task links and durable agent-fs paths go only under
-  \`## Swarm provenance\`.
-- **Slack** — link the agent-fs URL (team members only, the live viewer needs a login). Use a \`share-create\` link (up to 7 days) for anyone else.
-- **\`store-progress\`** — use the \`attachments\` field with \`kind: "agent-fs"\` and the path.
-- **Linear comments** — paste the live URL in the comment body.
-
-## What NOT to store
-
-- Secrets, API keys, OAuth tokens
-- Raw customer data without approval
-- Oversized files without approval (check size before uploading)
-- Ephemeral progress notes — those go in \`store-progress.progress\`
-
-## Trade-offs
-
-**agent-fs vs shared filesystem** — agent-fs is persistent, versioned, and
-searchable across sessions. The shared filesystem is faster for same-session
-handoffs but doesn't survive container restarts. Use agent-fs for anything that
-needs to outlive the current session or be reviewed by a human.
-
----
-
-# Part 2 — Serving interactive web content
-
-Serve a directory or a Hono app to a public, auth-protected URL via
-localtunnel. Use this when a static page won't do: custom routes, form posts,
-uploads, per-request computation.
-
-The CLI is a subcommand of \`agent-swarm\`. Always invoke it as
-**\`agent-swarm artifact <subcommand>\`** — there is no top-level \`artifact\`
-binary.
-
-## Quick start
-
-### Static content
-
-\`\`\`bash
-# Create your content in a persisted directory
-mkdir -p /workspace/personal/artifacts/my-report
-echo '<h1>My Report</h1>' > /workspace/personal/artifacts/my-report/index.html
-
-# Serve it (auto-assigns a free port, creates tunnel, registers in service registry)
-agent-swarm artifact serve /workspace/personal/artifacts/my-report --name my-report
-# -> Copy the deployment URL printed by the command; it is authoritative.
-\`\`\`
-
-### Programmatic (custom Hono server)
-
-\`\`\`typescript
-import { createArtifactServer } from '../artifact-sdk';
-import { Hono } from 'hono';
-
-const app = new Hono();
-app.get('/', (c) => c.html('<h1>Dashboard</h1>'));
-
-const server = createArtifactServer({ name: 'dashboard', app });
-await server.start();
-console.log(\`Live at: \${server.url}\`);
-\`\`\`
-
-You can also run \`agent-swarm artifact serve ./server.ts --name dashboard\` if
-\`server.ts\` exports a Hono instance as its default export.
-
-See the bundled \`examples/\` directory for complete working examples
-(\`static-report.sh\`, \`hono-dashboard.ts\`, \`approval-flow.ts\`,
-\`multi-artifact.ts\`).
-
-## CLI commands
-
-| Command | Description |
-|---|---|
-| \`agent-swarm artifact serve <path> --name <name> [--port <port>] [--no-auth] [--subdomain <sub>]\` | Start serving content. \`<path>\` is a directory (static) or a \`.ts\`/\`.js\` file exporting a default Hono app. |
-| \`agent-swarm artifact list\` | List active artifacts (name, agent, port, URL, status) from the service registry. |
-| \`agent-swarm artifact stop <name>\` | Stop an artifact: deletes the matching PM2 process and unregisters it from the service registry. See "Known limitation" below. |
-
-Flags accepted by \`serve\`:
-
-- \`--name <name>\` — defaults to the basename of \`<path>\`. Used for the subdomain and PM2 process name.
-- \`--port <port>\` — pin to a specific port. Default: auto-assigned ephemeral port.
-- \`--no-auth\` — disable HTTP Basic auth on the tunnel (DANGEROUS — anyone with the URL can access).
-- \`--subdomain <sub>\` — override the default \`\${agentId}-\${name}\` subdomain.
-
-## Auth & URL pattern
-
-Tunnels are protected by **HTTP Basic auth** by default:
-
-- **Username:** \`hi\` (hardcoded MVP default in \`src/artifact-sdk/tunnel.ts\`)
-- **Password:** the agent's \`API_KEY\`
-
-> **Never put the API key in the URL.** The Basic-auth password *is* the swarm
-> \`API_KEY\` — it authenticates against the whole swarm API, not just this
-> artifact. A \`https://user:key@host\` URL leaks that credential into shell
-> history, browser history, proxy and tunnel access logs, referrer headers, and
-> anything you paste it into. Treat a credential-bearing URL as a leaked key.
-
-The installed \`@desplega.ai/localtunnel\` package currently defaults to
-\`lt.desplega.ai\`, but deployments may configure another tunnel host. The URL
-printed by \`agent-swarm artifact serve\` (or exposed as \`server.url\`) is
-authoritative. Save that plain URL as \`ARTIFACT_URL\`; a browser will prompt for
-the credentials.
-
-For scripts and \`curl\`, pass the credential out-of-band instead of inlining it,
-and read it from the environment so it never appears as a literal:
-
-\`\`\`bash
-# -u keeps the credential out of the URL; --netrc-file keeps it out of argv too.
-curl -u "hi:$API_KEY" "$ARTIFACT_URL"
-
-# Better for anything long-lived or logged — argv is visible to other processes:
-ARTIFACT_HOST=\${ARTIFACT_URL#*://}
-ARTIFACT_HOST=\${ARTIFACT_HOST%%/*}
-printf 'machine %s login hi password %s\\n' \\
-  "$ARTIFACT_HOST" "$API_KEY" > /tmp/artifact-netrc
-chmod 600 /tmp/artifact-netrc
-curl --netrc-file /tmp/artifact-netrc "$ARTIFACT_URL"
-\`\`\`
-
-Do not echo the assembled command, and do not paste the credential into a task
-report, Slack message, PR body, or page — those are all persisted.
-
-Use \`--no-auth\` only for genuinely public content. Anyone who learns the
-subdomain can read it.
-
-## Running it as a daemon
-
-\`agent-swarm artifact serve\` blocks on a never-resolving promise to stay alive —
-you cannot inline it in a script that needs to do other work. Pick one:
-
-### Option A — \`nohup\` (quick, throwaway)
-
-\`\`\`bash
-mkdir -p /workspace/personal/logs
-nohup agent-swarm artifact serve /workspace/personal/artifacts/my-report \\
-  --name my-report \\
-  > /workspace/personal/logs/my-report.out 2>&1 &
-echo $! > /workspace/personal/logs/my-report.pid
-
-# Later, kill it manually:
-kill "$(cat /workspace/personal/logs/my-report.pid)"
-\`\`\`
-
-### Option B — PM2 (recommended for anything you'll come back to)
-
-PM2 gives you auto-restart on crash, a process name, log management, and —
-crucially — lets \`agent-swarm artifact stop <name>\` actually kill it.
-
-\`\`\`bash
-pm2 start agent-swarm \\
-  --name artifact-my-report \\
-  -- artifact serve /workspace/personal/artifacts/my-report --name my-report
-
-# Stop it cleanly later:
-agent-swarm artifact stop my-report
-\`\`\`
-
-The PM2 process name **must** be \`artifact-<name>\` (matching \`--name\`) — that's
-exactly what \`artifact stop\` looks for.
-
-### Known limitation — \`artifact stop\` only kills PM2-started processes
-
-\`agent-swarm artifact stop <name>\` runs \`pm2 delete artifact-<name>\` and then
-unregisters the entry from the service registry. If you started the artifact
-with \`nohup\` (or \`&\`, or any non-PM2 launcher), \`pm2 delete\` silently fails and
-the server keeps running and serving — even though the command prints
-\`Artifact '<name>' stopped.\` Until that's fixed:
-
-- Use **PM2** if you want \`artifact stop\` to do its job.
-- For \`nohup\`/foreground processes, kill the PID yourself
-  (\`kill <pid>\` or \`pkill -f 'artifact serve.*<name>'\`) **and then** run
-  \`agent-swarm artifact stop <name>\` to clear the registry row.
-
-## Multiple artifacts
-
-Each artifact gets its own port (auto-assigned) and subdomain
-(\`<agentId>-<name>\`). You can run several simultaneously — see
-\`examples/multi-artifact.ts\`.
-
-## Browser SDK
-
-Served HTML gets the same injected browser SDK that pages get. Load it and use
-the ready-made singleton:
-
-\`\`\`html
-<script src="/@swarm/sdk.js"></script>
-<script>
-  // \`window.swarmSdk\` is constructed for you — no \`new SwarmSDK()\` needed.
-  const tasks = await window.swarmSdk.tasks.list({ status: 'in_progress' });
-  const agents = await window.swarmSdk.agents.list();
-</script>
-\`\`\`
-
-The SDK is **domain-grouped** (\`swarmSdk.tasks\`, \`.agents\`, \`.events\`,
-\`.memory\`, \`.repos\`, \`.schedules\`, \`.approvalRequests\`, \`.assets\`), each domain
-mapping 1:1 onto the public REST API. The **\`pages\`** skill documents the full
-method surface — it's the same object, so don't duplicate it here.
-
-Calls route through the \`/@swarm/api/*\` proxy, which injects auth server-side.
-Browser code never sees the API key.
-
-## Storage
-
-Always store served content in persisted directories — the working dir is wiped
-between sessions:
-
-- \`/workspace/personal/artifacts/\` — per-agent, persists across sessions (default)
-- \`/workspace/shared/artifacts/\` — shared across the swarm
-
-## See also
-
-- The **\`pages\`** skill — DB-backed static HTML/JSON, no process to run. Prefer
-  it whenever the content is a snapshot.
-- The **\`kv-storage\`** skill — for the small state a served page needs.
-`;
+var content_default2 = "# Swarm Apps\n\nSwarm Apps are persistent, agent-authored internal applications: a schema-backed row store, named queries, custom script/task actions, and a validated json-render interface served at `/apps/<id>`. Use an app when people need to view and change live records; use `create_page` for a static snapshot.\n\n> **Capability gate**: app tools are available when the server's `CAPABILITIES` includes `pages` (for example `CAPABILITIES=core,task-pool,pages`). There is no separate `apps` capability. If these tools are absent from your MCP list, this is why.\n\n## Tools and iteration loop\n\n| Tool | Use it for |\n|---|---|\n| `app-list` | Discover apps by id, name, description, and timestamps. Definitions are omitted. |\n| `app-get` | Read one complete stored definition before changing it. |\n| `app-upsert` | Create an app, or replace an existing app's entire definition when you intentionally have the full desired state. |\n| `app-patch` | Make a focused change while preserving everything not mentioned in the patch. Prefer this for iteration. |\n| `app-query` | Run one declared named query and return its rows. Use this when an agent or saved script needs to consume app data rather than render the app UI. |\n| `app-history` | List definition snapshots and their compact model/column digests before choosing a restore point. |\n| `app-diff` | Show a unified definition diff; defaults to newest snapshot → CURRENT. |\n| `app-rollback` | Restore a snapshot through the normal schema-migration engine. |\n\nFor every edit: `app-get` -> modify the smallest coherent subtree -> `app-patch` -> if rejected, fix every returned `issues[]` entry (`path` + `message`) and retry. Validation happens before storage, so a rejected update leaves the saved app unchanged. Do not guess at the current definition or use `app-upsert` with a partial definition.\n\n`app-patch` can also change `name`; omit `description` to preserve it or pass `description: null` to clear it.\n\n### Reading an app's callable surface\n\nOne `app-get` returns everything needed to drive an app you did not write: `definition.queries` are runnable with `app-query` (supply every `$param` the query references), and `definition.actions` are invocable with `POST /api/apps/<id>/actions/<name>` (a `script` action runs its script, a `task` action spawns a task, a `sync` action refreshes sources). Read a query's `$param` placeholders and an action's kind/args from the definition before calling — do not guess parameter names.\n\n## Safe schema evolution and rollback\n\nPrefer **hiding** a column over deleting it. A hidden column's values stay on every existing row, so an unhide or rollback can make it visible again. Hiding is metadata-only: hidden columns cannot be used in queries, page bindings, `app.mutate` values, or new row writes, and `required` is ignored while hidden. Row GETs still expose the historical value for backward compatibility.\n\nDo not reuse a hidden column name. The name remains held until you either unhide it or explicitly purge its stored values. To permanently remove a column, delete its declaration with `null` and include `{ \"columnName\": { \"purge\": true } }` in the same `migration` object. That is deliberately one-shot and irreversible for row data.\n\nSchema-changing writes can carry this sibling `migration` object:\n\n```json\n{\n  \"migration\": {\n    \"priority\": { \"from\": \"flag\", \"map\": { \"urgent\": \"high\", \"watch\": \"low\" }, \"else\": \"none\" },\n    \"status\": { \"from\": \"flag\", \"map\": { \"watch\": \"watching\", \"done\": \"done\" }, \"else\": \"open\" },\n    \"oldColumn\": { \"purge\": true },\n    \"count\": { \"coerce\": true, \"else\": 0 },\n    \"owner\": { \"set\": \"unassigned\" }\n  }\n}\n```\n\nUse `set` to backfill a changed column, `from` with optional `map`/`else` to derive it from one existing (including hidden) column, `coerce` for a kind change, and `purge` only for explicit destruction. Non-purge directives target a column changed in that same write. The server fails loudly before writing when a lossy change needs a directive: inspect every returned `issues[]` item, including its per-value row counts, then choose an explicit policy and retry. Never guess a migration just to get a 200.\n\n**Source lifecycle** rides the same engine with the same all-or-nothing guarantees. Free: adding a source, adding a NEW column with a `source` binding, binding an existing column that holds zero values, changing a binding's `field`/`transform`, and changing a source's `args`/`config`/`connection`/`scriptId` (window changes churn staleness on the next pass — expect `stale` flips when narrowing). Rejected with a path-bearing issue: changing `joinKey` (immutable — remove the source and add it again), changing `connector` while the source owns rows (row count in the message), and binding an existing column that already holds values (purge it — or add a fresh column — and bind that instead; a sync pass would otherwise overwrite the data). Removing a source **detaches** its rows: values survive as ordinary columns, the `source`/`syncedAt`/`stale` envelope is stripped, and the report counts them in `detachedRows`. A patch removing a source must drop its column bindings in the same call — a dangling `source.of` is rejected before anything is written.\n\nSync never adopts rows it does not own: a pulled record whose join key matches an unowned row creates a second, source-owned row. Adding a source over a join-key column that already holds values therefore duplicates those records on the first pass — and remove-source → re-add duplicates for the same reason, because detached rows keep their values. To convert a hand-maintained model into a synced one, purge the old rows first or use a fresh join-key column.\n\nFor example, split a legacy `flag` into `priority` and `status` without losing data in one patch: add the two columns, map both from `flag`, update every affected query/page binding, then hide `flag`.\n\n```json\n{\n  \"appId\": \"<app-id>\",\n  \"definition\": {\n    \"models\": {\n      \"ticket\": {\n        \"columns\": {\n          \"priority\": { \"kind\": \"enum\", \"enum\": [\"none\", \"low\", \"high\"] },\n          \"status\": { \"kind\": \"enum\", \"enum\": [\"open\", \"watching\", \"done\"] },\n          \"flag\": { \"kind\": \"string\", \"hidden\": true }\n        }\n      }\n    }\n  },\n  \"migration\": {\n    \"priority\": { \"from\": \"flag\", \"map\": { \"urgent\": \"high\", \"watch\": \"low\" }, \"else\": \"none\" },\n    \"status\": { \"from\": \"flag\", \"map\": { \"watch\": \"watching\", \"done\": \"done\" }, \"else\": \"open\" }\n  }\n}\n```\n\nEvery schema migration returns `{ scanned, backfilled, coerced, mapped, elsed, purgedValues, idxRebuilt, detachedRows, orphanFields }`. Read `orphanFields`: it reports extra row fields that predate or no longer appear in the definition; they are preserved until an explicit purge. `schemaVersion` is server-managed: never set it in an input patch or try to use it as application data.\n\nEvery successful definition write snapshots the previous definition. Use `app-history` to select a version, `app-diff({ appId, from: <version> })` to inspect it against CURRENT, then `app-rollback({ appId, version: <version>, migration? })` to restore it. Rollback is a forward migration over live rows, not row-level time travel: it creates a new pre-rollback snapshot and may reject a lossy restore with the same migration directives and counts. A rejected rollback changes nothing.\n\n### Per-user configuration\n\n`userConfig` declares up to 20 typed settings in the versioned definition; its values are deliberately stored outside the definition, separately for each user (and the operator dashboard). Each field is `{ \"kind\": \"string\" | \"number\" | \"boolean\" | \"date\" | \"enum\", \"default\"?: ..., \"enum\"?: [...], \"label\"?: \"...\" }`. Defaults follow column rules, including enum membership; `required` is not allowed. A missing or obsolete stored value reads as its default, or `null` when no default is declared.\n\nUse `{ \"$state\": \"/user/<field>\" }` on a page for the read-only current-user binding; the field must be declared and the path cannot continue below it. Pure and bound reusable elements cannot bind `/user` directly — pass the value through an element prop from the consuming page. An agent acting on an owned user-requested task reads and edits that requester's preferences. `userConfig` schema changes are always migration-compatible and appear in migration reports; no migration directives are needed. Rollback restores the historical schema but never alters saved per-user values, so values can resurface when a field returns.\n\n### Theming\n\nAn optional top-level `\"theme\"` sets the preset the dashboard applies to the app's rendered canvas — a lowercase slug validated by shape only. The preset catalog ships with the dashboard (`apps/ui/src/lib/themes.ts` + `theme-classics.ts` — update this list and the `app-upsert` tool description when it changes); current ids: `hive` (the stock look), the accent/field presets `meadow`, `iris`, `rose`, `cobalt`, `ember`, `carbon`, and the classic editor/platform presets `github`, `vscode`, `material`, `solarized`, `tokyo`, `monokai`, `gruvbox`, `catppuccin`. Action and destructive tones are never themed; status tones are themed ONLY by the classic presets (their identity includes a status palette — hue semantics stay fixed, success reads green and error reads red everywhere). An id the viewer's dashboard build does not know degrades to the dashboard's own theme, so unknown slugs are safe but pointless. Omit `theme` to inherit whatever theme the viewer runs; `\"hive\"` is an explicit reset to the stock look even inside a themed dashboard.\n\nViewers can override the preset per app from the app's settings drawer; the override rides the reserved `$theme` key of the user-config values (accepted on every app, even without a declared `userConfig` schema, and never visible at `/user/...`). A present override always beats the definition's `theme` — even an unrecognized one, which degrades to the dashboard theme — so treat `theme` as the app's default styling, not a guarantee.\n\nDistinguish the two rollback 400s. A lossy-migration 400 is fixable: copy the required `migration` entries from the message and retry. A target-snapshot validation 400 explicitly says that directives cannot repair that historical definition; use `app-history` and choose a different version.\n\nWhen a schema patch reports stale page/query bindings, repair them in that same patch. Page elements are atomic: replace the complete `pages.<page>.elements.<id>` declaration, removing any reference to a hidden or deleted column, instead of sending only the changed nested prop. This is also the repair move for older apps whose stored page already references an undeclared column; full-definition validation otherwise blocks every patch.\n\n## Definition reference\n\n```json\n{\n  \"models\": {\n    \"modelName\": {\n      \"columns\": {\n        \"externalId\": { \"kind\": \"string\" },\n        \"title\": { \"kind\": \"string\" }\n      }\n    }\n  },\n  \"queries\": { \"queryName\": { \"model\": \"modelName\" } },\n  \"actions\": { \"actionName\": { \"kind\": \"task\", \"prompt\": \"Review the current rows and report\" } },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"root\",\n      \"elements\": { \"root\": { \"type\": \"Container\", \"props\": {} } }\n    }\n  },\n  \"defaultPage\": \"main\",\n  \"theme\": \"ember\"\n}\n```\n\nModel, reusable-element, element-prop, query, action, column, page, and page-param names start with a lowercase letter, contain only letters, numbers, or underscores, and are at most 40 characters. A definition has 0-10 models and at most 20 reusable elements; each declared model has 1-40 columns. Zero-model apps are valid for pure UI utilities as long as their pages and reusable elements validate.\n\n### Reusable elements\n\nTop-level `elements` are versioned inside the app definition and can be reused from the app's own pages or, when explicitly exported, from another app. They are private by default. Each entry declares a `mode`, optional typed `props`, one `root`, and a flat `elements` node map using the same validated tree vocabulary as a page:\n\n```json\n{\n  \"elements\": {\n    \"statCard\": {\n      \"mode\": \"pure\",\n      \"export\": true,\n      \"props\": {\n        \"label\": { \"kind\": \"string\", \"required\": true },\n        \"value\": { \"kind\": \"number\", \"default\": 0 }\n      },\n      \"root\": \"card\",\n      \"elements\": {\n        \"card\": { \"type\": \"Card\", \"props\": {}, \"children\": [\"label\", \"slot\"] },\n        \"label\": { \"type\": \"Metric\", \"props\": { \"label\": { \"$state\": \"/props/label\" }, \"value\": { \"$state\": \"/props/value\" } } },\n        \"slot\": { \"type\": \"ElementSlot\", \"props\": {} }\n      }\n    }\n  }\n}\n```\n\n- `pure` elements may read only their declared `/props/<name>` state; `$item` and `$index` are also legal inside repeated nodes. They cannot invoke any action step. A pure tree may contain at most one leaf `ElementSlot` where consumer children are inserted.\n- `bound` elements may additionally read the defining app's declared queries and actions and use its models. Those references are validated against the defining app, including hidden-column rules. Exported bound elements cannot use `app.navigate`; private bound elements may navigate within their defining app.\n- Prop kinds are `string`, `number`, `boolean`, `date`, or `enum`. An enum prop requires a non-empty `enum: [\"value\", ...]` values array. A literal default and each literal consumer value must match the kind and, for enums, be one of those values. A required prop without a default must be supplied.\n\nReference an element with an `ElementRef` node. Omit `app` for same-app reuse; cross-app references name the defining app id and require `export: true`. `instanceKey` is optional. Consumer `children` are accepted only when the target has an `ElementSlot`:\n\n```json\n{\n  \"type\": \"ElementRef\",\n  \"props\": {\n    \"app\": \"<defining-app-id>\",\n    \"element\": \"statCard\",\n    \"props\": { \"label\": \"Open issues\", \"value\": 12 },\n    \"instanceKey\": \"openIssues\"\n  },\n  \"children\": [\"details\"]\n}\n```\n\nElement references float to the defining app's current definition. `app` and `element` must be literal strings; dynamic references are not supported. The server rejects reference cycles and expansion deeper than five, missing/private targets, invalid props, and a breaking write to an exported element that other apps reference. Removing or unexporting an exported element, changing its mode, removing a declared prop, changing a prop kind, or adding a required prop without a default is breaking; publish the new contract under a new element name. If consumers are abandoned intentionally, retry the PUT, PATCH, or rollback with `\"forceElementBreak\": [\"elementName\"]`. The named consumers will then render an error once element rendering is available; deleting an entire app is deliberately not compatibility-gated.\n\n### Models\n\nEach column is `{ \"kind\": ..., \"required\"?: boolean, \"default\"?: ..., \"index\"?: boolean, \"enum\"?: string[], \"hidden\"?: boolean }`.\n\n| `kind` | Values and indexing |\n|---|---|\n| `string` | String value; set `index: true` only when equality lookups need it. |\n| `number` | Finite number; never indexed. |\n| `boolean` | Boolean; set `index: true` only when equality lookups need it. |\n| `date` | ISO-8601 string; never indexed. |\n| `enum` | String from the non-empty unique `enum` list; always indexed, without `index: true`. |\n\n`default` must match the column kind (and be one of the enum values). `required: true` rejects missing/null values unless a default supplies the value. `id`, `createdAt`, `updatedAt`, `createdBy`, `updatedBy` — and the sync envelope `source`, `syncedAt`, `stale` — are system columns and reserved names. An app created before the sync envelope that declared ordinary columns with these names surfaces `definitionError` after upgrade until they are renamed: patch in a fresh column with a `{from}` migration directive, then purge the old one. Rows always expose `id`/`createdAt`/`updatedAt`; `createdBy`/`updatedBy` record the acting principal (`user:<id>`, `agent:<id>`, `operator`, or `sync:<source>` for engine writes) and are system-managed on every row write.\n\n### Sources and sync\n\nA model may declare up to 4 named `sources` — one-way inbound projections of an external system into its rows. The `script` connector is THE way to bring external data in (GitHub, Linear, any API): a saved script owns the fetch, its auth placeholders, and its paging. `swarm-tasks` is the one native connector, projecting this swarm's own task pool (`config`: `status`/`tags` comma-lists, `agentId`, `assetKey` namespace prefix, `limit` up to 200 — default 100, `includeHeartbeat`). Synced rows are readable by EVERY principal with `app.use` on the app; an unscoped `swarm-tasks` source publishes task prompts (truncated, secret-scrubbed) to all of them, so scope it with `config.assetKey`/`config.agentId` unless that exposure is intended. A user-invoked sync only ever pulls the invoking user's own requested tasks. Script sources run with their run-as identity's credentials — an agent-owned script runs as its owner and only the owner may wire it; an owner-less catalog (global) script runs as the LEAD, so only the lead or the operator can wire or alter such a source (stored references stay valid with their args and connection pinned).\n\n```json\n{\n  \"models\": {\n    \"issue\": {\n      \"columns\": {\n        \"issueKey\": { \"kind\": \"string\" },\n        \"title\": { \"kind\": \"string\", \"source\": { \"of\": \"gh\", \"field\": \"title\" } },\n        \"openedAt\": { \"kind\": \"date\", \"source\": { \"of\": \"gh\", \"field\": \"created_at\", \"transform\": \"date-parse\" } },\n        \"note\": { \"kind\": \"string\" }\n      },\n      \"sources\": {\n        \"gh\": { \"connector\": \"script\", \"scriptId\": \"<script-uuid>\", \"joinKey\": \"issueKey\", \"args\": { \"repo\": \"owner/name\" }, \"connection\": \"github\" }\n      }\n    }\n  }\n}\n```\n\n- **Join key**: each source names a `joinKey` — an owned, non-hidden `string` column carrying the external identity. It must not be `required`, must not declare a `default`, and cannot itself be source-bound. A row belongs to at most ONE source (`row.source`).\n- **Column bindings**: `{ \"of\": \"<sourceName>\", \"field\": \"user.login\", \"transform\"? }` projects a (dotted-path) field of the pulled record into the column on every pass. Transforms and their required column kinds: `slug`/`lower`/`upper` → `string`, `cents` → `number` (×100, rounded), `date-parse` → `date` (ISO). A failed transform nulls that one column and warns; it never fails the pass.\n- **Read-only contract**: source-bound columns and the join key reject every direct write (row create/patch/bulk) with a path-bearing issue — mutate them via the source or a sync refresh. Owned columns on the same model stay writable. Every `required` owned column on a sourced model must declare a `default`, because sync-created rows cannot supply it.\n- **Provenance**: synced rows carry `source` (owner), `syncedAt` (last confirmed presence — sortable), and `stale` (true when a complete pull no longer returned the record; clears on reappearance). `syncedAt` advances on every confirmed row WITHOUT touching `updatedAt`; `updatedAt` moves only when projected data actually changed.\n- **`connection`** (optional, script sources): names a connections-system slug the source depends on. It buys write-time validation plus a preflight before every pull; it does not by itself gate egress. Credentials resolve for the sync run-as identity — the script's owner when it has one, else the lead agent — so global connections always work and agent-scoped ones need matching script ownership. The slug is injected into the script's args as `connection`, letting one generic script serve N connections.\n\n**The canonical sync-script contract** (every sync script, always):\n\n```ts\nexport default async function run(args, ctx) {\n  // args = { ...source.args, app: { id }, model: \"<model>\", source: \"<sourceName>\", connection?: \"<slug>\" }\n  const records = [{ key: \"42\", fields: { title: \"…\", created_at: \"…\" } }];\n  return { records, complete: true }; // or return the bare array — a bare array IS a complete snapshot\n}\n```\n\nReturn `Array<{ key, fields }>` or `{ records, complete? }`. `key` is the external identity the engine joins on `joinKey` (numbers are coerced to strings); `fields` is the bag bindings project from. Return `complete: false` whenever the pull window may have missed records — a paged fetch, a hit `limit`, or client-side filtering of a full page. An incomplete pull skips the stale sweep, so rows outside a narrow window are not falsely marked stale; compute `complete` BEFORE any client-side filtering. Hard cap 500 records per pull (over-cap pulls truncate and count as incomplete). An invalid return shape, thrown error, or non-zero exit fails the pass with zero row churn.\n\nThe seeded catalog script `github-issues-pull` is the worked example (placeholder auth via `[REDACTED:GITHUB_TOKEN]`, PR filtering, `complete` computed before filtering). For scheduled refreshes, point a `targetType: \"script\"` schedule at the seeded `app-sync-run` with `scriptArgs: { \"appId\": \"<id>\", \"model\"?, \"source\"? }`.\n\n**Three refresh doors, one engine**: `POST /api/apps/<id>/sync` (body `{ \"model\"?, \"source\"? }`), a `sync` action kind, and the `app-sync` MCP tool (`ctx.swarm.app_sync` from scripts). `{model?, source?}` fans out to every matching (model × source) pair; each pass reports `{ pulled, created, updated, refreshed, unchanged, markedStale, warnings }`. A pair already syncing in this API process short-circuits with `alreadyRunning: true` instead of pulling twice. Each pair's last-pass status (`lastFinishedAt`, counts, `error?`) comes back as `syncStatus` — keyed `\"<model>:<source>\"` — on `GET /api/apps/<id>` and in `app-get` data, so UI and agents can render \"last synced / last error\" without extra calls.\n\n### Freshness and the refresh button\n\nFreshness renders with the existing column kinds — no special components. Give the table `{ \"key\": \"syncedAt\", \"kind\": \"date\" }` and `{ \"key\": \"stale\", \"kind\": \"badge\", \"tones\": { \"true\": \"warning\" } }` columns, declare a `sync` action, and wire a Button to it:\n\n```json\n{\n  \"actions\": { \"refresh\": { \"kind\": \"sync\" } },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"root\",\n      \"elements\": {\n        \"root\": { \"type\": \"Container\", \"props\": {}, \"children\": [\"refreshBtn\", \"issuesTable\"] },\n        \"refreshBtn\": {\n          \"type\": \"Button\",\n          \"props\": { \"label\": \"Refresh\" },\n          \"on\": { \"press\": [{ \"action\": \"app.action\", \"params\": { \"name\": \"refresh\" } }] }\n        },\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [\n              { \"key\": \"title\", \"label\": \"Issue\" },\n              { \"key\": \"syncedAt\", \"label\": \"Synced\", \"kind\": \"date\" },\n              { \"key\": \"stale\", \"label\": \"Stale\", \"kind\": \"badge\", \"tones\": { \"true\": \"warning\" } }\n            ]\n          }\n        }\n      }\n    }\n  }\n}\n```\n\nA `sync` action answers the script-action state shape (`/actions/refresh` → `running` → `ok`/`error`, result under `result.passes`), so the page's queries refetch when it completes. Use `app-query` to READ rows (named queries may filter on `stale`/`source` and sort by `syncedAt`); use `app-sync` to REFRESH sources; never poll a sync door in a loop — schedule it or give people the button.\n\n### Queries\n\nA named query is:\n\n```json\n{\n  \"model\": \"idea\",\n  \"filter\": { \"status\": \"open\" },\n  \"sort\": { \"column\": \"createdAt\", \"dir\": \"desc\" },\n  \"limit\": 100\n}\n```\n\n`filter` is a strict AND of equality checks. A filter may target a declared model column or a system column (`id`, `createdAt`, `updatedAt`, `createdBy`, `updatedBy`, and on synced models `source`, `syncedAt`, `stale`) — filtering on `id` is the universal way to select one row for a detail view, and `{ \"stale\": true }` selects rows a complete pull stopped confirming. A literal value must match the column's kind; date filters compare the stored raw ISO string, not parsed instants. Omit `limit` for the default 200 rows, or set an integer from 1 through 1000. `sort.column` is a model column, `createdAt`, `updatedAt`, or `syncedAt`; `dir` is `asc` or `desc`. Query runtime state is `{ data, loading, error }` under `/queries/<queryName>`.\n\nA filter value may instead be exactly `{ \"$param\": \"<name>\" }`. At execution, the caller supplies that name and the server coerces its value to the filtered column's kind before equality matching:\n\n```json\n{\n  \"queries\": {\n    \"issueDetail\": { \"model\": \"issue\", \"filter\": { \"issueId\": { \"$param\": \"issueId\" } }, \"limit\": 1 }\n  }\n}\n```\n\nThe placeholder object must contain only `$param`. Missing caller values fail loudly rather than returning unfiltered rows: HTTP reports 400 and `app-query` returns a tool error listing every missing name. Supplying a param name the query does not reference is also an error. The app UI supplies current declared route params automatically. Direct calls use `app-query({ appId, query: \"issueDetail\", params: { issueId: 42 } })` or `ctx.swarm.app_query({ appId, query: \"issueDetail\", params: { issueId: 42 } })`.\n\n### Custom actions\n\nActions are optional (maximum 20) and are invoked from the page with the `app.action` runtime action.\n\n```json\n{\n  \"actions\": {\n    \"recalculate\": {\n      \"kind\": \"script\",\n      \"scriptId\": \"00000000-0000-4000-8000-000000000000\",\n      \"args\": { \"mode\": \"fast\" }\n    },\n    \"triage\": {\n      \"kind\": \"task\",\n      \"prompt\": \"Triage this idea and report a recommendation\"\n    }\n  }\n}\n```\n\n| Kind | Contract |\n|---|---|\n| `script` | `scriptId` must identify an existing script; optional `args` are defaults. Invocation input overrides same-named defaults, and the runtime also supplies `app: { id }`. |\n| `task` | `prompt` must be non-empty; omit `agentId` to use default (lead) assignment. Only set `agentId` to a real agent UUID. Invocation `input` is included as context for the task prompt. Spawned tasks carry asset key `shared/app:<appId>/action:<name>/`, so a `swarm-tasks` source with `config.assetKey: \"shared/app:<appId>/\"` pulls back the tasks this app spawned. |\n| `sync` | Optional `model` and `source` narrow which (model × source) pairs refresh; omitting both syncs every pair the app declares. At least one pair must exist. Answers the script-kind state shape with per-pass results under `result.passes`. |\n\n- Invocation state lands at `/actions/<name>` as `{ status, result?, error?, taskId?, taskStatus? }`, where `status` is `\"running\"`, `\"ok\"`, or `\"error\"`.\n\nUse a task action named Tackle when a person should hand one issue row to the swarm. Pass the complete current row under `input.issue`; `{ \"$row\": \"\" }` resolves to the whole row and that context lands in the task prompt.\n\n```json\n{\n  \"actions\": {\n    \"tackle\": { \"kind\": \"task\", \"prompt\": \"Tackle this issue. Inspect the supplied issue context, do the work, and report the outcome.\" }\n  },\n  \"pages\": {\n    \"main\": {\n      \"root\": \"issuesTable\",\n      \"elements\": {\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [{ \"key\": \"title\", \"label\": \"Issue\" }],\n            \"rowActions\": [{\n              \"label\": \"Tackle\",\n              \"actions\": [{\n                \"action\": \"app.action\",\n                \"params\": { \"name\": \"tackle\", \"input\": { \"issue\": { \"$row\": \"\" } } }\n              }]\n            }]\n          }\n        }\n      }\n    }\n  },\n  \"defaultPage\": \"main\"\n}\n```\n\nFor direct MCP calls, `app-query` accepts `{ appId, query, params? }` and returns rows from that declared named query; every supplied param must be referenced by a `$param` filter in that query. Use it when an agent needs to read app state without scraping the UI.\n\nSaved scripts use the generated SDK name `ctx.swarm.app_query({ appId, query, params? })`. Use `app_query` in scripts or workflows that turn current app rows into reports, digests, or follow-up work. Saved scripts also get generated per-app types automatically: each app contributes an `App_<Name>` namespace with one row interface per model (enum columns as literal unions) and a typed `app_query` overload per named query, all visible via `script-query-types`. Actions stay REST-only from scripts — there is no SDK method to invoke them.\n\n### Pages, routes, and page trees\n\n`pages` is a map of independently validated page trees and `defaultPage` must name one entry. Each page may also declare a display `title` and typed route `params`. On every non-default page the runtime automatically renders breadcrumbs (`<default page title> › <current page title>`, first crumb navigates back) — including in chromeless embeds — so a detail page does NOT need its own back button; give pages good `title`s instead. This complete pattern connects a table row to a typed detail route and its parameterized query:\n\n```json\n{\n  \"models\": {\n    \"issue\": {\n      \"columns\": {\n        \"issueId\": { \"kind\": \"number\" },\n        \"title\": { \"kind\": \"string\" },\n        \"status\": { \"kind\": \"string\" }\n      }\n    }\n  },\n  \"queries\": {\n    \"allIssues\": { \"model\": \"issue\" },\n    \"issueDetail\": {\n      \"model\": \"issue\",\n      \"filter\": { \"issueId\": { \"$param\": \"issueId\" } },\n      \"limit\": 1\n    }\n  },\n  \"pages\": {\n    \"issues\": {\n      \"title\": \"Issues\",\n      \"root\": \"issuesTable\",\n      \"elements\": {\n        \"issuesTable\": {\n          \"type\": \"Table\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/allIssues/data\" },\n            \"columns\": [\n              { \"key\": \"title\", \"label\": \"Issue\" },\n              { \"key\": \"status\", \"label\": \"Status\", \"kind\": \"badge\" }\n            ],\n            \"rowActions\": [{\n              \"label\": \"Open\",\n              \"actions\": [{\n                \"action\": \"app.navigate\",\n                \"params\": {\n                  \"page\": \"detail\",\n                  \"params\": { \"issueId\": { \"$row\": \"issueId\" } }\n                }\n              }]\n            }]\n          }\n        }\n      }\n    },\n    \"detail\": {\n      \"title\": \"Issue detail\",\n      \"params\": { \"issueId\": { \"kind\": \"number\", \"required\": true } },\n      \"root\": \"detail\",\n      \"elements\": {\n        \"detail\": {\n          \"type\": \"DetailList\",\n          \"props\": {\n            \"data\": { \"$state\": \"/queries/issueDetail/data/0\" },\n            \"fields\": [{ \"key\": \"title\", \"label\": \"Issue\" }]\n          }\n        }\n      }\n    }\n  },\n  \"defaultPage\": \"issues\"\n}\n```\n\nDrawer variant: declare a route param on the containing page, set the Drawer `props.param` to that literal param name, and use the same `app.navigate` shape targeting that page with the row id assigned to the Drawer's param. The Drawer then opens from route state without a separate action contract.\n\nParam `kind` is `string` by default, or `number` / `boolean`; `required` defaults to false. The names `mode`, `apiUrl`, `apiKey`, `email`, and `name` are reserved. `/apps/<id>` renders `defaultPage`; `/apps/<id>/p/<page>?issueId=42` is the shareable deep link for another page. Browser navigation is client-side, so app state and polled data stay warm across page changes.\n\nWithin each page, `root` names one entry in its non-empty `elements` map. Elements are a flat, single-parent tree: ids are map keys, `children` contains ids (not nested elements), all elements must be reachable from `root`, and cycles, missing children, or shared children are invalid. Element and Form/UI ids are page-local. Element keys are `type`, `props`, `children`, `on`, `visible`, `repeat`, and `watch`; only components with a `default` child slot accept `children` (Stack, Grid, Split, Tabs, Container, Card, Section, and Drawer). `watch` maps state paths to an action step or chain.\n\n## Component catalog (all 33)\n\nProps reject unknown keys. A `{\"$state\":\"...\"}` binding may replace a literal prop value at any depth.\n\nIcons: every `icon` prop (and the `Icon` block) takes one name from a curated lucide set: `plus`, `refresh-cw`, `search`, `filter`, `download`, `upload`, `external-link`, `copy`, `check`, `x`, `trash-2`, `pencil`, `eye`, `calendar`, `clock`, `user`, `users`, `bot`, `git-pull-request`, `git-branch`, `github`, `slack`, `mail`, `link`, `file-text`, `folder`, `database`, `zap`, `sparkles`, `flag`, `star`, `tag`, `alert-triangle`, `info`, `circle-check`, `trending-up`, `trending-down`, `dollar-sign`, `activity`, `rocket`. Any other name is rejected.\n\nTones: Badge, Metric and Progress `tone` take `neutral`, `success`, `active`, `error`, `info`, `pending`, `warning`, or `paused`.\n\n| Component | Required props | Optional props / values |\n|---|---|---|\n| `Stack` | none | Primary layout; `direction: \"column\", \"row\"`, `gap`, `padding: \"none\", \"xs\", \"sm\", \"md\", \"lg\", \"xl\"`; `align: \"start\", \"center\", \"end\", \"stretch\"`, `justify: \"start\", \"center\", \"end\", \"between\"`, `wrap`; `motion: \"rise\"` (default), `\"fade\"`, or `\"none\"` (see Motion below); has the `default` child slot. |\n| `Grid` | none | Responsive `columns`: integer 1 through 6, or `{ base, sm, md, lg }` counts 1 through 6; `gap` uses the Stack spacing values; has the `default` child slot. |\n| `Split` | none | `ratio: \"1-1\", \"1-2\", \"2-1\", \"1-3\", \"3-1\"`, `gap`, `collapseBelow: \"sm\", \"md\", \"lg\"`, `reverse`; has the positional `default` child slot. |\n| `Divider` | none | `label`; no children. |\n| `Tabs` | `id`, `tabs` | `tabs` entries are `{ key, label?, icon?, count? }` (`count` is a number shown as a small pill); `defaultTab`; `variant: \"line\"` (default) or `\"segmented\"` (a compact segmented control, same state and warm panels); has the positional `default` child slot. |\n| `Container` | none | Legacy layout primitive; prefer Stack. `direction: \"row\", \"column\"`, `gap: \"none\", \"sm\", \"md\", \"lg\"`; has the `default` child slot. |\n| `Card` | none | `title`, `description`; has the `default` child slot. |\n| `Heading` | `text` | `level: \"h1\", \"h2\", or \"h3\"`. |\n| `Text` | `content` | `tone: \"default\" or \"muted\"`. |\n| `Markdown` | `content` | Rendered Markdown for help, instructions, and rich prose; no children. |\n| `SearchInput` | `id` | `placeholder`, `label`, `shortcut` (one key, usually `\"/\"`: shows a keycap and focuses the field); writes debounced text to `/ui/<id>/value`; no children. |\n| `Select` | `id`, `options` | `options` are strings or `{ value, label?, icon?, hint? }`; `placeholder`, `label`, `clearable`, `searchable` (type to filter; on by default past 8 options), `searchPlaceholder`, `multiple`; writes a string or null to `/ui/<id>/value`, or with `multiple` a string array (empty = nothing picked); no children. |\n| `Chips` | `id`, `options` | Toggle chips for quick filters. `options` are strings or `{ value, label?, icon? }`; `multiple`; `label` (group name for screen readers). Writes a string or null to `/ui/<id>/value`, or a string array with `multiple`; pressing the selected chip clears it. |\n| `Button` | `label` | `variant: \"default\", \"secondary\", \"outline\", \"ghost\", \"destructive\", or \"destructive-outline\"` (use `destructive-outline` for standalone deletes); `disabled` (constant or bound boolean); `busyWith: \"<actionName>\"` swaps the label for a spinner while that custom action's `/actions/<name>/status` is `\"running\"` (presses are ignored), then shows a check and `successLabel` for about 1.5s when it turns `\"ok\"`; `icon`, `iconPosition: \"start\" or \"end\"`; `size: \"sm\", \"default\", or \"lg\"`; `shortcut` (one key, shown as a keycap, presses the button); `hint` (tooltip); dispatch with element-level `on.press`. |\n| `Metric` | `label`, `value` | The dashboard stat tile. `value` is string or number (empty renders an em dash); bind `loading` to `/queries/<name>/loading` for a skeleton while the query loads; `icon` with `tone` tinting its tile; `detail` (a line under the value); `trend: { direction: \"up\", \"down\", or \"flat\", label }`; `info` (explanation tooltip next to the label). |\n| `Alert` | `message` | `title`, `tone: \"info\", \"success\", \"warning\", or \"error\"`, `icon` (overrides the tone icon), `actionLabel` (a button inside the callout that emits `press`; wire it with `on.press`). |\n| `Badge` | `text` | `text` is string or number; `tone`; `icon` replaces the dot; `variant: \"tag\"` (default uppercase chip), `\"status\"` (sentence-case pill), `\"count\"` (numeric pill), or `\"beta\"` (the BETA tag); `status` (a lifecycle value renders the dashboard status chip); `hint` (tooltip; the beta tag's explanation). |\n| `Icon` | `name` | `size: \"sm\", \"md\", or \"lg\"`, `tone: \"default\", \"muted\", \"success\", \"warning\", \"error\", or \"info\"`, `label` (accessible name; decorative without it). |\n| `Progress` | `value` | `max` (default 100), `tone`, `label`, `variant: \"bar\"` (default) or `\"ring\"` (the dashboard progress ring; ignores `tone`), `showValue` (default true: percent for a bar, `value / max` for a ring). |\n| `EmptyState` | `title` | `icon` (default inbox), `body`, `actionLabel` (a button that emits `press`; wire it with `on.press`). |\n| `CopyButton` | `value` | `value` is string or number; `label` is the visible text, icon-only without it. Renders nothing for an empty value. |\n| `Kbd` | `keys` | Keycaps, one per string (`[\"⌘\", \"K\"]`). Display only. |\n| `Skeleton` | `shape` | `shape: \"line\", \"block\", \"rows\", \"metric\", or \"card\"`; `count` (1-20: lines, rows, tiles, or cards); `height` (px, `block` only, default 128). Show it with `visible` bound to a query's `loading`. |\n| `Spinner` | none | `variant: \"ring\", \"ellipsis\", or \"bars\"` (default: the dashboard spinner), `size: \"sm\" or \"md\"`, `label` (visible text and accessible name). |\n| `AvatarStack` | `users` | `users` are display names (initials avatars); `max` (default 4) before a `+N` count. Hover lists every name. |\n| `Section` | `title` | `description`, `collapsible`, `defaultOpen` (default true); has the `default` child slot. |\n| `Table` | `columns` | `data`, `loading`, `error`, `emptyMessage`, `emptyState`, `rowActions`, `onRowClick`, `selectedId`, `rowId`, `mobile`, `mobileFields`, `search`, `filters`; see below. |\n| `Form` | `id`, `fields`, `onSubmit` | `title`, `submitLabel`; see below. |\n| `Drawer` | `param` | `title`, `description`, `side: \"right\" or \"left\"`, `size: \"sm\", \"md\" (default), \"lg\", or \"xl\"` (about 480/660/900/1010px at 1440px; grows with the viewport up to 640/960/1280/1600px; full width on phones), `actions` (sticky footer buttons; see below); has the `default` child slot. |\n| `DetailList` | `fields` | `data`, `emptyMessage`, `columns: 1 or 2`, `loading` (bind `/queries/<name>/loading` for skeleton fields while loading); renders one record without edit controls; see below for field kinds. |\n| `Kanban` | `columnField`, `columns`, `titleField` | `data`, `loading`, `cardFields`, `idField` (default `id`), `onMove`, `onCardClick`; see below. |\n| `Calendar` | `startField`, `titleField` | `data`, `loading`, `endField`, `idField`, `onSelect`; read-only month grid; see below. |\n| `ContributionGraph` | none | `data`, `loading`, `dateField` (default `date`), `countField`, `days` (7-730, default 365); read-only activity heatmap. |\n\nTable details:\n\n- `columns[]`: `{ key, label?, kind?, tones?: {value: badgeTone}, width?: number, pinned?: \"left\" or \"right\", align?: \"start\" or \"end\", truncate?: \"end\" or \"middle\", icon?, tooltip?: \"<row field>\", max?: number, onChange?: chain }`. `kind` is `text`, `string`, `enum`, `number`, `boolean`, `date`, `badge`, `status`, `user`, `agent`, `relative`, `duration`, `progress`, `copy`, `switch`, or `link`; `string` and `enum` render as text. Pin id/actions columns so they survive horizontal scroll on narrow viewports.\n  - `status`: lifecycle values (`pending`, `in_progress`, `running`, `completed`, `failed`, `cancelled`, `paused`, `reviewing`, ...) render the dashboard status chip with its icon; other values use `tones` like `badge`.\n  - `user` / `agent`: avatar plus name. `relative` (and `date`): smart time, exact time on hover. `duration`: milliseconds as `1m 23s`. `progress`: a bar against `max` (default 100). `copy`: the value plus a copy button. `link`: an http(s) URL opening in a new tab (other values render as text).\n  - `switch`: a toggle. `onChange` runs with `$row` = the row with this column already set to the new value, e.g. `[{ \"action\": \"app.mutate\", \"params\": { \"model\": \"m\", \"op\": \"update\", \"rowId\": { \"$row\": \"id\" }, \"values\": { \"enabled\": { \"$row\": \"enabled\" } } } }]`. Without `onChange` the switch is read-only.\n  - Numbers, durations and progress right-align by default. `truncate: \"middle\"` keeps both ends of ids and paths. `icon` shows in the header; `tooltip` names a row field shown on hover.\n- `onRowClick`: action chain with `$row` / `$rowIndex`, run when a row is clicked (or Enter on a focused cell). Pair it with `app.navigate` that sets a Drawer param, and bind `selectedId` to `{ \"$state\": \"/route/params/<param>\" }` so the open row stays highlighted. `rowId` names the id field (default `id`).\n- Phones (below 768px): the table renders as a card list. `mobileFields: { title, subtitle?, meta?: string or string[], status? }` picks the columns; by default the first text column is the title and the first `status`/`badge` column the chip. `mobile: \"scroll\"` keeps the grid; it is the default when the table has `rowActions` but no `onRowClick`.\n- `emptyState: { icon?, title, body? }` replaces the plain empty message. A search or filter that hides every row shows its own \"No rows match\" state.\n- `pagination`: boolean; defaults to auto-enabling past 200 rows (set `false` to force one scroll region). `density: \"compact\"` tightens row height for dense readouts.\n- `rowActions[]`: `{ label, variant?, icon?, placement?: \"inline\" or \"menu\", confirm?, actions }`. `placement: \"menu\"` moves the action into the row's More menu. Variants add `destructive-outline` to the Button variants. `destructive` and `destructive-outline` confirm by default; customize with `{ \"title\": ..., \"description\": ..., \"confirmLabel\": ... }`, or use a bare `confirm` string as the dialog description (use `confirm: false` only for a reversible action).\n- `search`: optional string; case-insensitive substring matching across the listed string and number columns. Bind a SearchInput value for client-side search.\n- `filters`: optional record of per-column string, number, boolean, null, or array values. An array means \"the cell is one of these\" (what a `multiple` Chips or Select writes). Null, empty strings, empty arrays, or absent values disable one filter. Bind Select or Chips values for client-side filters.\n\nKanban details:\n\n- One card per `data` row, grouped by the row's `columnField` value. `columns[]` are plain strings or `{ id, label? }`, in display order; rows matching no column are hidden.\n- `cardFields[]` uses the DetailList field shape (`{ key, label?, kind?, tones? }`, same kinds) for extra lines under the title.\n- `onMove` is an action chain run when a card is dropped in another column. `$row` is the moved row with `columnField` already set to the new column: `[{ \"action\": \"app.mutate\", \"params\": { \"model\": \"deal\", \"op\": \"update\", \"rowId\": { \"$row\": \"id\" }, \"values\": { \"stage\": { \"$row\": \"stage\" } } } }]`. Without `onMove`, cards cannot be dragged.\n- `onCardClick` is an action chain with `$row`; pair it with `app.navigate` and a `Drawer` to open a card.\n\nCalendar details:\n\n- `startField` / `endField` hold ISO dates, ISO datetimes, or epoch ms. An event shows on every day from start to end; without `endField` it shows on its start day.\n- Each Calendar keeps its own visible month (prev/next controls in its header). `onSelect` is an action chain with `$row`, run when an event is clicked.\n\nContributionGraph details:\n\n- Buckets `data` rows by the calendar day of `dateField` over the trailing `days`. Each row counts 1, or adds its numeric `countField` when set.\n\nForm details:\n\n- `fields[]`: `{ name, label?, kind?, options?: string[], placeholder?, required? }`; `kind` is `string`, `text`, `number`, `boolean`, `date`, or `enum`, and enum fields need `options`.\n- Values live at `/forms/<formId>/<fieldName>`. `onSubmit` is an action chain.\n- The submit button shows a pending spinner while the chain runs, and `app.mutate` failures in the chain render inline under the fields (not the page banner) — no extra wiring needed.\n\nDrawer details:\n\n- `param` must name a param declared on the containing page. The drawer is open exactly when `/route/params/<param>` has a non-empty value, so its open state survives refresh and is shareable. Its children mount only while open; closing it clears that param with history replacement.\n- `actions[]`: `{ label, variant?, icon?, confirm?, actions }`, rendered as buttons in a sticky footer under the scrolling body. Confirmation follows Table `rowActions`: destructive variants confirm by default, and a chain with an `app.mutate` delete always confirms. Chains have no `$row`; address the open record with `{ \"$state\": \"/route/params/<param>\" }`, for example `{ \"action\": \"app.mutate\", \"params\": { \"model\": \"order\", \"op\": \"delete\", \"rowId\": { \"$state\": \"/route/params/panel\" } } }`. Prev/next record navigation is not available.\n\nDetailList details:\n\n- `fields[]`: `{ key, label?, kind?, tones? }`. Kinds reuse Table formatting (`text`, `string`, `number`, `boolean`, `date`, `badge`, `enum`) and the Table cell renderers (`status`: lifecycle chip or `tones` pill; `user`: avatar plus name; `relative`: smart time, exact on hover; `copy`: value plus copy button), and add `code` for a monospace block and `json` for a collapsible JSON tree (objects, or a string holding JSON). Bind `data` to one record, commonly `/queries/<detailQuery>/data/0`.\n\nMotion details:\n\n- Every `Stack` fades its direct children in and lifts them 4px over 200ms on first paint, staggered 30ms (capped at the 10th child). It never replays on the 5s data poll. A Stack nested inside another one does not add its own entrance. `motion: \"fade\"` drops the lift; `motion: \"none\"` turns it off. Viewers with reduced motion get a 150ms fade.\n\nShortcut details:\n\n- `Button.shortcut` and `SearchInput.shortcut` are one key. Letters and digits match without Shift; symbols such as `/` and `?` match as typed. They do nothing while focus is in a text field, while Ctrl, Cmd, or Alt is held, or while a dialog or menu is open (unless the control is inside it, such as a Button in an open Drawer).\n\n## Layout & interactivity\n\nUse `Stack` as the primary page and section layout; `Container` is the legacy two-prop primitive retained for existing pages. Stack supports vertical or horizontal flow, shared spacing, alignment, justification, wrapping, and padding; row Stacks (filter bars, button rows) should set `collapseBelow: \"sm\"|\"md\"|\"lg\"` so they stack vertically on phones. Use `Grid` for responsive card or metric strips: a bare column count is responsive shorthand (1 column on phones, 2 from `sm`, the count from `md` up), or pin breakpoints explicitly with `{ \"base\": 1, \"md\": 2, \"lg\": 3 }`. `Grid` and `Split` also accept `padding` on the shared spacing scale.\n\n`Split` and `Tabs` children are positional. For Split, `children[0]` is the first pane, `children[1]` is the second, and extra children append inside the second pane. Below `collapseBelow`, panes stack; `reverse` changes only that narrow-layout stacking order. For Tabs, `children[i]` is the body for `tabs[i]`; keep both arrays in the same order and with the same count. Inactive tab children stay mounted but hidden, so Tables keep polling. Use `Divider` to separate sections and `Markdown` for richer explanatory content.\n\nSearchInput, Select, and Chips are client-side controls: each needs a literal `id` and writes state under `/ui/<id>/value`; Tabs writes its active key to `/ui/<id>/tab`. Bind those values into a Table's `search` and `filters` props. This filters already-polled rows locally; it does not alter or re-run the named query.\n\n```json\n{\n  \"filters\": { \"type\": \"Stack\", \"props\": { \"gap\": \"sm\" }, \"children\": [\"query\", \"status\"] },\n  \"query\": { \"type\": \"SearchInput\", \"props\": { \"id\": \"ideaSearch\", \"placeholder\": \"Search ideas\" } },\n  \"status\": { \"type\": \"Select\", \"props\": { \"id\": \"ideaStatus\", \"options\": [\"open\", \"done\"] } },\n  \"ideas\": {\n    \"type\": \"Table\",\n    \"props\": {\n      \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n      \"columns\": [{ \"key\": \"title\" }, { \"key\": \"status\" }],\n      \"search\": { \"$state\": \"/ui/ideaSearch/value\" },\n      \"filters\": { \"status\": { \"$state\": \"/ui/ideaStatus/value\" } }\n    }\n  }\n}\n```\n\n`visible` accepts a boolean, a `$state` truthiness binding, comparisons, and logical groups. Put exactly one comparison key in each condition object. The renderer evaluates the first matching key in fixed priority order (`eq`, `neq`, `gt`, `gte`, `lt`, `lte`; otherwise truthiness), so additional comparison keys in the same object are ignored. Use `$and` / `$or` arrays to combine conditions. `not` is a negation FLAG inside a condition object (`\"not\": true`), never a wrapper around one — `{ \"not\": { \"$state\": … } }` is invalid and the validator rejects it. The absent-record pattern (e.g. an alert when a detail query matched nothing) is `{ \"$state\": \"/queries/<q>/data/0/id\", \"not\": true }`:\n\n```json\n[\n  { \"$state\": \"/route/params/issueId\", \"gt\": 0 },\n  {\n    \"$and\": [\n      { \"$state\": \"/route/page\", \"eq\": \"detail\" },\n      { \"$state\": \"/route/params/panel\", \"neq\": \"hidden\" }\n    ]\n  }\n]\n```\n\n## Bindings, sentinels, and action chains\n\nUse this exact query binding shape; do not invent `$query`, `$item`, or template strings:\n\n```json\n{\n  \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n  \"loading\": { \"$state\": \"/queries/allIdeas/loading\" },\n  \"error\": { \"$state\": \"/queries/allIdeas/error\" }\n}\n```\n\nValid `$state` roots are:\n\n- `/queries/<declaredQuery>/...`\n- `/forms/<formId>/...`, where a `Form` element has that literal `props.id`\n- `/ui/<id>/...`, where a SearchInput, Select, Chips, or Tabs element has that literal `props.id` (SearchInput, Select, and Chips use `/value`; Tabs uses `/tab`)\n- `/actions/<declaredAction>/...`\n- `/route/page` for the active page name\n- `/route/params/<declaredParam>` for a param declared on the current page\n\n`/route` is mirrored as `{ page, params }`. Only declared params appear. Values are coerced by their declared kind: `number` becomes a number when possible; boolean strings `true`/`1` become true; failed number coercion remains the raw string.\n\nOnly inside action-chain `params` (`on.<event>`, `Table.rowActions[].actions`, or `Form.onSubmit`) these scoped sentinels are valid, recursively inside objects and arrays:\n\n| Sentinel | Resolves to |\n|---|---|\n| `{ \"$row\": \"id\" }` | Current Table row's `id`; another column name selects that field. |\n| `{ \"$row\": \"\" }` | Entire current Table row. |\n| `{ \"$rowIndex\": true }` | Current Table row index. |\n| `{ \"$form\": \"title\" }` | One current Form value. |\n| `{ \"$form\": \"\" }` | All current Form values. |\n| `{ \"$state\": \"/queries/allIdeas/data\" }` | Current value at a valid app state path, including action state such as `/actions/refreshIssues/status`. |\n\nEach sentinel object must contain exactly the single key shown.\n\nAn action-chain step is `{ \"action\": \"<type>\", \"params\": {...} }`. Available action types:\n\n- `app.mutate`: `{ model, op, rowId?, values?, formId? }`, where `op` is `\"create\"`, `\"update\"`, or `\"delete\"`. `update`/`delete` require `rowId` (usually `{ \"$row\": \"id\" }`, or `{ \"$state\": \"/route/params/<param>\" }` in a Drawer footer); literal `values` keys must be model columns. Successful mutation refetches all queries on that model.\n- `app.refresh`: `{ query? }`; omit `query` to refetch all, or name a declared query.\n- `app.action`: `{ name, input? }`; `name` must be declared in definition `actions`. For a task-kind row action, pass whole-row context with `input: { issue: { \"$row\": \"\" } }`.\n- `app.navigate`: `{ page, params? }`; `page` must be declared, supplied keys must be params of the target page, and every required target param must be supplied. `params` replace the current route params wholesale and may contain action sentinels. Navigation pushes history, so browser Back returns to the previous page/params; only `mode` is preserved automatically.\n- `ui.toast`: `{ message, description?, tone?, undo? }`, where `tone` is `\"success\"`, `\"error\"`, `\"info\"` (default), or `\"warning\"`. `undo: { label?, actions }` adds an Undo button (default label `Undo`) that runs `actions` as a chain; its steps are validated like any chain. Put it after the step it confirms, e.g. a row delete followed by `{ \"action\": \"ui.toast\", \"params\": { \"message\": \"Order deleted\", \"undo\": { \"actions\": [{ \"action\": \"app.mutate\", \"params\": { \"model\": \"order\", \"op\": \"create\", \"values\": { \"title\": { \"$row\": \"title\" } } } }] } } }`. Undo params resolve `$state` when Undo is pressed; `$row` / `$form` resolve when the toast is shown.\n- `swarm.sdk`: `{ sdk, args? }`; invokes a catalog-supported Swarm browser SDK method with the viewer's bearer.\n- `swarm.call`: `{ method, endpoint: \"/api/...\", body? }`, where `method` is `\"GET\"`, `\"POST\"`, `\"PUT\"`, `\"DELETE\"`, or `\"PATCH\"`; raw authenticated API call.\n\n## Patch semantics\n\n`app-patch.definition` is RFC 7396 JSON Merge Patch applied to the stored definition:\n\n- omitted keys stay unchanged;\n- object keys merge recursively;\n- arrays and scalar values replace;\n- `null` deletes a key;\n- reusable-element disambiguation: a patch value for `elements.<name>` containing ONLY the `elements` key merges node-by-node; any other key present (`mode`, `root`, `props`, or `export`) makes it a full element replace — restate every field you want kept. In that node-by-node form, `elements.<name>.elements.<id>: null` deletes one node. Literal null nodes are rejected in a full element replace so they cannot be mistaken for deletions.\n- otherwise every supplied `pages.<page>.elements.<id>`, `pages.<page>.params.<param>`, `actions.<name>`, `models.<name>.columns.<col>`, and `models.<name>.sources.<src>` value is atomic and replaces that complete declaration; `null` deletes it (deleting a source detaches its rows — see the source lifecycle above).\n\n`pages.<page>: null` deletes a page, except the current `defaultPage` cannot be deleted. `root`, `title`, and top-level `defaultPage` use ordinary merge semantics. A top-level `page` patch is rejected with guidance to patch `pages.<name>` instead.\n\nBecause elements, param declarations, actions, and columns are atomic, include the complete desired object when changing one. For example, changing only a Table's `emptyMessage` requires sending its full `{ \"type\": \"Table\", \"props\": ... }` element. The merged result is validated as a whole; on failure, read `issues[]`, correct the paths, and retry without assuming anything was written.\n\n```json\n{\n  \"appId\": \"<app-id>\",\n  \"description\": null,\n  \"definition\": {\n    \"models\": {\n      \"idea\": {\n        \"columns\": {\n          \"priority\": { \"kind\": \"enum\", \"enum\": [\"low\", \"high\"], \"default\": \"low\" }\n        }\n      }\n    },\n    \"queries\": { \"openIdeas\": null },\n    \"pages\": {\n      \"main\": {\n        \"elements\": {\n          \"title\": { \"type\": \"Heading\", \"props\": { \"text\": \"Prioritized ideas\", \"level\": \"h1\" } }\n        }\n      }\n    }\n  }\n}\n```\n\n## Worked example: ideas tracker\n\nCreate this with `app-upsert`:\n\n```json\n{\n  \"name\": \"Ideas Tracker\",\n  \"description\": \"Collect and manage product ideas\",\n  \"definition\": {\n    \"models\": {\n      \"idea\": {\n        \"columns\": {\n          \"title\": { \"kind\": \"string\", \"required\": true },\n          \"status\": { \"kind\": \"enum\", \"enum\": [\"open\", \"done\"], \"default\": \"open\" }\n        }\n      }\n    },\n    \"queries\": {\n      \"allIdeas\": { \"model\": \"idea\", \"sort\": { \"column\": \"createdAt\", \"dir\": \"desc\" } }\n    },\n    \"actions\": {\n      \"triage\": { \"kind\": \"task\", \"prompt\": \"Review current ideas and recommend the next one to pursue\" }\n    },\n    \"pages\": {\n      \"main\": {\n        \"root\": \"root\",\n        \"elements\": {\n          \"root\": {\n            \"type\": \"Container\",\n            \"props\": { \"direction\": \"column\", \"gap\": \"lg\" },\n            \"children\": [\"heading\", \"formCard\", \"ideasCard\", \"triage\"]\n          },\n          \"heading\": { \"type\": \"Heading\", \"props\": { \"text\": \"Ideas\", \"level\": \"h1\" } },\n          \"formCard\": {\n            \"type\": \"Card\",\n            \"props\": { \"title\": \"Add an idea\" },\n            \"children\": [\"ideaForm\"]\n          },\n          \"ideaForm\": {\n            \"type\": \"Form\",\n            \"props\": {\n              \"id\": \"newIdea\",\n              \"fields\": [{ \"name\": \"title\", \"label\": \"Title\", \"required\": true }],\n              \"submitLabel\": \"Add\",\n              \"onSubmit\": [{\n                \"action\": \"app.mutate\",\n                \"params\": { \"model\": \"idea\", \"op\": \"create\", \"values\": { \"$form\": \"\" } }\n              }]\n            }\n          },\n          \"ideasCard\": {\n            \"type\": \"Card\",\n            \"props\": { \"title\": \"All ideas\" },\n            \"children\": [\"ideasTable\"]\n          },\n          \"ideasTable\": {\n            \"type\": \"Table\",\n            \"props\": {\n              \"data\": { \"$state\": \"/queries/allIdeas/data\" },\n              \"loading\": { \"$state\": \"/queries/allIdeas/loading\" },\n              \"error\": { \"$state\": \"/queries/allIdeas/error\" },\n              \"columns\": [\n                { \"key\": \"title\", \"label\": \"Title\" },\n                { \"key\": \"status\", \"label\": \"Status\", \"kind\": \"badge\", \"tones\": { \"open\": \"info\", \"done\": \"success\" } }\n              ],\n              \"rowActions\": [{\n                \"label\": \"Delete\",\n                \"variant\": \"destructive-outline\",\n                \"actions\": [{ \"action\": \"app.mutate\", \"params\": { \"model\": \"idea\", \"op\": \"delete\", \"rowId\": { \"$row\": \"id\" } } }]\n              }]\n            }\n          },\n          \"triage\": {\n            \"type\": \"Button\",\n            \"props\": { \"label\": \"Ask swarm to triage\", \"variant\": \"secondary\" },\n            \"on\": { \"press\": [{ \"action\": \"app.action\", \"params\": { \"name\": \"triage\" } }] }\n          }\n        }\n      }\n    },\n    \"defaultPage\": \"main\"\n  }\n}\n```\n\nThe tool returns `{ appId, url: \"/apps/<id>\" }`. Open that URL to verify the live UI, then continue with the read-patch-validate loop above.\n\n## View and screenshot a live app\n\n- An app renders at `<dashboard>/apps/<id>`. Two view modes are set by query string: `?mode=full` (full-viewport overlay with a slim header) and `?mode=chromeless` (only the rendered page, the embed surface). `app.navigate` keeps only `?mode`.\n- Logged-in browser: a fresh dashboard has no connection and redirects to /setup. Seed the localStorage key `agent-swarm-connections` with `{connections:[{id,name,apiUrl,apiKey}],activeId}`. Build the value from an env var and pipe it to `agent-browser eval --stdin`, so the key never reaches a command line. Reload, then pick a user in the \"Who are you?\" dialog.\n- Apps scroll inside an inner canvas, so a full-page screenshot captures only the viewport. Scroll the canvas or raise the viewport height. For mobile, set a 375px-wide viewport before the screenshot.\n- App definitions: `GET /api/apps` and `GET /api/apps/<id>` with the API key as Bearer.\n";
 
 // templates/skills/ask-user/config.json
-var config_default4 = `{
+var config_default3 = `{
   "category": "skills",
   "description": "Conventions for asking the user questions during a workflow via the AskUserQuestion tool. Other skills reference this to keep prompts consistent and structured.",
   "displayName": "Ask User",
@@ -6143,7 +5787,7 @@ var config_default4 = `{
 `;
 
 // templates/skills/ask-user/content.md
-var content_default4 = `# Ask User
+var content_default3 = `# Ask User
 
 Thin helper that codifies how to ask the user questions during a workflow. Other skills (planning, research, brainstorming, implementing) reference this skill instead of duplicating AskUserQuestion conventions.
 
@@ -6219,7 +5863,7 @@ options:
 `;
 
 // templates/skills/asset-namespaces/config.json
-var config_default5 = `{
+var config_default4 = `{
   "kind": "skill",
   "name": "asset-namespaces",
   "displayName": "Asset Namespaces",
@@ -6236,10 +5880,10 @@ var config_default5 = `{
 `;
 
 // templates/skills/asset-namespaces/content.md
-var content_default5 = "# Asset Namespaces\n\nUse an asset `key` as directory-like grouping metadata across tasks, workflows, schedules, pages, apps, scripts, and mapped provider files. Keep identity separate: entity IDs remain authoritative, task `contextKey` remains routing context, and many assets may intentionally share one key.\n\n## Choose a namespace\n\n- Use `shared/` for general work and stable descendants such as `shared/releases/` or `shared/platform/migrations/` for team-visible groupings.\n- Use `personal/<user-id>/` or a descendant only for work owned by the trusted resolved user in the current request or task context.\n- Prefer durable organizational paths over temporary status labels. Put lifecycle state in task or workflow status fields, not paths such as `shared/in-progress/`.\n- Supply canonical values: lowercase relative paths, forward slashes, and a trailing slash. The server trims, Unicode-normalizes, lowercases, and adds the trailing slash, but rejects empty segments, `.`, `..`, backslashes, absolute paths, NUL bytes, unknown roots, and values longer than 255 characters.\n\n`personal/` is a write-ownership convention, **not** a privacy or read-visibility boundary. Continue to rely on each entity's authorization rules, and never place sensitive data under `personal/` merely because of the key.\n\n## Set and inherit keys\n\nPass `key` when creating a task, workflow, schedule, or page. Omitting it creates a deterministic shared resource key such as `shared/task:<id>/`, `shared/workflow:<id>/`, `shared/schedule:<id>/`, `shared/page:<id>/`, or `shared/fs:agent-fs:<id>/`.\n\n- Tasks sent from another task inherit the source task's key unless explicitly overridden.\n- Tasks launched by a workflow inherit the workflow key unless the agent-task node supplies a key.\n- Tasks launched by a schedule inherit the schedule key.\n- Agent-fs task attachments receive logical file mappings and inherit their task key.\n\nUse only a canonical user-registry ID in `personal/<user-id>/`. Do not substitute an agent ID, email address, Slack ID, or unverified caller-provided value. The API authorizes the destination against trusted request/task context and rejects mismatches.\n\n## Find and manage assets\n\nUse entity list tools with `key` for an exact namespace or `keyPrefix` for a subtree where those filters are exposed. For a lightweight cross-entity view, use `GET /api/assets` or the public page SDK:\n\n```js\nconst result = await window.swarmSdk.assets.list({\n  keyPrefix: \"shared/releases/\",\n  types: \"task,workflow,schedule,page,app,script,file\",\n  limit: 100,\n});\n```\n\nMove an asset logically without changing its ID:\n\n```js\nawait window.swarmSdk.assets.move(\"workflow\", workflowId, \"shared/platform/\");\n```\n\nThe full `swarmSdk.assets` domain is:\n\n| Method | Purpose |\n|---|---|\n| `list(filters?)` | Return lightweight cross-entity summaries. |\n| `move(entityType, id, key)` | Change local namespace metadata. |\n| `registerMapping(body)` | Operator-only registration of a provider object under a logical key. |\n| `audit()` | Operator-only structural and mapping-drift audit. |\n\nProvider-backed moves are metadata-only: do not claim that a provider file, drive object, or agent-fs path was renamed or moved remotely. Repair audit warnings before retrying a blocked move.\n\n## Before writing\n\n1. Confirm whether the grouping is shared or owned by a resolved user.\n2. Keep the key non-unique and separate from entity identity or routing context.\n3. Pass the key at the highest-level parent so descendants inherit it.\n4. Use exact and prefix filters instead of scanning unrelated records.\n5. Treat personal namespaces and provider mappings according to their real authorization and remote-move limits.\n";
+var content_default4 = "# Asset Namespaces\n\nUse an asset `key` as directory-like grouping metadata across tasks, workflows, schedules, pages, apps, scripts, and mapped provider files. Keep identity separate: entity IDs remain authoritative, task `contextKey` remains routing context, and many assets may intentionally share one key.\n\n## Choose a namespace\n\n- Use `shared/` for general work and stable descendants such as `shared/releases/` or `shared/platform/migrations/` for team-visible groupings.\n- Use `personal/<user-id>/` or a descendant only for work owned by the trusted resolved user in the current request or task context.\n- Prefer durable organizational paths over temporary status labels. Put lifecycle state in task or workflow status fields, not paths such as `shared/in-progress/`.\n- Supply canonical values: lowercase relative paths, forward slashes, and a trailing slash. The server trims, Unicode-normalizes, lowercases, and adds the trailing slash, but rejects empty segments, `.`, `..`, backslashes, absolute paths, NUL bytes, unknown roots, and values longer than 255 characters.\n\n`personal/` is a write-ownership convention, **not** a privacy or read-visibility boundary. Continue to rely on each entity's authorization rules, and never place sensitive data under `personal/` merely because of the key.\n\n## Set and inherit keys\n\nPass `key` when creating a task, workflow, schedule, or page. Omitting it creates a deterministic shared resource key such as `shared/task:<id>/`, `shared/workflow:<id>/`, `shared/schedule:<id>/`, `shared/page:<id>/`, or `shared/fs:agent-fs:<id>/`.\n\n- Tasks sent from another task inherit the source task's key unless explicitly overridden.\n- Tasks launched by a workflow inherit the workflow key unless the agent-task node supplies a key.\n- Tasks launched by a schedule inherit the schedule key.\n- Agent-fs task attachments receive logical file mappings and inherit their task key.\n\nUse only a canonical user-registry ID in `personal/<user-id>/`. Do not substitute an agent ID, email address, Slack ID, or unverified caller-provided value. The API authorizes the destination against trusted request/task context and rejects mismatches.\n\n## Find and manage assets\n\nUse entity list tools with `key` for an exact namespace or `keyPrefix` for a subtree where those filters are exposed. For a lightweight cross-entity view, use `GET /api/assets` or the public page SDK:\n\n```js\nconst result = await window.swarmSdk.assets.list({\n  keyPrefix: \"shared/releases/\",\n  types: \"task,workflow,schedule,page,app,script,file\",\n  limit: 100,\n});\n```\n\nMove an asset logically without changing its ID:\n\n```js\nawait window.swarmSdk.assets.move(\"workflow\", workflowId, \"shared/platform/\");\n```\n\nThe full `swarmSdk.assets` domain is:\n\n| Method | Purpose |\n|---|---|\n| `list(filters?)` | Return lightweight cross-entity summaries. |\n| `move(entityType, id, key)` | Change local namespace metadata. |\n| `registerMapping(body)` | Operator-only registration of a provider object under a logical key. |\n| `audit()` | Operator-only structural and mapping-drift audit. |\n\nProvider-backed moves are metadata-only: do not claim that a provider file, drive object, or agent-fs path was renamed or moved remotely. Repair audit warnings before retrying a blocked move.\n\n## Before writing\n\n1. Confirm whether the grouping is shared or owned by a resolved user.\n2. Keep the key non-unique and separate from entity identity or routing context.\n3. Pass the key at the highest-level parent so descendants inherit it.\n4. Use exact and prefix filters instead of scanning unrelated records.\n5. Treat personal namespaces and provider mappings according to their real authorization and remote-move limits.\n";
 
 // templates/skills/attio-interaction/config.json
-var config_default6 = `{
+var config_default5 = `{
   "kind": "skill",
   "name": "attio-interaction",
   "displayName": "Attio Interaction",
@@ -6257,10 +5901,10 @@ var config_default6 = `{
 `;
 
 // templates/skills/attio-interaction/content.md
-var content_default6 = '# Attio Interaction (Read + Write)\n\nUse this skill to read and write your Attio CRM through the REST API v2. Every read or write is a direct API call; agent-swarm does not maintain a separate Attio sync.\n\n## TL;DR\n\n1. Resolve `ATTIO_API_KEY` from swarm config before making calls.\n2. Base URL: `https://api.attio.com/v2/`\n3. Use `Authorization: Bearer $ATTIO_API_KEY`, `Content-Type: application/json`, and `Accept: application/json`.\n4. Prefer upsert over create for People, Companies, and Deals: `PUT /v2/objects/{slug}/records` with `matching_attribute`.\n5. Rate limits: 100 reads/sec, 25 writes/sec. Pace write bursts to roughly 15-20/sec.\n6. Attribute values are arrays, even for scalar values: `[{ "value": 42 }]`, never `42`.\n\n## Authentication\n\n```bash\nATTIO_API_KEY=$(get-config key="ATTIO_API_KEY" includeSecrets=true)\n\ncurl -sS "https://api.attio.com/v2/objects" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json"\n```\n\nIf calls return `401`, re-fetch the key from config. If it still fails, notify the Lead; the key may need rotation. Do not retry silently.\n\n## Core object slugs\n\n| Object | API slug | Primary matching attribute |\n|---|---|---|\n| Companies | `companies` | `domains` |\n| People | `people` | `email_addresses` |\n| Deals | `deals` | Usually no global dedupe key; link to company/person records |\n\nCustom objects use their configured API slug. Discover them with `GET /v2/objects`.\n\n## Common operations\n\n### 1. Discover objects and slugs\n\n```bash\ncurl -sS "https://api.attio.com/v2/objects" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {slug: .api_slug, name: .title}\'\n```\n\n### 2. Query records with filters and pagination\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/objects/companies/records/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "filter": {\n      "stage": { "$not_equal": "Won" }\n    },\n    "limit": 100,\n    "offset": 0\n  }\' | jq \'.data[] | {record_id: .id.record_id, name: .values.name[0].value}\'\n```\n\nPaginate by increasing `offset` until `data` is empty. For no filter, omit the `filter` key.\n\n### 3. Get a single record\n\n```bash\ncurl -sS "https://api.attio.com/v2/objects/companies/records/{RECORD_ID}" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data.values\'\n```\n\n### 4. Upsert a company by domain\n\nUse `PUT` with `matching_attribute`. It creates if not found and updates if found, so it is safe to call repeatedly.\n\n```bash\ncurl -sS -X PUT "https://api.attio.com/v2/objects/companies/records" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "name": [{ "value": "Acme Corp" }],\n        "domains": [{ "domain": "acme.com" }],\n        "employee_count": [{ "value": 150 }]\n      }\n    },\n    "matching_attribute": "domains"\n  }\' | jq \'{record_id: .data.id.record_id}\'\n```\n\n### 5. Upsert a person by email\n\n```bash\ncurl -sS -X PUT "https://api.attio.com/v2/objects/people/records" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "name": [{ "first_name": "Jane", "last_name": "Doe" }],\n        "email_addresses": [{ "email_address": "jane@acme.com" }],\n        "job_title": [{ "value": "CTO" }]\n      }\n    },\n    "matching_attribute": "email_addresses"\n  }\' | jq \'{record_id: .data.id.record_id}\'\n```\n\nAn upsert returns HTTP `200` when it updates an existing record and `201` when it creates one. The response body has the same shape in both cases.\n\n### 6. Update specific attributes on an existing record\n\n```bash\ncurl -sS -X PATCH "https://api.attio.com/v2/objects/companies/records/{RECORD_ID}" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "icp_score": [{ "value": 85 }],\n        "icp_tier": [{ "value": "Tier 1" }]\n      }\n    }\n  }\'\n```\n\n### 7. Write a note to a record\n\nNotes are concise free-text entries linked to a record. Use them to preserve useful interaction context, enrichment findings, or an agent result that should remain visible in the CRM.\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/notes" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "parent_object": "companies",\n      "parent_record_id": "{RECORD_ID}",\n      "title": "Enrichment - 2026-06-02",\n      "content": "Employee count: 150. Funding stage: Series A. Tech stack: Node.js, React."\n    }\n  }\' | jq \'{note_id: .data.id.note_id}\'\n```\n\n### 8. Create a task linked to a record\n\n```bash\ncurl -sS "https://api.attio.com/v2/workspace_members" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {member_id: .id.workspace_member_id, name: .name, email: .email_address}\'\n\ncurl -sS -X POST "https://api.attio.com/v2/tasks" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "content": "Follow up - no contact in 21 days",\n      "is_completed": false,\n      "assignees": [\n        { "referenced_actor_type": "workspace-member", "referenced_actor_id": "{MEMBER_ID}" }\n      ],\n      "linked_records": [\n        { "target_object": "deals", "target_record_id": "{DEAL_RECORD_ID}" }\n      ]\n    }\n  }\' | jq \'{task_id: .data.id.task_id}\'\n```\n\n### 9. Post a comment on a record\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/comments" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "record": { "target_object": "companies", "target_record_id": "{RECORD_ID}" },\n      "content": [\n        { "type": "text", "text": "Possible duplicate of acme-corp-old - please review and merge." }\n      ]\n    }\n  }\' | jq \'{comment_id: .data.id.comment_id}\'\n```\n\n### 10. Query a list or pipeline view\n\n```bash\ncurl -sS "https://api.attio.com/v2/lists" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {list_id: .id.list_id, name: .title}\'\n\ncurl -sS -X POST "https://api.attio.com/v2/lists/{LIST_ID}/entries/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{ "limit": 100, "offset": 0 }\' \\\n  | jq \'.data[] | {entry_id: .id.entry_id, record_id: .record_id}\'\n```\n\n### 11. Global search across objects\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/records/search" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{ "query": "acme", "limit": 10 }\' \\\n  | jq \'.data[] | {object: .object_type, record_id: .id.record_id}\'\n```\n\n## Webhooks\n\nAttio delivers webhooks at least once. Payloads contain IDs only, so always re-fetch the full record via `GET` before acting.\n\nKey event types:\n\n- `record.created`, `record.updated`, `record.deleted`\n- `list-entry.created`, `list-entry.updated`, `list-entry.deleted`\n- `note.created`\n- `task.created`, `task.completed`\n\nWebhook timeout is 5 seconds. Respond `200` immediately and do async processing in a follow-up swarm task.\n\n## Rate limits\n\n| Operation | Hard limit | Safe working rate |\n|---|---|---|\n| Reads | 100 req/sec | ~80 req/sec |\n| Writes | 25 req/sec | ~15-20 req/sec |\n\nAdd `sleep 0.05` between write calls in loops. Attio does not provide a native batch endpoint for these operations.\n\n## Operational rules\n\n- Upsert first. Use `PUT /records` with `matching_attribute` for create-or-update. `POST /records` can create duplicates.\n- Re-fetch webhook records. Webhook payloads are event hints, not full source-of-truth records.\n- Values are arrays. Every attribute value must be wrapped in an array.\n- No merge endpoint. Attio has no API-level record merge; dedupe agents should flag duplicates as comments or tasks for human review.\n- Check config first. Fetch `ATTIO_API_KEY` via `get-config includeSecrets=true`; never hardcode it.\n\n## Error handling\n\n| Status | Likely cause | Action |\n|---|---|---|\n| 401 | API key invalid or expired | Re-fetch from config. If still failing, notify Lead for rotation. |\n| 403 | Key lacks permission | Check the Attio API key\'s workspace permissions. |\n| 404 | Wrong object slug or record ID | Re-discover slugs with `GET /v2/objects`. |\n| 400 | Malformed body | Ensure attribute values are wrapped in arrays. |\n| 422 | Validation or conflict error | Read the `errors` array for field-level details. |\n| 429 | Rate-limited | Back off and retry after `Retry-After` if provided. |\n\n## Worked example: stale deal reactivation\n\n```bash\nATTIO_API_KEY=$(get-config key="ATTIO_API_KEY" includeSecrets=true)\n\nDEALS=$(curl -sS -X POST "https://api.attio.com/v2/objects/deals/records/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{"filter": {"stage": {"$not_equal": "Won"}}, "limit": 200}\')\n\necho "$DEALS" | jq -r \'.data[] | .id.record_id\' | while read -r RECORD_ID; do\n  RECORD=$(curl -sS "https://api.attio.com/v2/objects/deals/records/$RECORD_ID" \\\n    -H "Authorization: Bearer $ATTIO_API_KEY" \\\n    -H "Accept: application/json")\n  # Compute staleness from the relevant date attribute. If stale, create a task.\n  sleep 0.05\ndone\n```\n\n## Related references\n\n- Official Attio REST API docs: https://developers.attio.com/reference\n- Official Attio MCP overview: https://docs.attio.com/mcp/overview\n';
+var content_default5 = '# Attio Interaction (Read + Write)\n\nUse this skill to read and write your Attio CRM through the REST API v2. Every read or write is a direct API call; agent-swarm does not maintain a separate Attio sync.\n\n## TL;DR\n\n1. Resolve `ATTIO_API_KEY` from swarm config before making calls.\n2. Base URL: `https://api.attio.com/v2/`\n3. Use `Authorization: Bearer $ATTIO_API_KEY`, `Content-Type: application/json`, and `Accept: application/json`.\n4. Prefer upsert over create for People, Companies, and Deals: `PUT /v2/objects/{slug}/records` with `matching_attribute`.\n5. Rate limits: 100 reads/sec, 25 writes/sec. Pace write bursts to roughly 15-20/sec.\n6. Attribute values are arrays, even for scalar values: `[{ "value": 42 }]`, never `42`.\n\n## Authentication\n\n```bash\nATTIO_API_KEY=$(get-config key="ATTIO_API_KEY" includeSecrets=true)\n\ncurl -sS "https://api.attio.com/v2/objects" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json"\n```\n\nIf calls return `401`, re-fetch the key from config. If it still fails, notify the Lead; the key may need rotation. Do not retry silently.\n\n## Core object slugs\n\n| Object | API slug | Primary matching attribute |\n|---|---|---|\n| Companies | `companies` | `domains` |\n| People | `people` | `email_addresses` |\n| Deals | `deals` | Usually no global dedupe key; link to company/person records |\n\nCustom objects use their configured API slug. Discover them with `GET /v2/objects`.\n\n## Common operations\n\n### 1. Discover objects and slugs\n\n```bash\ncurl -sS "https://api.attio.com/v2/objects" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {slug: .api_slug, name: .title}\'\n```\n\n### 2. Query records with filters and pagination\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/objects/companies/records/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "filter": {\n      "stage": { "$not_equal": "Won" }\n    },\n    "limit": 100,\n    "offset": 0\n  }\' | jq \'.data[] | {record_id: .id.record_id, name: .values.name[0].value}\'\n```\n\nPaginate by increasing `offset` until `data` is empty. For no filter, omit the `filter` key.\n\n### 3. Get a single record\n\n```bash\ncurl -sS "https://api.attio.com/v2/objects/companies/records/{RECORD_ID}" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data.values\'\n```\n\n### 4. Upsert a company by domain\n\nUse `PUT` with `matching_attribute`. It creates if not found and updates if found, so it is safe to call repeatedly.\n\n```bash\ncurl -sS -X PUT "https://api.attio.com/v2/objects/companies/records" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "name": [{ "value": "Acme Corp" }],\n        "domains": [{ "domain": "acme.com" }],\n        "employee_count": [{ "value": 150 }]\n      }\n    },\n    "matching_attribute": "domains"\n  }\' | jq \'{record_id: .data.id.record_id}\'\n```\n\n### 5. Upsert a person by email\n\n```bash\ncurl -sS -X PUT "https://api.attio.com/v2/objects/people/records" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "name": [{ "first_name": "Jane", "last_name": "Doe" }],\n        "email_addresses": [{ "email_address": "jane@acme.com" }],\n        "job_title": [{ "value": "CTO" }]\n      }\n    },\n    "matching_attribute": "email_addresses"\n  }\' | jq \'{record_id: .data.id.record_id}\'\n```\n\nAn upsert returns HTTP `200` when it updates an existing record and `201` when it creates one. The response body has the same shape in both cases.\n\n### 6. Update specific attributes on an existing record\n\n```bash\ncurl -sS -X PATCH "https://api.attio.com/v2/objects/companies/records/{RECORD_ID}" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "values": {\n        "icp_score": [{ "value": 85 }],\n        "icp_tier": [{ "value": "Tier 1" }]\n      }\n    }\n  }\'\n```\n\n### 7. Write a note to a record\n\nNotes are concise free-text entries linked to a record. Use them to preserve useful interaction context, enrichment findings, or an agent result that should remain visible in the CRM.\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/notes" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "parent_object": "companies",\n      "parent_record_id": "{RECORD_ID}",\n      "title": "Enrichment - 2026-06-02",\n      "content": "Employee count: 150. Funding stage: Series A. Tech stack: Node.js, React."\n    }\n  }\' | jq \'{note_id: .data.id.note_id}\'\n```\n\n### 8. Create a task linked to a record\n\n```bash\ncurl -sS "https://api.attio.com/v2/workspace_members" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {member_id: .id.workspace_member_id, name: .name, email: .email_address}\'\n\ncurl -sS -X POST "https://api.attio.com/v2/tasks" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "content": "Follow up - no contact in 21 days",\n      "is_completed": false,\n      "assignees": [\n        { "referenced_actor_type": "workspace-member", "referenced_actor_id": "{MEMBER_ID}" }\n      ],\n      "linked_records": [\n        { "target_object": "deals", "target_record_id": "{DEAL_RECORD_ID}" }\n      ]\n    }\n  }\' | jq \'{task_id: .data.id.task_id}\'\n```\n\n### 9. Post a comment on a record\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/comments" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{\n    "data": {\n      "record": { "target_object": "companies", "target_record_id": "{RECORD_ID}" },\n      "content": [\n        { "type": "text", "text": "Possible duplicate of acme-corp-old - please review and merge." }\n      ]\n    }\n  }\' | jq \'{comment_id: .data.id.comment_id}\'\n```\n\n### 10. Query a list or pipeline view\n\n```bash\ncurl -sS "https://api.attio.com/v2/lists" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Accept: application/json" \\\n  | jq \'.data[] | {list_id: .id.list_id, name: .title}\'\n\ncurl -sS -X POST "https://api.attio.com/v2/lists/{LIST_ID}/entries/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{ "limit": 100, "offset": 0 }\' \\\n  | jq \'.data[] | {entry_id: .id.entry_id, record_id: .record_id}\'\n```\n\n### 11. Global search across objects\n\n```bash\ncurl -sS -X POST "https://api.attio.com/v2/records/search" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{ "query": "acme", "limit": 10 }\' \\\n  | jq \'.data[] | {object: .object_type, record_id: .id.record_id}\'\n```\n\n## Webhooks\n\nAttio delivers webhooks at least once. Payloads contain IDs only, so always re-fetch the full record via `GET` before acting.\n\nKey event types:\n\n- `record.created`, `record.updated`, `record.deleted`\n- `list-entry.created`, `list-entry.updated`, `list-entry.deleted`\n- `note.created`\n- `task.created`, `task.completed`\n\nWebhook timeout is 5 seconds. Respond `200` immediately and do async processing in a follow-up swarm task.\n\n## Rate limits\n\n| Operation | Hard limit | Safe working rate |\n|---|---|---|\n| Reads | 100 req/sec | ~80 req/sec |\n| Writes | 25 req/sec | ~15-20 req/sec |\n\nAdd `sleep 0.05` between write calls in loops. Attio does not provide a native batch endpoint for these operations.\n\n## Operational rules\n\n- Upsert first. Use `PUT /records` with `matching_attribute` for create-or-update. `POST /records` can create duplicates.\n- Re-fetch webhook records. Webhook payloads are event hints, not full source-of-truth records.\n- Values are arrays. Every attribute value must be wrapped in an array.\n- No merge endpoint. Attio has no API-level record merge; dedupe agents should flag duplicates as comments or tasks for human review.\n- Check config first. Fetch `ATTIO_API_KEY` via `get-config includeSecrets=true`; never hardcode it.\n\n## Error handling\n\n| Status | Likely cause | Action |\n|---|---|---|\n| 401 | API key invalid or expired | Re-fetch from config. If still failing, notify Lead for rotation. |\n| 403 | Key lacks permission | Check the Attio API key\'s workspace permissions. |\n| 404 | Wrong object slug or record ID | Re-discover slugs with `GET /v2/objects`. |\n| 400 | Malformed body | Ensure attribute values are wrapped in arrays. |\n| 422 | Validation or conflict error | Read the `errors` array for field-level details. |\n| 429 | Rate-limited | Back off and retry after `Retry-After` if provided. |\n\n## Worked example: stale deal reactivation\n\n```bash\nATTIO_API_KEY=$(get-config key="ATTIO_API_KEY" includeSecrets=true)\n\nDEALS=$(curl -sS -X POST "https://api.attio.com/v2/objects/deals/records/query" \\\n  -H "Authorization: Bearer $ATTIO_API_KEY" \\\n  -H "Content-Type: application/json" \\\n  -d \'{"filter": {"stage": {"$not_equal": "Won"}}, "limit": 200}\')\n\necho "$DEALS" | jq -r \'.data[] | .id.record_id\' | while read -r RECORD_ID; do\n  RECORD=$(curl -sS "https://api.attio.com/v2/objects/deals/records/$RECORD_ID" \\\n    -H "Authorization: Bearer $ATTIO_API_KEY" \\\n    -H "Accept: application/json")\n  # Compute staleness from the relevant date attribute. If stale, create a task.\n  sleep 0.05\ndone\n```\n\n## Related references\n\n- Official Attio REST API docs: https://developers.attio.com/reference\n- Official Attio MCP overview: https://docs.attio.com/mcp/overview\n';
 
 // templates/skills/brainstorming/config.json
-var config_default7 = `{
+var config_default6 = `{
   "category": "skills",
   "description": "Interactive exploration of ideas through Socratic Q&A. Produces progressive documents that serve as lightweight pre-PRDs feeding into research.",
   "displayName": "Brainstorming",
@@ -6281,7 +5925,7 @@ var config_default7 = `{
 `;
 
 // templates/skills/brainstorming/content.md
-var content_default7 = `# Brainstorming
+var content_default6 = `# Brainstorming
 
 You are facilitating interactive exploration of ideas through Socratic Q&A. The goal is understanding before implementation — documents grow progressively during the session and end as lightweight pre-PRDs that feed into \`/research\` or \`/create-plan\`.
 
@@ -6423,6 +6067,26 @@ File-review is on by default:
 - Process feedback with the \`file-review:process-review\` skill
 `;
 
+// templates/skills/chat-sdk/config.json
+var config_default7 = `{
+  "kind": "skill",
+  "name": "chat-sdk",
+  "displayName": "Chat SDK",
+  "slug": "chat-sdk",
+  "title": "Chat SDK",
+  "description": "Chat threads from Telegram, Slack (Chat SDK), Discord, and Teams. Use when a task carries a task:chat-sdk contextKey or a user asked through Telegram, Slack, Discord, or Teams. Covers what the swarm posts for you, \`chat-reply\`, markdown and length per platform, attachments, \`chat-read-thread\` limits, and channel routes with \`register-chat-channel\`.",
+  "version": "1.0.0",
+  "category": "skills",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "systemDefault": false,
+  "tags": ["chat", "telegram", "discord", "teams", "slack", "communication"]
+}
+`;
+
+// templates/skills/chat-sdk/content.md
+var content_default7 = "# Chat SDK\n\nThe swarm receives messages from Telegram, Slack, Discord, and Microsoft Teams through the Chat SDK channel. A person mentions the bot or sends it a direct message, and the swarm creates a task for it. This skill tells you how to work on such a task.\n\n## How you know you are on a chat task\n\n- The task has `source: \"chat\"`, or it is a lead follow-up of one.\n- The task `contextKey` starts with `task:chat-sdk:`. The full form is `task:chat-sdk:<adapter>:<encoded thread id>`, for example `task:chat-sdk:telegram:555001`.\n- The task text holds the user's message. Later replies in the same thread arrive as follow-up tasks with the same `contextKey`, or as steering messages on your running task.\n- The user has four slash commands that never reach you as a task: `/help`, `/status`, `/cancel` and `/reset`. `/cancel` ends the thread's active tasks, yours included, with status `cancelled`. After `/reset` the next task has no parent task and no earlier thread context, so treat it as a new conversation.\n\nUse `get-task-details` to read the `contextKey` when you are not sure.\n\n## Reply with `chat-reply`\n\n`chat-reply { text }` posts to the thread your current task came from. It finds the thread from your task, so you do not pass ids.\n\n- Use it to ask the user a question you cannot answer yourself. Ask once, with all your questions together.\n- Use it for one short progress note when work takes more than a few minutes, such as \"Started. This takes about 10 minutes.\"\n- Do not use it for receipts (\"Got it\", \"On it\"), and do not send many progress notes.\n- It works only on a task with a `task:chat-sdk:` contextKey. A session bound to a non-chat task does not see `chat-reply` at all, because the tool is left out of its tool list.\n\n## The final summary is posted automatically\n\nWhen your task ends, the swarm posts the task output to the thread:\n\n- Completed: your `store-progress` output.\n- Failed: a \"Task failed.\" line, then the failure reason.\n- Cancelled: a \"Task cancelled.\" line, then the reason when there is one.\n\nDo not post your final answer with `chat-reply` as well. The user would get it twice. Put the answer in the `store-progress` output and stop.\n\nThe post is durable. If the platform is down, the swarm retries with backoff for up to 24 hours.\n\n## Markdown per platform\n\nWrite plain, short markdown: bold, italic, inline code, code blocks, bullet lists, and links. Avoid tables, nested lists, and HTML.\n\n| Platform | What renders | Limit per message |\n|---|---|---|\n| Telegram | Bold, italic, code, code blocks, links, lists. No tables. | 4096 characters |\n| Discord | Bold, italic, code, code blocks, lists, headings, links. No tables. | 2000 characters |\n| Slack | Converted to Slack mrkdwn: bold, italic, code, lists, links. Tables do not render well. | 4000 characters |\n| Teams | Basic markdown: bold, italic, code, lists, links. | 20000 characters |\n\nThe swarm splits longer text into several messages at line breaks. Long answers are hard to read in chat, so keep the answer short and put long material in an artifact or page, then post the link.\n\n## Attachments arrive as task attachments\n\nFiles and images the user sends in the thread are stored as attachments of the task. The task text names them. Download them with the `download-task-attachment` skill. You cannot send files back to the thread in this version. Share a link instead.\n\n## `chat-read-thread` limits per platform\n\n`chat-read-thread { threadId, limit? }` returns the most recent messages of a thread, oldest first. The thread id is the adapter name plus the URI-decoded remainder of the contextKey. Telegram ids have no escaping, so `telegram:555001` stays as it is. Slack, Discord, and Teams ids contain `%3A` in the contextKey, so do not build the id by hand. `chat-reply` resolves the thread itself. For `chat-read-thread`, use the thread id returned by `chat-reply`, `chat-post`, or `chat-open-dm`. You can read the thread of your current task. Any other thread needs lead privileges.\n\n- Telegram has no history API. The SDK keeps the Telegram thread history it saw in the swarm database, capped at 100 messages and 7 days.\n- Teams needs the `Chat.Read.*` Graph permission on the bot. Without it, the call fails.\n- Slack and Discord return the platform history.\n\nThe task text already holds the earlier swarm messages of the thread, so read the thread only when you need more.\n\n## Other tools\n\n- `chat-post { adapter, threadId | channelId, text }` posts outside your task's thread. Lead only. Use it only when the task asks you to message another thread or channel.\n- `chat-open-dm { adapter, userId }` returns the direct-message thread id for a user. Lead only. Then post to it with `chat-post`.\n\n## Leads: `register-chat-channel`\n\nBy default every message addressed to the swarm goes to the lead. A lead can route one channel to a fixed agent or workflow:\n\n```\nregister-chat-channel { adapter: \"telegram\", channelId: \"telegram:-100123\", agentId: \"<agent id>\" }\nregister-chat-channel { adapter: \"slack\", channelId: \"slack:C123\", workflowId: \"<workflow id>\" }\nunregister-chat-channel { adapter: \"telegram\", channelId: \"telegram:-100123\" }\n```\n\nGive exactly one of `agentId` or `workflowId`. A `swarm#<agentId>` token in a message still wins over the route. A workflow mapping fires only for a bot mention or a DM; a plain reply in the subscribed thread does not start another run. Only the lead can call these tools.\n\n## Etiquette\n\n- Keep messages short. Chat is read on phones.\n- Never post secrets, tokens, internal URLs with credentials, or private data from other users. The swarm scrubs known secrets, but do not depend on it.\n- When you ask a question in a group, start with the user's name so they see it.\n- One question message is better than several.\n";
+
 // templates/skills/code-quality/config.json
 var config_default8 = `{
   "kind": "skill",
@@ -6908,7 +6572,7 @@ var config_default12 = `{
 `;
 
 // templates/skills/composio-gmail/content.md
-var content_default12 = '# Composio · Gmail\n\nToolkit slug: **`gmail`**. Read the [[composio]] hub first for the call model\n(`agent-swarm x composio …`, user_id, connected accounts, the 4302 gotcha).\nTool `arguments` go inside the request body; `user_id` defaults to `"me"` (the\nauthorized account) — you usually don\'t need to set it.\n\n```bash\n# Direct execute (reliable path — pin the ACTIVE ca_… from the hub Recipe B)\nagent-swarm x composio POST /tools/execute/<SLUG> \\\n  --body \'{"user_id":"<connected-account-email>","connected_account_id":"<active-connected-account-id>","arguments":{ … }}\'\n```\n\nFollow the hub\'s **Resolve the user and connected account** procedure, then\nselect the resolved user\'s `gmail` account whose status is `ACTIVE`.\n\n## Headline tools\n\n| Slug | What | Key args |\n|---|---|---|\n| `GMAIL_FETCH_EMAILS` | List/search emails | `query`, `max_results` (def **1** — set it!), `include_payload` (def true), `verbose` (def true), `ids_only`, `label_ids`, `page_token` |\n| `GMAIL_FETCH_MESSAGE_BY_MESSAGE_ID` | Full single message | `message_id`, `include_payload` |\n| `GMAIL_FETCH_MESSAGE_BY_THREAD_ID` | All messages in a thread | `thread_id` |\n| `GMAIL_LIST_THREADS` | List threads | `query`, `max_results`, `page_token` |\n| `GMAIL_SEND_EMAIL` | Send | `recipient_email`, `subject`, `body`, `is_html` (def false), `cc`, `bcc`, `extra_recipients`, `attachment` |\n| `GMAIL_REPLY_TO_THREAD` | Reply in-thread | `thread_id`, `message_body`, `recipient_email` |\n| `GMAIL_CREATE_EMAIL_DRAFT` / `GMAIL_SEND_DRAFT` | Draft then send | `body`, `subject`, `recipient_email` / `draft_id` |\n| `GMAIL_GET_PROFILE` | Whose mailbox is this? | — |\n| `GMAIL_LIST_LABELS` / `GMAIL_CREATE_LABEL` / `GMAIL_ADD_LABEL_TO_EMAIL` | Labels | `message_id`, `label_ids` (use LIST_LABELS for custom IDs) |\n| `GMAIL_GET_CONTACTS` / `GMAIL_SEARCH_PEOPLE` | Contacts | `query` |\n| `GMAIL_GET_ATTACHMENT` | Download attachment | `message_id`, `attachment_id` |\n\nFull set: 63 tools — list with\n`agent-swarm x composio GET "/tools?toolkit_slug=gmail&limit=100" | jq -r \'.items[]|"\\(.slug)\\t\\(.name)"\'`.\nAvoid the ones marked Deprecated (`GMAIL_LIST_MESSAGES`, `GMAIL_REMOVE_LABEL`).\n\n## Read recipe (metadata-first)\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_FETCH_EMAILS \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"max_results":5,"include_payload":false,"verbose":false}}\'\n```\n- **Always set `max_results`** — the default is `1`.\n- Use Gmail `query` syntax: `"is:unread"`, `"from:foo@bar.com newer_than:7d"`,\n  `"subject:invoice has:attachment"`.\n- Keep `include_payload:false` + `verbose:false` unless the user needs full bodies\n  (token-heavy). Use `ids_only:true` for the cheapest listing.\n\n## Send recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_SEND_EMAIL \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "recipient_email":"someone@example.com",\n    "subject":"Hello",\n    "body":"<p>Hi there</p>",\n    "is_html":true,\n    "cc":["cc@example.com"]\n  }}\'\n```\n- Set `is_html:true` when `body` contains HTML, otherwise it sends as literal text.\n- `recipient_email` is the primary; add more via `extra_recipients` / `cc` / `bcc`.\n- **Sending is a write action** — only do it when the task explicitly asks.\n\n## Reply in a thread\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_REPLY_TO_THREAD \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "thread_id":"<thread_id>","recipient_email":"someone@example.com","message_body":"thanks!"\n  }}\'\n```\n\n## Gotchas\n\n- Default `max_results` is `1` — forgetting it makes "list my emails" return a\n  single message.\n- Bodies/attachments are token-heavy and may contain secrets — default to\n  metadata; the secret-scrubber doesn\'t run on Composio tool output.\n- If you get `ToolRouterV2_NoActiveConnection`, switch to direct execute with the\n  pinned `connected_account_id` (hub Gotchas).\n';
+var content_default12 = '# Composio · Gmail\n\nToolkit slug: **`gmail`**. Read the [[composio]] hub first for the call model\n(`agent-swarm x composio …`, user_id, connected accounts, the 4302 gotcha).\nTool `arguments` go inside the request body; `user_id` defaults to `"me"` (the\nauthorized account) — you usually don\'t need to set it.\n\n```bash\n# Direct execute (reliable path — pin the ACTIVE ca_… from the hub Recipe B)\nagent-swarm x composio POST /tools/execute/<SLUG> \\\n  --body \'{"user_id":"<connected-account-email>","connected_account_id":"<active-connected-account-id>","arguments":{ … }}\'\n```\n\nFollow the hub\'s **Resolve the user and connected account** procedure, then\nselect the resolved user\'s `gmail` account whose status is `ACTIVE`.\n\n## Headline tools\n\n| Slug | What | Key args |\n|---|---|---|\n| `GMAIL_FETCH_EMAILS` | List/search emails | `query`, `max_results` (def **1** — set it!), `include_payload` (def true), `verbose` (def true), `ids_only`, `label_ids`, `page_token` |\n| `GMAIL_FETCH_MESSAGE_BY_MESSAGE_ID` | Full single message | `message_id`, `include_payload` |\n| `GMAIL_FETCH_MESSAGE_BY_THREAD_ID` | All messages in a thread | `thread_id` |\n| `GMAIL_LIST_THREADS` | List threads | `query`, `max_results`, `page_token` |\n| `GMAIL_SEND_EMAIL` | Send | `recipient_email`, `subject`, `body`, `is_html` (def false), `cc`, `bcc`, `extra_recipients`, `attachment` |\n| `GMAIL_REPLY_TO_THREAD` | Reply in-thread | `thread_id`, `message_body`, `recipient_email` |\n| `GMAIL_CREATE_EMAIL_DRAFT` / `GMAIL_SEND_DRAFT` | Draft then send | `body`, `subject`, `recipient_email` / `draft_id` |\n| `GMAIL_GET_PROFILE` | Whose mailbox is this? | — |\n| `GMAIL_LIST_LABELS` / `GMAIL_CREATE_LABEL` / `GMAIL_ADD_LABEL_TO_EMAIL` | Labels | `message_id`, `label_ids` (use LIST_LABELS for custom IDs) |\n| `GMAIL_GET_CONTACTS` / `GMAIL_SEARCH_PEOPLE` | Contacts | `query` |\n| `GMAIL_GET_ATTACHMENT` | Download attachment | `message_id`, `attachment_id` |\n\nFull set: 63 tools — list with\n`agent-swarm x composio GET "/tools?toolkit_slug=gmail&limit=100" | jq -r \'.items[]|"\\(.slug)\\t\\(.name)"\'`.\nAvoid the ones marked Deprecated (`GMAIL_LIST_MESSAGES`, `GMAIL_REMOVE_LABEL`).\n\n## Read recipe (metadata-first)\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_FETCH_EMAILS \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"max_results":5,"include_payload":false,"verbose":false}}\'\n```\n- **Always set `max_results`** — the default is `1`.\n- Use Gmail `query` syntax: `"is:unread"`, `"from:foo@bar.com newer_than:7d"`,\n  `"subject:invoice has:attachment"`.\n- Keep `include_payload:false` + `verbose:false` unless the user needs full bodies\n  (token-heavy). Use `ids_only:true` for the cheapest listing.\n\n## Send recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_SEND_EMAIL \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "recipient_email":"someone@example.com",\n    "subject":"Hello",\n    "body":"<p>Hi there</p>",\n    "is_html":true,\n    "cc":["cc@example.com"]\n  }}\'\n```\n- Set `is_html:true` when `body` contains HTML, otherwise it sends as literal text.\n- `recipient_email` is the primary; add more via `extra_recipients` / `cc` / `bcc`.\n- **Sending is a write action** — only do it when the task explicitly asks.\n\n## Sender (From) and footer\n\n- A draft defaults to the connected account\'s primary address. Before you create drafts, list the account\'s verified send-as aliases and set From to the alias the requester prefers (requester profile or brief). Take the footer and signature domain from the same source.\n- Never set From to an alias that is not verified. Gmail rewrites it to the primary address.\n- After you create the drafts, check From as well as To and Subject on each one.\n- To fix existing drafts, update each draft in place with the alias. Draft ids stay the same, so there is no need to delete and recreate.\n\n## Reply in a thread\n\n```bash\nagent-swarm x composio POST /tools/execute/GMAIL_REPLY_TO_THREAD \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "thread_id":"<thread_id>","recipient_email":"someone@example.com","message_body":"thanks!"\n  }}\'\n```\n\n## Gotchas\n\n- Default `max_results` is `1` — forgetting it makes "list my emails" return a\n  single message.\n- Bodies/attachments are token-heavy and may contain secrets — default to\n  metadata; the secret-scrubber doesn\'t run on Composio tool output.\n- If you get `ToolRouterV2_NoActiveConnection`, switch to direct execute with the\n  pinned `connected_account_id` (hub Gotchas).\n';
 
 // templates/skills/composio-google-calendar/config.json
 var config_default13 = `{
@@ -6948,7 +6612,7 @@ var config_default14 = `{
 `;
 
 // templates/skills/composio-google-docs/content.md
-var content_default14 = '# Composio · Google Docs\n\nToolkit slug: **`googledocs`**. Read the [[composio]] hub first for the call model.\nA document is identified by its `document_id` (the id in the Docs URL).\n\n```bash\nagent-swarm x composio POST /tools/execute/<SLUG> \\\n  --body \'{"user_id":"<connected-account-email>","connected_account_id":"<active-connected-account-id>","arguments":{ … }}\'\n```\n\nFollow the hub\'s **Resolve the user and connected account** procedure, then\nselect the resolved user\'s `googledocs` account whose status is `ACTIVE`.\n\n## Headline tools\n\n| Slug | What | Key args |\n|---|---|---|\n| `GOOGLEDOCS_SEARCH_DOCUMENTS` | Find docs (Drive search) | `query`, `max_results` (def 10), `order_by` (def `modifiedTime desc`), `modified_after`, `created_after`, `starred_only`, `shared_with_me`, `response_detail` (def `minimal`) |\n| `GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT` | Read doc as text | **`document_id`**, `include_tables` (def true), `include_headers`, `include_footers`, `include_footnotes`, `include_tabs_content` |\n| `GOOGLEDOCS_GET_DOCUMENT_BY_ID` | Full structured doc JSON | `document_id` |\n| `GOOGLEDOCS_CREATE_DOCUMENT` | Create blank/with text | `title`, `text` |\n| `GOOGLEDOCS_CREATE_DOCUMENT_MARKDOWN` | Create from markdown | **`title`**, `markdown_text`, `image_assets` |\n| `GOOGLEDOCS_UPDATE_DOCUMENT_MARKDOWN` | Replace body with markdown | `document_id`, `markdown_text` |\n| `GOOGLEDOCS_INSERT_TEXT_ACTION` | Insert text at index | `document_id`, `text`, `index` |\n| `GOOGLEDOCS_REPLACE_ALL_TEXT` | Find & replace | `document_id`, `find`, `replace` |\n| `GOOGLEDOCS_COPY_DOCUMENT` | Duplicate a doc | `document_id`, `title` |\n| `GOOGLEDOCS_EXPORT_DOCUMENT_AS_PDF` | Export to PDF | `document_id` |\n\nFull set: 35 tools — `agent-swarm x composio GET "/tools?toolkit_slug=googledocs&limit=100" | jq -r \'.items[]|"\\(.slug)\\t\\(.name)"\'`.\nPrefer the `*_MARKDOWN` create/update tools for authoring; the granular\n`INSERT_*`/`DELETE_*`/table tools are for surgical structural edits.\n\n## Search recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_SEARCH_DOCUMENTS \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"query":"workshop","max_results":5}}\'\n# → results under .data.files[]  (id, name, modifiedTime …)\n```\n- Results are Drive file entries at **`.data.files[]`** — grab `.id` to read.\n- `order_by` defaults to `modifiedTime desc` (most recent first).\n- Use `modified_after` / `shared_with_me` to narrow.\n\n## Read recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"document_id":"<id>","include_tables":true}}\'\n```\nUse `GET_DOCUMENT_PLAINTEXT` for reading content; only reach for\n`GET_DOCUMENT_BY_ID` when you need the structured JSON (styles, indices) for an\nedit.\n\n## Create-from-markdown recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_CREATE_DOCUMENT_MARKDOWN \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "title":"Weekly updates","markdown_text":"# Heading\\n\\n- point one\\n- point two"\n  }}\'\n```\n\n## Google Doc to agent-fs\n\n1. Read the source with `GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT` and retain its\n   returned title and display URL as provenance.\n2. Write the converted content to your own agent-fs namespace with a short\n   provenance header naming the source document and import method.\n3. Resolve the destination org and drive from the environment or\n   `agent-fs stat <path> --json`; the `artifacts` skill documents the canonical\n   storage and share-link workflow. Never copy org or drive IDs from an example.\n4. Read the stored file back and assert several markers: the title, a middle\n   phrase, and the final sentence. A successful byte-count response alone does\n   not prove fidelity.\n\nPlaintext is intentionally lossy. Inline images may become bare `[IMAGE]`\nmarkers, and headings may be flattened into adjacent paragraphs. If those\nfeatures matter, use `GOOGLEDOCS_GET_DOCUMENT_BY_ID` for structured JSON or a\nGoogle Drive export, then preserve or reconstruct the structure explicitly.\nThere is no `GET_DOCUMENT_MARKDOWN` tool; markdown exists on create/update, not\non read.\n\n## Gotchas\n\n- Search returns Drive metadata, not document content — do a second\n  `GET_DOCUMENT_PLAINTEXT` call with the `.id` to read.\n- Doc bodies can be long/token-heavy and may contain secrets — read only what you\n  need (`include_headers/footers/footnotes` default off for a reason).\n- Create/update/replace are **write actions** — only on explicit request.\n';
+var content_default14 = '# Composio · Google Docs\n\nToolkit slug: **`googledocs`**. Read the [[composio]] hub first for the call model.\nA document is identified by its `document_id` (the id in the Docs URL).\n\n```bash\nagent-swarm x composio POST /tools/execute/<SLUG> \\\n  --body \'{"user_id":"<connected-account-email>","connected_account_id":"<active-connected-account-id>","arguments":{ … }}\'\n```\n\nFollow the hub\'s **Resolve the user and connected account** procedure, then\nselect the resolved user\'s `googledocs` account whose status is `ACTIVE`.\n\n## Headline tools\n\n| Slug | What | Key args |\n|---|---|---|\n| `GOOGLEDOCS_SEARCH_DOCUMENTS` | Find docs (Drive search) | `query`, `max_results` (def 10), `order_by` (def `modifiedTime desc`), `modified_after`, `created_after`, `starred_only`, `shared_with_me`, `response_detail` (def `minimal`) |\n| `GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT` | Read doc as text | **`document_id`**, `include_tables` (def true), `include_headers`, `include_footers`, `include_footnotes`, `include_tabs_content` |\n| `GOOGLEDOCS_GET_DOCUMENT_BY_ID` | Full structured doc JSON | `document_id` |\n| `GOOGLEDOCS_CREATE_DOCUMENT` | Create blank/with text | `title`, `text` |\n| `GOOGLEDOCS_CREATE_DOCUMENT_MARKDOWN` | Create from markdown | **`title`**, `markdown_text`, `image_assets` |\n| `GOOGLEDOCS_UPDATE_DOCUMENT_MARKDOWN` | Replace body with markdown | `document_id`, `markdown_text` |\n| `GOOGLEDOCS_INSERT_TEXT_ACTION` | Insert text at index | `document_id`, `text`, `index` |\n| `GOOGLEDOCS_REPLACE_ALL_TEXT` | Find & replace | `document_id`, `find`, `replace` |\n| `GOOGLEDOCS_COPY_DOCUMENT` | Duplicate a doc | `document_id`, `title` |\n| `GOOGLEDOCS_EXPORT_DOCUMENT_AS_PDF` | Export to PDF | `document_id` |\n\nFull set: 35 tools — `agent-swarm x composio GET "/tools?toolkit_slug=googledocs&limit=100" | jq -r \'.items[]|"\\(.slug)\\t\\(.name)"\'`.\nPrefer the `*_MARKDOWN` create/update tools for authoring; the granular\n`INSERT_*`/`DELETE_*`/table tools are for surgical structural edits.\n\n## Search recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_SEARCH_DOCUMENTS \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"query":"workshop","max_results":5}}\'\n# → results under .data.files[]  (id, name, modifiedTime …)\n```\n- Results are Drive file entries at **`.data.files[]`** — grab `.id` to read.\n- `order_by` defaults to `modifiedTime desc` (most recent first).\n- Use `modified_after` / `shared_with_me` to narrow.\n\n## Read recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT \\\n  --body \'{"connected_account_id":"ca_…","arguments":{"document_id":"<id>","include_tables":true}}\'\n```\nUse `GET_DOCUMENT_PLAINTEXT` for reading content; only reach for\n`GET_DOCUMENT_BY_ID` when you need the structured JSON (styles, indices) for an\nedit.\n\n## Create-from-markdown recipe\n\n```bash\nagent-swarm x composio POST /tools/execute/GOOGLEDOCS_CREATE_DOCUMENT_MARKDOWN \\\n  --body \'{"connected_account_id":"ca_…","arguments":{\n    "title":"Weekly updates","markdown_text":"# Heading\\n\\n- point one\\n- point two"\n  }}\'\n```\n\n## Google Doc to agent-fs\n\n1. Read the source with `GOOGLEDOCS_GET_DOCUMENT_PLAINTEXT` and retain its\n   returned title and display URL as provenance.\n2. Write the converted content to your own agent-fs namespace with a short\n   provenance header naming the source document and import method.\n3. Resolve the destination org and drive from the environment or\n   `agent-fs stat <path> --json`; the `agent-fs` skill documents the canonical\n   storage and share-link workflow. Never copy org or drive IDs from an example.\n4. Read the stored file back and assert several markers: the title, a middle\n   phrase, and the final sentence. A successful byte-count response alone does\n   not prove fidelity.\n\nPlaintext is intentionally lossy. Inline images may become bare `[IMAGE]`\nmarkers, and headings may be flattened into adjacent paragraphs. If those\nfeatures matter, use `GOOGLEDOCS_GET_DOCUMENT_BY_ID` for structured JSON or a\nGoogle Drive export, then preserve or reconstruct the structure explicitly.\nThere is no `GET_DOCUMENT_MARKDOWN` tool; markdown exists on create/update, not\non read.\n\n## Gotchas\n\n- Search returns Drive metadata, not document content — do a second\n  `GET_DOCUMENT_PLAINTEXT` call with the `.id` to read.\n- Doc bodies can be long/token-heavy and may contain secrets — read only what you\n  need (`include_headers/footers/footnotes` default off for a reason).\n- Create/update/replace are **write actions** — only on explicit request.\n';
 
 // templates/skills/db-query-guidance/config.json
 var config_default15 = `{
@@ -7141,8 +6805,159 @@ var config_default18 = `{
 // templates/skills/download-task-attachment/content.md
 var content_default18 = '# Download a Task Attachment\n\nTask attachments (files uploaded via the UI or API onto a task) are served\nthrough a single **provider-agnostic** REST route — regardless of whether the\nbacking storage is `local-fs` or `agent-fs`. You do not need to know or care\nwhich provider is active, and you do not need `agent-fs org`/`agent-fs drive`\ndiscovery.\n\n## The one-call recipe\n\n```bash\ncurl "$MCP_BASE_URL/api/fs/tasks/$AGENT_SWARM_TASK_ID/files/<attachmentId>/raw" \\\n  -H "X-Agent-ID: $AGENT_ID" \\\n  -H "Authorization: Bearer ${AGENT_SWARM_API_KEY:-$API_KEY}" \\\n  --create-dirs -o "/tmp/attachments/<attachmentId>/<name>"\n```\n\n- `$MCP_BASE_URL`, `$AGENT_ID`, `$AGENT_SWARM_TASK_ID` (or `$AGENT_SWARM_AGENT_ID`/`TASK_FILE`-derived taskId), and `$AGENT_SWARM_API_KEY`/`$API_KEY` are already present in every worker container\'s env — no new plumbing needed.\n- `<attachmentId>` and `<name>`/`mimeType` come from the task\'s attachment list (see below).\n- One directory per attachment: two attachments can share a name (every pasted screenshot is `image.png`), and `/tmp/<name>` would let one overwrite the other.\n- The route resolves the active file-storage provider (`local-fs` in dev, `agent-fs` in prod) server-side and streams the raw bytes back with the correct `Content-Type` — you get one call no matter which provider is behind it.\n\n## Finding the attachment ID\n\nIf the dispatch prompt already injected an `## Attachments` section with the\ncurl command pre-filled, just run it — that\'s the fast path (see\n`buildAttachmentsSection()` in `src/commands/runner.ts`).\n\nOtherwise, pull it from the task:\n\n```\nget-task-details taskId=<your task id>\n```\n\nThe response includes an `attachments` array: `{id, name, mimeType, sizeBytes}`.\nUse `id` as `<attachmentId>` in the curl above.\n\n## Why not the `agent-fs` CLI directly?\n\n`agent-fs` is a general-purpose CLI for the swarm\'s own agent-fs filesystem —\nit requires you to already know the org/drive a file lives in, and task\nattachments don\'t always carry that (older rows, or attachments stored via\n`local-fs` in dev have no org/drive at all). Reaching for `agent-fs cat` /\n`agent-fs download` on a task attachment means guessing subcommand names,\ndiscovering the right org via `agent-fs org list`, and re-trying — several\ntool calls where one `curl` suffices. This was root-caused from a real\nsession that burned 7 tool calls (~64s) doing exactly that detour before\nsucceeding; see `runbooks/harness-providers.md` and PR that added\n`buildAttachmentsSection()` for the full trace.\n\n## Gotchas\n\n- The route requires `X-Agent-ID` + bearer auth like any other swarm API call — same headers you\'d use for any MCP-adjacent REST call.\n- `mimeType` on the attachment record reflects the real upload `Content-Type` (not a filename-extension guess) — trust it when deciding how to handle the downloaded bytes (image vs PDF vs text).\n- If you get a 404, double-check you\'re using the **attachment ID** (from `attachments[].id`), not the display `name`.\n';
 
-// templates/skills/engineering-standards/config.json
+// templates/skills/email-domain-health/config.json
 var config_default19 = `{
+  "kind": "skill",
+  "name": "email-domain-health",
+  "displayName": "Email Domain Health",
+  "slug": "email-domain-health",
+  "title": "Email Domain Health",
+  "description": "Build a scheduled email domain health monitor: ask the user for domains, providers, test inbox, schedule and alert rules, then build a checks script (SPF, DKIM, DMARC, MX, provider records, blocklists with positive controls), a daily test send with score capture, bounce rate, run history in a Swarm App, and alerts only on a new red or a score drop. Orchestrates the swarm-scripts, apps, scheduling and composio-gmail skills.",
+  "version": "1.0.0",
+  "category": "skills",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "systemDefault": true,
+  "tags": ["email", "deliverability", "dns", "monitoring", "apps"]
+}
+`;
+
+// templates/skills/email-domain-health/content.md
+var content_default19 = `# Email Domain Health
+
+Build a monitor that tells a person, every working day, whether mail from their
+domains authenticates, lands, and stays off blocklists. It has four parts: one
+saved script (checks + test send), a Swarm App with run history, one or two
+schedules, and an alert that fires only when something gets worse.
+
+This skill decides **what** to build. The mechanics live in other skills; read
+them, do not re-derive them:
+
+- [[swarm-scripts]]: authoring, \`script-upsert\`, scope, connections, secrets.
+- [[apps]]: models, named queries, pages, row writes.
+- [[scheduling]]: \`targetType: "script"\` schedules, cron and timezone.
+- [[composio-gmail]] (or the user's own mail integration): the test send and
+  the bounce search.
+
+Full design notes and pitfalls: the "Email domain health" playbook on the docs
+site.
+
+## 1. Ask for requirements first
+
+Ask before building (one batched question, see [[ask-user]]). Do not guess any
+of these; a wrong selector or From address makes every later check wrong.
+
+| Ask | Why it matters |
+|---|---|
+| Domains to monitor, and which one is the envelope/bounce domain | One check set per domain; SPF is judged on the envelope domain. |
+| Sending providers per domain (Google Workspace, Microsoft 365, an ESP such as Resend, SES, Postmark) and each DKIM selector | DKIM is looked up at \`<selector>._domainkey.<domain>\`; there is no way to list selectors. |
+| The From address for the test send, and the integration that sends it (Composio Gmail, SMTP, ESP API) | The test must leave through the real path, alias included. |
+| Test inbox: mail-tester (free tier has a small daily cap) or an inbox the user owns | Decides how the score is captured. |
+| Schedule and timezone | Default: weekdays, morning, user's timezone. |
+| Alert channel and thresholds (score floor, bounce rate) | Defaults: score < 6/10, bounces >= 5% on >= 10 sends. |
+| History retention | Default 90 days of runs. |
+
+Read the answers back in one short message before you write code.
+
+## 2. Build the checks script
+
+One saved script with modes \`send\`, \`check\`, and optionally \`backfill\`. Keep
+domains, selectors, thresholds and ids in a config block at the top or in
+\`args\`, never scattered through the code.
+
+**DNS over HTTPS, two resolvers.** Query every record on two public DoH
+resolvers (for example dns.google and Cloudflare's JSON endpoint).
+NOERROR and NXDOMAIN are answers; SERVFAIL, REFUSED and timeouts are not.
+Same verdict on both: use it. Different verdicts: \`warn\` ("resolvers
+disagree", often propagation). One failed: use the other, note it. Both
+failed: \`unknown\`.
+
+**Checks per domain:**
+
+- SPF: exactly one \`v=spf1\` record, includes each provider, total DNS lookups
+  <= 10 (recurse \`include:\`/\`redirect=\`; warn at 9), ends \`~all\` or \`-all\`.
+- DKIM: TXT at each selector (follow a CNAME), non-empty \`p=\` (empty means
+  revoked), key length.
+- DMARC: exactly one \`v=DMARC1\` at \`_dmarc.<domain>\`, a \`p=\` tag, \`rua=\` (warn
+  without it).
+- MX: present and pointing at the expected provider.
+- Provider records the ESP documents (bounce subdomain SPF and MX, DKIM
+  CNAMEs).
+- Blocklists: domain lists such as Spamhaus DBL, SURBL, URIBL (details below).
+- Test-send result: score plus the SPF, DKIM and DMARC verdicts from the
+  receiver's headers.
+- Bounce rate: sent vs bounced in the last 24h from the sending mailbox,
+  excluding test sends.
+
+**Verdicts:** \`ok\`, \`warn\`, \`red\`, \`unknown\`. Overall = worst. \`unknown\` means
+"could not read", and it is **never** reported as clean.
+
+**Controls, not hope.** Every negative result needs a positive control in the
+same run:
+
+- Blocklists: before trusting a list, query its documented test entry
+  (\`dbltest.com\` on \`dbl.spamhaus.org\`, \`test.surbl.org\` on \`multi.surbl.org\`,
+  \`test.uribl.com\` on \`multi.uribl.com\`) on each resolver. Use the list only on
+  a resolver where the test entry answers "listed". Refusal codes
+  (\`127.255.255.x\` from Spamhaus, \`127.0.0.1\` from SURBL and URIBL) mean the
+  resolver is blocked: \`unknown\`.
+- Bounce rate: a whole-mailbox 24h count of 0 means the search failed:
+  \`unknown\`, not "0 bounces".
+- Test result page without a score yet: \`unknown\` for the first hour after the
+  send, then \`red\`.
+
+Return a \`controls.ok\` flag with the result so a run that read nothing cannot
+pass as green.
+
+**Send mode.** Send one realistic message (the same template and links real
+mail uses) to a fresh test address, through the user's integration. Read the
+sent message back and confirm the From header kept the address the user asked
+for. Store the pending test id in KV with a per-day key so a retry never
+sends twice.
+
+## 3. Build the app
+
+Use [[apps]]. Minimum models:
+
+- \`run\`: one row per run (time, overall, red/warn/unknown counts, score,
+  bounces, sent).
+- \`check\`: one row per check per run (history).
+- \`current\`: one row per \`domain|check\`, updated in place, with \`since\` = when
+  the status last changed.
+
+Optional per-domain views (\`domainRun\`, \`domainCheck\`) make tabs per domain
+cheap to render. Page: one tab per domain (problems first, raw record on
+hover), a score trend, and a collapsed "How it works". The script writes rows
+through the row endpoints; prune \`run\` and \`check\` rows older than the
+retention window.
+
+## 4. Schedule it
+
+Use [[scheduling]] with \`targetType: "script"\`, not an agent task that says
+"run the script". Two schedules: \`send\`, then \`check\` 10 to 15 minutes later
+in the user's timezone, so the test inbox has the message before the check
+reads it.
+
+## 5. Alert only on change
+
+Compare with the previous \`current\` rows. Alert when a check **turns** red, or
+the score drops below the floor after being above it. Never alert on a
+steady-state warn or an unknown. The message lists each new red with its raw
+detail and links the app. If the script's identity cannot post to the chosen
+channel, have it hand the message to an agent that can.
+
+## Done when
+
+- A manual \`check\` run returns every check, \`controls.ok: true\`, and writes
+  rows the app renders.
+- Every blocklist shows either a passing control or \`unknown\`, never a bare
+  "not listed".
+- One full scheduled send + check cycle has run and the score landed in \`run\`.
+- You reported the app link, script name and scope, and schedule ids.
+`;
+
+// templates/skills/engineering-standards/config.json
+var config_default20 = `{
   "category": "skills",
   "description": "Code-shape policy for ALL code that gets written or reviewed — the senior-engineer bar for minimal complexity. Use whenever you are about to write code, design a module or abstraction, draft a plan phase that shapes code, or review a diff; also when the user asks \\"is this over-engineered\\", \\"can this be simpler\\", or pushes back on complexity. Sibling of desplega:delegate-work (which picks WHO executes; this skill defines WHAT good output looks like).",
   "displayName": "Engineering Standards",
@@ -7163,7 +6978,7 @@ var config_default19 = `{
 `;
 
 // templates/skills/engineering-standards/content.md
-var content_default19 = `# engineering-standards
+var content_default20 = `# engineering-standards
 
 The goal is always the same: **solve the problem with the least code and the least complexity that actually solves it.** Not the cleverest solution, not the most extensible one — the one a senior engineer would defend in review. Every rule below is phrased as a *checkable test*, not a slogan: if you can't run the test, the rule doesn't apply; if the test fails, change the code.
 
@@ -7234,7 +7049,7 @@ runbooks/<name>/<slug>.md    # …or grouped by area when they multiply
 `;
 
 // templates/skills/heartbeat-runbook/config.json
-var config_default20 = `{
+var config_default21 = `{
   "kind": "skill",
   "name": "heartbeat-runbook",
   "displayName": "Heartbeat Runbook",
@@ -7251,7 +7066,7 @@ var config_default20 = `{
 `;
 
 // templates/skills/heartbeat-runbook/content.md
-var content_default20 = `# Heartbeat runbook
+var content_default21 = `# Heartbeat runbook
 
 Lead only. The heartbeat runbook is your \`heartbeatMd\` profile field. The server reads it every 30 minutes.
 
@@ -7318,7 +7133,7 @@ Two kinds of sections:
 `;
 
 // templates/skills/implementing/config.json
-var config_default21 = `{
+var config_default22 = `{
   "category": "skills",
   "description": "Plan implementation skill. Executes approved technical plans phase by phase with verification checkpoints.",
   "displayName": "Implementing",
@@ -7339,7 +7154,7 @@ var config_default21 = `{
 `;
 
 // templates/skills/implementing/content.md
-var content_default21 = `# Implementing
+var content_default22 = `# Implementing
 
 You are implementing an approved technical plan, executing it phase by phase with verification at each step. Each phase is executed as a background sub-agent via \`desplega:phase-running\` — the main session acts as an orchestrator.
 
@@ -7532,7 +7347,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/improve-agents-md/config.json
-var config_default22 = `{
+var config_default23 = `{
   "category": "skills",
   "description": "Improve (or bootstrap) an AGENTS.md / CLAUDE.md file using \`<important if>\` conditional blocks so the agent actually attends to the right guidance at the right time. Use this skill whenever the user mentions AGENTS.md, CLAUDE.md, agent instructions, project rules for AI, \\"my claude config\\", onboarding docs for agents, or asks to tighten / shorten / audit / rewrite an existing one — even if they don't explicitly say the filename. Also use when the user complains that an agent keeps ignoring their project rules.",
   "displayName": "Improve AGENTS.md",
@@ -7553,7 +7368,7 @@ var config_default22 = `{
 `;
 
 // templates/skills/improve-agents-md/content.md
-var content_default22 = `# improve-agents-md
+var content_default23 = `# improve-agents-md
 
 Progressively improve (or bootstrap from scratch) a project's agent-instruction file. Works on both \`AGENTS.md\` (vendor-neutral convention from OpenAI Codex, also read by Cursor, Claude Code, and others) and \`CLAUDE.md\` (Claude-specific). Keeps one canonical file on disk and symlinks the other, so every agent reads the same source of truth.
 
@@ -7973,7 +7788,7 @@ Run with \`turbo\` from the repo root.
 `;
 
 // templates/skills/kv-storage/config.json
-var config_default23 = `{
+var config_default24 = `{
   "kind": "skill",
   "name": "kv-storage",
   "displayName": "KV Storage",
@@ -7990,7 +7805,7 @@ var config_default23 = `{
 `;
 
 // templates/skills/kv-storage/content.md
-var content_default23 = `# KV Storage
+var content_default24 = `# KV Storage
 
 Namespaced key/value store inside the swarm SQLite DB. Auto-scoped to your
 calling context — same string used by \`agent_tasks.contextKey\`.
@@ -8279,15 +8094,15 @@ value so you can detect a clobber.
 ## See also
 
 - The **\`pages\`** skill — companion skill for authed pages and \`swarmSdk.kv\`.
-- The **\`artifacts\`** skill — for anything too big or too binary for KV.
+- The **\`agent-fs\`** skill — for anything too big or too binary for KV.
 - \`src/be/migrations/061_kv_store.sql\` — schema (\`kv_entries\`)
 - \`src/http/kv.ts\` — REST handler + namespace resolution
 - \`src/tools/kv/*\` — MCP tool registrars
-- \`src/artifact-sdk/browser-sdk.ts\` — \`swarmSdk.kv\` for pages
+- \`src/pages/browser-sdk.ts\` — \`swarmSdk.kv\` for pages
 `;
 
 // templates/skills/learning/config.json
-var config_default24 = `{
+var config_default25 = `{
   "category": "skills",
   "description": "Compounding knowledge across projects and teams. Captures, searches, and promotes institutional learnings via tiered backends (local/qmd/agent-fs).",
   "displayName": "Learning",
@@ -8308,7 +8123,7 @@ var config_default24 = `{
 `;
 
 // templates/skills/learning/content.md
-var content_default24 = `# Learning
+var content_default25 = `# Learning
 
 You are managing institutional knowledge — capturing insights, searching prior learnings, and promoting important patterns into CLAUDE.md for permanent reference.
 
@@ -8576,13 +8391,13 @@ The config file lives at \`~/.agentic-learnings.json\`:
 `;
 
 // templates/skills/memory/config.json
-var config_default25 = '{\n  "kind": "skill",\n  "name": "memory",\n  "displayName": "Memory",\n  "slug": "memory",\n  "title": "Memory",\n  "description": "Remember, recall, learning, memory: how swarm memory works and how to store, search, edit, rate, and delete memories with `memory-store`, `memory-search`, `memory-get`, `memory-edit`, `memory_rate`, and `memory-delete`, plus logical paths (`key`, `newKey`, `keyPrefix`, the `/longterm` roots and the lead-only ones) and lead promotion with `inject-learning`. Use before you store, edit, or delete a memory.",\n  "version": "1.1.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["memory", "recall", "learning"]\n}\n';
+var config_default26 = '{\n  "kind": "skill",\n  "name": "memory",\n  "displayName": "Memory",\n  "slug": "memory",\n  "title": "Memory",\n  "description": "Remember, recall, learning, memory: how swarm memory works and how to store, search, edit, rate, and delete memories with `memory-store`, `memory-search`, `memory-get`, `memory-edit`, `memory_rate`, and `memory-delete`, plus logical paths (`key`, `newKey`, `keyPrefix`, the `/longterm` roots and the lead-only ones) and lead promotion with `inject-learning`. Use before you store, edit, or delete a memory.",\n  "version": "1.1.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["memory", "recall", "learning"]\n}\n';
 
 // templates/skills/memory/content.md
-var content_default25 = '# Memory\n\nSwarm memory is a store of short texts with embeddings, searchable by meaning and by keyword. Recall is automatic: the runner puts the best matches for your task in the task message under "Relevant Past Knowledge". Everything else is a tool call.\n\n## What is stored without you\n\n| Source | When | Scope |\n|---|---|---|\n| `task_completion` | `store-progress` with status `completed` or `failed` | `agent`, or `swarm` for research tasks and tasks tagged `knowledge` or `shared` |\n| `session_summary` | your session ends | `agent` |\n| `file_index` | a file written under `/workspace/personal/memory/` or `/workspace/shared/memory/<agentId>/` on a harness with the file hook (claude, pi, opencode) | by path |\n\nAutomatic tasks (schedules, heartbeat, monitors) skip the `task_completion` write unless `store-progress` gets `persistMemory: true`.\n\nPrefer `memory-store` over memory files. It works on every harness, including the remote ones.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `memory-store` | create a memory: `content`, `name`, `scope`, optional `tags`, `taskId`, `intent`, `key` (a logical path, see Logical paths) |\n| `memory-search` | find memories: `query`, `scope` (`all`, `agent`, `swarm`), `limit`, optional `intent` (why you search), `source`, `keyPrefix` (only memories whose key starts with it) |\n| `memory-get` | the full content of one memory by ID |\n| `memory-edit` | change a memory in place: mode `replace` (whole content) or `exact` (one unique substring), `intent` required. `newKey` alone moves it to another logical path |\n| `memory-delete` | remove a memory by ID |\n| `memory_rate` | mark a memory you used in this task as useful or misleading |\n| `inject-learning` | lead only: push a learning into a worker\'s memory at swarm scope |\n\nSeed scripts (`script-run` with `name` and `args`):\n\n- `task-context-gathering` `{ taskId, queries: [...] }`: the task plus a deduplicated multi-query recall in one call.\n- `smart-recall` `{ queries: [...] }`: multi-query recall without the task.\n- `memory-dedup-check` `{ text, threshold? }`: near-duplicates of a candidate memory, default threshold 0.85.\n\n## What makes a good memory\n\n- One fact per memory: a fix, a pattern, a gotcha, a preference of a person, a fact about a repo or a host.\n- The context it applies to: repo, host, tool, version.\n- The evidence: what you saw, where.\n- A searchable `name`: "Linear API rejects issue updates without teamId", not "notes".\n- Under 2,000 characters stores as one chunk. Longer content splits on headings, one memory per chunk.\n\nSkip what a tool returns on demand (paths, tool lists, task status), what the repo already records (README, CLAUDE.md, git history), and what only mattered for this one task.\n\nA memory must not contain a token, password, key, or connection string. Remove the value and keep the reference ("the Linear token lives in config key LINEAR_API_KEY").\n\n## Scope\n\n- `agent` (default): only you recall it. Your own setup, your working notes, your mistakes.\n- `swarm`: every agent recalls it. Facts about shared repos, hosts, people, and processes. Choose `swarm` when a second agent would hit the same thing.\n\n## Logical paths (`key`)\n\nEvery memory has a `key`. By default it is an auto key (`<scope>/<source>/<id>`, or the file path for `file_index`), and the memory is **inbox material**: it keeps the lifecycle of its `source` and expires. Give it a path under `/longterm` and it becomes curated memory: findable by folder, ranked higher, and kept.\n\n`name` is a title. `key` is the address. Use a key only for what should outlive the task: a durable fact, a decision, a person or customer. Leave working notes and task results without one; expiring is the right outcome for them.\n\n### The `/longterm` roots\n\nThe list is closed. A key under `/longterm` whose second segment is not in it is refused, and the error lists the roots.\n\n| Root | Holds | Rank weight | Who may write |\n|---|---|---|---|\n| `/longterm/company-story` | what the company is and does | 1.4 | lead only |\n| `/longterm/entities/people/<slug>`, `/longterm/entities/customers/<slug>` | one doc per person or customer | 1.3 | lead only |\n| `/longterm/facts/<topic>/<slug>` | a durable fact about a repo, host, tool, or process | 1.2 | any agent |\n| `/longterm/decisions/<slug>` | a decision and why | 1.1 (0.3 with the tag `superseded`) | any agent |\n| `/longterm/workstreams/<slug>` | an ongoing effort | 1.0 | any agent |\n| `/longterm/timeline/<period>/<slug>` | dated events | 0.8 | lead only |\n\nAgents and repos are not entity types: agent profiles and `get-repos` own them, so `/longterm/entities/agents/...` is refused.\n\nKey shape: lowercase letters, digits, `-`, and `.` or `_` after the first segment; segments joined by `/`; starts with `/`; no trailing `/`; at most 200 characters. A key outside `/longterm` is not root-checked but must still have this shape.\n\n### Write, move, find\n\n```\nmemory-store key="/longterm/facts/swarm-runtime/sqlite-busy-retry" scope="swarm"\n  name="SQLite BUSY_SNAPSHOT needs BEGIN IMMEDIATE" content="..."\n\nmemory-edit memoryId="<id>" newKey="/longterm/decisions/sqlite-busy-retry" intent="promote the fact to a decision"\n\nmemory-search query="busy retry" keyPrefix="/longterm/facts/swarm-runtime/"\n```\n\n- `memory-store`: one key per owner and scope. A second memory under a key you already use fails: `memory-edit` that one. If you pass no `key` and the `name` starts with `/longterm/`, the name is the key, so you set one field. An invalid name of that form is refused, never stored under an auto key.\n- `memory-edit` `newKey`: pass it alone for a pure move. Every chunk of the document moves in one step. The ID, usefulness rating, access counts, and author stay. A key that is already taken is refused. Address the memory with `memoryId`, or with `key` plus `scope`.\n- `memory-search` `keyPrefix`: a literal, case-sensitive prefix, applied before the top results are cut, not after. End a folder with `/` (`/longterm/entities/`, not `/longterm/entities`) to stay inside it.\n\n### What a `/longterm` key changes\n\n`source` stays provenance: there is no `longterm` source. The key is the tier. A memory under `/longterm` follows a `manual` memory\'s lifecycle whatever its `source`:\n\n- It never expires. Storing under a `/longterm` key sets no expiry. Moving a memory in with `newKey` clears the expiry it had, on every chunk. Moving it back out does not restore one.\n- It has no recency decay, and its source-quality multiplier is 1.5.\n- Automated cleanup skips it.\n\nA memory under any other key keeps its `source` lifecycle: `task_completion` expires after 7 days, `session_summary` after 3, `file_index` after 30, `manual` never.\n\nRanking multiplies similarity by recency decay, access boost, source quality, **path weight** (the table above, by longest matching root; any other key weighs 1.0), and usefulness. Path weight is one factor: a weak match under `/longterm/company-story` does not beat a strong match elsewhere on weight alone.\n\n### Lead-only roots\n\nOnly the lead may write or move a key under `/longterm/company-story`, `/longterm/entities`, or `/longterm/timeline`. The check is the permission `memory.write.consolidated`. It applies to a `key`, to a `newKey`, to a `/longterm/` name, and to a `sourcePath` sent to `POST /api/memory/index`, so there is no side door. A worker that tries gets an error naming the lead-only paths. A worker puts durable knowledge under `/longterm/facts` or `/longterm/decisions`, or leaves the key off, and the lead consolidates the rest.\n\n## Before you store\n\n1. Run `memory-dedup-check` with the text, or `memory-search` with one or two queries and `intent: "dedup before store"`.\n2. A near-duplicate exists: `memory-edit` it. Mode `replace` for a rewrite, mode `exact` for a one-line correction. Say why in `intent`.\n3. Nothing close exists: `memory-store`. For a keyed memory, `memory-search` with `keyPrefix` set to the folder you will write into shows what is already there.\n\n## Triage\n\n- A memory is wrong: `memory-edit` with the correction.\n- A memory is stale and nobody needs it: `memory-delete`.\n- A recalled memory helped or misled you: `memory_rate` with `useful` true or false and a short `note`. The call needs a task context and counts once per memory per task. Ratings move the memory up or down in future searches.\n\n## Lead: promote a learning\n\nWhen a worker\'s output or failure holds a lesson other workers need, call `inject-learning` with the worker\'s `agentId`, the `learning`, and a `category`: `mistake-pattern`, `best-practice`, `codebase-knowledge`, or `preference`. It lands at swarm scope and every agent recalls it. It is stored as `manual`, so it never expires, but it takes no key: it has no path weight and `keyPrefix` does not find it. To file a learning by path, `memory-store` it with a `/longterm` key, or `memory-edit` it with `newKey`.\n';
+var content_default26 = '# Memory\n\nSwarm memory is a store of short texts with embeddings, searchable by meaning and by keyword. Recall is automatic: the runner puts the best matches for your task in the task message under "Relevant Past Knowledge". Everything else is a tool call.\n\n## What is stored without you\n\n| Source | When | Scope |\n|---|---|---|\n| `task_completion` | `store-progress` with status `completed` or `failed` | `agent`, or `swarm` for research tasks and tasks tagged `knowledge` or `shared` |\n| `session_summary` | your session ends | `agent` |\n| `file_index` | a file written under `/workspace/personal/memory/` or `/workspace/shared/memory/<agentId>/` on a harness with the file hook (claude, pi, opencode) | by path |\n\nAutomatic tasks (schedules, heartbeat, monitors) skip the `task_completion` write unless `store-progress` gets `persistMemory: true`.\n\nPrefer `memory-store` over memory files. It works on every harness, including the remote ones.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `memory-store` | create a memory: `content`, `name`, `scope`, optional `tags`, `taskId`, `intent`, `key` (a logical path, see Logical paths) |\n| `memory-search` | find memories: `query`, `scope` (`all`, `agent`, `swarm`), `limit`, optional `intent` (why you search), `source`, `keyPrefix` (only memories whose key starts with it) |\n| `memory-get` | the full content of one memory by ID |\n| `memory-edit` | change a memory in place: mode `replace` (whole content) or `exact` (one unique substring), `intent` required. `newKey` alone moves it to another logical path |\n| `memory-delete` | remove a memory by ID |\n| `memory_rate` | mark a memory you used in this task as useful or misleading |\n| `inject-learning` | lead only: push a learning into a worker\'s memory at swarm scope |\n\nSeed scripts (`script-run` with `name` and `args`):\n\n- `task-context-gathering` `{ taskId, queries: [...] }`: the task plus a deduplicated multi-query recall in one call.\n- `smart-recall` `{ queries: [...] }`: multi-query recall without the task.\n- `memory-dedup-check` `{ text, threshold? }`: near-duplicates of a candidate memory, default threshold 0.85.\n\n## What makes a good memory\n\n- One fact per memory: a fix, a pattern, a gotcha, a preference of a person, a fact about a repo or a host.\n- The context it applies to: repo, host, tool, version.\n- The evidence: what you saw, where.\n- A searchable `name`: "Linear API rejects issue updates without teamId", not "notes".\n- Under 2,000 characters stores as one chunk. Longer content splits on headings, one memory per chunk.\n\nSkip what a tool returns on demand (paths, tool lists, task status), what the repo already records (README, CLAUDE.md, git history), and what only mattered for this one task.\n\nA memory must not contain a token, password, key, or connection string. Remove the value and keep the reference ("the Linear token lives in config key LINEAR_API_KEY").\n\n## Scope\n\n- `agent` (default): only you recall it. Your own setup, your working notes, your mistakes.\n- `swarm`: every agent recalls it. Facts about shared repos, hosts, people, and processes. Choose `swarm` when a second agent would hit the same thing.\n\n## Logical paths (`key`)\n\nEvery memory has a `key`. By default it is an auto key (`<scope>/<source>/<id>`, or the file path for `file_index`), and the memory is **inbox material**: it keeps the lifecycle of its `source` and expires. Give it a path under `/longterm` and it becomes curated memory: findable by folder, ranked higher, and kept.\n\n`name` is a title. `key` is the address. Use a key only for what should outlive the task: a durable fact, a decision, a person or customer. Leave working notes and task results without one; expiring is the right outcome for them.\n\n### The `/longterm` roots\n\nThe list is closed. A key under `/longterm` whose second segment is not in it is refused, and the error lists the roots.\n\n| Root | Holds | Rank weight | Who may write |\n|---|---|---|---|\n| `/longterm/company-story` | what the company is and does | 1.4 | lead only |\n| `/longterm/entities/people/<slug>`, `/longterm/entities/customers/<slug>` | one doc per person or customer | 1.3 | lead only |\n| `/longterm/facts/<topic>/<slug>` | a durable fact about a repo, host, tool, or process | 1.2 | any agent |\n| `/longterm/decisions/<slug>` | a decision and why | 1.1 (0.3 with the tag `superseded`) | any agent |\n| `/longterm/workstreams/<slug>` | an ongoing effort | 1.0 | any agent |\n| `/longterm/timeline/<period>/<slug>` | dated events | 0.8 | lead only |\n\nAgents and repos are not entity types: agent profiles and `get-repos` own them, so `/longterm/entities/agents/...` is refused.\n\nKey shape: lowercase letters, digits, `-`, and `.` or `_` after the first segment; segments joined by `/`; starts with `/`; no trailing `/`; at most 200 characters. A key outside `/longterm` is not root-checked but must still have this shape.\n\n### Write, move, find\n\n```\nmemory-store key="/longterm/facts/swarm-runtime/sqlite-busy-retry" scope="swarm"\n  name="SQLite BUSY_SNAPSHOT needs BEGIN IMMEDIATE" content="..."\n\nmemory-edit memoryId="<id>" newKey="/longterm/decisions/sqlite-busy-retry" intent="promote the fact to a decision"\n\nmemory-search query="busy retry" keyPrefix="/longterm/facts/swarm-runtime/"\n```\n\n- `memory-store`: one key per owner and scope. A second memory under a key you already use fails: `memory-edit` that one. If you pass no `key` and the `name` starts with `/longterm/`, the name is the key, so you set one field. An invalid name of that form is refused, never stored under an auto key.\n- `memory-edit` `newKey`: pass it alone for a pure move. Every chunk of the document moves in one step. The ID, usefulness rating, access counts, and author stay. A key that is already taken is refused. Address the memory with `memoryId`, or with `key` plus `scope`.\n- `memory-search` `keyPrefix`: a literal, case-sensitive prefix, applied before the top results are cut, not after. End a folder with `/` (`/longterm/entities/`, not `/longterm/entities`) to stay inside it.\n\n### What a `/longterm` key changes\n\n`source` stays provenance: there is no `longterm` source. The key is the tier. A memory under `/longterm` follows a `manual` memory\'s lifecycle whatever its `source`:\n\n- It never expires. Storing under a `/longterm` key sets no expiry. Moving a memory in with `newKey` clears the expiry it had, on every chunk. Moving it back out does not restore one.\n- It has no recency decay, and its source-quality multiplier is 1.5.\n- Automated cleanup skips it.\n\nA memory under any other key keeps its `source` lifecycle: `task_completion` expires after 7 days, `session_summary` after 3, `file_index` after 30, `manual` never.\n\nRanking multiplies similarity by recency decay, access boost, source quality, **path weight** (the table above, by longest matching root; any other key weighs 1.0), and usefulness. Path weight is one factor: a weak match under `/longterm/company-story` does not beat a strong match elsewhere on weight alone.\n\n### Lead-only roots\n\nOnly the lead may write or move a key under `/longterm/company-story`, `/longterm/entities`, or `/longterm/timeline`. The check is the permission `memory.write.consolidated`. It applies to a `key`, to a `newKey`, to a `/longterm/` name, and to a `sourcePath` sent to `POST /api/memory/index`, so there is no side door. A worker that tries gets an error naming the lead-only paths. A worker puts durable knowledge under `/longterm/facts` or `/longterm/decisions`, or leaves the key off, and the lead consolidates the rest.\n\n## Before you store\n\n1. Run `memory-dedup-check` with the text, or `memory-search` with one or two queries and `intent: "dedup before store"`.\n2. A near-duplicate exists: `memory-edit` it. Mode `replace` for a rewrite, mode `exact` for a one-line correction. Say why in `intent`.\n3. Nothing close exists: `memory-store`. For a keyed memory, `memory-search` with `keyPrefix` set to the folder you will write into shows what is already there.\n\n## Triage\n\n- A memory is wrong: `memory-edit` with the correction.\n- A memory is stale and nobody needs it: `memory-delete`.\n- A recalled memory helped or misled you: `memory_rate` with `useful` true or false and a short `note`. The call needs a task context and counts once per memory per task. Ratings move the memory up or down in future searches.\n\n## Lead: promote a learning\n\nWhen a worker\'s output or failure holds a lesson other workers need, call `inject-learning` with the worker\'s `agentId`, the `learning`, and a `category`: `mistake-pattern`, `best-practice`, `codebase-knowledge`, or `preference`. It lands at swarm scope and every agent recalls it. It is stored as `manual`, so it never expires, but it takes no key: it has no path weight and `keyPrefix` does not find it. To file a learning by path, `memory-store` it with a `/longterm` key, or `memory-edit` it with `newKey`.\n';
 
 // templates/skills/one-shot/config.json
-var config_default26 = `{
+var config_default27 = `{
   "category": "skills",
   "description": "Small-scope plan+implement in one session. Assess the prompt, optionally one bundled round of questions, maintain a lightweight yolo plan while implementing, verify, quick code review, commit. Use when the user invokes /one-shot, or asks to \\"just build/fix/add\\" something small without the full create-plan → implement-plan pipeline. Small means ≤ ~3 phases inside one subsystem — anything bigger escalates to /desplega:create-plan.",
   "displayName": "One Shot",
@@ -8603,7 +8418,7 @@ var config_default26 = `{
 `;
 
 // templates/skills/one-shot/content.md
-var content_default26 = `# One-Shot
+var content_default27 = `# One-Shot
 
 Plan and implement a small task in a single session. This is the lightweight sibling of the \`create-plan\` → \`implement-plan\` pipeline: same discipline (written plan, verification, code review), a fraction of the ceremony.
 
@@ -8672,7 +8487,7 @@ Commit with a concise message referencing the change (only if the user hasn't sa
 `;
 
 // templates/skills/pages/config.json
-var config_default27 = `{
+var config_default28 = `{
   "kind": "skill",
   "name": "pages",
   "displayName": "Pages",
@@ -8695,11 +8510,11 @@ var config_default27 = `{
 `;
 
 // templates/skills/pages/content.md
-var content_default27 = `# Pages — DB-backed Static Artifacts
+var content_default28 = `# Pages — DB-backed Static Artifacts
 
 DB-backed static content (HTML or JSON) served by the API directly. Cheap,
-versioned, share-able by URL. The lighter-weight cousin of \`artifacts\` —
-no PM2, no tunnels, no port allocation, no \`services\` registry row.
+versioned, share-able by URL. No server process, no tunnel, no port
+allocation.
 
 A page should be a clean human-facing artifact, not a raw dump with a URL. This
 skill covers both halves: **how to publish** a page, and **the taste baseline**
@@ -8710,7 +8525,7 @@ every page should meet.
 > (e.g. \`CAPABILITIES=core,task-pool,pages\`). If the tool is missing from
 > your MCP list, this is why.
 
-## When to use Pages vs Artifacts
+## When to use Pages vs Apps
 
 | You need… | Use |
 |---|---|
@@ -8718,12 +8533,11 @@ every page should meet.
 | A JSON status payload + a few buttons that call swarm APIs | **Pages** (\`contentType: 'application/json'\`) |
 | To share an output via a URL with no server logic | **Pages** |
 | Analysis that should be linkable and bookmarkable | **Pages** |
-| Custom routes, websockets, server-side logic | The **\`artifacts\`** skill |
-| File uploads or per-request computation | The **\`artifacts\`** skill |
+| Persistent records, queries, and server-side actions | The **\`apps\`** skill |
+| Large or binary files (PNG, MP4, exports) | The **\`agent-fs\`** skill |
 
 Rule of thumb: if the content is a snapshot (you can write the full HTML/JSON
-in a single call), use pages. If the content is a *running program*, use
-artifacts.
+in a single call), use pages. If it needs stored data and actions, use apps.
 
 Do **not** use pages for:
 
@@ -9230,9 +9044,8 @@ human-facing summary.
 
 ## See Also
 
-- The **\`artifacts\`** skill — durable storage (agent-fs, shared workspace) plus
-  full custom Hono apps with PM2 + a tunneled subdomain. Use it for interactive
-  servers, not static content.
+- The **\`apps\`** skill — schema-backed records, named queries, and actions.
+- The **\`agent-fs\`** skill — durable file storage and share links.
 - The **\`kv-storage\`** skill — page-scoped state via \`swarmSdk.kv\`.
 - \`runbooks/secret-scrubbing.md\` — egress scrubbing details.
 - SPA listing: \`\${APP_URL}/pages\` — the same \`APP_URL\` used for share links above.
@@ -9387,7 +9200,7 @@ Channels cannot access internal workflow topics. The socket closes when its auth
 `;
 
 // templates/skills/phase-running/config.json
-var config_default28 = `{
+var config_default29 = `{
   "category": "skills",
   "description": "Execute individual plan phases as background sub-agents for context-efficient implementation.",
   "displayName": "Phase Running",
@@ -9408,7 +9221,7 @@ var config_default28 = `{
 `;
 
 // templates/skills/phase-running/content.md
-var content_default28 = `# Phase Running
+var content_default29 = `# Phase Running
 
 You are executing a single phase of an implementation plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.
 
@@ -9540,7 +9353,7 @@ Phase agents are atomic — they run to completion or stop:
 `;
 
 // templates/skills/planning/config.json
-var config_default29 = `{
+var config_default30 = `{
   "category": "skills",
   "description": "Implementation planning skill. Creates detailed technical plans through interactive research and iteration.",
   "displayName": "Planning",
@@ -9561,7 +9374,7 @@ var config_default29 = `{
 `;
 
 // templates/skills/planning/content.md
-var content_default29 = `# Planning
+var content_default30 = `# Planning
 
 You create detailed implementation plans through an interactive, iterative process. Be skeptical, thorough, collaborative.
 
@@ -9636,7 +9449,7 @@ Canonical format and heading hierarchy lives in \`template.md\`. Structure valid
 `;
 
 // templates/skills/qa/config.json
-var config_default30 = `{
+var config_default31 = `{
   "category": "skills",
   "description": "Functional validation skill. Captures test evidence (screenshots, recordings, links) and produces QA reports in thoughts/*/qa/.",
   "displayName": "QA",
@@ -9657,7 +9470,7 @@ var config_default30 = `{
 `;
 
 // templates/skills/qa/content.md
-var content_default30 = `# QA
+var content_default31 = `# QA
 
 You are performing functional validation of a feature, bugfix, or deployment. Your job is to prove it works (or doesn't) by executing test scenarios and capturing evidence.
 
@@ -9842,85 +9655,292 @@ Based on the answer:
 - **Done**: Finalize the QA report
 `;
 
-// templates/skills/questioning/config.json
-var config_default31 = `{
+// templates/skills/qa-loom/config.json
+var config_default32 = `{
   "category": "skills",
-  "description": "One-shot question answering using the research process. Answers inline without generating documents, then offers handoff to brainstorm or research.",
-  "displayName": "Questioning",
+  "description": "Narrated QA loom for UI work: record a UI QA pass with agent-browser and a timestamped step log, voice it with ElevenLabs, burn one-line subtitles with ffmpeg, and embed the narrated mp4 (plus an optional GIF preview) in the PR as GitHub user attachments. Use on UI-changing PRs and UI QA passes. Layers on the \`qa\` and \`agent-browser\` skills. Needs ELEVENLABS_API_KEY, ffmpeg with libass, and agent-browser.",
+  "displayName": "QA Loom",
   "kind": "skill",
-  "name": "questioning",
+  "name": "qa-loom",
   "placeholders": [],
   "runAllSeedersCandidate": true,
-  "slug": "questioning",
+  "slug": "qa-loom",
   "systemDefault": true,
-  "tags": [
-    "research",
-    "questions",
-    "analysis"
-  ],
-  "title": "Questioning",
+  "tags": ["qa", "video", "screen-recording", "evidence", "elevenlabs"],
+  "title": "QA Loom",
   "version": "1.0.0"
 }
 `;
 
-// templates/skills/questioning/content.md
-var content_default31 = `# Questioning
+// templates/skills/qa-loom/content.md
+var content_default32 = `# QA loom
 
-You are answering a question directly and concisely using the research process. No documents are created by default — the answer is the deliverable.
+A QA loom is a short screen recording of a real UI QA pass, with a voice-over and small one-line subtitles, embedded in the PR. The narrated mp4 plays inline on GitHub with audio. An optional subtitled GIF gives a silent preview.
 
-## When to Use
+Two bundled files ship next to this skill:
 
-This skill activates when:
-- User invokes \`/question\` command
-- Another skill references \`desplega:questioning\`
-- User asks a focused question that doesn't need a full research document
+- \`run-qa.sh\` records the QA pass with \`agent-browser\` and writes \`steps.json\`.
+- \`build-loom.mjs\` turns \`steps.json\` and the raw recording into \`qa-loom.mp4\`.
 
-## Philosophy
+Copy both into your working directory before you edit them.
 
-This is the fastest path from question to answer. Unlike \`/research\` (which documents comprehensively) or \`/brainstorm\` (which explores interactively), \`/question\` gets straight to the point:
+## When to use
 
-1. Hear the question
-2. Investigate as needed
-3. Answer inline
-4. Offer next steps
+- On every PR that changes visible UI, and on every UI QA pass.
+- Run your normal QA with the \`qa\` skill. Drive the browser with the \`agent-browser\` skill. This skill adds recording, narration and delivery on top.
+- Skip it when a PR has no visible UI change.
 
-**No ceremony** — no autonomy prompts, no preference setup, no working agreement. Just answer the question.
+## Requirements
 
-When you do need to ask the user something (handoff, follow-up choice), use \`AskUserQuestion\` per \`desplega:ask-user\` conventions.
+Check these first. If one is missing, use the fallback in section 7.
 
-## Process
+| Requirement | Check |
+|---|---|
+| \`ELEVENLABS_API_KEY\` env var | \`test -n "$ELEVENLABS_API_KEY"\` (never echo the value) |
+| \`agent-browser\` with recording | \`command -v agent-browser\`; on errors, \`agent-browser doctor\` |
+| \`ffmpeg\` built with libass | \`ffmpeg -hide_banner -filters 2>/dev/null \\| grep -w ass\` |
+| Node 18+ or Bun | \`node --version\` (the script needs global \`fetch\` and top-level await) |
+| \`jq\` and GNU \`date\` | \`jq --version\`; \`date +%N\` prints digits, not \`N\` |
+| A subtitle font | \`fc-list \\| grep -i "DejaVu Sans"\`, or set \`FONT\` to an installed font |
+| \`GITHUB_TOKEN\` for delivery | a token that can upload user attachments to the repo (section 6) |
 
-### Step 1: Analyze the Question
+Portability gotchas:
 
-Classify the question to determine what investigation is needed:
+- Some ffmpeg builds ship without \`ffprobe\`. Probe with \`ffmpeg -hide_banner -i f.mp4 2>&1 | grep -E "Duration|Stream"\`.
+- Some ffmpeg builds have no \`drawtext\` filter. Burn subtitles with the libass \`ass\` filter, as \`build-loom.mjs\` does.
+- libass ignores the alpha byte of \`BackColour\` for \`BorderStyle=3\`. The subtitle box is solid dark grey, not translucent.
+- Minimal containers may lack \`bc\`. Do time arithmetic in \`jq\`, as \`run-qa.sh\` does.
 
-| Question Type | Investigation Needed | Example |
-|---------------|---------------------|---------|
-| **Factual/locational** | Quick codebase search | "Where is the auth middleware defined?" |
-| **Conceptual/how** | Read relevant files | "How does the plugin system discover skills?" |
-| **Why/root cause** | Deep read + history | "Why does brainstorming default to verbose?" |
-| **Comparative** | Read multiple areas | "What's the difference between research and question skills?" |
-| **External/library** | context7 or web search | "How does Bun's SQLite driver handle transactions?" |
+## Style rules
 
-### Step 2: Investigate
+- **Speed 1.33x** on the raw footage (\`SPEED=1.33\`). 2x is too fast to follow.
+- **One short sentence per step**, present tense, describing what the viewer sees: "The editor opens a shared file." Aim for 6 to 12 words.
+- **Subtitles: one line, small, bottom centre.** 38 px on a 1080p frame, dark box, \`MarginV 30\`. Cues hold at most 6 words, split on punctuation, with no orphan cue under 3 words.
+- **Voice and subtitles start when the screen renders**, not when the click fires. That is why the step log carries \`visualAt\`.
+- **Letterbox, never stretch.** Mobile-viewport steps are fitted into 1920x1080 with padding.
+- **Keep it short.** 4 to 6 steps that prove the change, about 20 to 30 seconds final.
 
-Based on the question type, use the appropriate tools. **Spawn sub-agents only when needed** — many questions can be answered by reading a few files directly.
+## Context hygiene
 
-**For codebase questions:**
-- Read directly mentioned files first (use Read tool WITHOUT limit/offset)
-- Use **codebase-locator** agent if you need to find WHERE something lives
-- Use **codebase-analyzer** agent if you need to understand HOW something works
-- Use **codebase-pattern-finder** agent if you need examples of a pattern
+The pipeline handles large binary payloads. Keep them out of your context:
 
-**For library/framework questions:**
-- Use context7 MCP to fetch documentation (\`resolve-library-id\` → \`query-docs\`)
+- Run every ffmpeg call with \`-loglevel error\`, or send its stderr to a file and \`tail -3\` it only on failure.
+- Never print an ElevenLabs response. \`audio_base64\` is hundreds of KB. \`build-loom.mjs\` writes it straight to disk.
+- Never \`cat\` or read an mp4 or GIF. To look at the result, extract one PNG frame and view that.
 
-**For external/web questions:**
-- Use **web-search-researcher** agent for documentation or examples
+## 1. Record the QA pass with a step log
 
-**Efficiency rule**: If you can answer by reading 1-3 files, just read them. Don't spawn sub-agents for simple lookups.
+Each step logs:
 
-### Step 3: Answer
+- \`start\`: just before the action fires (\`act\`).
+- \`visualAt\`: after the resulting screen has rendered, following an \`agent-browser wait <selector>\` (\`step\`).
+- \`verdict\` and one \`narration\` sentence.
+- \`end\`: the next step's \`start\`. The last step ends when recording stops.
+
+All times are seconds from recording start. Replace the example steps in \`run-qa.sh\` with your QA steps, then run it:
+
+\`\`\`bash
+BASE_URL=http://localhost:5274 OUT=./loom bash run-qa.sh
+\`\`\`
+
+Notes:
+
+- Log in and seed data **before** \`record start\`, so the loom shows only the change.
+- For a mobile check, run \`agent-browser set viewport 390 844\` inside a step. The build letterboxes it.
+- After each step, wait about 800 ms so the viewer sees the result before the next action.
+- Take your normal QA screenshots as well. They are the fallback.
+
+## 2. Build the narrated mp4
+
+\`build-loom.mjs\` reads \`steps.json\` and the raw recording. For each step it:
+
+1. Calls ElevenLabs \`POST /v1/text-to-speech/{voice}/with-timestamps\` once and caches the mp3 and character alignment under \`work/\`. A re-run after a style tweak costs no characters.
+2. Cuts the step's segment, speeds it up, and letterboxes it to 1920x1080 at 30 fps.
+3. Freezes the last frame when the narration outlasts the segment.
+4. Builds subtitle cues from the same character alignment, offset by \`visualAt\`, so voice and subtitles cannot drift.
+
+Then it concatenates the segments with the concat demuxer, delays each step's audio to where its screen renders, mixes with \`amix normalize=0\`, burns the ASS subtitles, and writes \`qa-loom.mp4\` and \`qa-loom.ass\`.
+
+\`\`\`bash
+node build-loom.mjs loom/steps.json loom/raw.webm loom/out > loom/build.log 2>&1 || tail -5 loom/build.log
+cat loom/build.log   # one JSON line: {"durationS":..,"steps":..,"cues":..,"chars":..}
+\`\`\`
+
+Optional env: \`SPEED\` (default \`1.33\`), \`VOICE\` (default \`21m00Tcm4TlvDq8ikWAM\`, an ElevenLabs premade voice), \`MODEL\` (default \`eleven_turbo_v2_5\`), \`FONT\` (default \`DejaVu Sans\`).
+
+## 3. Check the result
+
+Look at one frame per cue, as PNG:
+
+\`\`\`bash
+cd loom/out
+ffmpeg -hide_banner -i qa-loom.mp4 2>&1 | grep -E "Duration|Stream"          # 1920x1080, 30 fps, h264 + aac
+grep Dialogue qa-loom.ass                                                     # one short line per cue
+ffmpeg -hide_banner -i qa-loom.mp4 -vn -af volumedetect -f null - 2>&1 | grep mean_volume   # about -91 dB means silent
+ffmpeg -y -loglevel error -ss 2 -i qa-loom.mp4 -frames:v 1 check-2s.png       # view it: the subtitle matches the screen
+\`\`\`
+
+If the loom feels slow or fast, change \`SPEED\` and re-run. TTS is cached, so the re-run is free.
+
+## 4. Optional GIF preview
+
+GitHub plays an mp4 inline only when it is a GitHub user attachment (section 6). The GIF is an optional silent preview with the subtitles already burned in.
+
+\`\`\`bash
+ffmpeg -y -loglevel error -i qa-loom.mp4 \\
+  -vf "fps=10,scale=960:-1:flags=lanczos,split[a][b];[a]palettegen=stats_mode=diff[p];[b][p]paletteuse=dither=bayer:bayer_scale=5:diff_mode=rectangle" \\
+  -loop 0 qa-loom.gif 2>gif.err || tail -3 gif.err
+ffmpeg -hide_banner -i qa-loom.gif 2>&1 | grep -E "Duration|Stream"   # 960x540, 10 fps
+head -c 6 qa-loom.gif; echo                                           # GIF89a
+ffmpeg -y -loglevel error -ss 5 -i qa-loom.gif -frames:v 1 gif-check.png   # view it: subtitle readable
+\`\`\`
+
+At these settings a GIF costs about 30 KB per second of loom. Keep it under 5 MB. If it is bigger, drop to \`fps=8\`, then to \`scale=720:-1\`. Below 720 px wide the subtitles become unreadable.
+
+## 5. Keep the originals
+
+Store \`qa-loom.mp4\` and \`qa-loom.gif\` wherever your team keeps QA evidence, next to the QA screenshots, under the same topic name. The GitHub attachment is the embed; your store is the durable original.
+
+## 6. Attach to the PR
+
+Upload both files to GitHub as user attachments. This uses GitHub's user-attachments upload endpoint, the one the web editor uses. It is not part of the documented REST API.
+
+\`\`\`bash
+REPO=<owner>/<repo>
+REPO_ID=$(gh api "repos/$REPO" --jq .id)
+attach() {  # $1 local file, $2 content type; prints https://github.com/user-attachments/assets/<uuid>
+  q=$(jq -rn --arg name "$(basename "$1")" --arg content_type "$2" --arg repository_id "$REPO_ID" \\
+    '$ARGS.named | to_entries | map("\\(.key)=\\(.value | @uri)") | join("&")')
+  curl --fail-with-body -sS -X POST "https://uploads.github.com/user-attachments/assets?$q" \\
+    -H "Authorization: Bearer $GITHUB_TOKEN" -H 'Content-Type: application/octet-stream' \\
+    --data-binary "@$1" | jq -er .url
+}
+MP4_URL=$(attach qa-loom.mp4 video/mp4)
+GIF_URL=$(attach qa-loom.gif image/gif)
+echo "$MP4_URL $GIF_URL"
+\`\`\`
+
+Verification rules:
+
+- Both URLs must match \`https://github.com/user-attachments/assets/<uuid>\`.
+- A 401 means the token type is not accepted (GitHub App installation tokens are rejected; a personal access token works). A 404 means a wrong repository ID or a token without write access to the repo.
+- Do not embed presigned storage URLs. A presigned mp4 usually downloads instead of playing, and it expires.
+
+Put the loom in the PR body's \`## Before / after\` section. Write the section to a file:
+
+\`\`\`bash
+cat > loom-section.md <<EOF
+QA loom: <one-line summary>. <n> steps, <verdicts>.
+
+$MP4_URL
+
+![QA loom preview (silent, subtitled)]($GIF_URL)
+EOF
+\`\`\`
+
+\`$MP4_URL\` must sit on its own line, so GitHub renders a player with audio. The GIF line is optional. Merge the section into the body (\`gh pr view <n> --json body\`, then \`gh pr edit <n> --body-file <file>\`) and leave every other line unchanged.
+
+Then open the PR and confirm that the mp4 player and the GIF render. A successful upload response does not prove that the embed renders.
+
+## 7. Fallback: never block the PR
+
+If ElevenLabs fails (401, 429, quota, or a 5xx after one retry with backoff), ffmpeg fails, or a requirement is missing:
+
+1. Post the QA screenshots in the PR as GitHub user attachments.
+2. Add one line to the PR that says why there is no loom, for example "QA loom skipped: ElevenLabs 429 quota exceeded."
+3. Ship the PR. The loom is evidence, never a merge gate.
+
+A 4xx validation error is deterministic. Do not loop on it. Fix the input or fall back.
+
+## Deliverable checklist
+
+- [ ] \`steps.json\` has \`start\`, \`visualAt\`, \`end\`, \`verdict\` and \`narration\` for every step
+- [ ] \`qa-loom.mp4\` is 1920x1080 at 30 fps with h264 and aac, is not silent, and shows one short subtitle line at the bottom
+- [ ] \`qa-loom.gif\`, if made, is 960 px wide at 10 fps, under 5 MB, and starts with \`GIF89a\`
+- [ ] The originals are stored with the QA screenshots
+- [ ] The PR body's \`## Before / after\` section has \`$MP4_URL\` on its own line, and every URL is \`https://github.com/user-attachments/assets/<uuid>\`
+- [ ] You opened the PR and saw the player render
+`;
+
+// templates/skills/questioning/config.json
+var config_default33 = `{
+  "category": "skills",
+  "description": "One-shot question answering using the research process. Answers inline without generating documents, then offers handoff to brainstorm or research.",
+  "displayName": "Questioning",
+  "kind": "skill",
+  "name": "questioning",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "slug": "questioning",
+  "systemDefault": true,
+  "tags": [
+    "research",
+    "questions",
+    "analysis"
+  ],
+  "title": "Questioning",
+  "version": "1.0.0"
+}
+`;
+
+// templates/skills/questioning/content.md
+var content_default33 = `# Questioning
+
+You are answering a question directly and concisely using the research process. No documents are created by default — the answer is the deliverable.
+
+## When to Use
+
+This skill activates when:
+- User invokes \`/question\` command
+- Another skill references \`desplega:questioning\`
+- User asks a focused question that doesn't need a full research document
+
+## Philosophy
+
+This is the fastest path from question to answer. Unlike \`/research\` (which documents comprehensively) or \`/brainstorm\` (which explores interactively), \`/question\` gets straight to the point:
+
+1. Hear the question
+2. Investigate as needed
+3. Answer inline
+4. Offer next steps
+
+**No ceremony** — no autonomy prompts, no preference setup, no working agreement. Just answer the question.
+
+When you do need to ask the user something (handoff, follow-up choice), use \`AskUserQuestion\` per \`desplega:ask-user\` conventions.
+
+## Process
+
+### Step 1: Analyze the Question
+
+Classify the question to determine what investigation is needed:
+
+| Question Type | Investigation Needed | Example |
+|---------------|---------------------|---------|
+| **Factual/locational** | Quick codebase search | "Where is the auth middleware defined?" |
+| **Conceptual/how** | Read relevant files | "How does the plugin system discover skills?" |
+| **Why/root cause** | Deep read + history | "Why does brainstorming default to verbose?" |
+| **Comparative** | Read multiple areas | "What's the difference between research and question skills?" |
+| **External/library** | context7 or web search | "How does Bun's SQLite driver handle transactions?" |
+
+### Step 2: Investigate
+
+Based on the question type, use the appropriate tools. **Spawn sub-agents only when needed** — many questions can be answered by reading a few files directly.
+
+**For codebase questions:**
+- Read directly mentioned files first (use Read tool WITHOUT limit/offset)
+- Use **codebase-locator** agent if you need to find WHERE something lives
+- Use **codebase-analyzer** agent if you need to understand HOW something works
+- Use **codebase-pattern-finder** agent if you need examples of a pattern
+
+**For library/framework questions:**
+- Use context7 MCP to fetch documentation (\`resolve-library-id\` → \`query-docs\`)
+
+**For external/web questions:**
+- Use **web-search-researcher** agent for documentation or examples
+
+**Efficiency rule**: If you can answer by reading 1-3 files, just read them. Don't spawn sub-agents for simple lookups.
+
+### Step 3: Answer
 
 Present the answer as **inline text** (not a document). Structure it naturally based on the question:
 
@@ -9975,7 +9995,7 @@ Each iteration is independent — no state accumulates between questions unless
 `;
 
 // templates/skills/researching/config.json
-var config_default32 = `{
+var config_default34 = `{
   "category": "skills",
   "description": "Comprehensive codebase research skill. Documents codebase as-is by spawning parallel sub-agents and synthesizing findings into research documents.",
   "displayName": "Researching",
@@ -9996,7 +10016,7 @@ var config_default32 = `{
 `;
 
 // templates/skills/researching/content.md
-var content_default32 = `# Researching
+var content_default34 = `# Researching
 
 You are conducting comprehensive research across the codebase to answer questions by spawning parallel sub-agents and synthesizing their findings.
 
@@ -10165,7 +10185,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/review-offered-task/config.json
-var config_default33 = `{
+var config_default35 = `{
   "kind": "skill",
   "name": "review-offered-task",
   "displayName": "Review Offered Task",
@@ -10182,10 +10202,10 @@ var config_default33 = `{
 `;
 
 // templates/skills/review-offered-task/content.md
-var content_default33 = '# Review Offered Task\n\nYou have been offered a task. Your job is to review it and decide whether to accept or reject it based on your capabilities and current workload.\n\n## Workflow\n\n1. **Get task details**: Call the `get-task-details` tool with the provided `taskId` to understand what the task involves.\n\n2. **Evaluate the task**: Consider:\n   - Does this task match your capabilities?\n   - Do you have the necessary context or access to complete it?\n   - Is the task description clear enough to proceed?\n\n3. **Make a decision**:\n   - **Accept**: If you can complete this task, call `task-action` with `action: "accept"` and `taskId: "<taskId>"`. Then immediately use the `work-on-task` skill with the taskId to start working on it.\n   - **Reject**: If you cannot complete this task, call `task-action` with `action: "reject"`, `taskId: "<taskId>"`, and provide a `reason` explaining why you\'re rejecting it (e.g., "Task requires Python expertise which I don\'t have", "Task description is too vague").\n\n## Example Accept Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="accept" taskId="abc-123"\n4. /work-on-task abc-123\n```\n\n## Example Reject Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="reject" taskId="abc-123" reason="Task requires access to production database which I don\'t have"\n4. Stop\n```\n\n## Important Notes\n\n- Always provide a clear reason when rejecting a task - this helps the lead agent reassign it appropriately\n- If you accept, you must immediately start working on the task using the `work-on-task` skill\n- If you reject, the task returns to the unassigned pool for reassignment\n';
+var content_default35 = '# Review Offered Task\n\nYou have been offered a task. Your job is to review it and decide whether to accept or reject it based on your capabilities and current workload.\n\n## Workflow\n\n1. **Get task details**: Call the `get-task-details` tool with the provided `taskId` to understand what the task involves.\n\n2. **Evaluate the task**: Consider:\n   - Does this task match your capabilities?\n   - Do you have the necessary context or access to complete it?\n   - Is the task description clear enough to proceed?\n\n3. **Make a decision**:\n   - **Accept**: If you can complete this task, call `task-action` with `action: "accept"` and `taskId: "<taskId>"`. Then immediately use the `work-on-task` skill with the taskId to start working on it.\n   - **Reject**: If you cannot complete this task, call `task-action` with `action: "reject"`, `taskId: "<taskId>"`, and provide a `reason` explaining why you\'re rejecting it (e.g., "Task requires Python expertise which I don\'t have", "Task description is too vague").\n\n## Example Accept Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="accept" taskId="abc-123"\n4. /work-on-task abc-123\n```\n\n## Example Reject Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="reject" taskId="abc-123" reason="Task requires access to production database which I don\'t have"\n4. Stop\n```\n\n## Important Notes\n\n- Always provide a clear reason when rejecting a task - this helps the lead agent reassign it appropriately\n- If you accept, you must immediately start working on the task using the `work-on-task` skill\n- If you reject, the task returns to the unassigned pool for reassignment\n';
 
 // templates/skills/reviewing/config.json
-var config_default34 = `{
+var config_default36 = `{
   "category": "skills",
   "description": "Structured critique of research, plan, and brainstorm documents for completeness, gaps, and quality.",
   "displayName": "Reviewing",
@@ -10206,7 +10226,7 @@ var config_default34 = `{
 `;
 
 // templates/skills/reviewing/content.md
-var content_default34 = `# Reviewing
+var content_default36 = `# Reviewing
 
 You are performing a structured critique of a document (research, plan, or brainstorm) to identify gaps, weaknesses, and quality issues. (For reviewing a code diff, use \`desplega:code-reviewing\` instead — this skill reviews documents.)
 
@@ -10458,7 +10478,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/scheduled-task-resilience/config.json
-var config_default35 = `{
+var config_default37 = `{
   "kind": "skill",
   "name": "scheduled-task-resilience",
   "displayName": "Scheduled Task Resilience",
@@ -10475,7 +10495,7 @@ var config_default35 = `{
 `;
 
 // templates/skills/scheduled-task-resilience/content.md
-var content_default35 = `# Scheduled Task Resilience
+var content_default37 = `# Scheduled Task Resilience
 
 Use these rules whenever a scheduled or regular task polls or waits on a long-running operation. They prevent heartbeat collisions, lost work, duplicate delivery, and sessions that fail after holding an external job open too long.
 
@@ -10575,7 +10595,7 @@ When historical incident detail is useful, search the deployment's memory regist
 `;
 
 // templates/skills/scheduling/config.json
-var config_default36 = `{
+var config_default38 = `{
   "kind": "skill",
   "name": "scheduling",
   "displayName": "Scheduling",
@@ -10592,10 +10612,10 @@ var config_default36 = `{
 `;
 
 // templates/skills/scheduling/content.md
-var content_default36 = '# Scheduling\n\nUse a schedule when work repeats on a clock, or when it must run once at a later time. On each tick the schedule creates one run. The run is a workflow, a catalog script, or an agent task.\n\n## Tools\n\n`list-schedules`, `create-schedule`, `update-schedule`, `patch-schedule`, `delete-schedule`, `run-schedule-now`. They are deferred. Load them with your harness tool search before the first call.\n\n## Pick the target type\n\n| The tick should | `targetType` | Required fields |\n|---|---|---|\n| Start a workflow | `workflow` | `workflowId` |\n| Run a catalog script | `script` | `scriptName`, optional `scriptArgs` |\n| Put a reasoning agent in the loop | `agent-task` (default) | `taskTemplate` |\n\nChoose `agent-task` only when the run needs judgment, open-ended work, or tool orchestration that no workflow or script covers. An `agent-task` whose template says "trigger workflow X" or "run script Y" is wrong: use the direct target instead.\n\nThe agent-task fields `targetAgentId`, `model`, `modelTier`, `taskTemplate`, `priority`, and `tags` do not apply to workflow or script targets. Workflow cooldowns still gate workflow targets.\n\n## Pick the timing\n\n| Shape | Fields |\n|---|---|\n| Recurring on a cron | `scheduleType: "recurring"`, `cronExpression` (for example `0 9 * * 1-5`), `timezone` (default `UTC`) |\n| Recurring on an interval | `scheduleType: "recurring"`, `intervalMs` (for example `3600000` for hourly) |\n| Once, at a time | `scheduleType: "one_time"`, `runAt` (ISO datetime) |\n| Once, after a delay | `scheduleType: "one_time"`, `delayMs` |\n\nGive the schedule a unique `name` and a one-line `description` that says what a human gets from it.\n\n## Write the task template (agent-task target)\n\nThe template is the whole task the agent receives. It must state:\n\n- the goal and the inputs (IDs, repo, channel),\n- where the result goes (a page, agent-fs, a Slack thread, a task output),\n- what done looks like.\n\n`targetAgentId` pins the task to one agent. Omit it to use the pool. `modelTier` (`smol`, `regular`, `smart`, `ultra`) is the portable way to pick a model. `model` is a provider-specific override.\n\nTasks created by a schedule are automatic tasks. Their completed output is not stored as memory unless the agent calls `store-progress` with `persistMemory: true`.\n\n## Check back later\n\nA task whose answer needs time (a build, a deploy, a reply) calls `defer-task` with `delayMs` or `runAt`, a `summary` of what you did so far, and a `note` that says what is pending. The tool completes the task and creates the one-off schedule for you. The task reaches its final state (`completed`) on this call, and the `summary` becomes its output. The wake-up task carries the deferred task as its parent, so you receive that task\'s context. Add `checks` to list what to verify on wake-up. Do not hand-roll this with `create-schedule`.\n\nWhen waiting on tasks, include `wakeOn:{event:"settled",taskIds:["<id>"],mode:"all"}` alongside `delayMs` or `runAt`. The displayed time is a ceiling; matching task outcomes wake you sooner. The task whose outcome wakes you creates no separate follow-up for you; the wake-up task is where you review it. In `mode:"all"`, a member that settles while others are pending still creates its follow-up.\n\n## Secrets\n\nA `taskTemplate` and `scriptArgs` are stored as plain text and replayed on every run. They must not contain a token, password, or key. Call the external API from a script through a registered connection or a credential binding instead. See the `swarm-scripts` skill, section Secrets.\n\n## Verify before you leave\n\n1. `run-schedule-now` once and read the run result.\n2. `list-schedules` with `name` to confirm `nextRunAt` and `enabled`.\n3. For a script target, the script must exist at global scope: `script-search` by name.\n\n## Repair a failing schedule\n\nSchedules fail in two places. A schedule whose spawned tasks fail: `get-tasks` with `scheduleId` and `status: "failed"`. A schedule the scheduler could not dispatch at all: `list-schedules` with `lastRunStatus: "failed"` or `consecutiveErrorsMin: 1`; these errors back off and auto-disable after 5. The `list-schedules` filters never see spawned-task failures. Fix the cause, then `run-schedule-now` to confirm. A schedule you cannot fix now: `patch-schedule` with `enabled: false` and say so in your task output. A second schedule next to a broken one is not a fix.\n\n## Related skills\n\n- `scheduled-task-resilience`: waiting on CI, builds, deploys, or other slow jobs inside a scheduled task.\n- `swarm-scripts`: writing the script a `script` target runs.\n- `workflow-iterate`: building and testing the workflow a `workflow` target starts.\n';
+var content_default38 = '# Scheduling\n\nUse a schedule when work repeats on a clock, or when it must run once at a later time. On each tick the schedule creates one run. The run is a workflow, a catalog script, or an agent task.\n\n## Tools\n\n`list-schedules`, `create-schedule`, `update-schedule`, `patch-schedule`, `delete-schedule`, `run-schedule-now`. They are deferred. Load them with your harness tool search before the first call.\n\n## Pick the target type\n\n| The tick should | `targetType` | Required fields |\n|---|---|---|\n| Start a workflow | `workflow` | `workflowId` |\n| Run a catalog script | `script` | `scriptName`, optional `scriptArgs` |\n| Put a reasoning agent in the loop | `agent-task` (default) | `taskTemplate` |\n\nChoose `agent-task` only when the run needs judgment, open-ended work, or tool orchestration that no workflow or script covers. An `agent-task` whose template says "trigger workflow X" or "run script Y" is wrong: use the direct target instead.\n\nThe agent-task fields `targetAgentId`, `model`, `modelTier`, `taskTemplate`, `priority`, and `tags` do not apply to workflow or script targets. Workflow cooldowns still gate workflow targets.\n\n## Pick the timing\n\n| Shape | Fields |\n|---|---|\n| Recurring on a cron | `scheduleType: "recurring"`, `cronExpression` (for example `0 9 * * 1-5`), `timezone` (default `UTC`) |\n| Recurring on an interval | `scheduleType: "recurring"`, `intervalMs` (for example `3600000` for hourly) |\n| Once, at a time | `scheduleType: "one_time"`, `runAt` (ISO datetime) |\n| Once, after a delay | `scheduleType: "one_time"`, `delayMs` |\n\nGive the schedule a unique `name` and a one-line `description` that says what a human gets from it.\n\n## Write the task template (agent-task target)\n\nThe template is the whole task the agent receives. It must state:\n\n- the goal and the inputs (IDs, repo, channel),\n- where the result goes (a page, agent-fs, a Slack thread, a task output),\n- what done looks like.\n\n`targetAgentId` pins the task to one agent. Omit it to use the pool. `modelTier` (`smol`, `regular`, `smart`, `ultra`) is the portable way to pick a model. `model` is a provider-specific override.\n\nTasks created by a schedule are automatic tasks. Their completed output is not stored as memory unless the agent calls `store-progress` with `persistMemory: true`.\n\n## Check back later\n\nA task whose answer needs time (a build, a deploy, a reply) calls `defer-task` with `delayMs` or `runAt`, a `summary` of what you did so far, and a `note` that says what is pending. The tool completes the task and creates the one-off schedule for you. The task reaches its final state (`completed`) on this call, and the `summary` becomes its output. The wake-up task carries the deferred task as its parent, so you receive that task\'s context. Add `checks` to list what to verify on wake-up. Do not hand-roll this with `create-schedule`.\n\nWhen waiting on tasks, include `wakeOn:{event:"settled",taskIds:["<id>"],mode:"all"}` alongside `delayMs` or `runAt`. The displayed time is a ceiling; matching task outcomes wake you sooner. The task whose outcome wakes you creates no separate follow-up for you; the wake-up task is where you review it. In `mode:"all"`, a member that settles while others are pending still creates its follow-up.\n\n## Secrets\n\nA `taskTemplate` and `scriptArgs` are stored as plain text and replayed on every run. They must not contain a token, password, or key. Call the external API from a script through a registered connection or a credential binding instead. See the `swarm-scripts` skill, section Secrets.\n\n## Verify before you leave\n\n1. `run-schedule-now` once and read the run result.\n2. `list-schedules` with `name` to confirm `nextRunAt` and `enabled`.\n3. For a script target, the script must exist at global scope: `script-search` by name.\n\n## Repair a failing schedule\n\nSchedules fail in two places. A schedule whose spawned tasks fail: `get-tasks` with `scheduleId` and `status: "failed"`. A schedule the scheduler could not dispatch at all: `list-schedules` with `lastRunStatus: "failed"` or `consecutiveErrorsMin: 1`; these errors back off and auto-disable after 5. The `list-schedules` filters never see spawned-task failures. Fix the cause, then `run-schedule-now` to confirm. A schedule you cannot fix now: `patch-schedule` with `enabled: false` and say so in your task output. A second schedule next to a broken one is not a fix.\n\n## Related skills\n\n- `scheduled-task-resilience`: waiting on CI, builds, deploys, or other slow jobs inside a scheduled task.\n- `swarm-scripts`: writing the script a `script` target runs.\n- `workflow-iterate`: building and testing the workflow a `workflow` target starts.\n';
 
 // templates/skills/script-builder/config.json
-var config_default37 = `{
+var config_default39 = `{
   "category": "skills",
   "description": "Generate durable, re-runnable scripts from session intent — validation scripts (PASS/FAIL contract) AND gather/bulk scripts (many API/tool calls in code, one derived summary out). Supports TypeScript, Python, Bash with auto-detection, enforces context-optimal output, and auto-documents scripts in CLAUDE.md. Triggers on \\"turn this into a script\\", \\"I want to test/validate X end-to-end\\", \\"wrap this in a re-runnable script\\" — and, critically, whenever you are about to make (or just made) ~10+ similar tool/API calls or any bulk fan-out over a list: that mechanical middle belongs in a script, not in context.",
   "displayName": "Script Builder",
@@ -10616,10 +10636,10 @@ var config_default37 = `{
 `;
 
 // templates/skills/script-builder/content.md
-var content_default37 = "# script-builder\n\nYou are converting session intent into a durable, re-runnable script committed to the target project's `scripts/` directory. Two script classes share one principle — **only the derived answer re-enters context; raw payloads never do**:\n\n- **Validation scripts** (`check-*`, `e2e-*`, `smoke-*`, …): a single PASS/FAIL line + `/tmp` log path on success, full verbose output redirected to a timestamped log file.\n- **Gather/bulk scripts** (`gather-*`, `bulk-*`): replace N similar tool/API calls with one script that loops, filters, and aggregates *in code* — stdout is one compact summary block (JSON or table), raw responses go to the `/tmp` log. Rubric (from production code-mode data): past ~10 items or any fan-out over a list, a script beats individual tool calls by ~100x on context and roughly halves end-to-end cost. Offer the script *before* the fan-out happens when you can see it coming, not just retrospectively.\n\nBoth classes get an `<important if>` block in `CLAUDE.md`/`AGENTS.md` so future agents discover the script when the intent recurs — durable scripts are reusable agent memory: import, don't re-derive.\n\n**Schema discovery happens in code, too**: when scripting against an unfamiliar API, grep/filter its OpenAPI spec or typed client programmatically to find the few relevant endpoints — never paste the full schema into context.\n\n## Working Agreement\n\nThese instructions establish a working agreement between you and the user. The key principles are:\n\n1. **AskUserQuestion is your primary communication tool** - Whenever you need to ask the user anything (clarifications, preferences, decisions, confirmations), use the **AskUserQuestion tool**. Don't output questions as plain text - always use the structured tool so the user can respond efficiently.\n\n2. **Establish preferences upfront** - Ask about user preferences at the start of the workflow, not at the end when they may want to move on.\n\n3. **Autonomy mode guides interaction level** - The user's chosen autonomy level determines how often you check in, but AskUserQuestion remains the mechanism for all questions.\n\n## When to Use\n\nThis skill activates when:\n- User invokes `/script-builder` command\n- Another skill references `**OPTIONAL SUB-SKILL:** desplega:script-builder`\n- A `planning`, `qa`, or `verifying` flow needs a re-runnable validation script that doesn't yet exist\n- The user expresses intent to \"turn X into a script\", \"wrap this validation into something reusable\", or \"I want to test X end-to-end\" with no existing script\n\n## Autonomy Mode\n\nAdapt your behavior based on the autonomy mode:\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Detect mode, draft, syntax-check, document, and (if escalation tier) run + iterate without intermediate confirmations. Pause only at hard blockers or destructive side-effects. |\n| **Critical** (Default) | Confirm at each tier boundary (after draft, before doc edit, before run). Use AskUserQuestion for fix application during iterate loop. |\n| **Verbose** | Confirm before each step. Show every diff. Walk through detection reasoning out loud. |\n\nThe autonomy mode is passed by the invoking command. If not specified, default to **Critical**.\n\n## Process Steps\n\n### Step 1: Detect Mode (Retrospective vs Forward-Declared)\n\nDecide silently — **do not** ask the user \"which mode?\". Use the following heuristics:\n\n1. **Scan recent session tool-use history** (the last ~20 tool calls in the current conversation) for test/validation-shaped activity: `curl`/`fetch` calls, `bun run`/`python`/`pytest`, database queries, `agent-browser` actions, repeated `grep`/log inspection of a single endpoint or table. If ≥2 such actions targeting the same area exist → **retrospective mode**. Separately, if the history (or the task ahead) shows the *same call shape repeated ~10+ times or a fan-out over a list* → **gather-script mode**: propose replacing the repetition with one `gather-*` script before continuing.\n2. **Parse the user's invocation message** for cues:\n   - Narrative cues → retrospective: *\"we just figured out\"*, *\"turn this into a script\"*, *\"wrap that in\"*, *\"that thing we just did\"*.\n   - Intent cues → forward-declared: *\"I want to test\"*, *\"validate that\"*, *\"smoke check\"*, *\"check before deploy\"*.\n3. **Fallback**: when ambiguous, default to **forward-declared**.\n\n**Retrospective first action**: summarize the observed activity back to the user as plain text (≤6 lines: what was probed, against what, with what success signal), then go to Step 3 with a confirmation prompt instead of Q&A.\n\n**Forward first action**: skip directly to Step 3's Q&A.\n\n### Step 2: Scan Existing Scripts for Overlap\n\n**Resolve the scripts directory** in this order:\n1. Check `CLAUDE.md` for a `<!-- script-builder:dir=<path> -->` marker. If present, use that path.\n2. If `scripts/` exists at the repo root, use it.\n3. Use **AskUserQuestion** with options: `scripts/ (Recommended) | custom path | skip dir persistence for this run`.\n\n**Edge case — directory absent**: if the resolved path doesn't exist, skip the dedup scan, print a one-line note (`No existing scripts directory at <path> — proceeding to intent gathering`), and remember to optionally offer to create the directory before Step 5.\n\n**When the directory exists**:\n1. List files in the scripts directory (top-level only for v1).\n2. For each file, read the top of the file (header comment) and capture the file-name tokens.\n3. Read `CLAUDE.md`/`AGENTS.md` for `<important if=\"...\">` blocks that point at scripts in this directory and capture the trigger phrases.\n4. Fuzzy-match the current intent string against (file-name tokens ∪ header keywords ∪ trigger phrases). A \"plausible match\" is shared keyword + same area noun (e.g., `auth`, `health`, `webhook`).\n5. If ≥1 plausible match → use **AskUserQuestion** with options: `Reuse <name> as-is | Extend <name> | Generate new anyway`.\n\nNever silently skip dedup on borderline matches — surface and let the user decide. The **Extend** branch appends a sub-command/flag to the existing script (do not create a new file); document the new flag in the script's header comment and the existing `<important if>` block.\n\n### Step 3: Gather Intent\n\nBoth modes converge on the same internal intent structure: `{ what, success_signal, failure_signal, inputs, env, side_effects }`.\n\n**Forward mode** — use **AskUserQuestion** (one or two questions, not five):\n\n| Question | Options |\n|----------|---------|\n| \"What are we validating, and what's the success signal?\" | [Free text — collect what + success signal in one answer] |\n| \"Any required env vars, inputs, or side-effects to flag (e.g., writes to prod, costs money)?\" | [Free text — optional; skip if forward intent already specified them] |\n\n**Retrospective mode** — present the summary from Step 1 and use **AskUserQuestion** with: `That's the flow | Close but fix X | Start over`. On *Close but fix X*, ask for the correction inline; on *Start over*, fall through to forward-mode Q&A.\n\nPersist the resolved intent in working memory (do not write to disk yet).\n\n### Step 4: Detect Language\n\nPriority order — first match wins, with override paths:\n\n1. **TypeScript** — `package.json` + `tsconfig.json` exist.\n   - **Bun** if `bun.lock` or `bunfig.toml` is present.\n   - else **tsx** if `tsx` appears in `package.json` devDependencies.\n   - else **compiled Node** (note in script header: requires `tsc` build).\n2. **Python** — `pyproject.toml` or `uv.lock` or `requirements.txt` exists.\n   - **uv** if `uv.lock` exists or `pyproject.toml` has `[tool.uv]` configured (sets `{{UV_METADATA}}`).\n   - else **vanilla python3** (`{{UV_METADATA}}` substituted with empty string).\n3. **Both TS and Python detected** — count source files in `src/`/top-level and ask **AskUserQuestion** tiebreaker with the dominant one Recommended.\n4. `Cargo.toml` / `go.mod` only → fall back to **bash** (note: TS/Python/Bash only in v1).\n5. Nothing matched → **bash**.\n\n**Task-driven override**: if the gathered intent is clearly shell-y (\"verify three docker containers respond\", \"tail this log file for an error\"), propose **bash** even in a TS/Python project.\n\nConfirm via **AskUserQuestion** with the detected language as the first option (Recommended). Skip in Autopilot.\n\n### Step 5: Draft the Script\n\n1. **Pick the template**: `templates/{typescript.ts.tmpl|python.py.tmpl|bash.sh.tmpl}`.\n2. **Resolve substitution markers** from gathered intent:\n   - `{{SCRIPT_NAME}}` ← proposed file-name stem (see naming table).\n   - `{{WHAT}}` / `{{WHEN}}` / `{{ENV}}` / `{{EXAMPLE}}` ← intent fields.\n   - `{{UV_METADATA}}` ← per Step 4.\n3. **Generate `{{TEST_BODY}}`** from the intent. Keep it minimal: a single concrete probe + assertion, not a battery. Re-read the templates' README (`templates/README.md`) for the contract — the body must respect the PASS/FAIL surface. Throw/raise/`exit 1` on failure; let the template's outer try/trap convert it into the FAIL line.\n   **Gather-class bodies** adapt the same template: the loop/aggregation replaces the probe, raw per-item responses go to the log only, and the final `console.log`/`print` emits one compact summary (JSON or aligned table) instead of the PASS line — exit non-zero only on operational failure (auth, network), not on \"found problems\" (problems ARE the output).\n4. **Propose a file name** matching the intent shape — see the prefix table below. Use **AskUserQuestion** with the proposed name first (Recommended) and `custom name` as the alternative.\n\n**Naming conventions** (advisory — skill proposes, user overrides):\n\n| Prefix | When | Example |\n|--------|------|---------|\n| `e2e-*` | End-to-end flows across multiple components | `e2e-auth-flow.ts` |\n| `check-*` | Idempotent single-probe verifications | `check-db-boundary.sh` |\n| `smoke-*` | Minimal-viability post-deploy checks | `smoke-prod-api.ts` |\n| `measure-*` | Performance / size / token measurements | `measure-tool-tokens.ts` |\n| `seed-*` / `generate-*` | Data seeding or artifact generation (rare for validation) | `seed-api-keys.sh` |\n| `gather-*` / `bulk-*` | Bulk data-gathering or bulk mutation replacing N tool calls; stdout = one summary block, not PASS/FAIL | `gather-workflow-health.ts` |\n\nIf the intent doesn't match any prefix cleanly, propose a free-form name like `validate-<area>.<ext>`.\n\n5. **Write the file** to the resolved scripts directory. Make it executable (`chmod +x`).\n\n### Step 6: Syntax/Type-Check\n\nRun the appropriate checker:\n\n| Language | Checker (in priority order) |\n|----------|-----------------------------|\n| TypeScript | `bunx tsc --noEmit <file>` if Bun present, else `npx tsc --noEmit <file>` |\n| Python | `python3 -m py_compile <file>` (always) + `ruff check <file>` if `ruff` is on PATH |\n| Bash | `shellcheck <file>` if available, else `bash -n <file>` |\n\n**On success**: log a single line (`syntax check OK`) and proceed to Step 7.\n\n**On failure**:\n1. Print the error (≤10 lines, not the full output).\n2. Propose a concrete one-edit fix (the exact `Edit` you'd apply).\n3. Use **AskUserQuestion** with `Apply fix | Investigate | Stop`.\n   - **Apply fix** → edit the script and re-run the checker (loop, no hardcoded cap).\n   - **Investigate** → drop into discussion with the user; do not auto-apply anything.\n   - **Stop** → leave script in place at its path; print the path; do not delete.\n\n### Step 7: Document the Script\n\nAuto-edit the target project's `CLAUDE.md` and/or `AGENTS.md` so future agents discover this script when the matching intent recurs.\n\n**Block template** (the literal markdown the skill emits):\n\n```markdown\n<important if=\"[TRIGGER: e.g., you are testing the auth flow]\">\n\n## [Area] validation\n\nRun `scripts/<name>` to [one-liner]. Requires [env/deps]. Example: `<cmd>`. Full log at `/tmp/<name>-*.log`.\n\nGenerated/maintained via `/script-builder`.\n\n</important>\n```\n\n**Behavior**:\n\n1. **Target file selection**: edit `CLAUDE.md` and `AGENTS.md` if both exist; edit only what exists. **Never** create either file from scratch — if neither exists, print a one-line note (`No CLAUDE.md or AGENTS.md found — script generated but not documented`) and skip this step.\n2. **Placement heuristic**: search the file for the first heading matching `Test|Testing|Validation|Scripts` (case-insensitive). If found, append the new block within/after that section. Otherwise, append a new `## Scripts for testing & validation` section near the end of the file but **before** any heading matching `License|Acknowledg|Maintain|Contributors`.\n3. **Idempotency**: if a block referencing `scripts/<name>` already exists (i.e., a prior `/script-builder` run for the same script name), update it in place — replace the entire `<important if=...>...</important>` block, do not append a duplicate.\n4. **Scripts-dir marker**: if Step 2 resolved the scripts directory by user choice (not from an existing marker), insert `<!-- script-builder:dir=<path> -->` near the top of `CLAUDE.md` (after the title) so subsequent runs are silent. Skip if the marker already exists.\n5. **Scale gate — `scripts/index.md`**: if the scripts directory holds **>10 documented scripts**, per-script `<important if>` blocks become their own context bloat. Generate/maintain a `scripts/index.md` hub instead (one line + link per script, mirroring the `runbooks/` convention from `desplega:engineering-standards`), collapse the CLAUDE.md/AGENTS.md blocks into ONE pointer block referencing the hub, and add new scripts to the hub only.\n6. **Show the diff**: run the equivalent of `git diff CLAUDE.md AGENTS.md` and print a 5-line summary of what changed. **Never auto-stage** — the user commits.\n\n### Step 8: Offer Escalation\n\nAfter the doc edit, decide whether to proceed to the run-and-iterate tier.\n\n| Autonomy | Behavior |\n|----------|----------|\n| **Autopilot** | Auto-escalate to Step 9 unless the intent flagged side-effects (writes to prod, sends real money, mutates a shared resource). On flagged side-effects, fall through to Critical behavior. |\n| **Critical** (Default) | Use **AskUserQuestion**: `Run it now to confirm it works | I'll run it myself later | Just generate, don't run`. |\n| **Verbose** | Same as Critical, plus offer the proposed run command for review before executing. |\n\nIf the user picks \"I'll run it myself later\" or \"Just generate, don't run\" → skip directly to Step 10.\n\n### Step 9: Iterate on Failures (Escalated Tier Only)\n\nA bounded-by-the-human loop. **Never auto-apply a fix** outside Autopilot.\n\n1. **Run the script** with the proposed example invocation (no `--verbose`, no `--json`). Capture exit code and `tail -n 40` of the `/tmp` log.\n2. **If exit code 0** → report PASS (echo the script's PASS line) and proceed to Step 10.\n3. **If exit code non-zero**:\n   - Summarize the failure in **1–3 lines**: error class (timeout / 4xx / 5xx / assertion / dependency-missing / etc.) + likely cause (grep the log for known signatures: `ECONNREFUSED`, `Traceback`, `non-zero exit`, `command not found`, etc.).\n   - **Propose a concrete diff** — the exact `Edit` you would apply to the script. Show old → new.\n   - Use **AskUserQuestion**: `Apply fix | Investigate differently | Stop`.\n     - **Apply fix** → edit the script, log the change, loop back to (1).\n     - **Investigate differently** → drop into discussion; do not auto-apply.\n     - **Stop** → leave the script in place, print its path; do not revert.\n\n**No hardcoded retry cap** — the human is the implicit bound.\n\n**Side-effect flag**: if the intent declared side-effects (Step 3) and Autopilot is active, surface a one-line `WARNING: this script <does X> against <target>` before the first run and require explicit confirmation via **AskUserQuestion** even in Autopilot mode.\n\n### Step 10: Handoff\n\nHow the skill exits depends on how it was invoked:\n\n**Invoked as a sub-skill** (from `planning`, `qa`, `verifying`):\nReturn control to the parent skill with a structured summary: `{ script_path, status: \"pass\"|\"fail\"|\"unrun\", log_path?, doc_files_edited: [...] }`.\n\n**Invoked directly** (`/script-builder`):\nUse **AskUserQuestion**: `Run it with /qa | Run /verify-plan | Commit the script and doc changes | Done`.\n- **Run with /qa** → invoke `desplega:qa` with the script path as the source.\n- **Run /verify-plan** → invoke `desplega:verifying` if a plan path is in current context.\n- **Commit** → propose a commit message (`feat(scripts): add scripts/<name> for <area> validation`) and stage only the generated script + the CLAUDE.md/AGENTS.md edits. Do not auto-commit; show the proposed `git add` and `git commit` commands and require user confirmation.\n- **Done** → print the script path + log path (if escalation ran) and exit.\n\n**Abort path** (Stop selected at any earlier gate): leave the generated script in place, leave any CLAUDE.md/AGENTS.md edit in place if Step 7 ran, and print a one-liner: `Aborted. Script: <path>. Doc edits: <files or \"none\">. Re-run /script-builder or git checkout to discard.` Do not `git restore` on the user's behalf.\n\n## Learning Capture\n\n**OPTIONAL SUB-SKILL:** If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using `desplega:learning` to capture them via `/learning capture`. Focus on learnings that would help someone else in a future session.\n";
+var content_default39 = "# script-builder\n\nYou are converting session intent into a durable, re-runnable script committed to the target project's `scripts/` directory. Two script classes share one principle — **only the derived answer re-enters context; raw payloads never do**:\n\n- **Validation scripts** (`check-*`, `e2e-*`, `smoke-*`, …): a single PASS/FAIL line + `/tmp` log path on success, full verbose output redirected to a timestamped log file.\n- **Gather/bulk scripts** (`gather-*`, `bulk-*`): replace N similar tool/API calls with one script that loops, filters, and aggregates *in code* — stdout is one compact summary block (JSON or table), raw responses go to the `/tmp` log. Rubric (from production code-mode data): past ~10 items or any fan-out over a list, a script beats individual tool calls by ~100x on context and roughly halves end-to-end cost. Offer the script *before* the fan-out happens when you can see it coming, not just retrospectively.\n\nBoth classes get an `<important if>` block in `CLAUDE.md`/`AGENTS.md` so future agents discover the script when the intent recurs — durable scripts are reusable agent memory: import, don't re-derive.\n\n**Schema discovery happens in code, too**: when scripting against an unfamiliar API, grep/filter its OpenAPI spec or typed client programmatically to find the few relevant endpoints — never paste the full schema into context.\n\n## Working Agreement\n\nThese instructions establish a working agreement between you and the user. The key principles are:\n\n1. **AskUserQuestion is your primary communication tool** - Whenever you need to ask the user anything (clarifications, preferences, decisions, confirmations), use the **AskUserQuestion tool**. Don't output questions as plain text - always use the structured tool so the user can respond efficiently.\n\n2. **Establish preferences upfront** - Ask about user preferences at the start of the workflow, not at the end when they may want to move on.\n\n3. **Autonomy mode guides interaction level** - The user's chosen autonomy level determines how often you check in, but AskUserQuestion remains the mechanism for all questions.\n\n## When to Use\n\nThis skill activates when:\n- User invokes `/script-builder` command\n- Another skill references `**OPTIONAL SUB-SKILL:** desplega:script-builder`\n- A `planning`, `qa`, or `verifying` flow needs a re-runnable validation script that doesn't yet exist\n- The user expresses intent to \"turn X into a script\", \"wrap this validation into something reusable\", or \"I want to test X end-to-end\" with no existing script\n\n## Autonomy Mode\n\nAdapt your behavior based on the autonomy mode:\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Detect mode, draft, syntax-check, document, and (if escalation tier) run + iterate without intermediate confirmations. Pause only at hard blockers or destructive side-effects. |\n| **Critical** (Default) | Confirm at each tier boundary (after draft, before doc edit, before run). Use AskUserQuestion for fix application during iterate loop. |\n| **Verbose** | Confirm before each step. Show every diff. Walk through detection reasoning out loud. |\n\nThe autonomy mode is passed by the invoking command. If not specified, default to **Critical**.\n\n## Process Steps\n\n### Step 1: Detect Mode (Retrospective vs Forward-Declared)\n\nDecide silently — **do not** ask the user \"which mode?\". Use the following heuristics:\n\n1. **Scan recent session tool-use history** (the last ~20 tool calls in the current conversation) for test/validation-shaped activity: `curl`/`fetch` calls, `bun run`/`python`/`pytest`, database queries, `agent-browser` actions, repeated `grep`/log inspection of a single endpoint or table. If ≥2 such actions targeting the same area exist → **retrospective mode**. Separately, if the history (or the task ahead) shows the *same call shape repeated ~10+ times or a fan-out over a list* → **gather-script mode**: propose replacing the repetition with one `gather-*` script before continuing.\n2. **Parse the user's invocation message** for cues:\n   - Narrative cues → retrospective: *\"we just figured out\"*, *\"turn this into a script\"*, *\"wrap that in\"*, *\"that thing we just did\"*.\n   - Intent cues → forward-declared: *\"I want to test\"*, *\"validate that\"*, *\"smoke check\"*, *\"check before deploy\"*.\n3. **Fallback**: when ambiguous, default to **forward-declared**.\n\n**Retrospective first action**: summarize the observed activity back to the user as plain text (≤6 lines: what was probed, against what, with what success signal), then go to Step 3 with a confirmation prompt instead of Q&A.\n\n**Forward first action**: skip directly to Step 3's Q&A.\n\n### Step 2: Scan Existing Scripts for Overlap\n\n**Resolve the scripts directory** in this order:\n1. Check `CLAUDE.md` for a `<!-- script-builder:dir=<path> -->` marker. If present, use that path.\n2. If `scripts/` exists at the repo root, use it.\n3. Use **AskUserQuestion** with options: `scripts/ (Recommended) | custom path | skip dir persistence for this run`.\n\n**Edge case — directory absent**: if the resolved path doesn't exist, skip the dedup scan, print a one-line note (`No existing scripts directory at <path> — proceeding to intent gathering`), and remember to optionally offer to create the directory before Step 5.\n\n**When the directory exists**:\n1. List files in the scripts directory (top-level only for v1).\n2. For each file, read the top of the file (header comment) and capture the file-name tokens.\n3. Read `CLAUDE.md`/`AGENTS.md` for `<important if=\"...\">` blocks that point at scripts in this directory and capture the trigger phrases.\n4. Fuzzy-match the current intent string against (file-name tokens ∪ header keywords ∪ trigger phrases). A \"plausible match\" is shared keyword + same area noun (e.g., `auth`, `health`, `webhook`).\n5. If ≥1 plausible match → use **AskUserQuestion** with options: `Reuse <name> as-is | Extend <name> | Generate new anyway`.\n\nNever silently skip dedup on borderline matches — surface and let the user decide. The **Extend** branch appends a sub-command/flag to the existing script (do not create a new file); document the new flag in the script's header comment and the existing `<important if>` block.\n\n### Step 3: Gather Intent\n\nBoth modes converge on the same internal intent structure: `{ what, success_signal, failure_signal, inputs, env, side_effects }`.\n\n**Forward mode** — use **AskUserQuestion** (one or two questions, not five):\n\n| Question | Options |\n|----------|---------|\n| \"What are we validating, and what's the success signal?\" | [Free text — collect what + success signal in one answer] |\n| \"Any required env vars, inputs, or side-effects to flag (e.g., writes to prod, costs money)?\" | [Free text — optional; skip if forward intent already specified them] |\n\n**Retrospective mode** — present the summary from Step 1 and use **AskUserQuestion** with: `That's the flow | Close but fix X | Start over`. On *Close but fix X*, ask for the correction inline; on *Start over*, fall through to forward-mode Q&A.\n\nPersist the resolved intent in working memory (do not write to disk yet).\n\n### Step 4: Detect Language\n\nPriority order — first match wins, with override paths:\n\n1. **TypeScript** — `package.json` + `tsconfig.json` exist.\n   - **Bun** if `bun.lock` or `bunfig.toml` is present.\n   - else **tsx** if `tsx` appears in `package.json` devDependencies.\n   - else **compiled Node** (note in script header: requires `tsc` build).\n2. **Python** — `pyproject.toml` or `uv.lock` or `requirements.txt` exists.\n   - **uv** if `uv.lock` exists or `pyproject.toml` has `[tool.uv]` configured (sets `{{UV_METADATA}}`).\n   - else **vanilla python3** (`{{UV_METADATA}}` substituted with empty string).\n3. **Both TS and Python detected** — count source files in `src/`/top-level and ask **AskUserQuestion** tiebreaker with the dominant one Recommended.\n4. `Cargo.toml` / `go.mod` only → fall back to **bash** (note: TS/Python/Bash only in v1).\n5. Nothing matched → **bash**.\n\n**Task-driven override**: if the gathered intent is clearly shell-y (\"verify three docker containers respond\", \"tail this log file for an error\"), propose **bash** even in a TS/Python project.\n\nConfirm via **AskUserQuestion** with the detected language as the first option (Recommended). Skip in Autopilot.\n\n### Step 5: Draft the Script\n\n1. **Pick the template**: `templates/{typescript.ts.tmpl|python.py.tmpl|bash.sh.tmpl}`.\n2. **Resolve substitution markers** from gathered intent:\n   - `{{SCRIPT_NAME}}` ← proposed file-name stem (see naming table).\n   - `{{WHAT}}` / `{{WHEN}}` / `{{ENV}}` / `{{EXAMPLE}}` ← intent fields.\n   - `{{UV_METADATA}}` ← per Step 4.\n3. **Generate `{{TEST_BODY}}`** from the intent. Keep it minimal: a single concrete probe + assertion, not a battery. Re-read the templates' README (`templates/README.md`) for the contract — the body must respect the PASS/FAIL surface. Throw/raise/`exit 1` on failure; let the template's outer try/trap convert it into the FAIL line.\n   **Gather-class bodies** adapt the same template: the loop/aggregation replaces the probe, raw per-item responses go to the log only, and the final `console.log`/`print` emits one compact summary (JSON or aligned table) instead of the PASS line — exit non-zero only on operational failure (auth, network), not on \"found problems\" (problems ARE the output).\n4. **Propose a file name** matching the intent shape — see the prefix table below. Use **AskUserQuestion** with the proposed name first (Recommended) and `custom name` as the alternative.\n\n**Naming conventions** (advisory — skill proposes, user overrides):\n\n| Prefix | When | Example |\n|--------|------|---------|\n| `e2e-*` | End-to-end flows across multiple components | `e2e-auth-flow.ts` |\n| `check-*` | Idempotent single-probe verifications | `check-db-boundary.sh` |\n| `smoke-*` | Minimal-viability post-deploy checks | `smoke-prod-api.ts` |\n| `measure-*` | Performance / size / token measurements | `measure-tool-tokens.ts` |\n| `seed-*` / `generate-*` | Data seeding or artifact generation (rare for validation) | `seed-api-keys.sh` |\n| `gather-*` / `bulk-*` | Bulk data-gathering or bulk mutation replacing N tool calls; stdout = one summary block, not PASS/FAIL | `gather-workflow-health.ts` |\n\nIf the intent doesn't match any prefix cleanly, propose a free-form name like `validate-<area>.<ext>`.\n\n5. **Write the file** to the resolved scripts directory. Make it executable (`chmod +x`).\n\n### Step 6: Syntax/Type-Check\n\nRun the appropriate checker:\n\n| Language | Checker (in priority order) |\n|----------|-----------------------------|\n| TypeScript | `bunx tsc --noEmit <file>` if Bun present, else `npx tsc --noEmit <file>` |\n| Python | `python3 -m py_compile <file>` (always) + `ruff check <file>` if `ruff` is on PATH |\n| Bash | `shellcheck <file>` if available, else `bash -n <file>` |\n\n**On success**: log a single line (`syntax check OK`) and proceed to Step 7.\n\n**On failure**:\n1. Print the error (≤10 lines, not the full output).\n2. Propose a concrete one-edit fix (the exact `Edit` you'd apply).\n3. Use **AskUserQuestion** with `Apply fix | Investigate | Stop`.\n   - **Apply fix** → edit the script and re-run the checker (loop, no hardcoded cap).\n   - **Investigate** → drop into discussion with the user; do not auto-apply anything.\n   - **Stop** → leave script in place at its path; print the path; do not delete.\n\n### Step 7: Document the Script\n\nAuto-edit the target project's `CLAUDE.md` and/or `AGENTS.md` so future agents discover this script when the matching intent recurs.\n\n**Block template** (the literal markdown the skill emits):\n\n```markdown\n<important if=\"[TRIGGER: e.g., you are testing the auth flow]\">\n\n## [Area] validation\n\nRun `scripts/<name>` to [one-liner]. Requires [env/deps]. Example: `<cmd>`. Full log at `/tmp/<name>-*.log`.\n\nGenerated/maintained via `/script-builder`.\n\n</important>\n```\n\n**Behavior**:\n\n1. **Target file selection**: edit `CLAUDE.md` and `AGENTS.md` if both exist; edit only what exists. **Never** create either file from scratch — if neither exists, print a one-line note (`No CLAUDE.md or AGENTS.md found — script generated but not documented`) and skip this step.\n2. **Placement heuristic**: search the file for the first heading matching `Test|Testing|Validation|Scripts` (case-insensitive). If found, append the new block within/after that section. Otherwise, append a new `## Scripts for testing & validation` section near the end of the file but **before** any heading matching `License|Acknowledg|Maintain|Contributors`.\n3. **Idempotency**: if a block referencing `scripts/<name>` already exists (i.e., a prior `/script-builder` run for the same script name), update it in place — replace the entire `<important if=...>...</important>` block, do not append a duplicate.\n4. **Scripts-dir marker**: if Step 2 resolved the scripts directory by user choice (not from an existing marker), insert `<!-- script-builder:dir=<path> -->` near the top of `CLAUDE.md` (after the title) so subsequent runs are silent. Skip if the marker already exists.\n5. **Scale gate — `scripts/index.md`**: if the scripts directory holds **>10 documented scripts**, per-script `<important if>` blocks become their own context bloat. Generate/maintain a `scripts/index.md` hub instead (one line + link per script, mirroring the `runbooks/` convention from `desplega:engineering-standards`), collapse the CLAUDE.md/AGENTS.md blocks into ONE pointer block referencing the hub, and add new scripts to the hub only.\n6. **Show the diff**: run the equivalent of `git diff CLAUDE.md AGENTS.md` and print a 5-line summary of what changed. **Never auto-stage** — the user commits.\n\n### Step 8: Offer Escalation\n\nAfter the doc edit, decide whether to proceed to the run-and-iterate tier.\n\n| Autonomy | Behavior |\n|----------|----------|\n| **Autopilot** | Auto-escalate to Step 9 unless the intent flagged side-effects (writes to prod, sends real money, mutates a shared resource). On flagged side-effects, fall through to Critical behavior. |\n| **Critical** (Default) | Use **AskUserQuestion**: `Run it now to confirm it works | I'll run it myself later | Just generate, don't run`. |\n| **Verbose** | Same as Critical, plus offer the proposed run command for review before executing. |\n\nIf the user picks \"I'll run it myself later\" or \"Just generate, don't run\" → skip directly to Step 10.\n\n### Step 9: Iterate on Failures (Escalated Tier Only)\n\nA bounded-by-the-human loop. **Never auto-apply a fix** outside Autopilot.\n\n1. **Run the script** with the proposed example invocation (no `--verbose`, no `--json`). Capture exit code and `tail -n 40` of the `/tmp` log.\n2. **If exit code 0** → report PASS (echo the script's PASS line) and proceed to Step 10.\n3. **If exit code non-zero**:\n   - Summarize the failure in **1–3 lines**: error class (timeout / 4xx / 5xx / assertion / dependency-missing / etc.) + likely cause (grep the log for known signatures: `ECONNREFUSED`, `Traceback`, `non-zero exit`, `command not found`, etc.).\n   - **Propose a concrete diff** — the exact `Edit` you would apply to the script. Show old → new.\n   - Use **AskUserQuestion**: `Apply fix | Investigate differently | Stop`.\n     - **Apply fix** → edit the script, log the change, loop back to (1).\n     - **Investigate differently** → drop into discussion; do not auto-apply.\n     - **Stop** → leave the script in place, print its path; do not revert.\n\n**No hardcoded retry cap** — the human is the implicit bound.\n\n**Side-effect flag**: if the intent declared side-effects (Step 3) and Autopilot is active, surface a one-line `WARNING: this script <does X> against <target>` before the first run and require explicit confirmation via **AskUserQuestion** even in Autopilot mode.\n\n### Step 10: Handoff\n\nHow the skill exits depends on how it was invoked:\n\n**Invoked as a sub-skill** (from `planning`, `qa`, `verifying`):\nReturn control to the parent skill with a structured summary: `{ script_path, status: \"pass\"|\"fail\"|\"unrun\", log_path?, doc_files_edited: [...] }`.\n\n**Invoked directly** (`/script-builder`):\nUse **AskUserQuestion**: `Run it with /qa | Run /verify-plan | Commit the script and doc changes | Done`.\n- **Run with /qa** → invoke `desplega:qa` with the script path as the source.\n- **Run /verify-plan** → invoke `desplega:verifying` if a plan path is in current context.\n- **Commit** → propose a commit message (`feat(scripts): add scripts/<name> for <area> validation`) and stage only the generated script + the CLAUDE.md/AGENTS.md edits. Do not auto-commit; show the proposed `git add` and `git commit` commands and require user confirmation.\n- **Done** → print the script path + log path (if escalation ran) and exit.\n\n**Abort path** (Stop selected at any earlier gate): leave the generated script in place, leave any CLAUDE.md/AGENTS.md edit in place if Step 7 ran, and print a one-liner: `Aborted. Script: <path>. Doc edits: <files or \"none\">. Re-run /script-builder or git checkout to discard.` Do not `git restore` on the user's behalf.\n\n## Learning Capture\n\n**OPTIONAL SUB-SKILL:** If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using `desplega:learning` to capture them via `/learning capture`. Focus on learnings that would help someone else in a future session.\n";
 
 // templates/skills/script-workflows/config.json
-var config_default38 = `{
+var config_default40 = `{
   "kind": "skill",
   "name": "script-workflows",
   "displayName": "Script Workflows",
@@ -10636,16 +10656,16 @@ var config_default38 = `{
 `;
 
 // templates/skills/script-workflows/content.md
-var content_default38 = "Use this skill when a user asks to launch, monitor, inspect, or debug a durable script workflow run. This is for the Script Workflows v1 runtime: one-off TypeScript workflow source with journaled `swarm-script`, `raw-llm`, and `agent-task` steps.\n\n## Tool Flow\n\nLoad the script workflow tools with ToolSearch when they are not already visible:\n\n```text\nlaunch-script-run\nget-script-run\nlist-script-runs\n```\n\nUse `launch-script-run` to start a one-off run. It calls the same `/api/script-runs` API as the dashboard, preserves the invoking agent identity, and starts the run in the background.\n\nUse `get-script-run` to read terminal status and journal entries. Poll it when needed, but keep polling bounded and report progress for long runs.\n\nUse `list-script-runs` to find recent runs or filter by `status` / `agentId`.\n\nDo not hand-roll raw HTTP for this flow unless the tool itself is broken and you are explicitly debugging the API. The tool handles auth and `X-Agent-ID` like the existing inline `script-run` tool family.\n\n## Source Shape\n\nAuthor TypeScript workflow source as a default export. The runtime provides `args` and `ctx`.\n\n```ts\nexport default async function main(args, ctx) {\n  const lookup = await ctx.step.swarmScript(\"lookup-data\", {\n    scriptName: \"fetch-readable\",\n    args: { url: args.url },\n  });\n\n  const summary = await ctx.step.rawLlm(\"summarize\", {\n    prompt: `Summarize this for an operator:\\n${JSON.stringify(lookup)}`,\n  });\n\n  const task = await ctx.step.agentTask(\"operator-review\", {\n    task: `Review this summary and flag risks:\\n${JSON.stringify(summary)}`,\n    tags: [\"script-run\"],\n    priority: 50,\n  });\n\n  return { lookup, summary, task };\n}\n```\n\n`ctx.step.agentTask` blocks until the dispatched task reaches a terminal status (default `waitForCompletion: true`, default `timeoutMs` 2h) and journals its real output — a sequential `plan → implement → review` chain will not fan out. Pass `waitForCompletion: false` for the legacy fire-and-poll-yourself shape, or `failOnTaskFailure: false` to receive `{taskId, status: \"failed\", error}` instead of a throw when the task fails/is cancelled.\n\n## Label Rules\n\nStep labels are durability keys. They must be stable and unique for each logical step. Do not reuse the same literal label inside a loop; launch will fail with `label_lint_violation`.\n\nFor looped work, include an item identifier in the label:\n\n```ts\nfor (const item of args.items) {\n  await ctx.step.agentTask(`review-${item.id}`, { task: item.prompt });\n}\n```\n\n## Statuses\n\nTerminal statuses to surface clearly:\n\n- `completed` — run finished and `output` may be present.\n- `failed` — run ended with `error`.\n- `cancelled` — run was cancelled before completion.\n- `aborted_limit` — runtime guardrail stopped the run, usually step count, agent-task count, or wall-clock cap.\n- `label_lint_violation` — launch-time rejection, not a persisted run status.\n\nWhen a run is not terminal, report the current status, journal count, and latest heartbeat if present.\n";
+var content_default40 = "Use this skill when a user asks to launch, monitor, inspect, or debug a durable script workflow run. This is for the Script Workflows v1 runtime: one-off TypeScript workflow source with journaled `swarm-script`, `raw-llm`, and `agent-task` steps.\n\n## Tool Flow\n\nLoad the script workflow tools with ToolSearch when they are not already visible:\n\n```text\nlaunch-script-run\nget-script-run\nlist-script-runs\n```\n\nUse `launch-script-run` to start a one-off run. It calls the same `/api/script-runs` API as the dashboard, preserves the invoking agent identity, and starts the run in the background.\n\nUse `get-script-run` to read terminal status and journal entries. Poll it when needed, but keep polling bounded and report progress for long runs.\n\nUse `list-script-runs` to find recent runs or filter by `status` / `agentId`.\n\nDo not hand-roll raw HTTP for this flow unless the tool itself is broken and you are explicitly debugging the API. The tool handles auth and `X-Agent-ID` like the existing inline `script-run` tool family.\n\n## Source Shape\n\nAuthor TypeScript workflow source as a default export. The runtime provides `args` and `ctx`.\n\n```ts\nexport default async function main(args, ctx) {\n  const lookup = await ctx.step.swarmScript(\"lookup-data\", {\n    scriptName: \"fetch-readable\",\n    args: { url: args.url },\n  });\n\n  const summary = await ctx.step.rawLlm(\"summarize\", {\n    prompt: `Summarize this for an operator:\\n${JSON.stringify(lookup)}`,\n  });\n\n  const task = await ctx.step.agentTask(\"operator-review\", {\n    task: `Review this summary and flag risks:\\n${JSON.stringify(summary)}`,\n    tags: [\"script-run\"],\n    priority: 50,\n  });\n\n  return { lookup, summary, task };\n}\n```\n\n`ctx.step.agentTask` blocks until the dispatched task reaches a terminal status (default `waitForCompletion: true`, default `timeoutMs` 2h) and journals its real output — a sequential `plan → implement → review` chain will not fan out. Pass `waitForCompletion: false` for the legacy fire-and-poll-yourself shape, or `failOnTaskFailure: false` to receive `{taskId, status: \"failed\", error}` instead of a throw when the task fails/is cancelled.\n\n## Label Rules\n\nStep labels are durability keys. They must be stable and unique for each logical step. Do not reuse the same literal label inside a loop; launch will fail with `label_lint_violation`.\n\nFor looped work, include an item identifier in the label:\n\n```ts\nfor (const item of args.items) {\n  await ctx.step.agentTask(`review-${item.id}`, { task: item.prompt });\n}\n```\n\n## Statuses\n\nTerminal statuses to surface clearly:\n\n- `completed` — run finished and `output` may be present.\n- `failed` — run ended with `error`.\n- `cancelled` — run was cancelled before completion.\n- `aborted_limit` — runtime guardrail stopped the run, usually step count, agent-task count, or wall-clock cap.\n- `label_lint_violation` — launch-time rejection, not a persisted run status.\n\nWhen a run is not terminal, report the current status, journal count, and latest heartbeat if present.\n";
 
 // templates/skills/slack-interaction/config.json
-var config_default39 = '{\n  "kind": "skill",\n  "name": "slack-interaction",\n  "displayName": "Slack Interaction",\n  "slug": "slack-interaction",\n  "title": "Slack Interaction",\n  "description": "Slack: reply, post, read, upload, and the thread rules. What the engine already posts, the one-message rule, `slack-reply`, `slack-post`, `slack-start-thread`, `slack-read`, `slack-upload-file`, `slack-download-file`, `slack-list-channels`, `slack-update`, `slack-delete`, unknown-user registration with `manage-user`, and Slack standing orders. Use before any Slack message.",\n  "version": "1.0.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["slack", "communication"]\n}\n';
+var config_default41 = '{\n  "kind": "skill",\n  "name": "slack-interaction",\n  "displayName": "Slack Interaction",\n  "slug": "slack-interaction",\n  "title": "Slack Interaction",\n  "description": "Slack: reply, post, read, upload, and the thread rules. What the engine already posts, the one-message rule, `slack-reply`, `slack-post`, `slack-start-thread`, `slack-read`, `slack-upload-file`, `slack-download-file`, `slack-list-channels`, `slack-update`, `slack-delete`, unknown-user registration with `manage-user`, and Slack standing orders. Use before any Slack message.",\n  "version": "1.0.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["slack", "communication"]\n}\n';
 
 // templates/skills/slack-interaction/content.md
-var content_default39 = '# Slack interaction\n\n## What the engine posts\n\nFor every task that came from Slack, the engine owns the thread tree and the top-level outcome card. It posts the start, the completion, and the failure. You do not.\n\n## Your one message\n\n- At most one message per task, and only when the outcome card will not carry it: a question, a decision the requester must make, a link to a page or file with one line of context.\n- Progress, receipts, acknowledgments, and relayed worker output stay out of Slack.\n- Concrete content. The length matches what the requester asked for.\n- The "How you write" rules of your system prompt apply. Slack renders mrkdwn: `*bold*`, `_italic_`, `` `code` ``, `<url|text>` for links. Markdown headings and tables do not render.\n\n## Where to post\n\nThe task carries `slackChannelId` and `slackThreadTs` in its metadata. A follow-up task with `parentTaskId` inherits them.\n\n- Reply in the task\'s thread: `slack-reply` with `taskId` and `message`.\n- Reply to an inbox message: `slack-reply` with `inboxMessageId`.\n- New top-level message in a channel (lead): `slack-start-thread` with `channelId`, then `slack-post` with the returned `ts` as `threadTs` for replies under it.\n- Fix your own message: `slack-update` (text) or `slack-delete` (lead). Both work only on messages this bot authored.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `slack-reply` | reply in a thread by `taskId` or `inboxMessageId` |\n| `slack-post` | post to a channel, optional `threadTs` (lead) |\n| `slack-start-thread` | post a top-level message and get its `ts` (lead) |\n| `slack-read` | read a thread by `taskId` or `inboxMessageId`, or a channel by `channelId` (lead) |\n| `slack-list-channels` | channels the bot is a member of |\n| `slack-upload-file` | upload a file to a thread or channel, up to 1 GB |\n| `slack-download-file` | attach a Slack file (by ID or URL) to your task; run the `fetchCommand` it returns to get the bytes |\n| `slack-update` | edit your own message |\n| `slack-delete` | delete your own message (lead) |\n| `slack-create-channel`, `slack-invite-to-channel`, `slack-archive-channel` | channel lifecycle (lead) |\n\nFiles attached to your task already come with download commands in the task message. Use those before `slack-download-file`. `slack-read` on your task also attaches the files in the thread and gives each one a `fetchCommand`. Don\'t look for Slack files under `/app/shared` or `/workspace/shared/downloads`: those paths are the API server\'s disk.\n\n## Unknown user\n\nA task without `requestedByUserId` came from a Slack user the swarm does not know. Register them with `manage-user`, using the Slack user ID and display name from the task metadata, then continue. When you learn a requester\'s stable preferences (language, tone, verbosity), the lead stores them in the user\'s `comms` field with `manage-user`.\n\n## Lead standing orders\n\nWhen your heartbeat runbook says so, check for unaddressed requests older than one hour: `slack-list-channels`, then `slack-read` per channel, then create a task for each open request.\n\n## Scripts-only mode\n\nThe named Slack tools are not registered. Use `script-run` with inline source: `ctx.swarm.slack_reply({ taskId, message })`. The task ID carries the thread context.\n';
+var content_default41 = '# Slack interaction\n\n## What the engine posts\n\nFor every task that came from Slack, the engine owns the thread tree and the top-level outcome card. It posts the start, the completion, and the failure. You do not.\n\n## Your one message\n\n- At most one message per task, and only when the outcome card will not carry it: a question, a decision the requester must make, a link to a page or file with one line of context.\n- Progress, receipts, acknowledgments, and relayed worker output stay out of Slack.\n- Concrete content. The length matches what the requester asked for.\n- The "How you write" rules of your system prompt apply. Slack renders mrkdwn: `*bold*`, `_italic_`, `` `code` ``, `<url|text>` for links. Markdown headings and tables do not render.\n\n## Where to post\n\nThe task carries `slackChannelId` and `slackThreadTs` in its metadata. A follow-up task with `parentTaskId` inherits them.\n\n- Reply in the task\'s thread: `slack-reply` with `taskId` and `message`.\n- Reply to an inbox message: `slack-reply` with `inboxMessageId`.\n- New top-level message in a channel (lead): `slack-start-thread` with `channelId`, then `slack-post` with the returned `ts` as `threadTs` for replies under it.\n- Fix your own message: `slack-update` (text) or `slack-delete` (lead). Both work only on messages this bot authored.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `slack-reply` | reply in a thread by `taskId` or `inboxMessageId` |\n| `slack-post` | post to a channel, optional `threadTs` (lead) |\n| `slack-start-thread` | post a top-level message and get its `ts` (lead) |\n| `slack-read` | read a thread by `taskId` or `inboxMessageId`, or a channel by `channelId` (lead) |\n| `slack-list-channels` | channels the bot is a member of |\n| `slack-upload-file` | upload a file to a thread or channel, up to 1 GB |\n| `slack-download-file` | attach a Slack file (by ID or URL) to your task; run the `fetchCommand` it returns to get the bytes |\n| `slack-update` | edit your own message |\n| `slack-delete` | delete your own message (lead) |\n| `slack-create-channel`, `slack-invite-to-channel`, `slack-archive-channel` | channel lifecycle (lead) |\n\nFiles attached to your task already come with download commands in the task message. Use those before `slack-download-file`. `slack-read` on your task also attaches the files in the thread and gives each one a `fetchCommand`. Don\'t look for Slack files under `/app/shared` or `/workspace/shared/downloads`: those paths are the API server\'s disk.\n\n## Unknown user\n\nA task without `requestedByUserId` came from a Slack user the swarm does not know. Register them with `manage-user`, using the Slack user ID and display name from the task metadata, then continue. When you learn a requester\'s stable preferences (language, tone, verbosity), the lead stores them in the user\'s `comms` field with `manage-user`.\n\n## Lead standing orders\n\nWhen your heartbeat runbook says so, check for unaddressed requests older than one hour: `slack-list-channels`, then `slack-read` per channel, then create a task for each open request.\n\n## Scripts-only mode\n\nThe named Slack tools are not registered. Use `script-run` with inline source: `ctx.swarm.slack_reply({ taskId, message })`. The task ID carries the thread context.\n\n## Status and blocker questions\n\nAnswer for the scope of the place the question was asked. In a customer or project channel or thread, "current blockers" or "what\'s the status" means that customer\'s or project\'s work: its tracker, its PRs, its open asks. Answer swarm-wide only in a DM or an ops channel, or when the person asks for it. Name the scope you used in the first line.\n';
 
 // templates/skills/step-running/config.json
-var config_default40 = `{
+var config_default42 = `{
   "category": "skills",
   "description": "Execute a single DAG step as an autonomous background sub-agent. Sibling of phase-running for DAG plans produced by v-planning. Reads a step-<n>.md file directly, atomically claims it via frontmatter status, runs the three-bucket Success Criteria, and reports back. Spawned by v-implementing or by /run-step.",
   "displayName": "Step Running",
@@ -10666,10 +10686,10 @@ var config_default40 = `{
 `;
 
 // templates/skills/step-running/content.md
-var content_default40 = "# Step Running\n\nYou execute a single step of a DAG plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.\n\nThis is the DAG sibling of `phase-running`. The execution model and atomicity contract are identical; the differences are:\n- You receive a **step file path** (`step-<n>.md`), not a plan path + phase number.\n- You **claim the step atomically** via the step's frontmatter `status` field before doing work, and release it on completion / failure. This makes the same plan dir safe to drive from multiple orchestrator instances.\n\n## Execution Model\n\nThis skill runs inside a background `Agent` (sub-agent). v-implementing (or a user invoking `/run-step`) spawns it via the Agent tool with `run_in_background: true`.\n\nThe step agent receives:\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory (read `root.md` from here for plan-level context)\n- **Agent ID**: unique identifier for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). Used for atomic claim + stale-claim detection.\n- **Relevant context**: any extra context from the caller\n\n## Concurrency: Atomic Claim\n\nBefore doing any work, claim the step:\n\n1. Read the step file's frontmatter.\n2. **If `status: done`** — report `Status: skipped` and exit. The step is already finished.\n3. **If `status: claimed`** and `assignee` differs from your agent ID:\n   - Fresh claim (`claimed_at` within last hour): report `Status: blocked` (reason: `claimed by <other-id>`) and exit.\n   - Stale claim (>1h): proceed and overwrite — the previous worker likely died.\n4. **Otherwise** (`status: ready`, or stale `claimed`): rewrite the frontmatter block in a single `Edit` so the write is atomic-enough for filesystem-based coordination. Set:\n   - `status: claimed`\n   - `assignee: <your-agent-id>`\n   - `claimed_at: <ISO timestamp UTC>`\n5. Re-read the file. If `assignee` is not yours, another worker raced you — report `Status: blocked` (reason: `lost claim race`) and exit.\n\nOn terminal transitions, set frontmatter:\n- **Completed**: `status: done`, clear `assignee` and `claimed_at`.\n- **Blocked or failed (retry-able)**: `status: ready`, clear `assignee` and `claimed_at`. The orchestrator (or another worker) can retry.\n- **Failed (non-retry-able)**: leave `status: claimed` so the orchestrator can investigate; include the reason in the report.\n\nFor true cross-machine atomicity (NFS, etc.), the caller is responsible for rendezvous (e.g. a shared lock service). The single-Edit pattern is good-enough for local filesystem and well-behaved network filesystems.\n\n## Autonomy\n\nStep agents always run as **Autopilot** within the sub-agent. The calling context controls outer autonomy and human checkpoints.\n\n**CRITICAL**: Step agents do NOT use AskUserQuestion. If something is ambiguous, report `Status: blocked` with details. The caller handles all user interaction.\n\n## Process Steps\n\n### Step 1: Load Context\n\n1. **Claim the step** (see \"Concurrency: Atomic Claim\"). Stop here on any non-claim outcome.\n2. Read the full step file.\n3. Read `root.md` from the plan dir for plan-level context: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n4. Read all files mentioned in the step's \"Changes Required\" section.\n\n### Step 2: Pre-flight Check\n\n| Check | Action if failed |\n|-------|-----------------|\n| All `depends_on` steps have `status: done` | Scheduler bug — release claim, report `blocked` |\n| No merge conflicts in target files | Release claim, report `blocked` |\n| Files/dirs from depended-on steps exist | Release claim, report `blocked` |\n\n### Step 3: Execute Step\n\nImplement the changes described in the step's \"Changes Required\" section. Adapt to minor mismatches; report `blocked` for significant ones.\n\n### Step 4: Run Verification\n\nSame three-bucket pattern as `phase-running`:\n1. **Automated Verification** (runnable commands): run each, record pass/fail. On failure, attempt one fix-and-retry.\n2. **Automated QA** (agent-driven scenarios — browser-use, screenshot diff, CLI walkthrough): execute, record pass/fail per item.\n3. **Manual Verification**: leave unchecked. Caller handles with the user.\n4. **QA Spec (linked doc)**: if present, report `QA Doc: <path>`. Do not execute scenarios inline.\n\n### Step 5: Update Step File\n\n- Check off (`- [x]`) Automated Verification + Automated QA items that passed.\n- Do NOT check off Manual Verification items.\n- Update frontmatter `status` per \"Concurrency: Atomic Claim\" terminal-transition rules.\n- Update `last_updated` / `last_updated_by` frontmatter fields if present.\n\n### Step 6: Report Results\n\n**Completed:**\n```\nStatus: completed\nStep: step-N - <Name>\nFinal frontmatter status: done\nFiles changed: [list]\nAutomated Verification: N/M passed\n- [x] [Check 1] — passed\nAutomated QA: N/M passed\n- [x] [Scenario 1] — passed\nQA Doc: <path> | n/a\nManual verification needed:\n- [ ] [Manual check 1]\n```\n\n**Blocked / failed:** mirror `phase-running`'s shape, plus a `Final frontmatter status:` line so the orchestrator knows whether the step is released for retry (`ready`) or held for investigation (`claimed`).\n\n## Atomicity Contract\n\n- No interactive questions.\n- No partial states left unexplained.\n- Frontmatter `status` always reflects the final state at exit.\n- Report includes enough detail for the caller to decide next steps.\n\n## Context Handoff Pattern\n\n| Direction | Data |\n|-----------|------|\n| **Caller → Step Agent** | Step path + plan dir + agent ID + autonomy mode |\n| **Step Agent reads** | Step file + root.md + files in Changes Required |\n| **Step Agent writes** | Frontmatter status transitions + checkboxes + code changes |\n| **Step Agent → Caller** | Status + changed files + verification results + final frontmatter status |\n| **Caller handles** | Manual verification, cross-step coordination, QA doc execution, human checkpoints |\n";
+var content_default42 = "# Step Running\n\nYou execute a single step of a DAG plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.\n\nThis is the DAG sibling of `phase-running`. The execution model and atomicity contract are identical; the differences are:\n- You receive a **step file path** (`step-<n>.md`), not a plan path + phase number.\n- You **claim the step atomically** via the step's frontmatter `status` field before doing work, and release it on completion / failure. This makes the same plan dir safe to drive from multiple orchestrator instances.\n\n## Execution Model\n\nThis skill runs inside a background `Agent` (sub-agent). v-implementing (or a user invoking `/run-step`) spawns it via the Agent tool with `run_in_background: true`.\n\nThe step agent receives:\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory (read `root.md` from here for plan-level context)\n- **Agent ID**: unique identifier for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). Used for atomic claim + stale-claim detection.\n- **Relevant context**: any extra context from the caller\n\n## Concurrency: Atomic Claim\n\nBefore doing any work, claim the step:\n\n1. Read the step file's frontmatter.\n2. **If `status: done`** — report `Status: skipped` and exit. The step is already finished.\n3. **If `status: claimed`** and `assignee` differs from your agent ID:\n   - Fresh claim (`claimed_at` within last hour): report `Status: blocked` (reason: `claimed by <other-id>`) and exit.\n   - Stale claim (>1h): proceed and overwrite — the previous worker likely died.\n4. **Otherwise** (`status: ready`, or stale `claimed`): rewrite the frontmatter block in a single `Edit` so the write is atomic-enough for filesystem-based coordination. Set:\n   - `status: claimed`\n   - `assignee: <your-agent-id>`\n   - `claimed_at: <ISO timestamp UTC>`\n5. Re-read the file. If `assignee` is not yours, another worker raced you — report `Status: blocked` (reason: `lost claim race`) and exit.\n\nOn terminal transitions, set frontmatter:\n- **Completed**: `status: done`, clear `assignee` and `claimed_at`.\n- **Blocked or failed (retry-able)**: `status: ready`, clear `assignee` and `claimed_at`. The orchestrator (or another worker) can retry.\n- **Failed (non-retry-able)**: leave `status: claimed` so the orchestrator can investigate; include the reason in the report.\n\nFor true cross-machine atomicity (NFS, etc.), the caller is responsible for rendezvous (e.g. a shared lock service). The single-Edit pattern is good-enough for local filesystem and well-behaved network filesystems.\n\n## Autonomy\n\nStep agents always run as **Autopilot** within the sub-agent. The calling context controls outer autonomy and human checkpoints.\n\n**CRITICAL**: Step agents do NOT use AskUserQuestion. If something is ambiguous, report `Status: blocked` with details. The caller handles all user interaction.\n\n## Process Steps\n\n### Step 1: Load Context\n\n1. **Claim the step** (see \"Concurrency: Atomic Claim\"). Stop here on any non-claim outcome.\n2. Read the full step file.\n3. Read `root.md` from the plan dir for plan-level context: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n4. Read all files mentioned in the step's \"Changes Required\" section.\n\n### Step 2: Pre-flight Check\n\n| Check | Action if failed |\n|-------|-----------------|\n| All `depends_on` steps have `status: done` | Scheduler bug — release claim, report `blocked` |\n| No merge conflicts in target files | Release claim, report `blocked` |\n| Files/dirs from depended-on steps exist | Release claim, report `blocked` |\n\n### Step 3: Execute Step\n\nImplement the changes described in the step's \"Changes Required\" section. Adapt to minor mismatches; report `blocked` for significant ones.\n\n### Step 4: Run Verification\n\nSame three-bucket pattern as `phase-running`:\n1. **Automated Verification** (runnable commands): run each, record pass/fail. On failure, attempt one fix-and-retry.\n2. **Automated QA** (agent-driven scenarios — browser-use, screenshot diff, CLI walkthrough): execute, record pass/fail per item.\n3. **Manual Verification**: leave unchecked. Caller handles with the user.\n4. **QA Spec (linked doc)**: if present, report `QA Doc: <path>`. Do not execute scenarios inline.\n\n### Step 5: Update Step File\n\n- Check off (`- [x]`) Automated Verification + Automated QA items that passed.\n- Do NOT check off Manual Verification items.\n- Update frontmatter `status` per \"Concurrency: Atomic Claim\" terminal-transition rules.\n- Update `last_updated` / `last_updated_by` frontmatter fields if present.\n\n### Step 6: Report Results\n\n**Completed:**\n```\nStatus: completed\nStep: step-N - <Name>\nFinal frontmatter status: done\nFiles changed: [list]\nAutomated Verification: N/M passed\n- [x] [Check 1] — passed\nAutomated QA: N/M passed\n- [x] [Scenario 1] — passed\nQA Doc: <path> | n/a\nManual verification needed:\n- [ ] [Manual check 1]\n```\n\n**Blocked / failed:** mirror `phase-running`'s shape, plus a `Final frontmatter status:` line so the orchestrator knows whether the step is released for retry (`ready`) or held for investigation (`claimed`).\n\n## Atomicity Contract\n\n- No interactive questions.\n- No partial states left unexplained.\n- Frontmatter `status` always reflects the final state at exit.\n- Report includes enough detail for the caller to decide next steps.\n\n## Context Handoff Pattern\n\n| Direction | Data |\n|-----------|------|\n| **Caller → Step Agent** | Step path + plan dir + agent ID + autonomy mode |\n| **Step Agent reads** | Step file + root.md + files in Changes Required |\n| **Step Agent writes** | Frontmatter status transitions + checkboxes + code changes |\n| **Step Agent → Caller** | Status + changed files + verification results + final frontmatter status |\n| **Caller handles** | Manual verification, cross-step coordination, QA doc execution, human checkpoints |\n";
 
 // templates/skills/swarm-extensions/config.json
-var config_default41 = `{
+var config_default43 = `{
   "kind": "skill",
   "name": "swarm-extensions",
   "displayName": "Swarm Extensions",
@@ -10686,7 +10706,7 @@ var config_default41 = `{
 `;
 
 // templates/skills/swarm-extensions/content.md
-var content_default41 = `# Swarm Extensions
+var content_default43 = `# Swarm Extensions
 
 An extension is a trusted TypeScript hook bundle that runs inside the swarm API server. Use one when a rule must apply to the whole swarm: block or rewrite new tasks, route Slack channels, suppress follow-ups, change stalled-task remediation, guard tool calls, or react after a task or tool call finishes.
 
@@ -10735,10 +10755,12 @@ curl -s "$MCP_BASE_URL/api/extensions/type-defs" \\
 | \`pre.task.create\` | before any task is stored (REST, MCP, Slack, schedule, workflow, webhook, follow-up) | \`block(reason)\`, \`modify({ priority, agentId, tags, description, ... })\`, or nothing |
 | \`pre.task.followUp\` | before the lead follow-up task for a finished worker task | \`block\`, \`modify({ description, priority, agentId })\`, or nothing |
 | \`pre.slack.route\` | before a Slack message becomes a task | \`modify({ target: { kind: "agent", agentId } })\`, \`{ kind: "lead" }\`, \`{ kind: "broadcast" }\` |
+| \`pre.chat.route\` | before buffered Chat SDK messages (Telegram, Slack, Discord, Teams) become a task | \`block(reason)\`, or \`modify({ target: { kind: "agent", agentId } })\`, \`{ kind: "lead" }\`, \`{ kind: "broadcast" }\`, \`{ kind: "workflow", workflowId }\` |
 | \`pre.heartbeat.remediate\` | after the heartbeat sweep finds a stalled task | \`modify({ proposedAction: "record" | "fail" | "supersede-resume" })\` |
 | \`pre.tool.call\` | before an agent MCP tool call runs | \`block(reason)\` or \`modify({ args })\` |
 | \`post.task.created\`, \`post.task.completed\`, \`post.task.failed\`, \`post.task.cancelled\`, \`post.task.superseded\`, \`post.task.progress\` | after the change is committed | none |
 | \`post.slack.message\`, \`post.tool.call\` | after the message or tool call finished | none |
+| \`post.chat.message\` | after a Chat SDK message is received (before buffering) or sent; \`direction\` is \`inbound\` or \`outbound\` | none |
 | \`post.approval.resolved\` | after a person answers an approval request, workflow or standalone (not on timeout or cancel) | none |
 | \`post.task.budgetRefused\` | after a task is refused by a daily spend budget | none |
 | \`post.email.received\`, \`post.kapso.message\` | after an inbound AgentMail or Kapso message is received | none |
@@ -10865,14 +10887,14 @@ export default extension;
 `;
 
 // templates/skills/swarm-scripts/config.json
-var config_default42 = `{
+var config_default44 = `{
   "kind": "skill",
   "name": "swarm-scripts",
   "displayName": "Swarm Scripts",
   "slug": "swarm-scripts",
   "title": "Swarm Scripts",
   "description": "Bulk, repeat, fan-out, or data-heavy work: write and run swarm scripts (inline \`script-run\`, named \`script-upsert\`, durable \`launch-script-run\`). Covers the script-vs-tool rubric, the authoring contract (\`args\` first, \`ctx\` second), the seed catalog, connections and secrets, \`db_query\`, and exposing a script as an API.",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "category": "skills",
   "placeholders": [],
   "runAllSeedersCandidate": true,
@@ -10882,7 +10904,7 @@ var config_default42 = `{
 `;
 
 // templates/skills/swarm-scripts/content.md
-var content_default42 = `# Swarm Scripts
+var content_default44 = `# Swarm Scripts
 
 A swarm script is TypeScript that runs out of process with a typed Swarm SDK. Only its return value enters your context. Use one when direct tool calls would repeat, flood your context, or need deterministic processing over many records.
 
@@ -10955,7 +10977,7 @@ export default async function (args: z.infer<typeof argsSchema>, ctx: ScriptCont
 
 - \`ctx.swarm.*\`: the swarm SDK. \`task_get\`, \`task_send\`, \`task_storeProgress\`, \`task_action\`, \`task_list\`, \`slack_reply\`, \`memory_search\`, \`memory_store\`, \`kv_get\`, \`kv_getOrNull\`, \`kv_set\`, \`kv_delete\`, \`kv_incr\`, \`kv_list\`, \`swarm_get\`, \`agent_info\`, \`db_query\`, and more. \`kv_getOrNull\` returns the entry, \`null\` on a missing key, and throws on other errors.
 - \`ctx.swarm.task_send\` requires \`routingReason\` and \`routingNote\` whenever \`agentId\` is present. The note must explain the worker choice in at least 10 characters after trimming whitespace (maximum 200 characters). Use \`human_pinned\` for an explicit/configured choice, \`skill\` for a role or specialization match, \`continuity\` for the same worker/session, \`reroute_fault\` for a fault handoff, or \`overflow\` for capacity/pool escalation. Omit both \`agentId\` and routing fields for the pool.
-- \`ctx.swarm.config\`: \`apiKey\`, \`agentId\`, \`mcpBaseUrl\`, and \`ctx.swarm.config.get("KEY")\` for user config values. All are \`Redacted\` wrappers that stringify to \`<redacted>\`. Never unwrap one into a return value, a log line, or a request body you build by hand.
+- \`ctx.swarm.config\`: \`apiKey\`, \`agentId\`, \`mcpBaseUrl\`, and \`ctx.swarm.config.get("KEY")\` for swarm config values, resolved for the agent running the script (agent scope over global, the same rows \`get-config\` returns for that agent). A key that is not set returns \`undefined\`, so \`config.get("KEY") ?? fallback\` works. All are \`Redacted\` wrappers that stringify to \`<redacted>\`. Never unwrap one into a return value, a log line, or a request body you build by hand.
 - \`ctx.api.<slug>\` and \`ctx.mcp.<slug>\`: typed clients for registered connections. They exist only for registered connections. Introspect with \`Object.keys(ctx.api ?? {})\` and \`Object.keys(ctx.mcp ?? {})\`.
 - \`ctx.stdlib\`: \`fetch\`, \`fetchJson\` (retries, 30 s timeout), \`grep\`, \`glob\`, \`table\`, \`Redacted\`.
 - \`ctx.logger\`: \`log\`, \`warn\`, \`error\`. Keep logs short.
@@ -10986,11 +11008,13 @@ export default async function main(args: { status?: string; limit?: number } | u
 
 ## Secrets
 
+A config row reaches your shell env only when its \`exportToEnv\` flag is on. If \`$KEY\` is empty in your shell but \`get-config\` or \`list-config\` shows the row marked \`not in agent env\`, the row stays server-side on purpose: do not copy the value into a file, an env var, or a command. Use it from a script instead, through one of the paths below. Harness, git, and agent-fs credentials stay exported. Keys only the API server reads (Slack app token and signing secret, GitHub App private key, webhook and OAuth client secrets) can never be exported. If a recipe genuinely needs the variable in a shell, ask the lead to turn \`exportToEnv\` on for that row (\`set-config\` with \`exportToEnv: true\`); it applies to your next task.
+
 Order of preference:
 
 1. A registered connection: \`ctx.api.<slug>.<operationId>({ path, query, header, body })\` (OpenAPI), \`ctx.api.<slug>.graphql(query, variables)\` (GraphQL), \`ctx.mcp.<slug>.<toolName>(args)\` (MCP, proxied server-side, returns the raw MCP envelope: read \`res.structuredContent ?? res.content?.[0]?.text\`). Credentials attach at egress. The script never sees them. OAuth tokens refresh on their own.
 2. A credential binding placeholder in a hand-written request: \`Authorization: Bearer [REDACTED:GITHUB_TOKEN]\`. The runtime substitutes the value at egress, only for the binding's allowed hosts.
-3. \`ctx.swarm.config.get("KEY")\` for a config value you pass to \`ctx.stdlib.fetch\` as a header value. Still \`Redacted\`; never log it.
+3. \`ctx.swarm.config.get("KEY")\` for a config value you pass to \`ctx.stdlib.fetch\` as a header value. Unwrap it with \`ctx.stdlib.Redacted.value(...)\` inside the header itself (a wrapped value sends the literal \`<redacted>\`), and never log it. Secret values are scrubbed from run output.
 
 A raw secret, or the output of \`get-config\` with \`includeSecrets: true\`, must not appear in script source, script \`args\`, a schedule's \`taskTemplate\` or \`scriptArgs\`, or a task description. Those are stored as plain text and replayed on every run.
 
@@ -11049,7 +11073,7 @@ A named script can serve \`POST /api/x/script/<id>\` for callers outside the swa
 `;
 
 // templates/skills/tackle-gh-comments/config.json
-var config_default43 = `{
+var config_default45 = `{
   "category": "skills",
   "description": "Work through every review comment on a GitHub PR — fetch the threads, verify each claim against the code, fix what is real, then reply and mark each thread resolved before pushing. Use when the user says \\"tackle the PR comments\\", \\"address the review\\", \\"handle the bot comments\\", \\"check the comments on the PR\\", \\"resolve the review threads\\", or invokes /tackle-gh-comments. Project-agnostic; works in any repo with a GitHub remote.",
   "displayName": "Tackle GH Comments",
@@ -11070,7 +11094,7 @@ var config_default43 = `{
 `;
 
 // templates/skills/tackle-gh-comments/content.md
-var content_default43 = `# Tackle GitHub PR comments
+var content_default45 = `# Tackle GitHub PR comments
 
 Review threads and their resolved state live **only in GraphQL**. The REST API
 cannot read \`isResolved\` and cannot resolve a thread, and \`gh pr view --comments\`
@@ -11189,7 +11213,7 @@ committed, and the branch is pushed.
 `;
 
 // templates/skills/taste-minimalist-skill/config.json
-var config_default44 = `{
+var config_default46 = `{
   "kind": "skill",
   "name": "taste-minimalist-skill",
   "displayName": "Taste Minimalist Skill",
@@ -11211,7 +11235,7 @@ var config_default44 = `{
 `;
 
 // templates/skills/taste-minimalist-skill/content.md
-var content_default44 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
+var content_default46 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
 > Upstream license: MIT, Copyright (c) 2026 Leonxlnx. See ../TASTE-SKILL-LICENSE.
 
 # Protocol: Premium Utilitarian Minimalism UI Architect
@@ -11297,7 +11321,7 @@ When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing
 `;
 
 // templates/skills/tdd-planning/config.json
-var config_default45 = `{
+var config_default47 = `{
   "category": "skills",
   "description": "TDD-focused implementation planning. Creates plans with strict Red-Green-Commit/Rollback cycles for each step.",
   "displayName": "TDD Planning",
@@ -11318,7 +11342,7 @@ var config_default45 = `{
 `;
 
 // templates/skills/tdd-planning/content.md
-var content_default45 = `# TDD Planning
+var content_default47 = `# TDD Planning
 
 You are creating implementation plans that follow a strict Test-Driven Development approach. Every implementation step follows the TDD cycle: **RED → GREEN → COMMIT/ROLLBACK**.
 
@@ -11580,7 +11604,7 @@ Before finalizing any TDD plan, verify:
 `;
 
 // templates/skills/v-implementing/config.json
-var config_default46 = `{
+var config_default48 = `{
   "category": "skills",
   "description": "Parallel DAG-plan implementation skill. Reads a v-planning plan directory (root.md + step-<n>.md files), topologically schedules ready steps, and fans them out as parallel sub-agents. Use whenever the user invokes /v-implement, points at a plan directory produced by /v-plan, or asks to \\"run the parallel plan\\", \\"implement the DAG\\", or \\"fan out the steps\\" — even without those exact words. For linear plans (single .md file), use \`implementing\` instead.",
   "displayName": "V-Implementing",
@@ -11601,10 +11625,10 @@ var config_default46 = `{
 `;
 
 // templates/skills/v-implementing/content.md
-var content_default46 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
+var content_default48 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
 
 // templates/skills/v-planning/config.json
-var config_default47 = `{
+var config_default49 = `{
   "category": "skills",
   "description": "Vertical / parallel implementation planning skill. Creates DAG-structured plan directories where each step is an independent, QA-able vertical slice that sub-agents can pick up and implement in parallel. Use whenever the user wants a plan that fans out (multiple independent features), invokes /v-plan, or asks for a \\"parallel plan\\", \\"DAG plan\\", \\"vertical plan\\", or \\"plan that can be parallelized\\" — even if they don't say those exact words. Prefer the linear \`planning\` skill for strictly sequential work.",
   "displayName": "V-Planning",
@@ -11625,7 +11649,7 @@ var config_default47 = `{
 `;
 
 // templates/skills/v-planning/content.md
-var content_default47 = `# v-planning
+var content_default49 = `# v-planning
 
 You create implementation plans as a **DAG of vertical steps** — each step a complete, QA-able slice of value (DB + API + UI + tests for one feature). The DAG captures feature-level dependencies, so independent steps can be implemented in parallel by sub-agents.
 
@@ -11716,7 +11740,7 @@ Structure validation runs automatically (rule 9, Haiku sub-agent).
 `;
 
 // templates/skills/verifying/config.json
-var config_default48 = `{
+var config_default50 = `{
   "category": "skills",
   "description": "Post-implementation plan verification. Cross-references plans against actual changes for completeness and accuracy.",
   "displayName": "Verifying",
@@ -11737,7 +11761,7 @@ var config_default48 = `{
 `;
 
 // templates/skills/verifying/content.md
-var content_default48 = `# Verifying
+var content_default50 = `# Verifying
 
 You are performing a post-implementation audit of a plan, cross-referencing it against actual changes to ensure nothing was missed, nothing is stale, and the implementation matches what was planned.
 
@@ -11885,7 +11909,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/work-on-task/config.json
-var config_default49 = `{
+var config_default51 = `{
   "kind": "skill",
   "name": "work-on-task",
   "displayName": "Work On Task",
@@ -11902,10 +11926,10 @@ var config_default49 = `{
 `;
 
 // templates/skills/work-on-task/content.md
-var content_default49 = "# Working on a task\n\nThe taskId follows the command. Without one, call `get-tasks` with `mineOnly: true` and take your `pending` or `in_progress` task. If there is none, say so and stop.\n\nThis message carries the task text, its attachments, its output format, and memories from past sessions. If it does not (you invoked this command yourself, or the context was compacted), run the `task-context-gathering` script with the taskId.\n\nWhen the task names a skill (`researching`, `planning`, `implementing`), use it. Otherwise work directly.\n\nFinish the task with one of the four endings in your operating contract: `completed`, `defer-task`, `request-human-input`, or `failed`. Then stop.\n\nResuming (a resume task, or work cut by a graceful shutdown): read the parent's last progress line, then re-read live state once (PR state and head SHA, branch, `git status`) before new work. Re-run controls only if the head moved. Never redo a pushed commit or open a second PR for the same branch. Store a progress line with branch, PR number and head SHA each time you push. A document task has no branch: its live state is the brief's agent-fs output path and the task attachments. Run `agent-fs ls` on that path, download any partial and extend it; never re-run collection steps that already produced artifacts. If your task's `model` differs from the parent's, say so in the output, because the result's provenance changed.\n\nWrite times in replies, outputs and defer notes in the requester's timezone when the Requester Profile names one, never raw UTC.\n\nIf the user interrupts, follow their instructions. To resume, call `/work-on-task <taskId>` again.\n";
+var content_default51 = "# Working on a task\n\nThe taskId follows the command. Without one, call `get-tasks` with `mineOnly: true` and take your `pending` or `in_progress` task. If there is none, say so and stop.\n\nThis message carries the task text, its attachments, its output format, and memories from past sessions. If it does not (you invoked this command yourself, or the context was compacted), run the `task-context-gathering` script with the taskId.\n\nWhen the task names a skill (`researching`, `planning`, `implementing`), use it. Otherwise work directly.\n\nFinish the task with one of the four endings in your operating contract: `completed`, `defer-task`, `request-human-input`, or `failed`. Then stop.\n\nResuming (a resume task, or work cut by a graceful shutdown): read the parent's last progress line, then re-read live state once (PR state and head SHA, branch, `git status`) before new work. Re-run controls only if the head moved. Never redo a pushed commit or open a second PR for the same branch. Store a progress line with branch, PR number and head SHA each time you push. A document task has no branch: its live state is the brief's agent-fs output path and the task attachments. Run `agent-fs ls` on that path, download any partial and extend it; never re-run collection steps that already produced artifacts. If your task's `model` differs from the parent's, say so in the output, because the result's provenance changed.\n\nWrite times in replies, outputs and defer notes in the requester's timezone when the Requester Profile names one, never raw UTC.\n\nIf the user interrupts, follow their instructions. To resume, call `/work-on-task <taskId>` again.\n";
 
 // templates/skills/workflow-iterate/config.json
-var config_default50 = `{
+var config_default52 = `{
   "kind": "skill",
   "name": "workflow-iterate",
   "displayName": "Workflow Iteration",
@@ -11927,7 +11951,7 @@ var config_default50 = `{
 `;
 
 // templates/skills/workflow-iterate/content.md
-var content_default50 = `# Workflow Iteration
+var content_default52 = `# Workflow Iteration
 
 Use this skill when you need to change an existing workflow without breaking live runs. The goal is to make small, verified revisions: inspect the current workflow, diagnose the failing step, patch only the required node or edge, trigger a realistic run, and keep iterating until the run reaches the intended terminal state.
 
@@ -12102,6 +12126,44 @@ Afterwards, a \`warnings\` entry on \`create-workflow\` or a patch tool means th
 - Do not set \`retry\` or \`validation.retry\` on a \`system-one-decision\` node. It retries connection errors, 408, 429, and 5xx itself (\`config.maxRetries\`, 0 to 3, default 2) inside \`config.timeoutMs\` (default 30000). A 401, a 422, or an answer that fails validation ends after one attempt.
 - The node reads its provider's key (\`TYPESAFE_API_KEY\`, \`OPENROUTER_API_KEY\`, \`LAYA_API_KEY\`, \`OPENAI_DECISIONS_API_KEY\`, or \`CLOUDFLARE_API_TOKEN\`, plus \`LAYA_URL\` for \`laya\` and \`CLOUDFLARE_ACCOUNT_ID\` for \`cloudflare\`) server-side. The key never appears in the definition, the step output, or an error. A run whose key or \`LAYA_URL\` is missing fails before any node executes, and a 401 or 403 fails the step as \`<KEY> was rejected\`. An unresolved \`{{token}}\` fails the step before any request.
 
+#### Jev images (direct TypeSafe API)
+
+\`system-one-decision\` cannot send images today: its strict config has no \`assets\` field, its wire sends only \`state\`, \`model\`, and \`questions\`, and it does not send the image opt-in header. A URL or base64 string in \`state\` stays text. Use a \`swarm-script\` calling \`POST https://api.typesafe.ai/v1/systemone\` with the credential kept server-side until the node supports assets.
+
+- Send \`TypeSafe-Danger-Zone-Images: true\`. Both \`jev-1.13.0\` and \`jev-1.14.0\` accept images; Box questions require 1.14. Pin the model you tested.
+- Upload PNG or JPEG bytes, not a URL. Prefer multipart: first part \`request\` is the JSON with content type \`application/json\`; an asset such as \`assets[uuid] = { type: "image", part: "photo-file" }\` names its file part. For JSON-only calls, use the base64 shape below: standard padded base64, no whitespace or \`data:\` prefix.
+- Each image must be still, at most 16 MiB decoded, 256–1568 pixels on each side, and 78,400–2,458,624 pixels total (256×256 is too small). Request body, all processed images together, and the expanded request each have a 32 MiB limit. Limits reject the whole request; the API does not resize. Rotate pixels upright before sending because EXIF orientation is not applied.
+- Generate a fresh UUID reference per image. References are replaced wherever they occur in string values in \`state\`, \`instructions\`, or \`criteria\`; object keys are not replaced. Every asset must be referenced. Repeating the same reference inserts and bills another image copy.
+
+\`\`\`json
+{
+  "model": "jev-1.13.0",
+  "state": { "photo": "d1369c6a-538e-4ab3-91cd-f76f2f67b651" },
+  "assets": {
+    "d1369c6a-538e-4ab3-91cd-f76f2f67b651": {
+      "type": "image", "format": "png", "data_base64": "<encoded PNG bytes>"
+    }
+  },
+  "questions": {
+    "ready": { "type": "noul", "instructions": "Is the product in \`photo\` fully assembled?" }
+  }
+}
+\`\`\`
+
+Measured 2026-10-15 on \`jev-1.13.0\`, using an 850×850 RGB PNG with a red square on white. Cost is the complete request's \`usage.input_tokens × $0.042 / 1,000,000\`; output is free:
+
+| Placement | Questions | Input tokens | Request cost (USD) |
+|---|---:|---:|---:|
+| Once in \`state\` | 1 | 2,273 | $0.000095466 |
+| Once in \`state\`, questions use the \`photo\` path | 2 | 2,289 | $0.000096138 |
+| Twice in \`state\` | 1 | 4,237 | $0.000177954 |
+| Once in each question's \`instructions\` | 2 | 4,203 | $0.000176526 |
+| Once in \`state\`, resized to 425×425 | 1 | 863 | $0.000036246 |
+
+The roughly $0.0001 claim (about 10,000 one-image requests per dollar) holds for this example; the exact cost depends on image size and prompt. **Question count alone does not multiply a shared state image's tokens.** Put shared images in \`state\` once and have questions use its field path, not the asset UUID. Image duplication scales with repeated references, including one copy per question when embedded in each question's instructions. If several judgments form one classification, a single \`choice\` can avoid repeating question-local images. Downscale when the detail permits: halving both dimensions reduced this request's billed tokens from 2,273 to 863; recheck accuracy on your images.
+
+Contract and current pricing: [TypeSafe images](https://docs.typesafe.ai/images), [models](https://docs.typesafe.ai/models). Re-measure before budgeting a different model, resolution, or prompt.
+
 ### \`human-in-the-loop\` (how approvals render)
 
 The same rules apply to a standalone \`request-human-input\` call.
@@ -12159,7 +12221,7 @@ The same rules apply to a standalone \`request-human-input\` call.
 `;
 
 // templates/skills/workflow-structured-output/config.json
-var config_default51 = `{
+var config_default53 = `{
   "kind": "skill",
   "name": "workflow-structured-output",
   "displayName": "Workflow Structured Output",
@@ -12176,10 +12238,10 @@ var config_default51 = `{
 `;
 
 // templates/skills/workflow-structured-output/content.md
-var content_default51 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
+var content_default53 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
 
 // templates/skills/wts-expert/config.json
-var config_default52 = `{
+var config_default54 = `{
   "category": "skills",
   "description": "Git worktree management expert for @desplega.ai/wts. Use when the user asks about git worktrees, wts commands, worktree workflows, or wants help managing multiple branches simultaneously.",
   "displayName": "WTS Expert",
@@ -12200,7 +12262,7 @@ var config_default52 = `{
 `;
 
 // templates/skills/wts-expert/content.md
-var content_default52 = `# WTS Expert
+var content_default54 = `# WTS Expert
 
 You are an expert on \`@desplega.ai/wts\`, a CLI tool for managing Git worktrees with tmux integration, Claude Code launcher support, and GitHub PR creation.
 
@@ -12350,128 +12412,24 @@ For complete command documentation with all flags and options, see [COMMANDS.md]
 
 // src/be/seed-skills/index.ts
 init_db2();
+
+// src/be/seed/state-db.ts
+init_db2();
+async function getSeedState(kind, key) {
+  return getDbClient().get("SELECT kind, key, seededHash, seededAt FROM seed_state WHERE kind = ? AND key = ?", [kind, key]);
+}
+async function recordSeedState(kind, key, seededHash) {
+  await getDbClient().run(`INSERT INTO seed_state (kind, key, seededHash, seededAt)
+     VALUES (?, ?, ?, ?)
+     ON CONFLICT(kind, key) DO UPDATE SET
+       seededHash = excluded.seededHash,
+       seededAt = excluded.seededAt`, [kind, key, seededHash, new Date().toISOString()]);
+}
+async function deleteSeedState(kind, key) {
+  await getDbClient().run("DELETE FROM seed_state WHERE kind = ? AND key = ?", [kind, key]);
+}
 // src/be/seed-skills/bundled-files.generated.json
 var bundled_files_generated_default = {
-  artifacts: [
-    {
-      path: "examples/approval-flow.ts",
-      content: `import { createArtifactServer } from "../../src/artifact-sdk";
-import { Hono } from "hono";
-
-const app = new Hono();
-app.get("/", (c) =>
-  c.html(\`
-<!DOCTYPE html>
-<html>
-<head><title>Approval Required</title></head>
-<body>
-  <h1>PR #42 — Review Required</h1>
-  <p>Agent wants to merge this PR. Please review.</p>
-  <button id="approve">Approve</button>
-  <button id="reject">Reject</button>
-  <script src="/@swarm/sdk.js"></script>
-  <script>
-    const swarm = new SwarmSDK();
-    document.getElementById('approve').onclick = async () => {
-      await swarm.createTask({ task: 'Merge PR #42 — human approved' });
-      document.body.innerHTML = '<h1>Approved! Task created.</h1>';
-    };
-    document.getElementById('reject').onclick = async () => {
-      await swarm.createTask({ task: 'PR #42 rejected by human — needs changes' });
-      document.body.innerHTML = '<h1>Rejected. Agent notified.</h1>';
-    };
-  </script>
-</body>
-</html>
-\`),
-);
-
-const server = createArtifactServer({ name: "approval-pr-42", app });
-await server.start();
-console.log(\`Approval artifact at: \${server.url}\`);
-`
-    },
-    {
-      path: "examples/hono-dashboard.ts",
-      content: `import { createArtifactServer } from "../../src/artifact-sdk";
-import { Hono } from "hono";
-
-const app = new Hono();
-
-app.get("/", (c) =>
-  c.html(\`
-<!DOCTYPE html>
-<html>
-<head><title>Dashboard</title></head>
-<body>
-  <h1>Agent Dashboard</h1>
-  <div id="agents"></div>
-  <script src="/@swarm/sdk.js"></script>
-  <script>
-    const swarm = new SwarmSDK();
-    swarm.getSwarm().then(agents => {
-      document.getElementById('agents').innerHTML =
-        '<ul>' + agents.map(a => '<li>' + a.name + ' (' + a.status + ')</li>').join('') + '</ul>';
-    });
-  </script>
-</body>
-</html>
-\`),
-);
-
-app.get("/api/status", (c) => c.json({ status: "ok", timestamp: Date.now() }));
-
-const server = createArtifactServer({ name: "dashboard", app });
-await server.start();
-console.log(\`Dashboard live at: \${server.url}\`);
-`
-    },
-    {
-      path: "examples/multi-artifact.ts",
-      content: `import { createArtifactServer } from "../../src/artifact-sdk";
-import { Hono } from "hono";
-
-// Artifact 1: Status page
-const statusApp = new Hono();
-statusApp.get("/", (c) => c.html("<h1>Status: All systems operational</h1>"));
-
-// Artifact 2: Data viewer
-const dataApp = new Hono();
-dataApp.get("/", (c) => c.json({ items: [1, 2, 3], generated: new Date().toISOString() }));
-
-const status = createArtifactServer({ name: "status", app: statusApp });
-const data = createArtifactServer({ name: "data", app: dataApp });
-
-await status.start();
-await data.start();
-
-console.log(\`Status page: \${status.url}\`);
-console.log(\`Data viewer: \${data.url}\`);
-console.log(\`Both artifacts running on different ports (\${status.port}, \${data.port})\`);
-`
-    },
-    {
-      path: "examples/static-report.sh",
-      content: `#!/bin/bash
-# Serve a static HTML report as an artifact
-ARTIFACT_DIR="/workspace/personal/artifacts/my-report"
-mkdir -p "$ARTIFACT_DIR"
-
-cat > "$ARTIFACT_DIR/index.html" << 'HTML'
-<!DOCTYPE html>
-<html>
-<head><title>Agent Report</title></head>
-<body>
-  <h1>Analysis Report</h1>
-  <p>Generated by agent</p>
-</body>
-</html>
-HTML
-
-agent-swarm artifact serve "$ARTIFACT_DIR" --name "my-report"
-`
-    }
-  ],
   brainstorming: [
     {
       path: "template.md",
@@ -13703,6 +13661,294 @@ last_updated_by: [Name]
 - **Verification**: \`thoughts/.../plans/YYYY-MM-DD-verification-report.md\`
 - **Related documents**: [links]
 - **Notes**: [follow-up QA, derail items, environment caveats]
+`
+    }
+  ],
+  "qa-loom": [
+    {
+      path: "build-loom.mjs",
+      content: `// build-loom.mjs: steps.json + raw recording -> narrated qa-loom.mp4 (+ qa-loom.ass, work/).
+// Usage: node build-loom.mjs <steps.json> <raw.webm> <outDir>   (bun works too)
+// Env: ELEVENLABS_API_KEY (required), SPEED=1.33, VOICE=21m00Tcm4TlvDq8ikWAM,
+//      MODEL=eleven_turbo_v2_5, FONT="DejaVu Sans"
+// Needs: Node 18+ (global fetch, top-level await) and ffmpeg built with libass (\`ass\` filter).
+import { execFileSync } from "node:child_process";
+import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { join, resolve } from "node:path";
+
+const [stepsPath, raw, outArg] = process.argv.slice(2);
+if (!stepsPath || !raw || !outArg) {
+  throw new Error("usage: node build-loom.mjs <steps.json> <raw.webm> <outDir>");
+}
+const out = resolve(outArg);
+const SPEED = Number(process.env.SPEED ?? 1.33);
+const VOICE = process.env.VOICE ?? "21m00Tcm4TlvDq8ikWAM";
+const MODEL = process.env.MODEL ?? "eleven_turbo_v2_5";
+const FONT = process.env.FONT ?? "DejaVu Sans";
+const KEY = process.env.ELEVENLABS_API_KEY;
+if (!KEY) throw new Error("ELEVENLABS_API_KEY is not set");
+mkdirSync(join(out, "work"), { recursive: true });
+const W = (f) => join(out, "work", f);
+
+// -loglevel error keeps ffmpeg's banner and progress output out of the logs.
+const ff = (...args) => {
+  try {
+    execFileSync("ffmpeg", ["-y", "-hide_banner", "-loglevel", "error", ...args], {
+      stdio: ["ignore", "ignore", "pipe"],
+    });
+  } catch (e) {
+    throw new Error(\`ffmpeg failed: \${String(e.stderr).slice(0, 400)}\`);
+  }
+};
+const ENC = [
+  "-c:v",
+  "libx264",
+  "-preset",
+  "veryfast",
+  "-crf",
+  "23",
+  "-pix_fmt",
+  "yuv420p",
+  "-r",
+  "30",
+  "-video_track_timescale",
+  "15360",
+];
+// Keep the aspect ratio: letterbox or pillarbox into 1920x1080, never stretch (mobile viewports).
+const FIT =
+  "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2:color=white";
+
+const { steps } = JSON.parse(readFileSync(stepsPath, "utf8"));
+const concat = [];
+const cues = [];
+const audio = [];
+let T = 0; // running output timeline, in seconds
+
+for (const [i, s] of steps.entries()) {
+  const visualAt = s.visualAt ?? s.start;
+  const segLen = (s.end - s.start) / SPEED;
+  const v = (visualAt - s.start) / SPEED; // voice and subtitles start when the screen renders
+
+  // 1. TTS with character timestamps, one request per step. Cached per narration text,
+  //    so a re-run after a style tweak costs no ElevenLabs characters.
+  const mp3 = W(\`audio-\${i + 1}.mp3\`);
+  const alPath = W(\`audio-\${i + 1}.json\`);
+  let cached = existsSync(alPath) ? JSON.parse(readFileSync(alPath, "utf8")) : null;
+  if (cached?.text !== s.narration) {
+    const res = await fetch(
+      \`https://api.elevenlabs.io/v1/text-to-speech/\${VOICE}/with-timestamps\`,
+      {
+        method: "POST",
+        headers: { "xi-api-key": KEY, "content-type": "application/json" },
+        body: JSON.stringify({ text: s.narration, model_id: MODEL }),
+      },
+    );
+    if (!res.ok) throw new Error(\`ElevenLabs \${res.status}: \${(await res.text()).slice(0, 200)}\`);
+    const tts = await res.json();
+    // audio_base64 is large: write it straight to disk, never print it.
+    writeFileSync(mp3, Buffer.from(tts.audio_base64, "base64"));
+    cached = { text: s.narration, alignment: tts.alignment };
+    writeFileSync(alPath, JSON.stringify(cached));
+  }
+  const al = cached.alignment;
+  const aDur = al.character_end_times_seconds.at(-1);
+
+  // 2. Sped-up segment. Freeze the last frame when the narration outlasts it.
+  const seg = W(\`seg-\${i + 1}.mp4\`);
+  ff(
+    "-ss",
+    String(s.start),
+    "-t",
+    String(s.end - s.start),
+    "-i",
+    raw,
+    "-an",
+    "-vf",
+    \`setpts=(PTS-STARTPTS)/\${SPEED},\${FIT},fps=30\`,
+    ...ENC,
+    seg,
+  );
+  concat.push(seg);
+  const need = v + aDur + 0.35;
+  let len = segLen;
+  if (need > segLen) {
+    const png = W(\`last-\${i + 1}.png\`);
+    ff("-sseof", "-0.2", "-i", seg, "-update", "1", "-frames:v", "1", png);
+    const pad = W(\`pad-\${i + 1}.mp4\`);
+    const padLen = (need - segLen).toFixed(3);
+    ff("-loop", "1", "-framerate", "30", "-t", padLen, "-i", png, "-vf", FIT, ...ENC, pad);
+    concat.push(pad);
+    len = need;
+  }
+  audio.push({ mp3, delayMs: Math.round((T + v) * 1000) });
+
+  // 3. Subtitle cues from the same alignment, so voice and subtitles cannot drift.
+  //    At most 6 words per cue, break on punctuation, merge orphans under 3 words.
+  const words = [];
+  let cur = null;
+  al.characters.forEach((ch, k) => {
+    if (/\\s/.test(ch)) {
+      if (cur) words.push(cur);
+      cur = null;
+      return;
+    }
+    if (!cur) cur = { text: "", t0: al.character_start_times_seconds[k] };
+    cur.text += ch;
+    cur.t1 = al.character_end_times_seconds[k];
+  });
+  if (cur) words.push(cur);
+  const groups = [];
+  let g = [];
+  for (const w of words) {
+    g.push(w);
+    if (g.length >= 6 || /[.,;:!?]$/.test(w.text)) {
+      groups.push(g);
+      g = [];
+    }
+  }
+  if (g.length) groups.push(g);
+  for (let k = groups.length - 1; k > 0; k--) {
+    if (groups[k].length < 3) {
+      groups[k - 1].push(...groups[k]);
+      groups.splice(k, 1);
+    }
+  }
+  for (const grp of groups) {
+    cues.push({
+      t0: T + v + grp[0].t0,
+      t1: T + v + grp.at(-1).t1 + 0.1,
+      text: grp.map((w) => w.text).join(" "),
+    });
+  }
+  T += len;
+}
+
+// 4. Concat with the concat demuxer. The concat filter in one big filtergraph can
+//    truncate the video stream.
+writeFileSync(W("concat.txt"), concat.map((f) => \`file '\${f}'\`).join("\\n"));
+ff("-f", "concat", "-safe", "0", "-i", W("concat.txt"), "-c", "copy", W("video.mp4"));
+
+// 5. ASS subtitles: one small line, bottom centre, dark box. libass ignores the
+//    BackColour alpha with BorderStyle=3, so the box is solid #303030.
+const ts = (t) => {
+  const cs = Math.round(t * 100);
+  const h = Math.floor(cs / 360000);
+  const m = String(Math.floor(cs / 6000) % 60).padStart(2, "0");
+  const sec = String(Math.floor(cs / 100) % 60).padStart(2, "0");
+  return \`\${h}:\${m}:\${sec}.\${String(cs % 100).padStart(2, "0")}\`;
+};
+for (let k = 0; k < cues.length - 1; k++) cues[k].t1 = Math.min(cues[k].t1, cues[k + 1].t0);
+const dialogue = cues
+  .map((c) => \`Dialogue: 0,\${ts(c.t0)},\${ts(c.t1)},Default,,0,0,0,,\${c.text}\`)
+  .join("\\n");
+const ass = \`[Script Info]
+ScriptType: v4.00+
+PlayResX: 1920
+PlayResY: 1080
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
+Style: Default,\${FONT},38,&H00FFFFFF,&H00FFFFFF,&H303030,&H00000000,0,0,0,0,100,100,0,0,3,2,0,2,40,40,30,1
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+\${dialogue}
+\`;
+const assPath = join(out, "qa-loom.ass");
+writeFileSync(assPath, ass);
+
+// 6. Mux: delay each step's audio to where its screen renders, mix, burn subtitles.
+//    normalize=0 stops amix from dividing the volume by the number of inputs.
+const inputs = audio.flatMap((a) => ["-i", a.mp3]);
+const delays = audio.map((a, k) => \`[\${k + 1}:a]adelay=\${a.delayMs}:all=1[a\${k}]\`).join(";");
+const labels = audio.map((_, k) => \`[a\${k}]\`).join("");
+const mix = \`\${labels}amix=inputs=\${audio.length}:normalize=0:duration=longest[a]\`;
+ff(
+  "-i",
+  W("video.mp4"),
+  ...inputs,
+  "-filter_complex",
+  \`\${delays};\${mix};[0:v]ass=\${assPath}[v]\`,
+  "-map",
+  "[v]",
+  "-map",
+  "[a]",
+  ...ENC,
+  "-c:a",
+  "aac",
+  "-b:a",
+  "128k",
+  "-movflags",
+  "+faststart",
+  "-t",
+  T.toFixed(3),
+  join(out, "qa-loom.mp4"),
+);
+const chars = steps.reduce((n, s) => n + s.narration.length, 0);
+console.log(
+  JSON.stringify({ durationS: +T.toFixed(2), steps: steps.length, cues: cues.length, chars }),
+);
+`
+    },
+    {
+      path: "run-qa.sh",
+      content: `#!/usr/bin/env bash
+# run-qa.sh: record a UI QA pass with agent-browser and write steps.json.
+# Every step offset is in seconds from the moment recording starts.
+#
+# Usage: BASE_URL=http://localhost:5274 OUT=./loom bash run-qa.sh
+# Needs: agent-browser (with \`record\`), jq, GNU date (%N). No bc: time math runs in jq.
+#
+# Replace the two example steps with the steps that prove your change.
+set -euo pipefail
+BASE_URL=\${BASE_URL:-http://localhost:5274}
+OUT=\${OUT:-./loom}
+mkdir -p "$OUT"
+LOG="$OUT/steps.ndjson"
+: >"$LOG"
+
+now() { date +%s.%N; }
+# act: call right before the action fires. It marks the step start.
+act() { STEP_START=$(now); }
+# step <action> <observed> <verdict> <narration>: call AFTER the resulting screen has
+# rendered (after an \`agent-browser wait <selector>\`). That moment becomes visualAt.
+step() {
+  jq -nc --arg a "$1" --arg o "$2" --arg v "$3" --arg n "$4" \\
+    --arg t0 "$T0" --arg s "$STEP_START" --arg va "$(now)" \\
+    '{action:$a, observed:$o, verdict:$v, narration:$n,
+      start:(($s|tonumber)-($t0|tonumber)), visualAt:(($va|tonumber)-($t0|tonumber))}' >>"$LOG"
+}
+
+# Log in and seed data BEFORE recording starts.
+agent-browser set viewport 1920 1080 >/dev/null
+agent-browser open "$BASE_URL" >/dev/null
+agent-browser wait 1500 >/dev/null
+agent-browser record start "$OUT/raw.webm" --cursor --fps 30 >/dev/null
+T0=$(now)
+
+act
+agent-browser reload >/dev/null
+agent-browser wait h1 >/dev/null
+step "Load home page" "Heading and nav render" pass "The home page loads with its heading and nav."
+agent-browser wait 800 >/dev/null # dwell so the viewer sees the result before the next action
+
+act
+agent-browser open "$BASE_URL/settings" >/dev/null
+agent-browser wait h1 >/dev/null
+step "Open settings" "Settings page renders" pass "The settings page opens."
+agent-browser wait 800 >/dev/null
+
+END=$(jq -n --arg a "$(now)" --arg b "$T0" '($a|tonumber)-($b|tonumber)')
+agent-browser record stop >/dev/null
+
+# Each step ends where the next one starts; the last one ends at record stop.
+jq -s --argjson end "$END" '
+  {steps: ([to_entries[] | .value + {idx: (.key + 1)}]
+    | . as $s
+    | [range(0; length) as $i
+        | $s[$i] + {end: (if $i + 1 < ($s | length) then $s[$i + 1].start else $end end)}])}
+' "$LOG" >"$OUT/steps.json"
+jq -c '.steps[] | {idx, start, visualAt, end, verdict}' "$OUT/steps.json"
 `
     }
   ],
@@ -14993,13 +15239,13 @@ var BUILT_IN_SKILL_SOURCES = [
   { config: config_default34, body: content_default34 },
   { config: config_default35, body: content_default35 },
   { config: config_default36, body: content_default36 },
-  { config: config_default41, body: content_default41 },
   { config: config_default37, body: content_default37 },
   { config: config_default38, body: content_default38 },
+  { config: config_default43, body: content_default43 },
   { config: config_default39, body: content_default39 },
   { config: config_default40, body: content_default40 },
+  { config: config_default41, body: content_default41 },
   { config: config_default42, body: content_default42 },
-  { config: config_default43, body: content_default43 },
   { config: config_default44, body: content_default44 },
   { config: config_default45, body: content_default45 },
   { config: config_default46, body: content_default46 },
@@ -15008,7 +15254,9 @@ var BUILT_IN_SKILL_SOURCES = [
   { config: config_default49, body: content_default49 },
   { config: config_default50, body: content_default50 },
   { config: config_default51, body: content_default51 },
-  { config: config_default52, body: content_default52 }
+  { config: config_default52, body: content_default52 },
+  { config: config_default53, body: content_default53 },
+  { config: config_default54, body: content_default54 }
 ];
 function canonicalFiles(files) {
   return [...files].sort((a, b) => a.path.localeCompare(b.path)).map((file) => `${file.path}
@@ -15098,6 +15346,42 @@ async function syncSeededSkillFiles(skillId, files) {
   if (files.length > 0)
     await upsertSkillFiles(skillId, files);
 }
+var RETIRED_SEED_SKILLS = ["artifacts"];
+function metadataAsSeeded(skill, fileCount) {
+  let seededDescription;
+  try {
+    seededDescription = parseSkillContent(skill.content).description;
+  } catch {
+    return false;
+  }
+  return skill.description === seededDescription && skill.type === "personal" && skill.isComplex === fileCount > 0 && skill.isEnabled && !skill.disableModelInvocation && skill.allowedTools === null && skill.model === null && skill.effort === null && skill.context === null && skill.agent === null && skill.sourceUrl === null && skill.sourceRepo === null && skill.sourcePath === null && skill.sourceBranch === "main" && skill.sourceHash === null && skill.lastFetchedAt === null;
+}
+async function retireSeedSkills(names = RETIRED_SEED_SKILLS) {
+  const retired = [];
+  for (const name of names) {
+    const existing = await getSkillByName(name, "swarm");
+    if (!existing)
+      continue;
+    const state = await getSeedState("skill", name);
+    if (!state)
+      continue;
+    const liveFiles = (await getSkillFiles(existing.id)).map((file) => ({
+      path: file.path,
+      content: file.content
+    }));
+    const liveHash = skillSeedHash(existing.content, existing.systemDefault, liveFiles, existing.userInvocable);
+    if (liveHash !== state.seededHash || !metadataAsSeeded(existing, liveFiles.length)) {
+      console.warn(`[seed:skill] kept retired skill "${name}": edited since it was seeded`);
+      continue;
+    }
+    await getDbClient().transaction(async () => {
+      await deleteSkill(existing.id);
+      await deleteSeedState("skill", name);
+    });
+    retired.push(name);
+  }
+  return retired;
+}
 var skillsSeeder = {
   kind: "skill",
   async items() {
@@ -15148,22 +15432,10 @@ var skillsSeeder = {
       });
       await syncSeededSkillFiles(created.id, skill.files);
     });
-  }
+  },
+  retire: () => retireSeedSkills()
 };
 
-// src/be/seed/state-db.ts
-init_db2();
-async function getSeedState(kind, key) {
-  return getDbClient().get("SELECT kind, key, seededHash, seededAt FROM seed_state WHERE kind = ? AND key = ?", [kind, key]);
-}
-async function recordSeedState(kind, key, seededHash) {
-  await getDbClient().run(`INSERT INTO seed_state (kind, key, seededHash, seededAt)
-     VALUES (?, ?, ?, ?)
-     ON CONFLICT(kind, key) DO UPDATE SET
-       seededHash = excluded.seededHash,
-       seededAt = excluded.seededAt`, [kind, key, seededHash, new Date().toISOString()]);
-}
-
 // src/be/seed/runner.ts
 async function runSeeder(seeder, opts) {
   const result = {
@@ -15172,6 +15444,7 @@ async function runSeeder(seeder, opts) {
     updated: 0,
     skippedUnchanged: 0,
     skippedUserModified: 0,
+    retired: 0,
     failed: []
   };
   const items = await seeder.items();
@@ -15207,8 +15480,18 @@ async function runSeeder(seeder, opts) {
       });
     }
   }
+  if (seeder.retire) {
+    try {
+      result.retired = (await seeder.retire()).length;
+    } catch (err) {
+      result.failed.push({
+        key: "(retire)",
+        error: err instanceof Error ? err.message : String(err)
+      });
+    }
+  }
   if (!opts?.quiet) {
-    console.log(`[seed:${result.kind}] created=${result.created} updated=${result.updated} ` + `unchanged=${result.skippedUnchanged} preserved=${result.skippedUserModified} ` + `failed=${result.failed.length}`);
+    console.log(`[seed:${result.kind}] created=${result.created} updated=${result.updated} ` + `unchanged=${result.skippedUnchanged} preserved=${result.skippedUserModified} ` + `retired=${result.retired} failed=${result.failed.length}`);
     for (const f of result.failed) {
       console.error(`[seed:${result.kind}] FAILED ${f.key}: ${f.error}`);
     }
@@ -15227,7 +15510,7 @@ async function runSeeders(seeders, opts) {
 var import_cron_parser = __toESM(require_dist(), 1);
 
 // templates/schedules/daily-blocker-digest/config.json
-var config_default53 = `{
+var config_default55 = `{
   "kind": "schedule",
   "name": "daily-blocker-digest",
   "displayName": "Daily Blocker Digest",
@@ -15249,7 +15532,7 @@ var config_default53 = `{
 `;
 
 // templates/schedules/daily-blocker-digest/content.md
-var content_default53 = `# Daily Blocker Digest
+var content_default55 = `# Daily Blocker Digest
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -15418,7 +15701,7 @@ Call \`store-progress\` with status \`completed\` and an output paragraph coveri
 `;
 
 // templates/schedules/daily-compounding-reflection/config.json
-var config_default54 = `{
+var config_default56 = `{
   "kind": "schedule",
   "name": "daily-compounding-reflection",
   "displayName": "Daily Evolution",
@@ -15441,7 +15724,7 @@ var config_default54 = `{
 `;
 
 // templates/schedules/daily-compounding-reflection/content.md
-var content_default54 = `# Daily Compounding Reflection
+var content_default56 = `# Daily Compounding Reflection
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -15666,7 +15949,7 @@ If you have zero changes across all three folds and zero deferred items, somethi
 `;
 
 // templates/schedules/daily-hn-briefing/config.json
-var config_default55 = `{
+var config_default57 = `{
   "kind": "schedule",
   "name": "daily-hn-briefing",
   "displayName": "Daily Hacker News Briefing",
@@ -15683,7 +15966,7 @@ var config_default55 = `{
 `;
 
 // templates/schedules/daily-hn-briefing/content.md
-var content_default55 = `# Daily Hacker News Briefing
+var content_default57 = `# Daily Hacker News Briefing
 
 Template parameters: {{REPORT_EMAIL}}
 
@@ -15785,7 +16068,7 @@ IMPORTANT:
 `;
 
 // templates/schedules/daily-status-report/config.json
-var config_default56 = `{
+var config_default58 = `{
   "kind": "schedule",
   "name": "daily-status-report",
   "displayName": "Daily Status Report",
@@ -15807,7 +16090,7 @@ var config_default56 = `{
 `;
 
 // templates/schedules/daily-status-report/content.md
-var content_default56 = `# Daily Status Report
+var content_default58 = `# Daily Status Report
 
 Give the operator one daily read on whether the swarm is healthy: what's running, what's failed, what's waiting on them.
 
@@ -15903,7 +16186,7 @@ More than 3 qualify ⇒ post the 3 that matter and put the rest in the task outp
 `;
 
 // templates/schedules/daily-swarm-update-check/config.json
-var config_default57 = `{
+var config_default59 = `{
   "kind": "schedule",
   "name": "daily-swarm-update-check",
   "displayName": "Daily Agent-Swarm Update Check",
@@ -15925,7 +16208,7 @@ var config_default57 = `{
 `;
 
 // templates/schedules/daily-swarm-update-check/content.md
-var content_default57 = `# Daily Agent-Swarm Update Check
+var content_default59 = `# Daily Agent-Swarm Update Check
 
 Zero-config auto-update watchdog: compares the swarm's own running version against the latest published GitHub release of \`desplega-ai/agent-swarm\`, and flags the operator when an upgrade is available. No placeholders and no integration required — every install gets this by default.
 
@@ -15977,7 +16260,7 @@ Do not attempt the upgrade yourself — this schedule only detects and reports.
 `;
 
 // templates/schedules/daily-workflow-health-audit/config.json
-var config_default58 = `{
+var config_default60 = `{
   "kind": "schedule",
   "name": "daily-workflow-health-audit",
   "displayName": "Daily Workflow Health Audit",
@@ -15999,7 +16282,7 @@ var config_default58 = `{
 `;
 
 // templates/schedules/daily-workflow-health-audit/content.md
-var content_default58 = `# Daily Workflow Health Audit
+var content_default60 = `# Daily Workflow Health Audit
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -16193,7 +16476,7 @@ Omit any section whose count is 0. **HARD CEILING 700 characters — not the 400
 `;
 
 // templates/schedules/gtm-weekly-review/config.json
-var config_default59 = `{
+var config_default61 = `{
   "kind": "schedule",
   "name": "gtm-weekly-review",
   "displayName": "Weekly GTM Metrics Review",
@@ -16210,7 +16493,7 @@ var config_default59 = `{
 `;
 
 // templates/schedules/gtm-weekly-review/content.md
-var content_default59 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
+var content_default61 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
 
 # Weekly GTM Metrics Review
 
@@ -16291,7 +16574,7 @@ This is part of your team's GTM goal; update the goal statement before enabling
 `;
 
 // templates/schedules/weekly-code-health-reports/config.json
-var config_default60 = `{
+var config_default62 = `{
   "kind": "schedule",
   "name": "weekly-code-health-reports",
   "displayName": "Weekly Code Health Reports",
@@ -16308,7 +16591,7 @@ var config_default60 = `{
 `;
 
 // templates/schedules/weekly-code-health-reports/content.md
-var content_default60 = `# Weekly Code Health Reports
+var content_default62 = `# Weekly Code Health Reports
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{SCOPE_PATH}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -16373,7 +16656,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 `;
 
 // templates/schedules/weekly-dependabot-triage/config.json
-var config_default61 = `{
+var config_default63 = `{
   "kind": "schedule",
   "name": "weekly-dependabot-triage",
   "displayName": "Weekly Dependency Triage",
@@ -16390,7 +16673,7 @@ var config_default61 = `{
 `;
 
 // templates/schedules/weekly-dependabot-triage/content.md
-var content_default61 = `# Weekly Dependency Triage
+var content_default63 = `# Weekly Dependency Triage
 
 Template parameters: {{SLACK_CHANNEL_ID}}, {{REPO_URL}}, {{TIMEZONE}}
 
@@ -16444,7 +16727,7 @@ Call \`store-progress\` with status \`completed\` and an output summary listing
 `;
 
 // templates/schedules/weekly-dora-metrics/config.json
-var config_default62 = `{
+var config_default64 = `{
   "kind": "schedule",
   "name": "weekly-dora-metrics",
   "displayName": "Weekly DORA Metrics",
@@ -16461,7 +16744,7 @@ var config_default62 = `{
 `;
 
 // templates/schedules/weekly-dora-metrics/content.md
-var content_default62 = `# Weekly DORA Metrics
+var content_default64 = `# Weekly DORA Metrics
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{TAG_PATTERN}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -16527,7 +16810,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 `;
 
 // templates/schedules/weekly-harness-upgrade-check/config.json
-var config_default63 = `{
+var config_default65 = `{
   "kind": "schedule",
   "name": "weekly-harness-upgrade-check",
   "displayName": "Weekly Harness Upgrade Check",
@@ -16544,7 +16827,7 @@ var config_default63 = `{
 `;
 
 // templates/schedules/weekly-harness-upgrade-check/content.md
-var content_default63 = '# Weekly Harness Upgrade Check\n\nThis is a topology-preserving, anonymized port of the live Sunday schedule. It keeps its bundle, deduplication, baseline, partial-fallback, and CI acceptance behavior.\n\n```json\n{"cron":"0 16 * * 0","timezone":"UTC","agentRole":"lead","enabled":true}\n```\n\n**Weekly Harness Upgrade — self-hosted repository Dockerfile.worker**\n\nRepo: `{{REPO_URL}}` (working dir: `/workspace/repo`)\nFile: `Dockerfile.worker`\n\nThe worker image pins these harnesses via `ARG`. Each week, check upstream for new versions and open ONE PR bundling ALL outdated harness bumps together ({{PR_REVIEWER}}\'s preference — bump ALL in one PR per run, do NOT stagger one-per-run).\n\n| ARG | Source | Sync requirement |\n|---|---|---|\n| `CLAUDE_CODE_VERSION` | npm `@anthropic-ai/claude-code` | none |\n| `PI_CODING_AGENT_VERSION` | npm `@earendil-works/pi-coding-agent` | MUST match `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` in `package.json` (family-pin, all same version) — bump all together |\n| `CODEX_VERSION` | npm `@openai/codex` | MUST match direct `@openai/codex` in `package.json` (enforced by `scripts/check-codex-default-model.sh`) |\n| `OPENCODE_VERSION` | npm `@opencode/sdk` | Installs both `@opencode/cli` and `@opencode/sdk`. MUST match `@opencode/sdk` and `@opencode/plugin` in `package.json` devDependencies. OpenCode 2 ships under the `@opencode/*` scope; never take a version from `opencode-ai`, `@opencode-ai/sdk`, or the `sst/opencode` GitHub releases (still the 1.x line, which would be a downgrade) |\n\n## Steps\n\n1. `cd /workspace/repo && git fetch origin && git checkout main && git pull --ff-only`\n2. Read current pinned versions from `Dockerfile.worker` (the `ARG` lines) and from `package.json` (for the pi family + `@openai/codex` + `@opencode/sdk`).\n3. For each harness, fetch the latest version:\n   - npm claude-code: `npm view @anthropic-ai/claude-code version`\n   - npm pi: `npm view @earendil-works/pi-coding-agent version` (use the SAME version for `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` — they\'re a family pin)\n   - npm codex: `npm view @openai/codex version`\n   - npm opencode: `npm view @opencode/sdk version` (one version for `@opencode/cli`, `@opencode/sdk`, `@opencode/plugin`)\n4. Check for an existing open bundled PR — `gh pr list --search "harness upgrade in:title" --state open --repo {{REPO_URL}}`. Look at the branch prefix `harness-upgrade/`. If one is already open AND was created within the last 48h (sibling schedule may have just opened it), skip and complete with `"Skipped: sibling harness upgrade PR already open"` + the existing PR URL.\n5. Collect ALL outdated harnesses. If none are outdated, complete with output `"All harnesses up to date as of YYYY-MM-DD"` (no PR).\n6. Branch: `harness-upgrade/weekly-YYYY-MM-DD` (e.g. `harness-upgrade/weekly-2026-06-03`).\n7. Edit `Dockerfile.worker` — bump every outdated ARG. Also update `package.json`:\n   - Codex: bump direct `@openai/codex` to match `CODEX_VERSION`.\n   - Pi family: bump `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` to the same new version as `PI_CODING_AGENT_VERSION`.\n   - Opencode: bump `@opencode/sdk` and `@opencode/plugin` (devDependencies) to match `OPENCODE_VERSION`.\n   Then re-run `bun install` so `bun.lock` updates.\n8. Local verification (all must pass before pushing):\n   ```bash\n   bun install --frozen-lockfile\n   bun run lint\n   bun run tsc:check\n   bun test\n   bash scripts/check-db-boundary.sh\n   ```\n   For Codex bumps: also run `bash scripts/check-codex-default-model.sh`.\n   Note: do NOT run `docker build -f Dockerfile.worker .` locally — the runner lacks docker. CI\'s `docker-worker-build` job is the acceptance gate.\n9. If any local check fails, apply the **partial-bundle fallback** before giving up — one harness must never block the others:\n   **BASELINE FIRST — do this before ANY isolation work.** A red gate does NOT mean the bumps broke anything. Re-run the EXACT failing command on a pristine `origin/main` worktree with zero bumps applied (`git worktree add /tmp/hb-baseline origin/main && cd /tmp/hb-baseline && bun install --frozen-lockfile`) and compare. If the SAME checks fail with the SAME assertions and the same pass/skip/fail totals, the failure is **PRE-EXISTING and unrelated to the bumps** ⇒ it does NOT block this PR, and you must NOT attempt isolation for it. Proceed to step 10, open the PR, and add a `## Pre-existing failures (also fail on origin/main)` section quoting the verbatim error plus both totals (baseline vs branch) so the reviewer can see they match. Only a failure that is RED on your branch and GREEN on baseline was caused by a bump — apply a–d below to that failure ONLY. A gate that is red on origin/main is never a reason to skip the weekly bump.\n   a. Isolate which harness\'s bump caused it. The error usually names the package; if not, revert bumps one at a time until the step-8 gate passes.\n   b. Revert ONLY that harness — its `Dockerfile.worker` ARG **and** its `package.json` pins (respect the family/sync requirements in the table above) — then re-run `bun install` and the FULL step-8 gate.\n   c. Gate green ⇒ open the PR with the remaining harnesses and add a `## Held back` section naming the excluded harness, current → attempted version, and the VERBATIM error. Name it in your `store-progress` output too.\n   d. Gate still red with that harness reverted, OR the failure cannot be isolated to one harness ⇒ do NOT open a PR; report via `store-progress` with `failureReason`.\n   Migrating an upstream API break (a removed option, a renamed export, a moved type) is still OUT OF SCOPE for this routine — hold that harness back per (c) rather than changing code here.\n10. Push the branch and open a PR:\n    - Title: `chore(docker): bump harnesses (weekly YYYY-MM-DD)` — or list the bumps, e.g. `chore(docker): bump claude-code, pi, opencode (weekly YYYY-MM-DD)`.\n    - Body: include a table of current → new versions for every harness bumped, link to each upstream changelog (e.g. https://github.com/anthropics/claude-code/releases/tag/v<X.Y.Z>), and the local verification output (or "all green").\n    - Add `{{PR_REVIEWER}}` as a reviewer.\n    - DO NOT merge — {{PR_REVIEWER}} reviews and merges.\n11. Verify CI on the PR — wait for the merge-gate workflow to start, confirm at least the `docker-worker-build` job is queued/passing. If CI fails, comment on the PR with the failure log and leave the branch for human review.\n\n## Constraints\n\n- **ONE bundled PR per run.** Bump every outdated harness in the same PR — do not stagger one-per-run. The ONLY permitted exclusion is a harness held back by the step-9 partial-bundle fallback, which must be declared in the PR body.\n- **No `--no-verify`, no force pushes.**\n- If a harness has a major-version bump (e.g. 2.x → 3.x), still bundle it but flag clearly in the PR description that this is a major bump and may need extra review.\n- Pi family-pin: all three pi packages MUST be the same version. If they drift in the lockfile, fix the drift in the same PR.\n\n## Sibling-schedule coordination\nThis schedule has a sibling — `weekly-harness-upgrade-check-wed` (Wednesday 05:00 BCN). If a sibling-opened PR is OPEN and `< 48h` old, step 4 skips. This is the dedup gate. Don\'t change branch-naming heuristics in a way that breaks the dedup.\n\n## Output\n\n`store-progress` with `status: "completed"` and `output` containing:\n- The PR URL (if one was opened) + the table of harnesses bumped, OR\n- "No-op: all harnesses up to date as of YYYY-MM-DD" with the version table, OR\n- "Skipped: sibling harness upgrade PR already open" with the existing PR URL.\n';
+var content_default65 = '# Weekly Harness Upgrade Check\n\nThis is a topology-preserving, anonymized port of the live Sunday schedule. It keeps its bundle, deduplication, baseline, partial-fallback, and CI acceptance behavior.\n\n```json\n{"cron":"0 16 * * 0","timezone":"UTC","agentRole":"lead","enabled":true}\n```\n\n**Weekly Harness Upgrade — self-hosted repository Dockerfile.worker**\n\nRepo: `{{REPO_URL}}` (working dir: `/workspace/repo`)\nFile: `Dockerfile.worker`\n\nThe worker image pins these harnesses via `ARG`. Each week, check upstream for new versions and open ONE PR bundling ALL outdated harness bumps together ({{PR_REVIEWER}}\'s preference — bump ALL in one PR per run, do NOT stagger one-per-run).\n\n| ARG | Source | Sync requirement |\n|---|---|---|\n| `CLAUDE_CODE_VERSION` | npm `@anthropic-ai/claude-code` | none |\n| `PI_CODING_AGENT_VERSION` | npm `@earendil-works/pi-coding-agent` | MUST match `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` in `package.json` (family-pin, all same version) — bump all together |\n| `CODEX_VERSION` | npm `@openai/codex` | MUST match direct `@openai/codex` in `package.json` (enforced by `scripts/check-codex-default-model.sh`) |\n| `OPENCODE_VERSION` | npm `@opencode/sdk` | Installs both `@opencode/cli` and `@opencode/sdk`. MUST match `@opencode/sdk` and `@opencode/plugin` in `package.json` devDependencies. OpenCode 2 ships under the `@opencode/*` scope; never take a version from `opencode-ai`, `@opencode-ai/sdk`, or the `sst/opencode` GitHub releases (still the 1.x line, which would be a downgrade) |\n\n## Steps\n\n1. `cd /workspace/repo && git fetch origin && git checkout main && git pull --ff-only`\n2. Read current pinned versions from `Dockerfile.worker` (the `ARG` lines) and from `package.json` (for the pi family + `@openai/codex` + `@opencode/sdk`).\n3. For each harness, fetch the latest version:\n   - npm claude-code: `npm view @anthropic-ai/claude-code version`\n   - npm pi: `npm view @earendil-works/pi-coding-agent version` (use the SAME version for `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` — they\'re a family pin)\n   - npm codex: `npm view @openai/codex version`\n   - npm opencode: `npm view @opencode/sdk version` (one version for `@opencode/cli`, `@opencode/sdk`, `@opencode/plugin`)\n4. Check for an existing open bundled PR — `gh pr list --search "harness upgrade in:title" --state open --repo {{REPO_URL}}`. Look at the branch prefix `harness-upgrade/`. If one is already open AND was created within the last 48h (sibling schedule may have just opened it), skip and complete with `"Skipped: sibling harness upgrade PR already open"` + the existing PR URL.\n5. Collect ALL outdated harnesses. If none are outdated, complete with output `"All harnesses up to date as of YYYY-MM-DD"` (no PR).\n6. Branch: `harness-upgrade/weekly-YYYY-MM-DD` (e.g. `harness-upgrade/weekly-2026-06-03`).\n7. Edit `Dockerfile.worker` — bump every outdated ARG. Also update `package.json`:\n   - Codex: bump direct `@openai/codex` to match `CODEX_VERSION`.\n   - Pi family: bump `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` to the same new version as `PI_CODING_AGENT_VERSION`.\n   - Opencode: bump `@opencode/sdk` and `@opencode/plugin` (devDependencies) to match `OPENCODE_VERSION`.\n   Then re-run `bun install` so `bun.lock` updates.\n8. Local verification (all must pass before pushing):\n   ```bash\n   bun install --frozen-lockfile\n   bun run lint\n   bun run tsc:check\n   bun test\n   bash scripts/check-db-boundary.sh\n   ```\n   For Codex bumps: also run `bash scripts/check-codex-default-model.sh`.\n   Note: do NOT run `docker build -f Dockerfile.worker .` locally — the runner lacks docker. CI\'s `docker-worker-build` job is the acceptance gate.\n9. If any local check fails, apply the **partial-bundle fallback** before giving up — one harness must never block the others:\n   **BASELINE FIRST — do this before ANY isolation work.** A red gate does NOT mean the bumps broke anything. Re-run the EXACT failing command on a pristine `origin/main` worktree with zero bumps applied (`git worktree add /tmp/hb-baseline origin/main && cd /tmp/hb-baseline && bun install --frozen-lockfile`) and compare. If the SAME checks fail with the SAME assertions and the same pass/skip/fail totals, the failure is **PRE-EXISTING and unrelated to the bumps** ⇒ it does NOT block this PR, and you must NOT attempt isolation for it. Proceed to step 10, open the PR, and add a `## Pre-existing failures (also fail on origin/main)` section quoting the verbatim error plus both totals (baseline vs branch) so the reviewer can see they match. Only a failure that is RED on your branch and GREEN on baseline was caused by a bump — apply a–d below to that failure ONLY. A gate that is red on origin/main is never a reason to skip the weekly bump.\n   a. Isolate which harness\'s bump caused it. The error usually names the package; if not, revert bumps one at a time until the step-8 gate passes.\n   b. Revert ONLY that harness — its `Dockerfile.worker` ARG **and** its `package.json` pins (respect the family/sync requirements in the table above) — then re-run `bun install` and the FULL step-8 gate.\n   c. Gate green ⇒ open the PR with the remaining harnesses and add a `## Held back` section naming the excluded harness, current → attempted version, and the VERBATIM error. Name it in your `store-progress` output too.\n   d. Gate still red with that harness reverted, OR the failure cannot be isolated to one harness ⇒ do NOT open a PR; report via `store-progress` with `failureReason`.\n   Migrating an upstream API break (a removed option, a renamed export, a moved type) is still OUT OF SCOPE for this routine — hold that harness back per (c) rather than changing code here.\n10. Push the branch and open a PR:\n    - Title: `chore(docker): bump harnesses (weekly YYYY-MM-DD)` — or list the bumps, e.g. `chore(docker): bump claude-code, pi, opencode (weekly YYYY-MM-DD)`.\n    - Body: include a table of current → new versions for every harness bumped, link to each upstream changelog (e.g. https://github.com/anthropics/claude-code/releases/tag/v<X.Y.Z>), and the local verification output (or "all green").\n    - Add `{{PR_REVIEWER}}` as a reviewer.\n    - DO NOT merge — {{PR_REVIEWER}} reviews and merges.\n11. Verify CI on the PR — wait for the merge-gate workflow to start, confirm at least the `docker-worker-build` job is queued/passing. If CI fails, comment on the PR with the failure log and leave the branch for human review.\n\n## Constraints\n\n- **ONE bundled PR per run.** Bump every outdated harness in the same PR — do not stagger one-per-run. The ONLY permitted exclusion is a harness held back by the step-9 partial-bundle fallback, which must be declared in the PR body.\n- **No `--no-verify`, no force pushes.**\n- If a harness has a major-version bump (e.g. 2.x → 3.x), still bundle it but flag clearly in the PR description that this is a major bump and may need extra review.\n- Pi family-pin: all three pi packages MUST be the same version. If they drift in the lockfile, fix the drift in the same PR.\n\n## Sibling-schedule coordination\nThis schedule has a sibling — `weekly-harness-upgrade-check-wed` (Wednesday 05:00 BCN). If a sibling-opened PR is OPEN and `< 48h` old, step 4 skips. This is the dedup gate. Don\'t change branch-naming heuristics in a way that breaks the dedup.\n\n## Output\n\n`store-progress` with `status: "completed"` and `output` containing:\n- The PR URL (if one was opened) + the table of harnesses bumped, OR\n- "No-op: all harnesses up to date as of YYYY-MM-DD" with the version table, OR\n- "Skipped: sibling harness upgrade PR already open" with the existing PR URL.\n';
 
 // src/be/seed/schedules-seeder.ts
 init_db2();
@@ -16566,7 +16849,7 @@ function resolveSeededEnabled(params) {
 }
 
 // templates/workflows/alerts-triage/config.json
-var config_default64 = `{
+var config_default66 = `{
   "kind": "workflow",
   "name": "alerts-triage",
   "displayName": "Alerts Triage",
@@ -16583,7 +16866,7 @@ var config_default64 = `{
 `;
 
 // templates/workflows/alerts-triage/content.md
-var content_default64 = `# Alerts Triage
+var content_default66 = `# Alerts Triage
 
 The Slack handler emits \`slack.message\`; this workflow keeps the event-driven path and deduplicates work after the channel filter.
 
@@ -16603,7 +16886,7 @@ The Slack handler emits \`slack.message\`; this workflow keeps the event-driven
 `;
 
 // templates/workflows/autopilot/config.json
-var config_default65 = `{
+var config_default67 = `{
   "kind": "workflow",
   "name": "autopilot",
   "displayName": "Autopilot Feature Pipeline",
@@ -16620,7 +16903,7 @@ var config_default65 = `{
 `;
 
 // templates/workflows/autopilot/content.md
-var content_default65 = `# Autopilot Feature Pipeline
+var content_default67 = `# Autopilot Feature Pipeline
 
 Template parameter: {{REPO_URL}}
 
@@ -16632,7 +16915,7 @@ Use this workflow as a canonical feature delivery pipeline. Customize roles and
 `;
 
 // templates/workflows/claude-code-changelog-watch/config.json
-var config_default66 = `{
+var config_default68 = `{
   "kind": "workflow",
   "name": "claude-code-changelog-watch",
   "displayName": "Claude Code Changelog Watch",
@@ -16649,10 +16932,10 @@ var config_default66 = `{
 `;
 
 // templates/workflows/claude-code-changelog-watch/content.md
-var content_default66 = '# Claude Code Changelog Watch\n\nThis topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow\'s nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.\n\nPrerequisite: the `check` and `commit` nodes run the global script `claude-code-changelog-check`, which is not seeded. Author it before enabling the workflow, or every run fails at the first node.\n\n```json\n{"name":"claude-code-changelog-watch","description":"Changelog watcher with deduplication: fetch, gate on a new version, publish an in-app receipt plus any configured delivery providers, then commit the version marker.","nodes":[{"id":"check","type":"swarm-script","label":"Fetch changelog + compare vs KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"check"}},"next":"gate"},{"id":"gate","type":"property-match","label":"Gate: only continue on a new version","config":{"mode":"all","conditions":[{"field":"check.result.isNew","op":"eq","value":true}]},"next":{"true":"post"}},{"id":"post","type":"agent-task","label":"Post new version to Slack","config":{"model":"sonnet","tags":["changelog","claude-code","workflow"],"priority":50,"template":"**Claude Code new version announcement**\\n\\nA new Claude Code version was detected by the claude-code-changelog-watch workflow.\\n\\nNew version: {{check.result.latestVersion}} (released {{check.result.releaseDate}}, previous known: {{check.result.lastKnown}})\\n\\nRaw release notes:\\n{{check.result.section}}\\n\\nSteps:\\n1. ONE `slack-post` to the configured Slack notification target, **max 400 chars**:\\n\\n```\\n:rocket: *Claude Code {{check.result.latestVersion}}* — <the one change that matters to us, one line>\\n<https://code.claude.com/docs/en/changelog|changelog>\\n```\\n\\nRules:\\n- **One line.** Pick the single item that affects how we run the swarm (a fix we were hitting, a flag we use, a breaking change). Not 3-5 bullets.\\n- If a second item genuinely matters, one more bullet. Never more than two.\\n- **Routine release with nothing relevant to us ⇒ still post, but the one line is just the headline feature.** Never paste the release notes.\\n- No preamble, no \\"is out!\\", no per-surface breakdown (VSCode/CLI/SDK), no closing line.\\n\\n2. Complete with output \\"Posted Claude Code {{check.result.latestVersion}} to in-app activity and configured delivery providers.\\" plus the charCount.\\n\\nDo NOT update any version state — the workflow\'s commit node handles that after you complete. Do NOT post more than once."},"next":"commit","inputs":{"check":"check"}},{"id":"commit","type":"swarm-script","label":"Commit new version to KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"commit","version":"{{check.result.latestVersion}}"}},"inputs":{"check":"check"}}],"onNodeFailure":"fail"}\n```\n\n\n\n\n';
+var content_default68 = '# Claude Code Changelog Watch\n\nThis topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow\'s nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.\n\nPrerequisite: the `check` and `commit` nodes run the global script `claude-code-changelog-check`, which is not seeded. Author it before enabling the workflow, or every run fails at the first node.\n\n```json\n{"name":"claude-code-changelog-watch","description":"Changelog watcher with deduplication: fetch, gate on a new version, publish an in-app receipt plus any configured delivery providers, then commit the version marker.","nodes":[{"id":"check","type":"swarm-script","label":"Fetch changelog + compare vs KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"check"}},"next":"gate"},{"id":"gate","type":"property-match","label":"Gate: only continue on a new version","config":{"mode":"all","conditions":[{"field":"check.result.isNew","op":"eq","value":true}]},"next":{"true":"post"}},{"id":"post","type":"agent-task","label":"Post new version to Slack","config":{"model":"sonnet","tags":["changelog","claude-code","workflow"],"priority":50,"template":"**Claude Code new version announcement**\\n\\nA new Claude Code version was detected by the claude-code-changelog-watch workflow.\\n\\nNew version: {{check.result.latestVersion}} (released {{check.result.releaseDate}}, previous known: {{check.result.lastKnown}})\\n\\nRaw release notes:\\n{{check.result.section}}\\n\\nSteps:\\n1. ONE `slack-post` to the configured Slack notification target, **max 400 chars**:\\n\\n```\\n:rocket: *Claude Code {{check.result.latestVersion}}* — <the one change that matters to us, one line>\\n<https://code.claude.com/docs/en/changelog|changelog>\\n```\\n\\nRules:\\n- **One line.** Pick the single item that affects how we run the swarm (a fix we were hitting, a flag we use, a breaking change). Not 3-5 bullets.\\n- If a second item genuinely matters, one more bullet. Never more than two.\\n- **Routine release with nothing relevant to us ⇒ still post, but the one line is just the headline feature.** Never paste the release notes.\\n- No preamble, no \\"is out!\\", no per-surface breakdown (VSCode/CLI/SDK), no closing line.\\n\\n2. Complete with output \\"Posted Claude Code {{check.result.latestVersion}} to in-app activity and configured delivery providers.\\" plus the charCount.\\n\\nDo NOT update any version state — the workflow\'s commit node handles that after you complete. Do NOT post more than once."},"next":"commit","inputs":{"check":"check"}},{"id":"commit","type":"swarm-script","label":"Commit new version to KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"commit","version":"{{check.result.latestVersion}}"}},"inputs":{"check":"check"}}],"onNodeFailure":"fail"}\n```\n\n\n\n\n';
 
 // templates/workflows/competitor-radar/config.json
-var config_default67 = `{
+var config_default69 = `{
   "kind": "workflow",
   "name": "competitor-radar",
   "displayName": "Competitor Radar",
@@ -16669,7 +16952,7 @@ var config_default67 = `{
 `;
 
 // templates/workflows/competitor-radar/content.md
-var content_default67 = `# Competitor Radar
+var content_default69 = `# Competitor Radar
 
 This self-hosted port retains the scheduled, fixture, extraction, gap-analysis, litmus, cooldown, and bounded-report behavior. Its pinned GSC helper is embedded in the workflow, so it does not fetch executable code from Desplega infrastructure.
 
@@ -16679,7 +16962,7 @@ This self-hosted port retains the scheduled, fixture, extraction, gap-analysis,
 `;
 
 // templates/workflows/docs-site-releases/config.json
-var config_default68 = `{
+var config_default70 = `{
   "kind": "workflow",
   "name": "docs-site-releases",
   "displayName": "Documentation Release Notes",
@@ -16696,7 +16979,7 @@ var config_default68 = `{
 `;
 
 // templates/workflows/docs-site-releases/content.md
-var content_default68 = `# Documentation Release Notes
+var content_default70 = `# Documentation Release Notes
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -16711,7 +16994,7 @@ This topology-preserving self-hosted port removes installation-specific identiti
 `;
 
 // templates/workflows/gsc-topic-miner/config.json
-var config_default69 = `{
+var config_default71 = `{
   "kind": "workflow",
   "name": "gsc-topic-miner",
   "displayName": "Search Topic Miner",
@@ -16728,7 +17011,7 @@ var config_default69 = `{
 `;
 
 // templates/workflows/gsc-topic-miner/content.md
-var content_default69 = `# Search Topic Miner
+var content_default71 = `# Search Topic Miner
 
 This template uses only the configured GSC and agent-fs integrations. The deferred seeder creates the weekly schedule binding; no installation-specific schedule ID is shipped.
 
@@ -16738,7 +17021,7 @@ This template uses only the configured GSC and agent-fs integrations. The deferr
 `;
 
 // templates/workflows/linear-drain-loop/config.json
-var config_default70 = `{
+var config_default72 = `{
   "kind": "workflow",
   "name": "linear-drain-loop",
   "displayName": "Linear Drain Loop",
@@ -16760,7 +17043,7 @@ var config_default70 = `{
 `;
 
 // templates/workflows/linear-drain-loop/content.md
-var content_default70 = `# Linear Drain Loop
+var content_default72 = `# Linear Drain Loop
 
 Template parameter: {{LINEAR_PROJECT_ID}}
 
@@ -16805,7 +17088,7 @@ Blocked and ambiguous items are explicitly left alone — the dispatch node surf
 `;
 
 // templates/workflows/llm-safe-release-context/config.json
-var config_default71 = `{
+var config_default73 = `{
   "kind": "workflow",
   "name": "llm-safe-release-context",
   "displayName": "LLM-Safe Release Context",
@@ -16822,7 +17105,7 @@ var config_default71 = `{
 `;
 
 // templates/workflows/llm-safe-release-context/content.md
-var content_default71 = `# LLM-Safe Release Context
+var content_default73 = `# LLM-Safe Release Context
 
 Template parameters: {{ORG_ID}}, {{REPO_URL}}
 
@@ -16896,7 +17179,7 @@ This avoids the common failure mode where a large \`context.json\` fills the mod
 `;
 
 // templates/workflows/pr-review-status-sweep/config.json
-var config_default72 = `{
+var config_default74 = `{
   "kind": "workflow",
   "name": "pr-review-status-sweep",
   "displayName": "PR Review Status Sweep",
@@ -16913,7 +17196,7 @@ var config_default72 = `{
 `;
 
 // templates/workflows/pr-review-status-sweep/content.md
-var content_default72 = `# PR Review Status Sweep
+var content_default74 = `# PR Review Status Sweep
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -16928,7 +17211,7 @@ Prerequisite: the \`sweep\` node runs the agent-scoped script \`pr-review-status
 `;
 
 // templates/workflows/ralph-loop/config.json
-var config_default73 = `{
+var config_default75 = `{
   "kind": "workflow",
   "name": "ralph-loop",
   "displayName": "Iterative Review Loop",
@@ -16945,7 +17228,7 @@ var config_default73 = `{
 `;
 
 // templates/workflows/ralph-loop/content.md
-var content_default73 = `# Iterative Review Loop
+var content_default75 = `# Iterative Review Loop
 
 Template parameter: {{REPO_URL}}
 
@@ -16996,19 +17279,19 @@ The \`maxIterations\` parameter is declarative: the reviewer signals PASS when d
 init_db2();
 var asText2 = (value) => value;
 var BUILT_IN_WORKFLOW_SOURCES = [
-  { config: asText2(config_default64), content: asText2(content_default64) },
-  { config: asText2(config_default65), content: asText2(content_default65) },
+  { config: asText2(config_default66), content: asText2(content_default66) },
+  { config: asText2(config_default67), content: asText2(content_default67) },
   {
-    config: asText2(config_default66),
-    content: asText2(content_default66)
+    config: asText2(config_default68),
+    content: asText2(content_default68)
   },
-  { config: asText2(config_default67), content: asText2(content_default67) },
-  { config: asText2(config_default68), content: asText2(content_default68) },
   { config: asText2(config_default69), content: asText2(content_default69) },
   { config: asText2(config_default70), content: asText2(content_default70) },
   { config: asText2(config_default71), content: asText2(content_default71) },
   { config: asText2(config_default72), content: asText2(content_default72) },
-  { config: asText2(config_default73), content: asText2(content_default73) }
+  { config: asText2(config_default73), content: asText2(content_default73) },
+  { config: asText2(config_default74), content: asText2(content_default74) },
+  { config: asText2(config_default75), content: asText2(content_default75) }
 ];
 function sortJson(value) {
   if (Array.isArray(value))
@@ -17124,34 +17407,34 @@ var workflowsSeeder = createWorkflowsSeeder();
 // src/be/seed/schedules-seeder.ts
 var asText3 = (value) => value;
 var BUILT_IN_SCHEDULE_SOURCES = [
-  { config: asText3(config_default53), content: asText3(content_default53) },
-  {
-    config: asText3(config_default54),
-    content: asText3(content_default54)
-  },
   { config: asText3(config_default55), content: asText3(content_default55) },
-  { config: asText3(config_default56), content: asText3(content_default56) },
   {
-    config: asText3(config_default57),
-    content: asText3(content_default57)
+    config: asText3(config_default56),
+    content: asText3(content_default56)
   },
+  { config: asText3(config_default57), content: asText3(content_default57) },
+  { config: asText3(config_default58), content: asText3(content_default58) },
   {
-    config: asText3(config_default58),
-    content: asText3(content_default58)
+    config: asText3(config_default59),
+    content: asText3(content_default59)
   },
-  { config: asText3(config_default59), content: asText3(content_default59) },
   {
     config: asText3(config_default60),
     content: asText3(content_default60)
   },
+  { config: asText3(config_default61), content: asText3(content_default61) },
   {
-    config: asText3(config_default61),
-    content: asText3(content_default61)
+    config: asText3(config_default62),
+    content: asText3(content_default62)
   },
-  { config: asText3(config_default62), content: asText3(content_default62) },
   {
     config: asText3(config_default63),
     content: asText3(content_default63)
+  },
+  { config: asText3(config_default64), content: asText3(content_default64) },
+  {
+    config: asText3(config_default65),
+    content: asText3(content_default65)
   }
 ];
 function parseScheduleSource(source) {