@desplega.ai/agent-swarm 1.165.0 → 1.167.0

package/dist/{index-056j5kzn.js → index-2t9kesn1.js}

@@ -1,32 +1,33 @@
 import {
   getEmbeddingProvider,
   getMemoryStore,
+  init_memory,
   resetEmbeddingProvider
-} from "./cli-yhmwmv0g.js";
-import"./cli-wfajtmf7.js";
-import"./cli-cvk6yzw5.js";
-import"./cli-qdv8kgz7.js";
-import"./cli-9s3h836g.js";
+} from "./cli-mkdsy1nq.js";
 import"./cli-3qhyh31j.js";
-import"./cli-3a4m1aws.js";
+import"./cli-xvdgasgy.js";
+import"./cli-mxvnnv5q.js";
 import"./cli-7mm2r1kp.js";
 import"./cli-g5erf0zt.js";
 import"./cli-dmtrxqhg.js";
-import"./cli-tadfgd0t.js";
-import"./cli-ywybs5as.js";
-import"./cli-gd4favx9.js";
 import"./cli-agamgm0p.js";
 import"./cli-5c2j5yvx.js";
 import"./cli-1a2j50m0.js";
+import"./cli-tadfgd0t.js";
+import"./cli-ywybs5as.js";
 import"./cli-f9w1semm.js";
+import"./cli-a35hzdve.js";
+import"./cli-gd4favx9.js";
 import"./cli-ej6gbxfb.js";
-import"./cli-zsh093hk.js";
+import"./cli-014vns2y.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-1kzfvd1z.js";
+import"./cli-ymmc1zxg.js";
 import"./cli-zf8jjwex.js";
-import"./cli-h1spv8v4.js";
+import"./cli-wt7ccy4r.js";
 import"./cli-bc05qbss.js";
+init_memory();
+
 export {
   getEmbeddingProvider,
   getMemoryStore,

package/dist/{index-cj1r9q83.js → index-bt8wkv1w.js}

@@ -4,71 +4,67 @@ import {
   runRebootSweep,
   startHeartbeat,
   stopHeartbeat
-} from "./cli-ba66wyhy.js";
-import"./cli-50eg13rj.js";
-import"./cli-x7afk5wm.js";
-import"./cli-420bdgw0.js";
+} from "./cli-qzmzwegq.js";
+import"./cli-wydz3feg.js";
+import"./cli-xvc3q9br.js";
+import"./cli-mv2520nm.js";
 import"./cli-w0bwte75.js";
 import"./cli-re8z5p8p.js";
-import"./cli-k6xx3pve.js";
-import"./cli-e7t4snpa.js";
-import"./cli-nfygw434.js";
-import"./cli-xtgtyafv.js";
+import"./cli-tx2zvn23.js";
+import"./cli-p8rt8spp.js";
+import"./cli-v1pwxreq.js";
+import"./cli-577bxkf6.js";
 import"./cli-epan13p1.js";
 import"./cli-f14fvzag.js";
+import"./cli-7mhy3ths.js";
+import"./cli-v1w7pbd8.js";
 import"./cli-zt3w1cn1.js";
-import"./cli-xb3c6aat.js";
-import"./cli-ftry7975.js";
-import"./cli-3dpj7atn.js";
-import"./cli-2x0e561b.js";
-import"./cli-pkke6geq.js";
+import"./cli-km4x66j0.js";
 import"./cli-rb9m6rpe.js";
+import"./cli-2x0e561b.js";
+import"./cli-kw0jcfje.js";
 import"./cli-mzfth0bp.js";
-import"./cli-jqt9hrnz.js";
-import"./cli-yhmwmv0g.js";
-import"./cli-wfajtmf7.js";
-import"./cli-a87b04k8.js";
 import"./cli-fad8m16k.js";
 import"./cli-bsakbbkm.js";
 import"./cli-zxg80zs9.js";
 import"./cli-51tf7ac3.js";
 import"./cli-ydt3zkwv.js";
