@desplega.ai/agent-swarm 2.5.2 → 2.5.4

package/dist/{index-r70q0xjx.js → index-1ef1myq2.js}

@@ -1,41 +1,41 @@
 import {
   getExecutorRegistry2,
   initWorkflows2
-} from "./cli-h5d22pfs.js";
+} from "./cli-asq5ydm4.js";
 import"./cli-pasyvjmm.js";
-import"./cli-xw9q173h.js";
+import"./cli-9s05422w.js";
 import"./cli-qz93y3x5.js";
 import"./cli-3h26v7yj.js";
-import"./cli-e8xyjvfc.js";
-import"./cli-0vgy5wfw.js";
-import"./cli-e91vshb1.js";
+import"./cli-bvpgr9ny.js";
+import"./cli-7p4jxgtt.js";
 import"./cli-3ggwdtb0.js";
-import"./cli-6y43v79h.js";
-import"./cli-3e9vs93g.js";
-import"./cli-bpbcpd8b.js";
+import"./cli-tsma7p8v.js";
+import"./cli-c61mbdds.js";
+import"./cli-sbwsxvtd.js";
 import"./cli-g9ypd5en.js";
 import {
   retryFailedRun2,
   cancelWorkflowRun2
-} from "./cli-y3dzwyy3.js";
+} from "./cli-x0f2v69c.js";
 import {
   startWorkflowExecution2
-} from "./cli-j3dwd4kz.js";
+} from "./cli-gbfxp48k.js";
 import"./cli-qqzmjxkf.js";
 import"./cli-kxpfx2xr.js";
-import"./cli-d172svcw.js";
+import"./cli-e8xyjvfc.js";
+import"./cli-gwhjmh8g.js";
 import"./cli-13p25grh.js";
 import"./cli-0adyhvq2.js";
-import"./cli-15xd0j7w.js";
-import"./cli-b63d08rs.js";
-import"./cli-4qkg9968.js";
-import"./cli-b6tnjdvx.js";
+import"./cli-abs8ndtr.js";
+import"./cli-eftzyh9y.js";
+import"./cli-19202kew.js";
+import"./cli-6a1xg1p7.js";
 import"./cli-rycdaj0a.js";
 import"./cli-445c1vp7.js";
 import"./cli-kvzgak7c.js";
 import"./cli-2nf3b08t.js";
-import"./cli-86zpfje5.js";
-import"./cli-csh8fnbg.js";
+import"./cli-ff1tm9n9.js";
+import"./cli-jb30dzvk.js";
 import"./cli-dabehxhp.js";
 export {
   cancelWorkflowRun2 as cancelWorkflowRun,

package/dist/{index-a9nsavhx.js → index-3n8m9ea2.js}

@@ -3,7 +3,7 @@ import {
   resetEmbeddingProvider2,
   getMemoryStore2,
   init_memory
-} from "./cli-csh8fnbg.js";
+} from "./cli-jb30dzvk.js";
 init_memory();
 
 export {

package/dist/{index-cbxkmfc5.js → index-9pn1pfkf.js}

@@ -39,7 +39,7 @@ import {
   createJsonResponseHandler,
   withoutTrailingSlash,
   executeTool
-} from "./cli-w9etnnxk.js";
+} from "./cli-bf8ma3f1.js";
 import {
   require_token_error
 } from "./cli-5ss6qqt9.js";

package/dist/{index-s193j5fh.js → index-nmm79qgr.js}

@@ -2,40 +2,40 @@ import"./cli-ns59dc6r.js";
 import {
   startHeartbeat2,
   stopHeartbeat2
-} from "./cli-n2918sed.js";
-import"./cli-cyfgxnvb.js";
-import"./cli-ydg6ep51.js";
-import"./cli-h5d22pfs.js";
+} from "./cli-gn5af0x5.js";
+import"./cli-1r5ad7j5.js";
+import"./cli-6n8axjv1.js";
+import"./cli-asq5ydm4.js";
 import"./cli-pasyvjmm.js";
-import"./cli-xw9q173h.js";
+import"./cli-9s05422w.js";
 import"./cli-qz93y3x5.js";
 import"./cli-3h26v7yj.js";
-import"./cli-e8xyjvfc.js";
-import"./cli-0vgy5wfw.js";
-import"./cli-e91vshb1.js";
+import"./cli-bvpgr9ny.js";
+import"./cli-7p4jxgtt.js";
 import"./cli-3ggwdtb0.js";
-import"./cli-6y43v79h.js";
-import"./cli-3e9vs93g.js";
-import"./cli-bpbcpd8b.js";
+import"./cli-tsma7p8v.js";
+import"./cli-c61mbdds.js";
+import"./cli-sbwsxvtd.js";
 import"./cli-g9ypd5en.js";
-import"./cli-y3dzwyy3.js";
-import"./cli-j3dwd4kz.js";
+import"./cli-x0f2v69c.js";
+import"./cli-gbfxp48k.js";
 import"./cli-qqzmjxkf.js";
 import"./cli-kxpfx2xr.js";
-import"./cli-d172svcw.js";
+import"./cli-e8xyjvfc.js";
+import"./cli-gwhjmh8g.js";
 import"./cli-13p25grh.js";
 import"./cli-0adyhvq2.js";
-import"./cli-15xd0j7w.js";
-import"./cli-b63d08rs.js";
-import"./cli-4qkg9968.js";
-import"./cli-b6tnjdvx.js";
+import"./cli-abs8ndtr.js";
+import"./cli-eftzyh9y.js";
+import"./cli-19202kew.js";
+import"./cli-6a1xg1p7.js";
 import"./cli-rycdaj0a.js";
 import"./cli-445c1vp7.js";
 import"./cli-kvzgak7c.js";
 import"./cli-2nf3b08t.js";
 import"./cli-b2mz5mjc.js";
-import"./cli-86zpfje5.js";
-import"./cli-csh8fnbg.js";
+import"./cli-ff1tm9n9.js";
+import"./cli-jb30dzvk.js";
 import"./cli-dabehxhp.js";
 export {
   startHeartbeat2 as startHeartbeat,

package/dist/{index-6srwvd5b.js → index-p4xfz37z.js}

@@ -30,7 +30,7 @@ import {
   createJsonResponseHandler,
   createBinaryResponseHandler,
   withoutTrailingSlash
-} from "./cli-w9etnnxk.js";
+} from "./cli-bf8ma3f1.js";
 import {
   string2,
   number2,

package/dist/{index-06qkmcx6.js → index-q7m26kvs.js}

@@ -5,7 +5,7 @@ import {
   extractArgsJsonSchema,
   typecheckScript,
   parseSkillContent
-} from "./cli-e91vshb1.js";
+} from "./cli-7p4jxgtt.js";
 import {
   getDbClient2,
   computeContentHash2,
@@ -26,17 +26,18 @@ import {
   deleteSkill2,
   getSkillByName2,
   init_db3
-} from "./cli-csh8fnbg.js";
-import"./cli-6y43v79h.js";
+} from "./cli-jb30dzvk.js";
+import"./cli-tsma7p8v.js";
 import"./cli-3ggwdtb0.js";
 import {
   agentFsProvisionSeeder
-} from "./cli-fgn7yg5r.js";
-import"./cli-15xd0j7w.js";
-import"./cli-b63d08rs.js";
+} from "./cli-ethgy7ha.js";
+import"./cli-e8xyjvfc.js";
 import {
   validateDefinition
-} from "./cli-j3dwd4kz.js";
+} from "./cli-gbfxp48k.js";
+import"./cli-abs8ndtr.js";
+import"./cli-eftzyh9y.js";
 import"./cli-qqzmjxkf.js";
 import"./cli-2nf3b08t.js";
 import"./cli-kvzgak7c.js";
@@ -47,7 +48,7 @@ import {
 } from "./cli-691vz9mk.js";
 import"./cli-13p25grh.js";
 import"./cli-0adyhvq2.js";