-import"./cli-0n4fasz0.js";
+import"./cli-c8r99akr.js";
 import"./cli-q51yprfq.js";
 import"./cli-3er6gcsn.js";
-import"./cli-cvk6yzw5.js";
 import"./cli-yatxqynm.js";
-import"./cli-b0f70z24.js";
-import"./cli-nexwh8zg.js";
+import"./cli-mn8qkd8v.js";
+import"./cli-g7k7zbcz.js";
 import"./cli-btbzvq95.js";
 import"./cli-1m2e086m.js";
-import"./cli-bzr0ftht.js";
+import"./cli-wnb9b2g3.js";
 import"./cli-bd957dgb.js";
 import"./cli-pzxba7gw.js";
-import"./cli-xnzrzets.js";
+import"./cli-ypgba1a8.js";
 import"./cli-rfphkzh5.js";
-import"./cli-qdv8kgz7.js";
-import"./cli-9s3h836g.js";
+import"./cli-mkdsy1nq.js";
 import"./cli-3qhyh31j.js";
-import"./cli-3a4m1aws.js";
+import"./cli-xvdgasgy.js";
+import"./cli-mxvnnv5q.js";
 import"./cli-7mm2r1kp.js";
 import"./cli-g5erf0zt.js";
 import"./cli-dmtrxqhg.js";
-import"./cli-tadfgd0t.js";
-import"./cli-ywybs5as.js";
-import"./cli-gd4favx9.js";
 import"./cli-agamgm0p.js";
 import"./cli-5c2j5yvx.js";
 import"./cli-1a2j50m0.js";
+import"./cli-tadfgd0t.js";
+import"./cli-ywybs5as.js";
 import"./cli-f9w1semm.js";
+import"./cli-a35hzdve.js";
+import"./cli-gd4favx9.js";
 import"./cli-ej6gbxfb.js";
-import"./cli-zsh093hk.js";
+import"./cli-014vns2y.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-1kzfvd1z.js";
-import"./cli-hpryr6em.js";
+import"./cli-ymmc1zxg.js";
+import"./cli-mb75wpxf.js";
 import"./cli-zf8jjwex.js";
-import"./cli-h1spv8v4.js";
+import"./cli-wt7ccy4r.js";
 import"./cli-bc05qbss.js";
 export {
   getBootEpochMs,

package/dist/{index-7n70jwbb.js → index-cx1sb9bq.js}

@@ -3,43 +3,36 @@ import {
 } from "./cli-ep19k3mb.js";
 import {
   agentFsProvisionSeeder
-} from "./cli-prt9emct.js";
+} from "./cli-c2tpw9ck.js";
 import {
   extractArgsJsonSchema,
   extractScriptSignature,
-  getScript,
   require_dist,
   typecheckScript,
-  upsertScriptByName,
   validateDefinition,
   validateScriptImports
-} from "./cli-xtgtyafv.js";
+} from "./cli-577bxkf6.js";
 import"./cli-epan13p1.js";
 import"./cli-f14fvzag.js";
+import"./cli-7mhy3ths.js";
+import"./cli-v1w7pbd8.js";
 import"./cli-zt3w1cn1.js";
-import"./cli-xb3c6aat.js";
-import"./cli-ftry7975.js";
-import"./cli-3dpj7atn.js";
-import"./cli-2x0e561b.js";
-import"./cli-pkke6geq.js";
+import"./cli-km4x66j0.js";
 import"./cli-rb9m6rpe.js";
-import"./cli-jqt9hrnz.js";
-import"./cli-yhmwmv0g.js";
-import"./cli-wfajtmf7.js";
-import"./cli-a87b04k8.js";
+import"./cli-2x0e561b.js";
+import"./cli-kw0jcfje.js";
 import"./cli-bsakbbkm.js";
 import"./cli-zxg80zs9.js";
 import"./cli-ydt3zkwv.js";
-import"./cli-0n4fasz0.js";
+import"./cli-c8r99akr.js";
 import"./cli-q51yprfq.js";
 import"./cli-3er6gcsn.js";
-import"./cli-cvk6yzw5.js";
 import"./cli-yatxqynm.js";
-import"./cli-b0f70z24.js";
-import"./cli-nexwh8zg.js";
+import"./cli-mn8qkd8v.js";
+import"./cli-g7k7zbcz.js";
 import"./cli-btbzvq95.js";
 import"./cli-1m2e086m.js";
-import"./cli-bzr0ftht.js";
+import"./cli-wnb9b2g3.js";
 import"./cli-bd957dgb.js";
 import"./cli-pzxba7gw.js";
 import {
@@ -50,40 +43,45 @@ import {
   deleteSkillFile,
   getDbClient,
   getScheduledTaskByName,
+  getScript,
   getSkillByName,
   getSkillFiles,
   init_db,
+  init_db1 as init_db2,
   listWorkflows,
   updateScheduledTask,
   updateSkill,
   updateWorkflow,
+  upsertScriptByName,
   upsertSkillFiles
-} from "./cli-qdv8kgz7.js";
-import"./cli-9s3h836g.js";
+} from "./cli-mkdsy1nq.js";
 import"./cli-3qhyh31j.js";
-import"./cli-3a4m1aws.js";
+import"./cli-xvdgasgy.js";
+import"./cli-mxvnnv5q.js";
 import"./cli-7mm2r1kp.js";
 import"./cli-g5erf0zt.js";
 import"./cli-dmtrxqhg.js";
-import"./cli-tadfgd0t.js";
-import"./cli-ywybs5as.js";
-import"./cli-gd4favx9.js";
 import"./cli-agamgm0p.js";
 import"./cli-5c2j5yvx.js";
 import"./cli-1a2j50m0.js";
+import"./cli-tadfgd0t.js";
+import"./cli-ywybs5as.js";
 import"./cli-f9w1semm.js";
+import"./cli-a35hzdve.js";
+import"./cli-gd4favx9.js";
 import"./cli-ej6gbxfb.js";
-import"./cli-zsh093hk.js";
+import"./cli-014vns2y.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-1kzfvd1z.js";
+import"./cli-ymmc1zxg.js";
 import"./cli-zf8jjwex.js";
-import"./cli-h1spv8v4.js";
+import"./cli-wt7ccy4r.js";
 import {
   __toESM
 } from "./cli-bc05qbss.js";
 
 // src/be/seed-scripts/index.ts
+init_db2();
 init_db();
 
 // src/be/seed-scripts/catalog/app-sync-run.ts