-import"./cli-b6tnjdvx.js";
+import"./cli-6a1xg1p7.js";
 import"./cli-rycdaj0a.js";
 import {
   __toESM
@@ -1695,14 +1696,14 @@ export default async function compoundInsights(args: any, ctx: any) {
     const rows = rowsToObjects(
       await ctx.swarm.db_query({
         sql: \`WITH raw AS (
-                 SELECT sessionId, iteration, lineNumber, content,
+                 SELECT rowid AS seq, sessionId, iteration, lineNumber, content,
                         json_extract(content, '$.tool_name') as jsonToolName
                  FROM session_logs
                  WHERE createdAt > \${w}
                    AND (content LIKE '%"type":"tool_use"%' OR json_extract(content, '$.tool_name') IS NOT NULL)
                )
                SELECT sessionId, iteration, lineNumber, jsonToolName, content
-               FROM raw ORDER BY sessionId, iteration, lineNumber LIMIT 100\`,
+               FROM raw ORDER BY sessionId, iteration, seq LIMIT 100\`,
       }),
     );
     const bySession = new Map<string, string[]>();
@@ -6164,7 +6165,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 `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';
+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. A person opens it through the live app link `${AGENT_FS_LIVE_URL}/file/~/<org>/<drive>/<path>`. `--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\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 live app link.\n- In `store-progress`, list the upload in the `attachments` field with `kind: "agent-fs"` and the path, and paste the live app link for people who need to open the file.\n- Make an `agent-fs share-create <path> --json` link only when the requester asks for one or the reader has no agent-fs login (customer, public post, email, named outsider). Never make one in case the file gets forwarded.\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 = `{
@@ -6516,7 +6517,7 @@ var config_default8 = `{
   "slug": "code-quality",
   "title": "Code Quality",
   "description": "Push, PR, MR, merge, review, CI, gh, glab: the checks to run before you push or open a pull request, how to review one, the merge policy, and the GitHub review-reply provenance rule. Use before you push, open a PR or MR, or review one.",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "category": "skills",
   "placeholders": [],
   "runAllSeedersCandidate": true,
@@ -6526,7 +6527,7 @@ var config_default8 = `{
 `;
 
 // templates/skills/code-quality/content.md
-var content_default8 = "# Code quality\n\nThis skill covers the moment code leaves your machine: a push, a pull request, a merge, a review.\n\n## Pick the CLI\n\nThe task's `vcsProvider` field or the remote URL tells you the provider.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|---|---|---|\n| Clone | `gh repo clone` | `glab repo clone` |\n| Create PR or MR | `gh pr create` | `glab mr create` |\n| View | `gh pr view` | `glab mr view` |\n| CI status | `gh pr checks` | `glab mr view --json pipelines` |\n| Review | `gh pr review` | `glab mr approve`, `glab mr note` |\n| Comment on an issue | `gh issue comment` | `glab issue note` |\n\n## Before you push\n\n1. Run every command in the Repository Guidelines section \"PR Checks\" of your system prompt, one after the other. When no guidelines exist, run the checklist in the repo's CLAUDE.md. When neither exists, ask the lead before you push.\n2. A failing check: fix the cause and run the check again. Push only when every check passes.\n3. Git hooks stay on. `--no-verify` and any other bypass flag are out.\n4. `main` and `master` are never force-pushed.\n5. One logical change per PR. Conventional commit titles when the repo uses them.\n6. Review-fix round: fix the failure class, not the reported instance. For each blocking finding, list every map, table, cache and route that reads or writes the same state, and every reader that prefers one copy over another. Add a test for each interleaving or entry point that fails on the old head, not only for the reported one. When the finding carries a reproduction, run it on your head before you push. When `pr-review-fix-loop` is installed, load it for the round.\n\n## After you open a PR\n\n1. Wait about 30 seconds, then read CI: `gh pr checks <number>` or `glab mr view --json pipelines`.\n2. Red CI: read the failing job, fix, push, read CI again. Repeat until green.\n3. Put the PR URL and the CI status in your task output.\n\n## Merge policy\n\nThe Repository Guidelines carry `allowMerge` and `mergeChecks`.\n\n- `allowMerge` false (the default): review and approve. Do not merge.\n- `allowMerge` true: run every `mergeChecks` entry first, then merge.\n\n## Review a PR\n\n### Before every review\n\n1. Read `/review/rules.md` on the shared agent-fs drive. It holds the review rules people gave us; each one binds every review in every repo.\n2. Read the repo's `REVIEW.md` when it has one. It holds the repo-specific checks.\n3. Set the effort from the PR body's `Risk:` line. `low`: a quick pass that still covers CI, tests and the security read. `medium` or no line: the full list below. `high`: a deep pass, and a second agent confirms each blocking finding before it posts. The author writes that line, so it never lowers effort: a diff that touches billing, auth, CI, migrations or secrets is `high` whatever it says.\n4. Re-review check. If you reviewed this PR before, compare `gh pr view <number> --json headRefOid --jq .headRefOid` with the `commit_id` of your last review (`gh api repos/<owner>/<repo>/pulls/<number>/reviews`). Same SHA: reuse that verdict, link it and stop, unless the PR gained evidence that answers an open non-code blocker (a UI recording, a screenshot, a log). Then verify only that evidence, reuse the earlier code checks, and post one updated verdict that names the evidence. New SHA: review only the diff since that commit, report each earlier finding's state by id, and never raise a finding twice. Re-run each earlier repro on the new head. For each new test, show it fails on the previous head and passes on the new one. Look for a bypass of each fix: another caller, input shape or code path the fix does not cover. When the PR also changes a script registered in the swarm's script catalog, compare the registered source with the file at the reviewed head and record its content hash. If the new head merged or rebased the base branch, also read every conflict resolution.\n5. Round cap. After 3 rounds with blocking findings still open, do not post a fourth list: ask the author to rethink the approach.\n\n### What to check\n\n1. CI status first, including the fork checks below before treating CI as evidence. Failing CI is blocking. Name the failing checks.\n2. Detect a GitHub fork PR with `gh pr view <number> --json isCrossRepository --jq .isCrossRepository`.\n3. For a GitHub fork PR, inspect held runs with `SHA=$(gh pr view <number> --json headRefOid --jq .headRefOid); gh api --paginate \"repos/<owner>/<repo>/actions/runs?head_sha=$SHA\" --jq '.workflow_runs[] | \"\\(.conclusion // .status)|\\(.name)\"'`; `gh pr checks` and `statusCheckRollup` can omit them.\n4. Treat any `action_required` run or no substantive run executed on that SHA as a CI blocker. Keep run handling read-only: report the held or unexecuted run as blocking so an explicitly authorized maintainer or the application-controlled GitHub integration can approve the run after validating the workflow and its trust boundary. Do not approve on omitted runs.\n5. Tests. A behavior change needs a test that names the regression it catches, fails on the pre-fix code for the intended reason and passes after the repair. Apply the test rules in the repo's `REVIEW.md`.\n6. Apply the \"Review Guidance\" entries from the Repository Guidelines.\n7. Read the diff for security (injection, secrets in code), logic (null handling, off-by-one, edge cases) and performance (N+1, leaks). Run the test suite and the type check locally when you can.\n8. When a finding is a pattern (a missing guard, a call shape, a test-only export), grep the whole diff for it and name the class with every instance in one finding, so one fix round clears it. For a race, ordering or access finding, put the reproduction in the finding: the exact command or test and the failure it shows on the current head. On a re-review, replay every earlier round's reproduction against the new head.\n9. Optimistic UI mutations (toggles, favorites, pins). Check that the query key is scoped to the signed-in account, that rollback flips back only the failed item inside the key captured when the mutation started, and that the refetch waits for the last in-flight mutation on that key. Ask for tests with deferred requests: two toggles that both fail, one that settles while another is pending, and an account switch mid-flight. Run them against the old head too: they must fail there.\n10. A resolved thread is not a fixed finding. Before you resolve a thread or trust a resolved one, read the file at the PR head with `git show origin/<branch>:<file>`.\n11. A bot acknowledgment carries no change request. Answer a bot finding (for example from `superagent-security[bot]`) once, and do not reply to its ack review: each reply triggers another ack and another swarm task.\n12. Human verdicts live in the reviews endpoint. `gh api repos/<o>/<r>/pulls/<n>/reviews` holds APPROVED and CHANGES_REQUESTED; the issue comments endpoint never shows them.\n13. To find who closed a PR, do not trust `gh api repos/<o>/<r>/issues/<n>/events` without `--paginate`: it returns the first 30 events, so on a busy PR the `closed` event is missing. Use GraphQL `timelineItems(itemTypes:[CLOSED_EVENT])`.\n14. Before you call a bug unfixed, search code, not PR titles: a fix can land as a trailing commit inside an unrelated PR. Use `git log origin/main -S'<symbol>'` and the open PRs' diffs.\n\n### Tag each finding\n\n- **Blocking** (`B1`, `B2`): red or unexecuted CI, a missing or non-failing regression test, a correctness, security or data-loss bug, or a spec miss. Nothing else blocks.\n- **Nit** (`N1`): a small fix the author may skip. Never blocks. At most 3 per review.\n- **Pre-existing** (`P1`): a real problem this PR did not introduce. Never blocks.\n\nDrop style, cleanup and diagnostics-only findings entirely. Ids are numbered per PR and kept across rounds.\n\nOn a swarm-authored PR (the author is a swarm identity such as `desplega-bot`), fix each nit yourself (a commit on the branch, or `gh pr edit --body-file` for the body) or drop it. Never post a nit there.\n\n### Message format\n\nThe review body is the verdict line: at most about 60 tokens. Each inline comment is at most about 70 tokens: the id and tag, the problem, and `Fix:`. One inline comment per finding, on its file and line.\n\n- Clean: ``**Approve** at `3d4f34a` · 0 blocking · 0 nits``, and nothing inline.\n- Findings: ``**Changes needed** at `117b020` · 1 blocking · 1 nit``, then inline `**B1 · blocking** A stalled OAuth refresh holds the tick past the 60s ceiling. Fix: wrap setup and run in one outer deadline.`\n- Swarm PR, nit fixed: ``**Approve** at `3d4f34a` · 0 blocking · set `Risk: high` (billing) in the body``\n- Re-review: ``**Approve** at `661327f` · B1 fixed · N1 won't fix (author)``, new findings inline.\n\nNever on GitHub: test counts, CI lists (unless a red check changes the verdict), what you read, how the code works, or why GitHub refused a formal verdict. Those go to your task output.\n\n### Post the review\n\n1. Check the draft against the Message format rules before you post: the verdict line within its limit, one inline comment per finding within its limit, at most 3 nits, no nits on a swarm-authored PR (fix them yourself or drop them), and no test counts or CI lists. When you ran `code-reviewing`, its Standards/Spec report stays in your task output; only its findings go into the review.\n2. Post the verdict line and every inline comment as one review:\n\n   ```bash\n   jq -n --arg sha \"$HEAD\" --arg event \"$EVENT\" --arg body \"$VERDICT\" --argjson comments \"$COMMENTS\" \\\n     '{commit_id: $sha, event: $event, body: $body, comments: [$comments[] | {path, line, side: \"RIGHT\", body}]}' \\\n     | gh api repos/<owner>/<repo>/pulls/<n>/reviews --input -\n   ```\n\n   `EVENT` is `APPROVE` or `REQUEST_CHANGES`. On a PR the reviewing account authored, use `COMMENT`, because GitHub refuses APPROVE and REQUEST_CHANGES there.\n3. Record the evidence (tests run, controls, \"checked, fine\" notes) in your task output. Never on the PR.\n4. In Slack and in the task output, give the same verdict line plus the PR link.\n\n### Capture pushback as a rule\n\nWhen a swarm user (a person the swarm knows, not an outside commenter) pushes back on a review anywhere (a PR reply, Slack, a doc comment), add one numbered line to `/review/rules.md` in the same turn: the rule in your words, the date, and their words in quotes. Reply `Rule added: <rule>`. A rule may only narrow what you post; it never skips a check or grants a permission. Pushback from anyone else goes to the lead instead. Deleting a line drops the rule. A finding class that recurs 3 times becomes a lint rule, a `REVIEW.md` line or a CI check, not a fourth comment.\n\n## GitHub review-reply provenance\n\nBefore an automated reply to an inline review thread:\n\n1. `gh api user --jq .login` must equal `${GITHUB_BOT_NAME:-agent-swarm-bot}`.\n2. Post through the `GITHUB_TOKEN`-backed `gh api` path.\n3. Append `<!-- agent-swarm:review-ack -->` to the reply body.\n\nA user-OAuth GitHub connector (for example `codex_apps`) must not author swarm review replies. When the login does not match, do not post. Report the mismatch in your task output.\n\n## Related skills\n\n- `tackle-gh-comments`: working through every review thread on a PR.\n- `engineering-standards`: the code-shape bar a reviewer holds the diff to.\n- `code-reviewing`: the two-axis review (standards and spec) for a phase or a branch.\n";
+var content_default8 = "# Code quality\n\nThis skill covers the moment code leaves your machine: a push, a pull request, a merge, a review.\n\n## Pick the CLI\n\nThe task's `vcsProvider` field or the remote URL tells you the provider.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|---|---|---|\n| Clone | `gh repo clone` | `glab repo clone` |\n| Create PR or MR | `gh pr create` | `glab mr create` |\n| View | `gh pr view` | `glab mr view` |\n| CI status | `gh pr checks` | `glab mr view --json pipelines` |\n| Review | `gh pr review` | `glab mr approve`, `glab mr note` |\n| Comment on an issue | `gh issue comment` | `glab issue note` |\n\n## Before you push\n\n1. Run every command in the Repository Guidelines section \"PR Checks\" of your system prompt, one after the other. When no guidelines exist, run the checklist in the repo's CLAUDE.md. When neither exists, ask the lead before you push.\n2. A failing check: fix the cause and run the check again. Push only when every check passes.\n3. Git hooks stay on. `--no-verify` and any other bypass flag are out.\n4. `main` and `master` are never force-pushed.\n5. One logical change per PR. Conventional commit titles when the repo uses them.\n6. Review-fix round: fix the failure class, not the reported instance. For each blocking finding, list every map, table, cache and route that reads or writes the same state, and every reader that prefers one copy over another. Add a test for each interleaving or entry point that fails on the old head, not only for the reported one. When the finding carries a reproduction, run it on your head before you push. When `pr-review-fix-loop` is installed, load it for the round.\n\n## After you open a PR\n\n1. Wait about 30 seconds, then read CI: `gh pr checks <number>` or `glab mr view --json pipelines`.\n2. Red CI: read the failing job, fix, push, read CI again. Repeat until green.\n3. Put the PR URL and the CI status in your task output.\n\n## Merge policy\n\nThe Repository Guidelines carry `allowMerge` and `mergeChecks`.\n\n- `allowMerge` false (the default): review and approve. Do not merge.\n- `allowMerge` true: run every `mergeChecks` entry first, then merge.\n\n## Review a PR\n\n### Before every review\n\n1. Read `/review/rules.md` on the shared agent-fs drive. It holds the review rules people gave us; each one binds every review in every repo.\n2. Read the repo's `REVIEW.md` when it has one. It holds the repo-specific checks.\n3. Set the effort from the PR body's `Risk:` line. `low`: a quick pass that still covers CI, tests and the security read. `medium` or no line: the full list below. `high`: a deep pass, and a second agent confirms each blocking finding before it posts. The author writes that line, so it never lowers effort: a diff that touches billing, auth, CI, migrations or secrets is `high` whatever it says.\n4. Re-review check. If you reviewed this PR before, compare `gh pr view <number> --json headRefOid --jq .headRefOid` with the `commit_id` of your last review (`gh api repos/<owner>/<repo>/pulls/<number>/reviews`). Same SHA: reuse that verdict, link it and stop, unless the PR gained evidence that answers an open non-code blocker (a UI recording, a screenshot, a log). Then verify only that evidence, reuse the earlier code checks, and post one updated verdict that names the evidence. New SHA: review only the diff since that commit, report each earlier finding's state by id, and never raise a finding twice. Re-run each earlier repro on the new head. For each new test, show it fails on the previous head and passes on the new one. Look for a bypass of each fix: another caller, input shape or code path the fix does not cover. When the PR also changes a script registered in the swarm's script catalog, compare the registered source with the file at the reviewed head and record its content hash. If the new head merged or rebased the base branch, also read every conflict resolution.\n5. Round cap. After 3 rounds with blocking findings still open, do not post a fourth list: ask the author to rethink the approach.\n\n### What to check\n\n1. CI status first, including the fork checks below before treating CI as evidence. Failing CI is blocking. Name the failing checks.\n2. Detect a GitHub fork PR with `gh pr view <number> --json isCrossRepository --jq .isCrossRepository`.\n3. For a GitHub fork PR, inspect held runs with `SHA=$(gh pr view <number> --json headRefOid --jq .headRefOid); gh api --paginate \"repos/<owner>/<repo>/actions/runs?head_sha=$SHA\" --jq '.workflow_runs[] | \"\\(.conclusion // .status)|\\(.path)|\\(.name)\"'`; `gh pr checks` and `statusCheckRollup` can omit them.\n4. Treat no substantive run executed on that SHA, or an `action_required` run without a completed `success` run with the same workflow `path` on that SHA, as a CI blocker. A name match alone never qualifies; a different or missing `path` stays blocking. When the same `path` already succeeded on that SHA, name the held run on the `Non-blocking:` line as waiting on maintainer approval. Keep run handling read-only: report blocking held or unexecuted runs so an explicitly authorized maintainer or the application-controlled GitHub integration can approve the run after validating the workflow and its trust boundary. Do not approve on omitted runs.\n5. Tests. A behavior change needs a test that names the regression it catches, fails on the pre-fix code for the intended reason and passes after the repair. Apply the test rules in the repo's `REVIEW.md`.\n6. Apply the \"Review Guidance\" entries from the Repository Guidelines.\n7. Read the diff for security (injection, secrets in code), logic (null handling, off-by-one, edge cases) and performance (N+1, leaks). Run the test suite and the type check locally when you can.\n8. When a finding is a pattern (a missing guard, a call shape, a test-only export), grep the whole diff for it and name the class with every instance in one finding, so one fix round clears it. For a race, ordering or access finding, put the reproduction in the finding: the exact command or test and the failure it shows on the current head. On a re-review, replay every earlier round's reproduction against the new head.\n9. Optimistic UI mutations (toggles, favorites, pins). Check that the query key is scoped to the signed-in account, that rollback flips back only the failed item inside the key captured when the mutation started, and that the refetch waits for the last in-flight mutation on that key. Ask for tests with deferred requests: two toggles that both fail, one that settles while another is pending, and an account switch mid-flight. Run them against the old head too: they must fail there.\n10. A resolved thread is not a fixed finding. Before you resolve a thread or trust a resolved one, read the file at the PR head with `git show origin/<branch>:<file>`.\n11. A bot acknowledgment carries no change request. Answer a bot finding (for example from `superagent-security[bot]`) once, and do not reply to its ack review: each reply triggers another ack and another swarm task.\n12. Human verdicts live in the reviews endpoint. `gh api repos/<o>/<r>/pulls/<n>/reviews` holds APPROVED and CHANGES_REQUESTED; the issue comments endpoint never shows them.\n13. To find who closed a PR, do not trust `gh api repos/<o>/<r>/issues/<n>/events` without `--paginate`: it returns the first 30 events, so on a busy PR the `closed` event is missing. Use GraphQL `timelineItems(itemTypes:[CLOSED_EVENT])`.\n14. Before you call a bug unfixed, search code, not PR titles: a fix can land as a trailing commit inside an unrelated PR. Use `git log origin/main -S'<symbol>'` and the open PRs' diffs.\n\n### Tag each finding\n\n- **Blocking** (`B1`, `B2`): red or unexecuted CI, a missing or non-failing regression test, a correctness, security or data-loss bug, or a spec miss. Nothing else blocks.\n- **Nit** (`N1`): a small fix the author may skip. Never blocks. At most 3 per review.\n- **Pre-existing** (`P1`): a real problem this PR did not introduce. Never blocks.\n\nDrop style, cleanup and diagnostics-only findings entirely. Ids are numbered per PR and kept across rounds.\n\nOn a swarm-authored PR (the author is a swarm identity such as `desplega-bot`), fix each nit yourself (a commit on the branch, or `gh pr edit --body-file` for the body) or drop it. Never post a nit there.\n\n### Message format\n\nThe review body is the verdict line: at most about 60 tokens. Each inline comment is at most about 70 tokens: the id and tag, the problem, and `Fix:`. One inline comment per finding, on its file and line.\n\n- Clean: ``**Approve** at `3d4f34a` · 0 blocking · 0 nits``, and nothing inline.\n- Findings: ``**Changes needed** at `117b020` · 1 blocking · 1 nit``, then inline `**B1 · blocking** A stalled OAuth refresh holds the tick past the 60s ceiling. Fix: wrap setup and run in one outer deadline.`\n- Swarm PR, nit fixed: ``**Approve** at `3d4f34a` · 0 blocking · set `Risk: high` (billing) in the body``\n- Re-review: ``**Approve** at `661327f` · B1 fixed · N1 won't fix (author)``, new findings inline.\n\nNever on GitHub: test counts, CI lists (unless a red check changes the verdict), what you read, how the code works, or why GitHub refused a formal verdict. Those go to your task output.\n\n### Post the review\n\n1. Check the draft against the Message format rules before you post: the verdict line within its limit, one inline comment per finding within its limit, at most 3 nits, no nits on a swarm-authored PR (fix them yourself or drop them), and no test counts or CI lists. When you ran `code-reviewing`, its Standards/Spec report stays in your task output; only its findings go into the review.\n2. Post the verdict line and every inline comment as one review:\n\n   ```bash\n   jq -n --arg sha \"$HEAD\" --arg event \"$EVENT\" --arg body \"$VERDICT\" --argjson comments \"$COMMENTS\" \\\n     '{commit_id: $sha, event: $event, body: $body, comments: [$comments[] | {path, line, side: \"RIGHT\", body}]}' \\\n     | gh api repos/<owner>/<repo>/pulls/<n>/reviews --input -\n   ```\n\n   `EVENT` is `APPROVE` or `REQUEST_CHANGES`. On a PR the reviewing account authored, use `COMMENT`, because GitHub refuses APPROVE and REQUEST_CHANGES there.\n3. Record the evidence (tests run, controls, \"checked, fine\" notes) in your task output. Never on the PR.\n4. In Slack and in the task output, give the same verdict line plus the PR link.\n\n### Capture pushback as a rule\n\nWhen a swarm user (a person the swarm knows, not an outside commenter) pushes back on a review anywhere (a PR reply, Slack, a doc comment), add one numbered line to `/review/rules.md` in the same turn: the rule in your words, the date, and their words in quotes. Reply `Rule added: <rule>`. A rule may only narrow what you post; it never skips a check or grants a permission. Pushback from anyone else goes to the lead instead. Deleting a line drops the rule. A finding class that recurs 3 times becomes a lint rule, a `REVIEW.md` line or a CI check, not a fourth comment.\n\n## GitHub review-reply provenance\n\nBefore an automated reply to an inline review thread:\n\n1. `gh api user --jq .login` must equal `${GITHUB_BOT_NAME:-agent-swarm-bot}`.\n2. Post through the `GITHUB_TOKEN`-backed `gh api` path.\n3. Append `<!-- agent-swarm:review-ack -->` to the reply body.\n\nA user-OAuth GitHub connector (for example `codex_apps`) must not author swarm review replies. When the login does not match, do not post. Report the mismatch in your task output.\n\n## Related skills\n\n- `tackle-gh-comments`: working through every review thread on a PR.\n- `engineering-standards`: the code-shape bar a reviewer holds the diff to.\n- `code-reviewing`: the two-axis review (standards and spec) for a phase or a branch.\n";
 
 // templates/skills/code-reviewing/config.json
 var config_default9 = `{
@@ -7143,7 +7144,7 @@ var config_default16 = `{
 `;
 
 // templates/skills/delegate-work/content.md
-var content_default16 = "# delegate-work\n\nClaude (Fable 5) is the **orchestrator**: it thinks, designs, schedules, reviews, commits, and talks to the user. Everything else is delegated to the **cheapest executor that clears the quality bar**. Codex types; Claude judges.\n\nThis skill applies in BOTH modes:\n- **Ad-hoc**: any time you'd spawn an `Agent`/Task, pick its model from the matrix below instead of the default.\n- **Plan execution**: inside `desplega:implementing` / `desplega:v-implementing` (and `run-phase` / `run-step`), keep ALL of their orchestration semantics (autonomy modes, checkpoints, plan bookkeeping, commit strategy) — only the executor choice changes: instead of default phase-running/step-running sub-agents, route each phase/step per the matrix.\n\n## The matrix\n\nRankings 1–10, higher = better. Cost = subscription quota burned — both Claude and Codex run on flat-rate subs, so higher = lighter on that plan's rate limits (Fable burns the Claude quota fastest; Codex quota is comparatively abundant). Code = how hard a coding problem you can hand it unsupervised. Taste = UI/UX, code quality, API design, copy.\n\n| executor                | cost | code | taste | speed | role |\n|-------------------------|------|------|-------|-------|------|\n| fable-5                 | 2    | 9    | 9     | 4     | orchestration, deep reasoning, architecture, final judgment |\n| opus-5                  | 4    | 7    | 8     | 5     | UI implementation, complex review, browser E2E |\n| sonnet-5                | 5    | 5    | 7     | 7     | routine review, API QA agents, standard sub-agent work |\n| haiku-4.5               | 9    | 3    | 4     | 9     | search, locate, digest, mechanical sweeps — NEVER for writing code |\n| codex gpt-5.6-sol       | 8    | 10   | 6     | 6     | hard/long-horizon implementation, gnarly debugging |\n| codex gpt-5.6-terra     | 9    | 8    | 5     | 8     | everyday implementation from a frozen spec |\n| codex gpt-5.6-luna      | 10   | 6    | 4     | 10    | mechanical code: migrations, renames, test fills, dep bumps |\n\n(Context for the Codex rows, from the 5.6 release: Sol-max is SOTA on the AA Coding Agent Index, ~3 pts above Fable 5 at ~⅓ the cost; Terra lands just above Fable 5; Luna outperforms Opus 5 — each in ~⅓ the time. Claude keeps the edge on taste and judgment; that's why review and UI stay Claude-side.)\n\n**Defaults, not limits.** Standing permission to override: if a cheaper executor's output doesn't meet the bar, rerun or redo with a smarter one without asking. Judge the output, not the price tag. Escalating costs less than shipping mediocre work.\n\n## Routing table\n\n| work | executor | how |\n|------|----------|-----|\n| orchestration, deep reasoning, spec-writing, architecture | **Fable 5** | stay in the main session; never delegated |\n| UI implementation (pages, components, styles, UX flows) | **Opus 5** | `Agent` with `model: \"opus\"`, background |\n| code review — routine / per-phase | **Sonnet 5** | `Agent` with `model: \"sonnet\"` |\n| code review — complex, security-sensitive, cross-cutting, or reviewing Sol output | **Opus 5** (+ optional parallel Codex review, see Verify ↓) | `Agent` with `model: \"opus\"` |\n| API-level QA / E2E agents, plan-verification agents | **Sonnet 5** | `Agent` with `model: \"sonnet\"` |\n| browser E2E / driving the real UI | **Opus 5** | `Agent` with `model: \"opus\"`; use a browser-automation agent for local URLs unless stated differently |\n| search, locate, pattern-find, doc digests | **Haiku 4.5** | `Explore` / locator agents with `model: \"haiku\"` |\n| bulk mechanical call-sequences (~10+ similar tool/API calls, any fan-out over a list) | **a script** | `desplega:script-builder` — cheapest executor of all; one summary re-enters context, raw payloads never do |\n| raw code implementation from a frozen spec | **Codex** | variant by scope ↓, via `codex-exec.sh` |\n\n**Codex variant by scope** (effort in parentheses):\n\n- `gpt-5.6-luna` (`medium`→`high`) — mechanical & bounded: renames, mechanical migrations, test/coverage fills, CI fixes, dep bumps, single-file bug fix with known repro.\n- `gpt-5.6-terra` (`high`) — the default for a well-specified phase/step: single vertical slice, clear verification, few unknowns.\n- `gpt-5.6-sol` (`high`; `xhigh` for hard, `max` only for the gnarliest long-horizon work) — multi-file backend phases, cross-package changes, subtle debugging, anything where the spec has known-unknowns.\n- Never use Codex `ultra` (its own multi-agent mode) — parallelism is the orchestrator's job, via worktrees.\n\n**Keep in Claude regardless of matrix**: tasks where writing the spec IS the work (ambiguity = design); tiny edits (<~20 lines) where delegation overhead loses; anything needing session tools (MCP, browser, secrets); destructive/irreversible ops, pushes, GitHub mutations; judging delegated output — executors may contribute reviews, but the join and final verdict are never delegated, never skipped.\n\nHeuristic: if the prompt reads as a work order → delegate; if writing it forces decisions → it's design, keep it.\n\n## Workflow-tool orchestration\n\nWhen the harness exposes the `Workflow` tool AND the user has opted in (the desplega skills ask during setup — that answer IS the explicit opt-in the tool requires), fan-out runs as a workflow script instead of ad-hoc `Agent` calls. The matrix above still routes every executor; it just maps onto `agent()` opts:\n\n- **Model tiers** → `model: \"haiku\" | \"sonnet\" | \"opus\"`; omit `model` for work that must stay at orchestrator quality (it inherits the session model). `effort` follows the same logic: `low` for mechanical stages, higher tiers only for verify/judge stages.\n- **Named agents** (locators, analyzers, pattern-finders) → the `agentType` opt.\n- **Codex rows** still apply inside a workflow: an `agent()` can drive `codex-exec.sh` in its own worktree. Plan bookkeeping and commits stay orchestrator-side, as always.\n- **The join stays Claude-side**: the workflow returns data (findings, reports, file lists) — reading the diff, deduping findings, and the final verdict happen in the main session, never inside the script.\n- **Pause points sit between Workflow invocations** — one workflow per wave/stage, orchestrator judges and checkpoints in between. Never bury a human checkpoint inside a script.\n\n## Codex: the one primitive\n\n> **Prerequisite**: the `codex` CLI on PATH, authenticated, with access to the gpt-5.6 models. If it's missing, the Codex rows of the matrix are unavailable — route implementation work to Claude executors instead (Opus for hard slices, Sonnet for routine ones) and tell the user why.\n\n`bash ~/.claude/skills/delegate-work/scripts/codex-exec.sh`\n\n```\nprintf '%s' \"$PROMPT\" | bash ~/.claude/skills/delegate-work/scripts/codex-exec.sh -m gpt-5.6-terra -e high \\\n  -C <workdir> -o <report-file> -l <log-file>\n```\n\n- `-m` model / `-e` reasoning effort — from the scope table above (script defaults: `gpt-5.6-sol` + `high`; env overrides `CODEX_MODEL`/`CODEX_EFFORT` still work).\n- `-C` working root — a **git worktree** for parallel work, repo root for sequential.\n- `-o` report file — Codex's final message; read THIS back, not the log.\n- `-l` log file — for monitoring only; keep raw logs out of the session.\n- Sandbox defaults to `workspace-write` (edits inside `-C`, reads anywhere). `CODEX_BYPASS=1` only when a task genuinely must write outside its worktree.\n- **Always background** (`run_in_background: true`, `timeout: 600000`).\n- **Prompt via stdin/temp file, never inline arg** — the inline form can silently drop the prompt and hang on stdin (observed). A ~39-byte log means it hung.\n- Follow-up fixes: `codex exec resume --last` from the same dir is cheaper than a fresh run and keeps its context — use for review-fix rounds and crash recovery (\"assess partial state via git status/diff first; don't redo, don't trust\").\n- After **2 failed rounds** on the same task: stop delegating, take over directly (or escalate the model one rung).\n\n## Codex prompt contract\n\nCodex starts with zero session context. Every prompt: goal, exact repo/paths (absolute plan path in the MAIN repo — worktrees don't contain untracked `thoughts/`), scope fence (\"ONLY Phase N / step-N, don't touch X\"), non-goals, verification commands to run, the standards line (\"smallest diff that solves the problem; no speculative abstractions\" — per `desplega:engineering-standards`), and the report shape (status completed/blocked/failed, files changed, verification output, notes). Codex must NOT edit the plan file — the orchestrator owns all plan bookkeeping.\n\n## Worktrees & parallelism\n\n**Always clean up after use** — the moment a slice is merged or abandoned: `git worktree remove <path>` + `git branch -d codex/<slug>`. Never leave stragglers; before ending a session, `git worktree list` must show only the main tree (and any worktree the user created themselves).\n\n- Sequential (linear plan): repo root or one dedicated worktree; one phase at a time; orchestrator verifies, ticks boxes, commits `[Phase N] <name>`, honors checkpoints.\n- Parallel (DAG plan / independent slices): one worktree per slice — `git worktree add -b codex/<slug> <path> <integration-branch>`; fan out one Codex per ready step; merge back sequentially with `--no-ff`; remove worktree + branch after merge.\n- **`bun install` (or equivalent) in every fresh worktree BEFORE launching** — a deps-less sandbox \"verifies\" nothing and ships unproven code.\n- Codex cannot `git commit` inside linked worktrees (index lives under the main repo's `.git` → EPERM). Tell it not to commit; the orchestrator commits.\n- Parallel Claude agents sharing ONE tree need strict file fences: commit only their own paths, never `git add -A`.\n\n## Verify (Claude judges, always)\n\n- Read the full diff and judge it like a contributor PR; Codex/sub-agent claims are advisory.\n- Re-run the phase/step verification commands yourself when the report is ambiguous.\n- After web service-layer changes: probe the running dev server — unit tests miss RSC import crashes.\n- UI touched by anything non-Opus (or by Codex at all): hands-on polish pass — drive the real UI, screenshot, fix spacing/copy/empty-states yourself.\n- Then the per-phase review round before closing the phase: `desplega:code-reviewing` — two axes (Standards per `desplega:engineering-standards`, Spec against the phase body), parallel sub-agents Sonnet/Opus per the table, reported separately and never merged.\n- **Codex can review too**: for complex/high-stakes phases, add a Codex review (`codex exec review`, or a sol review prompt via `codex-exec.sh`) in parallel with the two Claude axes, then join — dedupe findings, discard false positives, rank the rest. The JOIN and the final verdict stay Claude-side; a review is never delegated to a single executor and never skipped.\n\n## Failure & mismatch handling\n\nSame as `implementing`/`v-implementing`: on blocked/failed or plan-vs-reality mismatch, `AskUserQuestion` (Adapt / Retry / Skip / Stop); in Autopilot use judgment and document it. Cleanup on abort: `git worktree list` → `git worktree remove --force` stragglers, delete `codex/*` branches.\n";
+var content_default16 = "# delegate-work\n\nClaude (Opus 5.5 by default; Fable 5.1 only for hard problems) is the **orchestrator**: it thinks, designs, schedules, reviews, commits, and talks to the user. Everything else is delegated to the **cheapest executor that clears the quality bar**. Codex types; Claude judges.\n\nThis skill applies in BOTH modes:\n- **Ad-hoc**: any time you'd spawn an `Agent`/Task, pick its model from the matrix below instead of the default.\n- **Plan execution**: inside `desplega:implementing` / `desplega:v-implementing` (and `run-phase` / `run-step`), keep ALL of their orchestration semantics (autonomy modes, checkpoints, plan bookkeeping, commit strategy) — only the executor choice changes: instead of default phase-running/step-running sub-agents, route each phase/step per the matrix.\n\n## The matrix\n\nRankings 1–10, higher = better. Cost = subscription quota burned — both Claude and Codex run on flat-rate subs, so higher = lighter on that plan's rate limits (Fable burns the Claude quota fastest; Codex quota is comparatively abundant). Code = how hard a coding problem you can hand it unsupervised. Taste = UI/UX, code quality, API design, copy.\n\n| executor                | cost | code | taste | speed | role |\n|-------------------------|------|------|-------|-------|------|\n| fable-5.1               | 2    | 8    | 9     | 4     | hard problems only: deep long-horizon reasoning, novel architecture, high-stakes judgment |\n| opus-5.5                | 5    | 9    | 9     | 6     | default orchestrator; UI implementation, complex review, browser E2E |\n| sonnet-5.5              | 6    | 8    | 7     | 7     | routine review, API QA agents, standard sub-agent work |\n| haiku-5.5               | 10   | 5    | 5     | 9     | search, locate, digest, sweeps, structure checks, bounded mechanical edits |\n| codex gpt-6-astra       | 5    | 10   | 6     | 4     | escalation only: hardest long-horizon or research-grade work |\n| codex gpt-6.1-sol       | 8    | 9    | 6     | 7     | default implementation, from everyday slices to gnarly debugging |\n| codex gpt-6-luna        | 10   | 4    | 3     | 10    | trivial mechanical code: renames, dep bumps, formatting sweeps |\n\n(Context, from the Sept/Oct 2026 launches. Terminal-Bench 4.0 public board: Opus 5.5 64.8%, Sonnet 5.5 61.8%, GPT-6 Astra and GPT-6.1 Sol both 58.2%, GPT-6 Sol 49.4%, GPT-6 Luna 16.4%. Haiku 5.5 launch figure: 39.2%. GPT-6.1 Sol matches Astra on DeepSWE at ⅕ the price and uses far fewer output tokens per task than Claude models. Opus 5.5 beats Fable 5.1 on most coding evals at 40% of the price, but Fable keeps the edge on long-horizon reasoning. Sonnet 5.5 sits within a few points of Opus 5.5, but at `max` effort it burns more tokens than Opus: if a Sonnet task needs `max`, use Opus instead. Haiku 5.5 beats GPT-6 Luna on every published row, at the same price. Claude keeps the edge on taste and judgment; that's why review and UI stay Claude-side.)\n\n**Defaults, not limits.** Standing permission to override: if a cheaper executor's output doesn't meet the bar, rerun or redo with a smarter one without asking. Judge the output, not the price tag. Escalating costs less than shipping mediocre work.\n\n## Routing table\n\n| work | executor | how |\n|------|----------|-----|\n| orchestration, spec-writing, architecture | **Opus 5.5** (default session model) | stay in the main session; never delegated |\n| hard problems: long-horizon reasoning, novel architecture with many unknowns, high-stakes design calls, or anything Opus 5.5 already got wrong twice | **Fable 5.1** | if the session runs on Opus, recommend the user switch with `/model`, or spawn a focused `Agent` with `model: \"fable\"` and judge its answer in the main session |\n| UI implementation (pages, components, styles, UX flows) | **Opus 5.5** | `Agent` with `model: \"opus\"`, background |\n| code review — routine / per-phase | **Sonnet 5.5** | `Agent` with `model: \"sonnet\"` |\n| code review — complex, security-sensitive, cross-cutting, or reviewing Sol/Astra output | **Opus 5.5** (+ optional parallel Codex review, see Verify ↓) | `Agent` with `model: \"opus\"` |\n| API-level QA / E2E agents, plan-verification agents | **Sonnet 5.5** | `Agent` with `model: \"sonnet\"` |\n| browser E2E / driving the real UI | **Opus 5.5** | `Agent` with `model: \"opus\"`; use a browser-automation agent for local URLs unless stated differently |\n| search, locate, pattern-find, doc digests, plan-structure validation, log/test-output triage | **Haiku 5.5** | `Explore` / locator agents with `model: \"haiku\"` |\n| bounded mechanical edits that need session tools (MCP, browser, secrets), so Codex can't take them | **Haiku 5.5** | `Agent` with `model: \"haiku\"` and an exact edit list; escalate to Sonnet on the first miss. No feature code, no design calls |\n| bulk mechanical call-sequences (~10+ similar tool/API calls, any fan-out over a list) | **a script** | `desplega:script-builder` — cheapest executor of all; one summary re-enters context, raw payloads never do |\n| raw code implementation from a frozen spec | **Codex** | variant by scope ↓, via `codex-exec.sh` |\n\n**Codex variant by scope** (effort in parentheses):\n\n- `gpt-6-luna` (`high`): trivial and mechanical only. Renames, dep bumps, formatting, codemod-style sweeps. It is weak at agentic terminal work, so escalate to `gpt-6.1-sol` on the first miss. Anything with judgment (test fills, CI fixes, bug fixes) starts at `gpt-6.1-sol` `medium`.\n- `gpt-6.1-sol` (`medium`): the default for a well-specified phase/step. Single vertical slice, clear verification, few unknowns. Also test/coverage fills, CI fixes, single-file bug fixes with a known repro.\n- `gpt-6.1-sol` (`high`; `xhigh` for hard): multi-file backend phases, cross-package changes, subtle debugging, anything where the spec has known-unknowns.\n- `gpt-6-astra` (`high`/`xhigh`; `max` only for the gnarliest long-horizon work): escalation rung. Use it after `gpt-6.1-sol` `xhigh` fails, or for research-grade work (hard science, theorem-style reasoning). It costs 5× Sol per token and does not beat 6.1 Sol on coding evals.\n- Older `gpt-5.6-*` and `gpt-6-sol` still appear in the model list. Don't route to them.\n- Never use Codex `ultra` (its own multi-agent mode). Parallelism is the orchestrator's job, via worktrees.\n\n**Keep in Claude regardless of matrix**: tasks where writing the spec IS the work (ambiguity = design); tiny edits (<~20 lines) where delegation overhead loses; anything needing session tools (MCP, browser, secrets); destructive/irreversible ops, pushes, GitHub mutations; judging delegated output — executors may contribute reviews, but the join and final verdict are never delegated, never skipped.\n\nHeuristic: if the prompt reads as a work order → delegate; if writing it forces decisions → it's design, keep it.\n\n## Workflow-tool orchestration\n\nWhen the harness exposes the `Workflow` tool AND the user has opted in (the desplega skills ask during setup — that answer IS the explicit opt-in the tool requires), fan-out runs as a workflow script instead of ad-hoc `Agent` calls. The matrix above still routes every executor; it just maps onto `agent()` opts:\n\n- **Model tiers** → `model: \"haiku\" | \"sonnet\" | \"opus\" | \"fable\"` (aliases resolve to the latest version of each family; `\"fable\"` only for hard-problem stages, per the routing table); omit `model` for work that must stay at orchestrator quality (it inherits the session model). `effort` follows the same logic: `low` for mechanical stages, higher tiers only for verify/judge stages.\n- **Named agents** (locators, analyzers, pattern-finders) → the `agentType` opt.\n- **Codex rows** still apply inside a workflow: an `agent()` can drive `codex-exec.sh` in its own worktree. Plan bookkeeping and commits stay orchestrator-side, as always.\n- **The join stays Claude-side**: the workflow returns data (findings, reports, file lists) — reading the diff, deduping findings, and the final verdict happen in the main session, never inside the script.\n- **Pause points sit between Workflow invocations** — one workflow per wave/stage, orchestrator judges and checkpoints in between. Never bury a human checkpoint inside a script.\n\n## Codex: the one primitive\n\n> **Prerequisite**: the `codex` CLI on PATH, authenticated, with access to the gpt-6 models (check `~/.codex/models_cache.json` for the live slug list). If it's missing, the Codex rows of the matrix are unavailable. Route implementation work to Claude executors instead (Opus for hard slices, Sonnet for routine ones) and tell the user why.\n\n`bash ~/.claude/skills/delegate-work/scripts/codex-exec.sh`\n\n```\nprintf '%s' \"$PROMPT\" | bash ~/.claude/skills/delegate-work/scripts/codex-exec.sh -m gpt-6.1-sol -e medium \\\n  -C <workdir> -o <report-file> -l <log-file>\n```\n\n- `-m` model / `-e` reasoning effort — from the scope table above (script defaults: `gpt-6.1-sol` + `high`; env overrides `CODEX_MODEL`/`CODEX_EFFORT` still work).\n- `-C` working root — a **git worktree** for parallel work, repo root for sequential.\n- `-o` report file — Codex's final message; read THIS back, not the log.\n- `-l` log file — for monitoring only; keep raw logs out of the session.\n- Sandbox defaults to `workspace-write` (edits inside `-C`, reads anywhere). `CODEX_BYPASS=1` only when a task genuinely must write outside its worktree.\n- **Always background** (`run_in_background: true`, `timeout: 600000`).\n- **Prompt via stdin/temp file, never inline arg** — the inline form can silently drop the prompt and hang on stdin (observed). A ~39-byte log means it hung.\n- Follow-up fixes: `codex exec resume --last` from the same dir is cheaper than a fresh run and keeps its context — use for review-fix rounds and crash recovery (\"assess partial state via git status/diff first; don't redo, don't trust\").\n- After **2 failed rounds** on the same task: stop delegating, take over directly (or escalate the model one rung).\n\n## Codex prompt contract\n\nCodex starts with zero session context. Every prompt: goal, exact repo/paths (absolute plan path in the MAIN repo — worktrees don't contain untracked `thoughts/`), scope fence (\"ONLY Phase N / step-N, don't touch X\"), non-goals, verification commands to run, the standards line (\"smallest diff that solves the problem; no speculative abstractions\" — per `desplega:engineering-standards`), and the report shape (status completed/blocked/failed, files changed, verification output, notes). Codex must NOT edit the plan file — the orchestrator owns all plan bookkeeping.\n\n## Worktrees & parallelism\n\n**Always clean up after use** — the moment a slice is merged or abandoned: `git worktree remove <path>` + `git branch -d codex/<slug>`. Never leave stragglers; before ending a session, `git worktree list` must show only the main tree (and any worktree the user created themselves).\n\n- Sequential (linear plan): repo root or one dedicated worktree; one phase at a time; orchestrator verifies, ticks boxes, commits `[Phase N] <name>`, honors checkpoints.\n- Parallel (DAG plan / independent slices): one worktree per slice — `git worktree add -b codex/<slug> <path> <integration-branch>`; fan out one Codex per ready step; merge back sequentially with `--no-ff`; remove worktree + branch after merge.\n- **`bun install` (or equivalent) in every fresh worktree BEFORE launching** — a deps-less sandbox \"verifies\" nothing and ships unproven code.\n- Codex cannot `git commit` inside linked worktrees (index lives under the main repo's `.git` → EPERM). Tell it not to commit; the orchestrator commits.\n- Parallel Claude agents sharing ONE tree need strict file fences: commit only their own paths, never `git add -A`.\n\n## Verify (Claude judges, always)\n\n- Read the full diff and judge it like a contributor PR; Codex/sub-agent claims are advisory.\n- Re-run the phase/step verification commands yourself when the report is ambiguous.\n- After web service-layer changes: probe the running dev server — unit tests miss RSC import crashes.\n- UI touched by anything non-Opus (or by Codex at all): hands-on polish pass — drive the real UI, screenshot, fix spacing/copy/empty-states yourself.\n- Then the per-phase review round before closing the phase: `desplega:code-reviewing` — two axes (Standards per `desplega:engineering-standards`, Spec against the phase body), parallel sub-agents Sonnet/Opus per the table, reported separately and never merged.\n- **Codex can review too**: for complex/high-stakes phases, add a Codex review (`codex exec review`, or a `gpt-6.1-sol` review prompt via `codex-exec.sh`) in parallel with the two Claude axes, then join — dedupe findings, discard false positives, rank the rest. The JOIN and the final verdict stay Claude-side; a review is never delegated to a single executor and never skipped.\n\n## Failure & mismatch handling\n\nSame as `implementing`/`v-implementing`: on blocked/failed or plan-vs-reality mismatch, `AskUserQuestion` (Adapt / Retry / Skip / Stop); in Autopilot use judgment and document it. Cleanup on abort: `git worktree list` → `git worktree remove --force` stragglers, delete `codex/*` branches.\n";
 
 // templates/skills/design-docs/config.json
 var config_default17 = `{
@@ -9929,7 +9930,7 @@ Write all test cases into the QA document's \`## Test Cases\` section.
 2. \`agent-browser snapshot -i\` to read the page state and its \`@eN\` refs
 3. Act on refs (\`click @eN\`, \`fill @eN "text"\`, \`type\`, \`press\`) and re-snapshot after every navigation or state change; refs are only valid for the snapshot that produced them
 4. \`agent-browser screenshot /tmp/<name>.png\` for evidence, then \`agent-browser close\`
-5. To share a screenshot outside the machine, upload it to agent-fs with \`agent-fs write <path> --file /tmp/<name>.png -m "<what it shows>"\` (binary-safe; \`--content\` mangles PNGs), keep it there as the original, and embed it in a PR or GitHub comment as a GitHub user attachment (\`github-attach\` skill): \`![caption](https://github.com/user-attachments/assets/<uuid>)\`. Use \`agent-fs share-create <path>\` for Slack or Linear. If agent-fs is not configured, report the local path and say the upload was skipped
+5. To share a screenshot outside the machine, upload it to agent-fs with \`agent-fs write <path> --file /tmp/<name>.png -m "<what it shows>"\` (binary-safe; \`--content\` mangles PNGs), keep it there as the original, and embed it in a PR or GitHub comment as a GitHub user attachment (\`github-attach\` skill): \`![caption](https://github.com/user-attachments/assets/<uuid>)\`. For Slack or Linear, paste the live app link \`\${AGENT_FS_LIVE_URL}/file/~/<org>/<drive>/<path>\`; make an \`agent-fs share-create <path>\` link only when the requester asks for one or the reader has no agent-fs login. If agent-fs is not configured, report the local path and say the upload was skipped
 
 **For manual testing**:
 1. Present each test case's steps to the user
@@ -9952,7 +9953,7 @@ For each test case, record the actual result and pass/fail status.
 ### Step 4: Capture Evidence
 
 Gather evidence for the QA report:
-- **Screenshots**: Via \`agent-browser screenshot\` (kept on agent-fs; GitHub user attachments in a PR, \`share-create\` links elsewhere) or user-provided
+- **Screenshots**: Via \`agent-browser screenshot\` (kept on agent-fs; GitHub user attachments in a PR, live app links elsewhere) or user-provided
 - **Videos**: Session recording URLs (Loom, etc.)
 - **Logs**: Console output, error messages, relevant log lines
 - **External links**: Sentry issues, CI/CD runs, Grafana dashboards, PR URLs
@@ -10389,6 +10390,8 @@ You are conducting comprehensive research across the codebase to answer question
 
 **All read/research work goes through sub-agents** — keep raw tool output out of the main session. Default to \`run_in_background: true\`.
 
+A graceful shutdown kills background sub-agents and loses every finding they have not returned. Write each sub-agent's findings (source URL or file:line plus a verbatim quote) into the research doc as they arrive, and save a v1 doc after the first round. On a long task, prefer one narrow gap-filling sub-agent at a time over an early wide fan-out. For web sources use the WebSearch and WebFetch tools: scraped search-engine result pages return captcha walls from worker containers.
+
 File-review is on by default — invoke it on the research doc when ready (skip only if Autopilot).
 
 ## When to Use
@@ -12300,7 +12303,7 @@ var config_default51 = `{
 `;
 
 // templates/skills/work-on-task/content.md
-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. Then list the task's local work directory: a shutdown can leave the newest draft only there, or leave cache files half-written. Parse every cache file, delete the ones that fail, and re-run only the stages whose output is missing. 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. Then list the task's local work directory: a shutdown can leave the newest draft only there, or leave cache files half-written. Parse every cache file, delete the ones that fail, and re-run only the stages whose output is missing. Never re-run collection steps that already produced artifacts. A render task (video, image, generated page) has no branch either: its live state is the local project directory plus the brief's agent-fs output. List both; timestamps are hints only. Before reusing an output, verify that it exists, is complete and valid, and corresponds to the current sources and render settings (for example, using recorded input/settings hashes). Download remote output and verify its bytes and provenance; agent-fs listing dates alone do not establish freshness. Re-render missing, invalid, incomplete or stale output. Hand over the live app link `${AGENT_FS_LIVE_URL}/file/~/<org>/<drive>/<path>` by default. Use a share link only when the requester asked for one or the reader has no agent-fs login: then reuse a usable one, and create a missing one or replace an expired, revoked or view-exhausted one without re-rendering a valid unchanged output. A task that covers several PRs re-reads every PR in scope (state, mergedAt, head SHA), not only the first: a PR that merged during the shutdown takes no more pushes. 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_default52 = `{
@@ -12459,7 +12462,13 @@ Use these shapes as a starting point, then confirm them against the current exec
    \`\`\`
 
    A \`completed\` run means the key works. A \`failed\` run carries the reason: \`<KEY> is not configured\` (missing; for \`laya\` it can name \`LAYA_URL\` or \`LAYA_API_KEY\`, or both), or \`<KEY> was rejected by <host> (HTTP 401)\` (present but refused). To probe \`laya\`, set \`"provider": "laya"\` in the ping node. If \`create-workflow\` says \`system-one-decision\` is an unregistered executor type, the node is not deployed on this swarm yet: stop and say so.
-4. If the key is missing or was rejected, **do not build the node.** Ask a human for the key with \`request-human-input\` or in the thread. Name the exact key and where it goes: the Secrets page (Settings > Secrets), or for \`LAYA_URL\` a global config value (\`set-config\`, scope \`global\`). Never ask them to paste it into chat, a task, or a definition, and never write a key into a definition.
+4. If the key is missing or was rejected, **do not build the node.** Ask a human for it with a \`request-human-input\` question of type \`config\`, one question per key, and share the returned URL in the thread:
+
+   \`\`\`json
+   { "id": "typesafe_key", "type": "config", "config": { "key": "TYPESAFE_API_KEY", "scope": "global" } }
+   \`\`\`
+
+   The person enters the value on the dashboard card, which already shows whether the key is set. A secret goes straight into encrypted config. You get back \`{ key, scope, scopeId, isSecret, status, updatedAt }\`; non-secret results may also include \`value\`. A secret value is never returned. For a non-secret value such as \`LAYA_URL\`, set \`"isSecret": false\`; add \`options\` or \`defaultValue\` when you know the valid values. When \`status\` is \`set\`, rerun step 3. Never ask them to paste a key into chat, a task, or a definition, and never write a key into a definition.
 
 Afterwards, a \`warnings\` entry on \`create-workflow\` or a patch tool means the key went missing since you checked. Treat it as step 4.
 
@@ -12544,6 +12553,7 @@ The same rules apply to a standalone \`request-human-input\` call.
 
 - **Dashboard card.** \`title\` is plain text. Each question's \`label\` is its heading and renders as markdown. \`description\` renders as full markdown and is the only field that shows images, so put drafts, diffs, and logs there.
 - **Code.** Fence code, logs, and JSON with a language (\`\`\`\` \`\`\`json \`\`\`\`): the block keeps its lines and scrolls. Fence a prose draft with no language: it wraps. A single newline outside a fence becomes a paragraph break.
+- **Config questions.** A \`config\` question (\`config: { key, scope }\`) renders the key, whether it is already set, and a password field for secrets or a select for non-secret \`options\`. The value is written only when the request resolves approved, and the response holds only the result (\`status\` \`set\`, \`kept\`, or \`skipped\`), never a secret value. It needs \`approvers.policy: "any"\`. Use it whenever you need a person to supply a config value or secret.
 - **Images.** Put an \`http(s)\` URL ending in \`.png\`, \`.jpg\`, \`.jpeg\`, \`.gif\`, or \`.webp\` alone on its own line in \`description\`, or use \`![alt](url)\`. The link must outlive the request: an expired presigned URL shows an "image unavailable" note.
 - **Slack.** A node's \`notifications\` post the title, the question labels (each collapsed to one line, capped at 3000 characters in total), a Review button, and the timeout. Descriptions, options, code, and images are not shown, so the title and labels must make sense alone. \`request-human-input\` posts nothing to Slack: share the returned URL yourself.
 
@@ -13051,9 +13061,9 @@ function expandSkill(command: string): string {
 # codex-exec.sh — invoke \`codex exec\` (non-interactive) for delegated
 # implementation work. This is the SINGLE SOURCE OF TRUTH for the invocation
 # flags. The delegate-work skill calls only this script; its routing matrix
-# decides WHICH gpt-5.6 variant (-m) and effort (-e) each task gets:
-#   luna  = mechanical/bounded     terra = everyday frozen-spec slice
-#   sol   = hard/long-horizon      effort: medium|high|xhigh|max (never ultra)
+# decides WHICH gpt-6 variant (-m) and effort (-e) each task gets:
+#   gpt-6-luna  = trivial/mechanical   gpt-6.1-sol = default (medium) to hard (high/xhigh)
+#   gpt-6-astra = escalation only      effort: medium|high|xhigh|max (never ultra)
 #
 # Usage:
 #   codex-exec.sh [-m <model>] [-e <effort>] -C <workdir> -o <last-message-file> [-l <log-file>] "PROMPT"
@@ -13072,7 +13082,7 @@ function expandSkill(command: string): string {
 # parallel worktree runs from clobbering each other or the main tree.
 #
 # Env overrides (flags -m/-e take precedence):
-#   CODEX_MODEL   default: gpt-5.6-sol          gpt-5.6-sol | gpt-5.6-terra | gpt-5.6-luna
+#   CODEX_MODEL   default: gpt-6.1-sol          gpt-6.1-sol | gpt-6-astra | gpt-6-luna
 #   CODEX_EFFORT  default: high                 reasoning effort (never "fast"/low)
 #   CODEX_SANDBOX default: workspace-write (passed to codex's -s option)
 #   CODEX_BYPASS  set to 1 to use --dangerously-bypass-approvals-and-sandbox
@@ -13100,7 +13110,7 @@ while [[ $# -gt 0 ]]; do
   esac
 done
 
-MODEL="\${MODEL_FLAG:-\${CODEX_MODEL:-gpt-5.6-sol}}"
+MODEL="\${MODEL_FLAG:-\${CODEX_MODEL:-gpt-6.1-sol}}"
 EFFORT="\${EFFORT_FLAG:-\${CODEX_EFFORT:-high}}"
 SANDBOX="\${CODEX_SANDBOX:-workspace-write}"
 

package/dist/{index-1cscynkb.js → index-xdaahthb.js}

@@ -3,36 +3,36 @@ import {
   startScheduler2,
   stopScheduler2,
   runScheduleNow2
-} from "./cli-h5d22pfs.js";
+} from "./cli-asq5ydm4.js";
 import"./cli-pasyvjmm.js";
-import"./cli-xw9q173h.js";
+import"./cli-9s05422w.js";
 import"./cli-qz93y3x5.js";
 import"./cli-3h26v7yj.js";
-import"./cli-e8xyjvfc.js";
-import"./cli-0vgy5wfw.js";
-import"./cli-e91vshb1.js";
+import"./cli-bvpgr9ny.js";
+import"./cli-7p4jxgtt.js";
 import"./cli-3ggwdtb0.js";
-import"./cli-6y43v79h.js";
-import"./cli-3e9vs93g.js";
-import"./cli-bpbcpd8b.js";
+import"./cli-tsma7p8v.js";
+import"./cli-c61mbdds.js";
+import"./cli-sbwsxvtd.js";
 import"./cli-g9ypd5en.js";
-import"./cli-y3dzwyy3.js";
-import"./cli-j3dwd4kz.js";
+import"./cli-x0f2v69c.js";
+import"./cli-gbfxp48k.js";
 import"./cli-qqzmjxkf.js";
 import"./cli-kxpfx2xr.js";
-import"./cli-d172svcw.js";
+import"./cli-e8xyjvfc.js";
+import"./cli-gwhjmh8g.js";
 import"./cli-13p25grh.js";
 import"./cli-0adyhvq2.js";
-import"./cli-15xd0j7w.js";
-import"./cli-b63d08rs.js";
-import"./cli-4qkg9968.js";
-import"./cli-b6tnjdvx.js";
+import"./cli-abs8ndtr.js";
+import"./cli-eftzyh9y.js";
+import"./cli-19202kew.js";
+import"./cli-6a1xg1p7.js";
 import"./cli-rycdaj0a.js";
 import"./cli-445c1vp7.js";
 import"./cli-kvzgak7c.js";
 import"./cli-2nf3b08t.js";
-import"./cli-86zpfje5.js";
-import"./cli-csh8fnbg.js";
+import"./cli-ff1tm9n9.js";
+import"./cli-jb30dzvk.js";
 import"./cli-dabehxhp.js";
 export {
   calculateNextRun2 as calculateNextRun,

package/dist/{keepalive-a9srcphj.js → keepalive-v4ta8wgg.js}

@@ -1,10 +1,10 @@
 import {
   listKeepAliveAuthorizations,
   init_oauth
-} from "./cli-csh8fnbg.js";
+} from "./cli-jb30dzvk.js";
 import {
   ensureAuthorizationTokenOrThrow
-} from "./cli-6y43v79h.js";
+} from "./cli-tsma7p8v.js";
 import {
   scrubSecrets,
   init_secret_scrubber
@@ -57,7 +57,7 @@ async function notifySlack(text) {
     return;
   }
   try {
-    const { getSlackApp } = await import("./app-ft6r6v23.js");
+    const { getSlackApp } = await import("./app-ctn8gsgx.js");
     const app = getSlackApp();
     if (!app) {
       console.warn("[OAuth Keepalive] Slack not available, cannot send notification");