@@ -5736,7 +5734,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\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 `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';
 
 // templates/skills/apps/config.json
 var config_default2 = `{
@@ -6442,7 +6440,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.\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\n1. CI status first, including the fork checks below before treating CI as evidence. Failing CI is a REQUEST_CHANGES. Name the failing checks in the review.\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: REQUEST_CHANGES naming the held or unexecuted run, and report the blocker 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 second. This authoring gate applies to production changes and tests under root `src/` only; `apps/ui/` and `apps/evals/` are out of scope for now. For a behavior change in root `src/`, no new or updated test that names the regression it catches is a REQUEST_CHANGES. A test that fails the gate below is also a REQUEST_CHANGES. Documentation-only, configuration-only, and dependency-bump PRs are exempt.\n\n   Before adding or changing a root `src/` test, answer all four questions:\n   - What observable behavior, invariant, or independent contract does it protect?\n   - What credible regression would make it fail?\n   - Why would existing coverage miss that regression? Give each contract one primary test owner at its strongest boundary. Another layer needs a distinct risk the owner cannot reach. Prefer extending a table-driven case or shared fixture over a near-duplicate.\n   - Does it need a production seam (export, flag, wrapper, or injection hook) that no production caller needs? If so, move the test to the real boundary.\n\n   Reject tests that match these junk patterns:\n   - Assertion-free coverage probes.\n   - Self-comparisons and identity copiers.\n   - Copied fixtures, inventories, manifests, or export lists.\n   - Exact source, import, or string greps.\n   - Private predicate or call-shape tests duplicated at real boundaries.\n   - Duplicate invocations of the same contract.\n   - Provider-local replays of shared helpers.\n   - Tests whose only purpose is preserving test-only exports, globals, or wrappers.\n   - Dead production code whose only callers are tests.\n   - Expected values produced by the helper or renderer under test.\n   - Mocks that implement the asserted behavior, or one identical mock standing in for different APIs.\n   - Fixtures that supply the receipt, admission, or callback ordering the owner should produce, or persistence asserted against a store the path never writes.\n   - Capability tests that restate declared flags instead of exercising the delivery or acknowledgement the flag promises.\n   - Negative controls that pass for an unrelated reason, such as denial from a different guard or a rejection the production path never reaches.\n   - Test names or fixtures that promise more than the input exercises.\n\n   A regression test must fail on the pre-fix code for the intended reason and pass after the repair. A regression test that never demonstrably failed does not prove the fix.\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), performance (N+1, leaks), and code shape (naming, duplication, error handling). Run the test suite and the type check locally when you can.\n8. Post the review with the verdict first. One finding per comment, with file and line, and what to change.\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.\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\n0. 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. New SHA: review the diff since that commit, then run the full list below. If the new head merged or rebased main, also read every conflict resolution (files both sides touched), check migration numbering and order against main, grep for stale migration numbers, and confirm CI is green at the exact head you review.\n1. CI status first, including the fork checks below before treating CI as evidence. Failing CI is a REQUEST_CHANGES. Name the failing checks in the review.\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: REQUEST_CHANGES naming the held or unexecuted run, and report the blocker 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 second. This authoring gate applies to production changes and tests under root `src/` only; `apps/ui/` and `apps/evals/` are out of scope for now. For a behavior change in root `src/`, no new or updated test that names the regression it catches is a REQUEST_CHANGES. A test that fails the gate below is also a REQUEST_CHANGES. Documentation-only, configuration-only, and dependency-bump PRs are exempt.\n\n   Before adding or changing a root `src/` test, answer all four questions:\n   - What observable behavior, invariant, or independent contract does it protect?\n   - What credible regression would make it fail?\n   - Why would existing coverage miss that regression? Give each contract one primary test owner at its strongest boundary. Another layer needs a distinct risk the owner cannot reach. Prefer extending a table-driven case or shared fixture over a near-duplicate.\n   - Does it need a production seam (export, flag, wrapper, or injection hook) that no production caller needs? If so, move the test to the real boundary.\n\n   Reject tests that match these junk patterns:\n   - Assertion-free coverage probes.\n   - Self-comparisons and identity copiers.\n   - Copied fixtures, inventories, manifests, or export lists.\n   - Exact source, import, or string greps.\n   - Private predicate or call-shape tests duplicated at real boundaries.\n   - Duplicate invocations of the same contract.\n   - Provider-local replays of shared helpers.\n   - Tests whose only purpose is preserving test-only exports, globals, or wrappers.\n   - Dead production code whose only callers are tests.\n   - Expected values produced by the helper or renderer under test.\n   - Mocks that implement the asserted behavior, or one identical mock standing in for different APIs.\n   - Fixtures that supply the receipt, admission, or callback ordering the owner should produce, or persistence asserted against a store the path never writes.\n   - Capability tests that restate declared flags instead of exercising the delivery or acknowledgement the flag promises.\n   - Negative controls that pass for an unrelated reason, such as denial from a different guard or a rejection the production path never reaches.\n   - Test names or fixtures that promise more than the input exercises.\n\n   A regression test must fail on the pre-fix code for the intended reason and pass after the repair. A regression test that never demonstrably failed does not prove the fix.\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), performance (N+1, leaks), and code shape (naming, duplication, error handling). Run the test suite and the type check locally when you can.\n8. Post the review with the verdict first. One finding per comment, with file and line, and what to change.\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 = `{
@@ -7272,7 +7270,7 @@ Two kinds of sections:
 
 ## Handle a heartbeat-checklist task
 
-0. Quiet check. Take the fast path when three things hold: the system status shows no failed, stalled or reboot-interrupted task; no mention has gone unanswered since the last heartbeat; and no tracked item in the task's runbook snapshot is at or past its date. On the fast path, run the two step 3 scripts. If both are clean, complete with one line that names the zero counts and skip steps 1, 2 and 4-7. Anything non-zero means continue at step 1.
+0. Quiet check. Take the fast path when three things hold: every failed, stalled or reboot-interrupted task in the system status was already named in the previous heartbeat-checklist task's output (newest completed one via \`get-tasks\`); no mention has gone unanswered since the last heartbeat; and no tracked item in the task's runbook snapshot is at or past its date. On the fast path, run the two step 3 scripts. If they report nothing the previous heartbeat had not already triaged, complete with one line citing the previous heartbeat task id and the counts, and skip steps 1, 2 and 4-7. Anything new means continue at step 1.
 1. Read the latest runbook. The snapshot in the task may be stale.
 2. Prune first. Check every tracked item against its lift trigger. Remove resolved, stale, and past-date items.
 3. Run the seeded scripts: \`script-run\` with name \`schedule-health\`, then \`task-failure-audit\`, both with \`args: { days: 1, publishPage: false }\`. They report failing schedules and failure clusters. Check any other standing order in the runbook yourself.
@@ -11854,7 +11852,7 @@ 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\nIf the user interrupts, follow their instructions. To resume, call `/work-on-task <taskId>` again.\n";
+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.\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 = `{
@@ -12054,6 +12052,15 @@ 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.
 
+### \`human-in-the-loop\` (how approvals render)
+
+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.
+- **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.
+
 ### \`swarm-script\`
 
 \`\`\`json
@@ -12292,7 +12299,7 @@ For complete command documentation with all flags and options, see [COMMANDS.md]
 `;
 
 // src/be/seed-skills/index.ts
-init_db();
+init_db2();
 // src/be/seed-skills/bundled-files.generated.json
 var bundled_files_generated_default = {
   artifacts: [
@@ -15095,7 +15102,7 @@ var skillsSeeder = {
 };
 
 // src/be/seed/state-db.ts
-init_db();
+init_db2();
 async function getSeedState(kind, key) {
   return getDbClient().get("SELECT kind, key, seededHash, seededAt FROM seed_state WHERE kind = ? AND key = ?", [kind, key]);
 }
@@ -16490,7 +16497,7 @@ var config_default63 = `{
 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` | https://opencode.ai (latest release) | MUST match `OPENCODE_SDK_VERSION` |\n| `OPENCODE_SDK_VERSION` | npm `@opencode-ai/sdk` | MUST match `OPENCODE_VERSION` — bump both together |\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-ai/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-sdk: `npm view @opencode-ai/sdk version`\n   - opencode: `curl -fsSL https://api.github.com/repos/sst/opencode/releases/latest | jq -r .tag_name`\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_VERSION` and `@opencode-ai/sdk` 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_db();
+init_db2();
 
 // src/be/seed/automation-toggle.ts
 var SEED_AUTOMATIONS_ENABLED_ENV = "SEED_AUTOMATIONS_ENABLED";
@@ -16936,7 +16943,7 @@ The \`maxIterations\` parameter is declarative: the reviewer signals PASS when d
 `;
 
 // src/be/seed/workflows-seeder.ts
-init_db();
+init_db2();
 var asText2 = (value) => value;
 var BUILT_IN_WORKFLOW_SOURCES = [
   { config: asText2(config_default64), content: asText2(content_default64) },

package/dist/{index-9bfssf54.js → index-ekywyv2v.js}

@@ -4,70 +4,66 @@ import {
   runScheduleNow,
   startScheduler,
   stopScheduler
-} from "./cli-50eg13rj.js";
-import"./cli-x7afk5wm.js";
-import"./cli-420bdgw0.js";
+} from "./cli-wydz3feg.js";
+import"./cli-xvc3q9br.js";
+import"./cli-mv2520nm.js";
 import"./cli-w0bwte75.js";
 import"./cli-re8z5p8p.js";
-import"./cli-k6xx3pve.js";
-import"./cli-e7t4snpa.js";
-import"./cli-nfygw434.js";
-import"./cli-xtgtyafv.js";
+import"./cli-tx2zvn23.js";
+import"./cli-p8rt8spp.js";
+import"./cli-v1pwxreq.js";
+import"./cli-577bxkf6.js";
 import"./cli-epan13p1.js";
 import"./cli-f14fvzag.js";
+import"./cli-7mhy3ths.js";
+import"./cli-v1w7pbd8.js";
 import"./cli-zt3w1cn1.js";
-import"./cli-xb3c6aat.js";
-import"./cli-ftry7975.js";
-import"./cli-3dpj7atn.js";
-import"./cli-2x0e561b.js";
-import"./cli-pkke6geq.js";
+import"./cli-km4x66j0.js";
 import"./cli-rb9m6rpe.js";
+import"./cli-2x0e561b.js";
+import"./cli-kw0jcfje.js";
 import"./cli-mzfth0bp.js";
-import"./cli-jqt9hrnz.js";
-import"./cli-yhmwmv0g.js";
-import"./cli-wfajtmf7.js";
-import"./cli-a87b04k8.js";
 import"./cli-fad8m16k.js";
 import"./cli-bsakbbkm.js";
 import"./cli-zxg80zs9.js";
 import"./cli-51tf7ac3.js";
 import"./cli-ydt3zkwv.js";
-import"./cli-0n4fasz0.js";
+import"./cli-c8r99akr.js";
 import"./cli-q51yprfq.js";
 import"./cli-3er6gcsn.js";
-import"./cli-cvk6yzw5.js";
 import"./cli-yatxqynm.js";
-import"./cli-b0f70z24.js";
-import"./cli-nexwh8zg.js";
+import"./cli-mn8qkd8v.js";
+import"./cli-g7k7zbcz.js";
 import"./cli-btbzvq95.js";
 import"./cli-1m2e086m.js";
-import"./cli-bzr0ftht.js";
+import"./cli-wnb9b2g3.js";
 import"./cli-bd957dgb.js";
 import"./cli-pzxba7gw.js";
-import"./cli-xnzrzets.js";
+import"./cli-ypgba1a8.js";
 import"./cli-rfphkzh5.js";
-import"./cli-qdv8kgz7.js";
-import"./cli-9s3h836g.js";
+import"./cli-mkdsy1nq.js";
 import"./cli-3qhyh31j.js";
-import"./cli-3a4m1aws.js";
+import"./cli-xvdgasgy.js";
+import"./cli-mxvnnv5q.js";
 import"./cli-7mm2r1kp.js";
 import"./cli-g5erf0zt.js";
 import"./cli-dmtrxqhg.js";
-import"./cli-tadfgd0t.js";
-import"./cli-ywybs5as.js";
-import"./cli-gd4favx9.js";
 import"./cli-agamgm0p.js";
 import"./cli-5c2j5yvx.js";
 import"./cli-1a2j50m0.js";
+import"./cli-tadfgd0t.js";
+import"./cli-ywybs5as.js";
 import"./cli-f9w1semm.js";
+import"./cli-a35hzdve.js";
+import"./cli-gd4favx9.js";
 import"./cli-ej6gbxfb.js";
-import"./cli-zsh093hk.js";
+import"./cli-014vns2y.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-1kzfvd1z.js";
-import"./cli-hpryr6em.js";
+import"./cli-ymmc1zxg.js";
+import"./cli-mb75wpxf.js";
 import"./cli-zf8jjwex.js";
-import"./cli-h1spv8v4.js";
+import"./cli-wt7ccy4r.js";
 import"./cli-bc05qbss.js";
 export {
   calculateNextRun,