@desplega.ai/agent-swarm 2.6.0 → 2.7.1

package/dist/{index-qhjf2htm.js → index-ejqdkkqx.js}

@@ -5,7 +5,7 @@ import {
   extractArgsJsonSchema,
   typecheckScript,
   parseSkillContent
-} from "./cli-3gfvmzht.js";
+} from "./cli-kbtdftbw.js";
 import {
   getDbClient2,
   computeContentHash2,
@@ -26,19 +26,20 @@ import {
   deleteSkill2,
   getSkillByName2,
   init_db3
-} from "./cli-g8ka5j4j.js";
-import"./cli-kf4jree9.js";
+} from "./cli-qvaa1gjp.js";
+import"./cli-rm66vqdz.js";
 import"./cli-3ggwdtb0.js";
+import"./cli-hpkvgdad.js";
 import {
   agentFsProvisionSeeder
-} from "./cli-6y51ryva.js";
+} from "./cli-x3cngb1h.js";
 import"./cli-e8xyjvfc.js";
 import {
   validateDefinition
-} from "./cli-3fwqy71j.js";
-import"./cli-g20jjwt4.js";
-import"./cli-gnsb1zxa.js";
-import"./cli-v49fkghp.js";
+} from "./cli-dv11pgpv.js";
+import"./cli-thsaq4pd.js";
+import"./cli-vhpckzvp.js";
+import"./cli-ekptgk2m.js";
 import"./cli-2nf3b08t.js";
 import"./cli-kvzgak7c.js";
 import"./cli-445c1vp7.js";
@@ -48,7 +49,7 @@ import {
 } from "./cli-691vz9mk.js";
 import"./cli-13p25grh.js";
 import"./cli-0adyhvq2.js";
-import"./cli-esakngh8.js";
+import"./cli-nf6k60sn.js";
 import"./cli-rycdaj0a.js";
 import {
   __toESM
@@ -11056,8 +11057,172 @@ var config_default42 = `{
 // templates/skills/step-running/content.md
 var content_default42 = "# Step Running\n\nYou execute a single step of a DAG plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.\n\nThis is the DAG sibling of `phase-running`. The execution model and atomicity contract are identical; the differences are:\n- You receive a **step file path** (`step-<n>.md`), not a plan path + phase number.\n- You **claim the step atomically** via the step's frontmatter `status` field before doing work, and release it on completion / failure. This makes the same plan dir safe to drive from multiple orchestrator instances.\n\n## Execution Model\n\nThis skill runs inside a background `Agent` (sub-agent). v-implementing (or a user invoking `/run-step`) spawns it via the Agent tool with `run_in_background: true`.\n\nThe step agent receives:\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory (read `root.md` from here for plan-level context)\n- **Agent ID**: unique identifier for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). Used for atomic claim + stale-claim detection.\n- **Relevant context**: any extra context from the caller\n\n## Concurrency: Atomic Claim\n\nBefore doing any work, claim the step:\n\n1. Read the step file's frontmatter.\n2. **If `status: done`** — report `Status: skipped` and exit. The step is already finished.\n3. **If `status: claimed`** and `assignee` differs from your agent ID:\n   - Fresh claim (`claimed_at` within last hour): report `Status: blocked` (reason: `claimed by <other-id>`) and exit.\n   - Stale claim (>1h): proceed and overwrite — the previous worker likely died.\n4. **Otherwise** (`status: ready`, or stale `claimed`): rewrite the frontmatter block in a single `Edit` so the write is atomic-enough for filesystem-based coordination. Set:\n   - `status: claimed`\n   - `assignee: <your-agent-id>`\n   - `claimed_at: <ISO timestamp UTC>`\n5. Re-read the file. If `assignee` is not yours, another worker raced you — report `Status: blocked` (reason: `lost claim race`) and exit.\n\nOn terminal transitions, set frontmatter:\n- **Completed**: `status: done`, clear `assignee` and `claimed_at`.\n- **Blocked or failed (retry-able)**: `status: ready`, clear `assignee` and `claimed_at`. The orchestrator (or another worker) can retry.\n- **Failed (non-retry-able)**: leave `status: claimed` so the orchestrator can investigate; include the reason in the report.\n\nFor true cross-machine atomicity (NFS, etc.), the caller is responsible for rendezvous (e.g. a shared lock service). The single-Edit pattern is good-enough for local filesystem and well-behaved network filesystems.\n\n## Autonomy\n\nStep agents always run as **Autopilot** within the sub-agent. The calling context controls outer autonomy and human checkpoints.\n\n**CRITICAL**: Step agents do NOT use AskUserQuestion. If something is ambiguous, report `Status: blocked` with details. The caller handles all user interaction.\n\n## Process Steps\n\n### Step 1: Load Context\n\n1. **Claim the step** (see \"Concurrency: Atomic Claim\"). Stop here on any non-claim outcome.\n2. Read the full step file.\n3. Read `root.md` from the plan dir for plan-level context: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n4. Read all files mentioned in the step's \"Changes Required\" section.\n\n### Step 2: Pre-flight Check\n\n| Check | Action if failed |\n|-------|-----------------|\n| All `depends_on` steps have `status: done` | Scheduler bug — release claim, report `blocked` |\n| No merge conflicts in target files | Release claim, report `blocked` |\n| Files/dirs from depended-on steps exist | Release claim, report `blocked` |\n\n### Step 3: Execute Step\n\nImplement the changes described in the step's \"Changes Required\" section. Adapt to minor mismatches; report `blocked` for significant ones.\n\n### Step 4: Run Verification\n\nSame three-bucket pattern as `phase-running`:\n1. **Automated Verification** (runnable commands): run each, record pass/fail. On failure, attempt one fix-and-retry.\n2. **Automated QA** (agent-driven scenarios — browser-use, screenshot diff, CLI walkthrough): execute, record pass/fail per item.\n3. **Manual Verification**: leave unchecked. Caller handles with the user.\n4. **QA Spec (linked doc)**: if present, report `QA Doc: <path>`. Do not execute scenarios inline.\n\n### Step 5: Update Step File\n\n- Check off (`- [x]`) Automated Verification + Automated QA items that passed.\n- Do NOT check off Manual Verification items.\n- Update frontmatter `status` per \"Concurrency: Atomic Claim\" terminal-transition rules.\n- Update `last_updated` / `last_updated_by` frontmatter fields if present.\n\n### Step 6: Report Results\n\n**Completed:**\n```\nStatus: completed\nStep: step-N - <Name>\nFinal frontmatter status: done\nFiles changed: [list]\nAutomated Verification: N/M passed\n- [x] [Check 1] — passed\nAutomated QA: N/M passed\n- [x] [Scenario 1] — passed\nQA Doc: <path> | n/a\nManual verification needed:\n- [ ] [Manual check 1]\n```\n\n**Blocked / failed:** mirror `phase-running`'s shape, plus a `Final frontmatter status:` line so the orchestrator knows whether the step is released for retry (`ready`) or held for investigation (`claimed`).\n\n## Atomicity Contract\n\n- No interactive questions.\n- No partial states left unexplained.\n- Frontmatter `status` always reflects the final state at exit.\n- Report includes enough detail for the caller to decide next steps.\n\n## Context Handoff Pattern\n\n| Direction | Data |\n|-----------|------|\n| **Caller → Step Agent** | Step path + plan dir + agent ID + autonomy mode |\n| **Step Agent reads** | Step file + root.md + files in Changes Required |\n| **Step Agent writes** | Frontmatter status transitions + checkboxes + code changes |\n| **Step Agent → Caller** | Status + changed files + verification results + final frontmatter status |\n| **Caller handles** | Manual verification, cross-step coordination, QA doc execution, human checkpoints |\n";
 
-// templates/skills/swarm-extensions/config.json
+// templates/skills/swarm-docs/config.json
 var config_default43 = `{
+  "kind": "skill",
+  "name": "swarm-docs",
+  "displayName": "Swarm Docs",
+  "slug": "swarm-docs",
+  "title": "Swarm Docs",
+  "description": "docs.agent-swarm.dev index: general docs, guides and playbooks, when to offer a playbook or guide to a person, and how to fetch a page. Load on demand: when no existing skill, workflow, schedule or memory covers a person's request, or they ask where something is documented.",
+  "version": "1.0.0",
+  "category": "skills",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "systemDefault": true,
+  "tags": ["docs", "playbooks", "guides", "lead"]
+}
+`;
+
+// templates/skills/swarm-docs/content.md
+var content_default43 = `# Swarm docs
+
+docs.agent-swarm.dev documents Agent Swarm: general docs, guides, and playbooks. A playbook is a tested way to run the swarm for one job (on-call, PR review, DORA metrics). Its page lists the agents, workflows, schedules and scripts to set up. The index below is generated from the docs frontmatter and ships with this release, so you can read it offline.
+
+## When to load this skill
+
+Load it on demand. Load it when a person asks for something that no skill, workflow, schedule or memory of yours covers, or asks where something is documented. When you already know how to handle the ask, handle it and leave the docs out.
+
+## Offer a page (lead)
+
+Follow these rules when you reply to a person.
+
+1. Offer only in a reply to a person's request (Slack, DM, dashboard, email). Never offer in a heartbeat, schedule, workflow step, worker follow-up, or task output.
+2. Offer only on a clear match with an entry's \`when\` line, and never on a \`not when\` match. With two candidates, offer the better one. Never offer a list.
+3. Make at most one offer per reply. Offer a page at most once per thread, and never again after a no.
+4. Skip the offer when the setup is already in place (\`list-workflows\` or the schedules list shows it), when one of your skills already covers the ask, or when the person already chose an approach.
+5. Put the offer in one sentence at the end, with the title and the link: "This matches the [Open Oncall playbook](https://docs.agent-swarm.dev/docs/playbooks/open-oncall). Want me to set it up that way?" For a setup request, wait for the answer before you build. For a question, answer it and add the link without asking.
+6. On yes, delegate to a worker: "Follow <page URL>. Read the page with the \`swarm-docs\` skill." Name the template when the entry has one.
+
+Entries marked "reference" are never offered. Read them when a task touches their topic.
+
+## Read a page (any agent)
+
+Fetch the page as markdown: \`curl -fsSL https://docs.agent-swarm.dev/llms.mdx/docs/<slug>\`, where \`<slug>\` is the path after \`/docs/\` in the index link. Follow the page; it names the agents, templates, schedules and scripts to create.
+
+- A 404 means the slug changed after this release. Fetch \`https://docs.agent-swarm.dev/llms.txt\` and find the page by title.
+- When the site is unreachable (an offline or air-gapped install), say so in one line, give the page URL, and ask the requester to attach the page. An operator can host \`docs-site/\` from the agent-swarm repo as a mirror and edit this skill to point at it; the edit survives reseed.
+- A \`template\` entry names a template that ships with the swarm (\`templates/<id>\` in the agent-swarm repo). Prefer it over writing the setup from scratch.
+
+<!-- docs-index:start -->
+<!-- Generated by \`bun run build:docs-index\` from the docs frontmatter. Do not edit by hand. -->
+
+## Playbooks
+
+- [Playbooks](https://docs.agent-swarm.dev/docs/playbooks). Reference.
+- [The rulebook our lead agent wrote for itself](https://docs.agent-swarm.dev/docs/playbooks/lead-agent-rulebook). Reference.
+- [Feature Development](https://docs.agent-swarm.dev/docs/playbooks/feature-development). When: Someone wants feature requests from Slack or Linear turned into reviewed pull requests end to end.
+- [Lead Prospecting](https://docs.agent-swarm.dev/docs/playbooks/lead-prospecting). When: Someone wants prospects found and outreach drafted on a schedule, with a person approving before anything sends.
+- [Content Generation](https://docs.agent-swarm.dev/docs/playbooks/content-generation). When: Someone wants blog posts, social posts, comparison pages or release notes written on a regular cadence.
+- [UX Command Center](https://docs.agent-swarm.dev/docs/playbooks/ux-command-center). When: Someone wants regular UX audits of their product and proposals for usability fixes.
+- [Proactive Customer Support](https://docs.agent-swarm.dev/docs/playbooks/proactive-customer-support). When: Someone wants an agent per key customer that remembers the account and prepares briefings or value reports.
+- [Observability Alert Management](https://docs.agent-swarm.dev/docs/playbooks/code-health-alert-management). When: Someone wants Datadog, Sentry, New Relic or SigNoz alerts filtered for noise, plus recurring production health audits. Not when: Alerts that page a person and should be investigated and fixed as they fire; offer Open Oncall instead.
+- [Code Health](https://docs.agent-swarm.dev/docs/playbooks/code-health-reports). When: Someone wants a recurring report on code hotspots, churn or technical debt in a repository. Template: \`community/code-health-reports\`.
+- [DORA Metrics](https://docs.agent-swarm.dev/docs/playbooks/dora-metrics). When: Someone wants deploy frequency, lead time or other DORA metrics reported on a schedule. Template: \`community/dora-metrics\`.
+- [Reports from Multiple Sources](https://docs.agent-swarm.dev/docs/playbooks/reports-multiple-sources). When: Someone wants business questions answered across their warehouse, analytics, billing and other data, with charts.
+- [Self-Documenting & Release Reports](https://docs.agent-swarm.dev/docs/playbooks/self-documenting-release-reports). When: Someone wants docs kept current, release notes written from commits, or release videos made.
+- [Open-Prompt Showreel Videos](https://docs.agent-swarm.dev/docs/playbooks/open-prompt-showreel). When: Someone wants a motion-graphics or showreel video made from a prompt. Template: \`community/open-prompt-showreel\`.
+- [Email Domain Health](https://docs.agent-swarm.dev/docs/playbooks/email-domain-health). When: Someone wants the domains they send email from watched for SPF, DKIM, DMARC or blocklist problems.
+- [Open Oncall](https://docs.agent-swarm.dev/docs/playbooks/open-oncall). When: Someone wants alerts from PagerDuty, Datadog, Sentry or a webhook investigated and fixed, with a person approving each fix. Not when: A one-off question about a single incident.
+- [PR Review](https://docs.agent-swarm.dev/docs/playbooks/pr-review). When: Someone wants every pull request reviewed automatically before a person looks at it.
+- [Linear Delivery Loop](https://docs.agent-swarm.dev/docs/playbooks/linear-delivery-loop). When: Someone wants agents to take Linear issues through implementation, CI and review to merged pull requests, with a person approving each one. Template: \`community/linear-delivery-loop\`.
+- [Hot Patterns](https://docs.agent-swarm.dev/docs/playbooks/patterns). Reference.
+- [Pattern: Litmus Tests (LLM-as-Judge Quality Gates)](https://docs.agent-swarm.dev/docs/playbooks/patterns/litmus-tests). When: Someone wants one agent to check another agent's output against a rubric before it ships.
+- [Pattern: Drain Loops (Stacked PRs + Merge Loop)](https://docs.agent-swarm.dev/docs/playbooks/patterns/drain-loops). When: Someone wants a large change split into small stacked pull requests and merged in order.
+- [Pattern: HITL Gates (Human-in-the-Loop Approval)](https://docs.agent-swarm.dev/docs/playbooks/patterns/hitl-gates). When: Someone wants a workflow to wait for a person's approval before it sends, merges, deletes or posts.
+- [Pattern: Per-Customer Working Directories](https://docs.agent-swarm.dev/docs/playbooks/patterns/per-customer-working-directories). When: Someone wants agents to keep long-lived notes per customer or account.
+- [Pattern: No-op When Nothing Changed](https://docs.agent-swarm.dev/docs/playbooks/patterns/no-op-workflows). When: Someone wants a scheduled job that stays silent when nothing changed.
+
+## Guides
+
+- [Deployment Guide](https://docs.agent-swarm.dev/docs/guides/deployment). When: Someone wants to run Agent Swarm on their own server with Docker Compose.
+- [Kubernetes and Helm](https://docs.agent-swarm.dev/docs/guides/kubernetes). When: Someone wants to install Agent Swarm on Kubernetes.
+- [Rootless Podman](https://docs.agent-swarm.dev/docs/guides/podman-rootless). When: Someone wants to run Agent Swarm under rootless Podman.
+- [Published Artifacts](https://docs.agent-swarm.dev/docs/guides/published-artifacts). Reference.
+- [Asset Namespaces](https://docs.agent-swarm.dev/docs/guides/asset-namespaces). Reference.
+- [agent-fs Co-deployment](https://docs.agent-swarm.dev/docs/guides/agent-fs-co-deployment). When: Someone wants shared persistent files for agents on a self-hosted swarm.
+- [Self-Hosted SSO](https://docs.agent-swarm.dev/docs/guides/self-hosted-sso). When: Someone wants their self-hosted swarm dashboard behind single sign-on.
+- [E2B Provider Smoke Tests](https://docs.agent-swarm.dev/docs/guides/e2b-provider-smoke-tests). Reference.
+- [Evals Harness](https://docs.agent-swarm.dev/docs/guides/evals-harness). Reference.
+- [Personalization & Status](https://docs.agent-swarm.dev/docs/guides/personalization). Reference.
+- [Secrets Encryption](https://docs.agent-swarm.dev/docs/guides/secrets-encryption). When: Someone asks how swarm secrets are stored, encrypted or backed up.
+- [Harness Configuration](https://docs.agent-swarm.dev/docs/guides/harness-configuration). When: Someone wants agents to run on a different AI provider or coding CLI.
+- [Provider Capability Matrix](https://docs.agent-swarm.dev/docs/guides/provider-capability-matrix). Reference.
+- [Adding a Harness Provider](https://docs.agent-swarm.dev/docs/guides/harness-providers). Reference.
+- [Steer a Running Task](https://docs.agent-swarm.dev/docs/guides/task-steering). Reference.
+- [Claude Code Mod](https://docs.agent-swarm.dev/docs/guides/claude-code-mod). Reference.
+- [Observability with OpenTelemetry](https://docs.agent-swarm.dev/docs/guides/observability-opentelemetry). When: Someone wants swarm traces and metrics in SigNoz or another OpenTelemetry backend.
+- [Host Requirements & Disk Cleanup](https://docs.agent-swarm.dev/docs/guides/host-requirements). When: Someone asks how big a host their self-hosted swarm needs, or their disk is filling up with Docker images.
+- [Performance & Resource Sizing](https://docs.agent-swarm.dev/docs/guides/performance-resource-sizing). Reference.
+- [Cost & context computation](https://docs.agent-swarm.dev/docs/guides/cost-and-context-computation). Reference.
+- [Extensions](https://docs.agent-swarm.dev/docs/guides/extensions). Reference.
+- [Scripts runtime](https://docs.agent-swarm.dev/docs/guides/scripts-runtime). Reference.
+- [Agent capabilities and tool allowlist](https://docs.agent-swarm.dev/docs/guides/agent-capabilities). Reference.
+- [Scripts-only mode (code-mode)](https://docs.agent-swarm.dev/docs/guides/scripts-only-mode). Reference.
+- [Script connections](https://docs.agent-swarm.dev/docs/guides/script-connections). When: Someone wants the swarm to call an external API, with credentials kept out of the code.
+- [OAuth callback migration](https://docs.agent-swarm.dev/docs/guides/oauth-callback-migration). Reference.
+- [Scripts as external APIs](https://docs.agent-swarm.dev/docs/guides/scripts-external-apis). When: Someone wants a swarm script exposed as a public HTTP endpoint or webhook receiver.
+- [Scripts credential broker](https://docs.agent-swarm.dev/docs/guides/scripts-credential-broker). Reference.
+- [One-off Script Workflow Runs](https://docs.agent-swarm.dev/docs/guides/script-workflow-runs). Reference.
+- [Claude Bridge](https://docs.agent-swarm.dev/docs/guides/claude-bridge-experimental). Reference.
+- [Worker Credential Recovery](https://docs.agent-swarm.dev/docs/guides/worker-credential-recovery). Reference.
+- [Model Gateways](https://docs.agent-swarm.dev/docs/guides/provider-auth/model-gateways). Reference.
+- [Codex OAuth](https://docs.agent-swarm.dev/docs/guides/provider-auth/codex-oauth). Reference.
+- [Cursor](https://docs.agent-swarm.dev/docs/guides/provider-auth/cursor). Reference.
+- [Amp](https://docs.agent-swarm.dev/docs/guides/provider-auth/amp). Reference.
+- [Grok](https://docs.agent-swarm.dev/docs/guides/provider-auth/grok). Reference.
+- [DeepSeek Harness (dsh)](https://docs.agent-swarm.dev/docs/guides/provider-auth/dsh). Reference.
+- [x402 Payments](https://docs.agent-swarm.dev/docs/guides/x402-payments). Reference.
+- [Multi-runtime agents](https://docs.agent-swarm.dev/docs/guides/multi-runtime-agents). Reference.
+- [Runtime pools (beta)](https://docs.agent-swarm.dev/docs/guides/runtime-pools). Reference.
+
+## Other docs
+
+- [Introduction](https://docs.agent-swarm.dev/docs)
+- [Getting Started](https://docs.agent-swarm.dev/docs/getting-started)
+- [Architecture Overview](https://docs.agent-swarm.dev/docs/architecture/overview)
+- [Agent Identity & Configuration](https://docs.agent-swarm.dev/docs/architecture/agents)
+- [Memory System](https://docs.agent-swarm.dev/docs/architecture/memory)
+- [Hook System](https://docs.agent-swarm.dev/docs/architecture/hooks)
+- [Task Lifecycle](https://docs.agent-swarm.dev/docs/concepts/task-lifecycle)
+- [Scheduled Tasks](https://docs.agent-swarm.dev/docs/concepts/scheduling)
+- [Workflows](https://docs.agent-swarm.dev/docs/concepts/workflows)
+- [Team Collaboration](https://docs.agent-swarm.dev/docs/features/team-collaboration)
+- [Apps](https://docs.agent-swarm.dev/docs/apps)
+- [App concepts](https://docs.agent-swarm.dev/docs/apps/concepts)
+- [Build an App](https://docs.agent-swarm.dev/docs/apps/build-an-app)
+- [App recipes](https://docs.agent-swarm.dev/docs/apps/recipes)
+- [Overview](https://docs.agent-swarm.dev/docs/ui)
+- [Sessions](https://docs.agent-swarm.dev/docs/ui/sessions)
+- [Configuration](https://docs.agent-swarm.dev/docs/ui/configuration)
+- [Comb](https://docs.agent-swarm.dev/docs/ui/comb)
+- [Integrations](https://docs.agent-swarm.dev/docs/integrations)
+- [Slack Integration](https://docs.agent-swarm.dev/docs/integrations/slack)
+- [GitHub App Integration](https://docs.agent-swarm.dev/docs/integrations/github)
+- [GitLab Integration](https://docs.agent-swarm.dev/docs/integrations/gitlab)
+- [Azure DevOps Integration](https://docs.agent-swarm.dev/docs/integrations/azure-devops)
+- [Bitbucket Integration](https://docs.agent-swarm.dev/docs/integrations/bitbucket)
+- [Linear](https://docs.agent-swarm.dev/docs/integrations/linear)
+- [Jira Integration](https://docs.agent-swarm.dev/docs/integrations/jira)
+- [Sentry Integration](https://docs.agent-swarm.dev/docs/integrations/sentry)
+- [AgentMail Integration](https://docs.agent-swarm.dev/docs/integrations/agentmail)
+- [Kapso (WhatsApp)](https://docs.agent-swarm.dev/docs/integrations/kapso)
+- [Chat SDK](https://docs.agent-swarm.dev/docs/integrations/chat-sdk)
+- [Composio](https://docs.agent-swarm.dev/docs/integrations/composio)
+- [Salesforce](https://docs.agent-swarm.dev/docs/integrations/salesforce)
+- [Microsoft Graph](https://docs.agent-swarm.dev/docs/integrations/microsoft-graph)
+- [Serply Search](https://docs.agent-swarm.dev/docs/integrations/serply)
+- [MCP Tools Reference](https://docs.agent-swarm.dev/docs/reference/mcp-tools)
+- [Environment Variables](https://docs.agent-swarm.dev/docs/reference/environment-variables)
+- [CLI Reference](https://docs.agent-swarm.dev/docs/reference/cli)
+- [The \`x\` command](https://docs.agent-swarm.dev/docs/reference/x-command)
+- [Telemetry](https://docs.agent-swarm.dev/docs/reference/telemetry)
+- [Contributing](https://docs.agent-swarm.dev/docs/contributing)
+<!-- docs-index:end -->
+`;
+
+// templates/skills/swarm-extensions/config.json
+var config_default44 = `{
   "kind": "skill",
   "name": "swarm-extensions",
   "displayName": "Swarm Extensions",
@@ -11074,7 +11239,7 @@ var config_default43 = `{
 `;
 
 // templates/skills/swarm-extensions/content.md
-var content_default43 = `# Swarm Extensions
+var content_default44 = `# Swarm Extensions
 
 An extension is a trusted TypeScript hook bundle that runs inside the swarm API server. Use one when a rule must apply to the whole swarm: block or rewrite new tasks, route Slack channels, suppress follow-ups, change stalled-task remediation, guard tool calls, or react after a task or tool call finishes.
 
@@ -11255,10 +11420,10 @@ export default extension;
 `;
 
 // templates/skills/swarm-scripts/config.json
-var config_default44 = '{\n  "kind": "skill",\n  "name": "swarm-scripts",\n  "displayName": "Swarm Scripts",\n  "slug": "swarm-scripts",\n  "title": "Swarm Scripts",\n  "description": "Bulk, repeat, fan-out, or data-heavy work: write and run swarm scripts (inline `script-run`, named `script-upsert`, durable `launch-script-run`). Covers the script-vs-tool rubric, the authoring contract (`args` first, `ctx` second), the seed catalog, connections and secrets, files and bash over the agent-fs drive (`ctx.fs`, `ctx.sh`), `db_query`, and exposing a script as an API.",\n  "version": "1.3.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["scripts", "automation", "context"]\n}\n';
+var config_default45 = '{\n  "kind": "skill",\n  "name": "swarm-scripts",\n  "displayName": "Swarm Scripts",\n  "slug": "swarm-scripts",\n  "title": "Swarm Scripts",\n  "description": "Bulk, repeat, fan-out, or data-heavy work: write and run swarm scripts (inline `script-run`, named `script-upsert`, durable `launch-script-run`). Covers the script-vs-tool rubric, the authoring contract (`args` first, `ctx` second), the seed catalog, connections and secrets, files and bash over the agent-fs drive (`ctx.fs`, `ctx.sh`), `db_query`, and exposing a script as an API.",\n  "version": "1.3.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["scripts", "automation", "context"]\n}\n';
 
 // templates/skills/swarm-scripts/content.md
-var content_default44 = `# Swarm Scripts
+var content_default45 = `# Swarm Scripts
 
 A swarm script is TypeScript that runs out of process with a typed Swarm SDK. Only its return value enters your context. Use one when direct tool calls would repeat, flood your context, or need deterministic processing over many records.
 
@@ -11453,7 +11618,7 @@ A named script can serve \`POST /api/x/script/<id>\` for callers outside the swa
 `;
 
 // templates/skills/tackle-gh-comments/config.json
-var config_default45 = `{
+var config_default46 = `{
   "category": "skills",
   "description": "Work through every review comment on a GitHub PR — fetch the threads, verify each claim against the code, fix what is real, then reply and mark each thread resolved before pushing. Use when the user says \\"tackle the PR comments\\", \\"address the review\\", \\"handle the bot comments\\", \\"check the comments on the PR\\", \\"resolve the review threads\\", or invokes /tackle-gh-comments. Project-agnostic; works in any repo with a GitHub remote.",
   "displayName": "Tackle GH Comments",
@@ -11474,7 +11639,7 @@ var config_default45 = `{
 `;
 
 // templates/skills/tackle-gh-comments/content.md
-var content_default45 = `# Tackle GitHub PR comments
+var content_default46 = `# Tackle GitHub PR comments
 
 Review threads and their resolved state live **only in GraphQL**. The REST API
 cannot read \`isResolved\` and cannot resolve a thread, and \`gh pr view --comments\`
@@ -11593,7 +11758,7 @@ committed, and the branch is pushed.
 `;
 
 // templates/skills/taste-minimalist-skill/config.json
-var config_default46 = `{
+var config_default47 = `{
   "kind": "skill",
   "name": "taste-minimalist-skill",
   "displayName": "Taste Minimalist Skill",
@@ -11615,7 +11780,7 @@ var config_default46 = `{
 `;
 
 // templates/skills/taste-minimalist-skill/content.md
-var content_default46 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
+var content_default47 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
 > Upstream license: MIT, Copyright (c) 2026 Leonxlnx. See ../TASTE-SKILL-LICENSE.
 
 # Protocol: Premium Utilitarian Minimalism UI Architect
@@ -11701,7 +11866,7 @@ When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing
 `;
 
 // templates/skills/tdd-planning/config.json
-var config_default47 = `{
+var config_default48 = `{
   "category": "skills",
   "description": "TDD-focused implementation planning. Creates plans with strict Red-Green-Commit/Rollback cycles for each step.",
   "displayName": "TDD Planning",
@@ -11722,7 +11887,7 @@ var config_default47 = `{
 `;
 
 // templates/skills/tdd-planning/content.md
-var content_default47 = `# TDD Planning
+var content_default48 = `# TDD Planning
 
 You are creating implementation plans that follow a strict Test-Driven Development approach. Every implementation step follows the TDD cycle: **RED → GREEN → COMMIT/ROLLBACK**.
 
@@ -11984,7 +12149,7 @@ Before finalizing any TDD plan, verify:
 `;
 
 // templates/skills/v-implementing/config.json
-var config_default48 = `{
+var config_default49 = `{
   "category": "skills",
   "description": "Parallel DAG-plan implementation skill. Reads a v-planning plan directory (root.md + step-<n>.md files), topologically schedules ready steps, and fans them out as parallel sub-agents. Use whenever the user invokes /v-implement, points at a plan directory produced by /v-plan, or asks to \\"run the parallel plan\\", \\"implement the DAG\\", or \\"fan out the steps\\" — even without those exact words. For linear plans (single .md file), use \`implementing\` instead.",
   "displayName": "V-Implementing",
@@ -12005,10 +12170,10 @@ var config_default48 = `{
 `;
 
 // templates/skills/v-implementing/content.md
-var content_default48 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
+var content_default49 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
 
 // templates/skills/v-planning/config.json
-var config_default49 = `{
+var config_default50 = `{
   "category": "skills",
   "description": "Vertical / parallel implementation planning skill. Creates DAG-structured plan directories where each step is an independent, QA-able vertical slice that sub-agents can pick up and implement in parallel. Use whenever the user wants a plan that fans out (multiple independent features), invokes /v-plan, or asks for a \\"parallel plan\\", \\"DAG plan\\", \\"vertical plan\\", or \\"plan that can be parallelized\\" — even if they don't say those exact words. Prefer the linear \`planning\` skill for strictly sequential work.",
   "displayName": "V-Planning",
@@ -12029,7 +12194,7 @@ var config_default49 = `{
 `;
 
 // templates/skills/v-planning/content.md
-var content_default49 = `# v-planning
+var content_default50 = `# v-planning
 
 You create implementation plans as a **DAG of vertical steps** — each step a complete, QA-able slice of value (DB + API + UI + tests for one feature). The DAG captures feature-level dependencies, so independent steps can be implemented in parallel by sub-agents.
 
@@ -12120,7 +12285,7 @@ Structure validation runs automatically (rule 9, Haiku sub-agent).
 `;
 
 // templates/skills/verifying/config.json
-var config_default50 = `{
+var config_default51 = `{
   "category": "skills",
   "description": "Post-implementation plan verification. Cross-references plans against actual changes for completeness and accuracy.",
   "displayName": "Verifying",
@@ -12141,7 +12306,7 @@ var config_default50 = `{
 `;
 
 // templates/skills/verifying/content.md
-var content_default50 = `# Verifying
+var content_default51 = `# Verifying
 
 You are performing a post-implementation audit of a plan, cross-referencing it against actual changes to ensure nothing was missed, nothing is stale, and the implementation matches what was planned.
 
@@ -12289,7 +12454,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/work-on-task/config.json
-var config_default51 = `{
+var config_default52 = `{
   "kind": "skill",
   "name": "work-on-task",
   "displayName": "Work On Task",
@@ -12306,10 +12471,10 @@ 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. 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";
+var content_default52 = "# 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 = `{
+var config_default53 = `{
   "kind": "skill",
   "name": "workflow-iterate",
   "displayName": "Workflow Iteration",
@@ -12331,7 +12496,7 @@ var config_default52 = `{
 `;
 
 // templates/skills/workflow-iterate/content.md
-var content_default52 = `# Workflow Iteration
+var content_default53 = `# Workflow Iteration
 
 Use this skill when you need to change an existing workflow without breaking live runs. The goal is to make small, verified revisions: inspect the current workflow, diagnose the failing step, patch only the required node or edge, trigger a realistic run, and keep iterating until the run reaches the intended terminal state.
 
@@ -12608,7 +12773,7 @@ The same rules apply to a standalone \`request-human-input\` call.
 `;
 
 // templates/skills/workflow-structured-output/config.json
-var config_default53 = `{
+var config_default54 = `{
   "kind": "skill",
   "name": "workflow-structured-output",
   "displayName": "Workflow Structured Output",
@@ -12625,10 +12790,10 @@ var config_default53 = `{
 `;
 
 // templates/skills/workflow-structured-output/content.md
-var content_default53 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
+var content_default54 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
 
 // templates/skills/wts-expert/config.json
-var config_default54 = `{
+var config_default55 = `{
   "category": "skills",
   "description": "Git worktree management expert for @desplega.ai/wts. Use when the user asks about git worktrees, wts commands, worktree workflows, or wants help managing multiple branches simultaneously.",
   "displayName": "WTS Expert",
@@ -12649,7 +12814,7 @@ var config_default54 = `{
 `;
 
 // templates/skills/wts-expert/content.md
-var content_default54 = `# WTS Expert
+var content_default55 = `# WTS Expert
 
 You are an expert on \`@desplega.ai/wts\`, a CLI tool for managing Git worktrees with tmux integration, Claude Code launcher support, and GitHub PR creation.
 
@@ -15629,11 +15794,11 @@ var BUILT_IN_SKILL_SOURCES = [
   { config: config_default37, body: content_default37 },
   { config: config_default38, body: content_default38 },
   { config: config_default43, body: content_default43 },
+  { config: config_default44, body: content_default44 },
   { config: config_default39, body: content_default39 },
   { config: config_default40, body: content_default40 },
   { config: config_default41, body: content_default41 },
   { config: config_default42, body: content_default42 },
-  { config: config_default44, body: content_default44 },
   { config: config_default45, body: content_default45 },
   { config: config_default46, body: content_default46 },
   { config: config_default47, body: content_default47 },
@@ -15643,7 +15808,8 @@ var BUILT_IN_SKILL_SOURCES = [
   { config: config_default51, body: content_default51 },
   { config: config_default52, body: content_default52 },
   { config: config_default53, body: content_default53 },
-  { config: config_default54, body: content_default54 }
+  { config: config_default54, body: content_default54 },
+  { config: config_default55, body: content_default55 }
 ];
 function canonicalFiles(files) {
   return [...files].sort((a, b) => a.path.localeCompare(b.path)).map((file) => `${file.path}
@@ -15897,7 +16063,7 @@ async function runSeeders(seeders, opts) {
 var import_cron_parser = __toESM(require_dist2(), 1);
 
 // templates/schedules/daily-blocker-digest/config.json
-var config_default55 = `{
+var config_default56 = `{
   "kind": "schedule",
   "name": "daily-blocker-digest",
   "displayName": "Daily Blocker Digest",
@@ -15919,7 +16085,7 @@ var config_default55 = `{
 `;
 
 // templates/schedules/daily-blocker-digest/content.md
-var content_default55 = `# Daily Blocker Digest
+var content_default56 = `# Daily Blocker Digest
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -16088,7 +16254,7 @@ Call \`store-progress\` with status \`completed\` and an output paragraph coveri
 `;
 
 // templates/schedules/daily-compounding-reflection/config.json
-var config_default56 = `{
+var config_default57 = `{
   "kind": "schedule",
   "name": "daily-compounding-reflection",
   "displayName": "Daily Evolution",
@@ -16111,7 +16277,7 @@ var config_default56 = `{
 `;
 
 // templates/schedules/daily-compounding-reflection/content.md
-var content_default56 = `# Daily Compounding Reflection
+var content_default57 = `# Daily Compounding Reflection
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -16336,7 +16502,7 @@ If you have zero changes across all three folds and zero deferred items, somethi
 `;
 
 // templates/schedules/daily-hn-briefing/config.json
-var config_default57 = `{
+var config_default58 = `{
   "kind": "schedule",
   "name": "daily-hn-briefing",
   "displayName": "Daily Hacker News Briefing",
@@ -16353,7 +16519,7 @@ var config_default57 = `{
 `;
 
 // templates/schedules/daily-hn-briefing/content.md
-var content_default57 = `# Daily Hacker News Briefing
+var content_default58 = `# Daily Hacker News Briefing
 
 Template parameters: {{REPORT_EMAIL}}
 
@@ -16455,7 +16621,7 @@ IMPORTANT:
 `;
 
 // templates/schedules/daily-status-report/config.json
-var config_default58 = `{
+var config_default59 = `{
   "kind": "schedule",
   "name": "daily-status-report",
   "displayName": "Daily Status Report",
@@ -16477,7 +16643,7 @@ var config_default58 = `{
 `;
 
 // templates/schedules/daily-status-report/content.md
-var content_default58 = `# Daily Status Report
+var content_default59 = `# Daily Status Report
 
 Give the operator one daily read on whether the swarm is healthy: what's running, what's failed, what's waiting on them.
 
@@ -16573,7 +16739,7 @@ More than 3 qualify ⇒ post the 3 that matter and put the rest in the task outp
 `;
 
 // templates/schedules/daily-swarm-update-check/config.json
-var config_default59 = `{
+var config_default60 = `{
   "kind": "schedule",
   "name": "daily-swarm-update-check",
   "displayName": "Daily Agent-Swarm Update Check",
@@ -16595,7 +16761,7 @@ var config_default59 = `{
 `;
 
 // templates/schedules/daily-swarm-update-check/content.md
-var content_default59 = `# Daily Agent-Swarm Update Check
+var content_default60 = `# Daily Agent-Swarm Update Check
 
 Zero-config auto-update watchdog: compares the swarm's own running version against the latest published GitHub release of \`desplega-ai/agent-swarm\`, and flags the operator when an upgrade is available. No placeholders and no integration required — every install gets this by default.
 
@@ -16647,7 +16813,7 @@ Do not attempt the upgrade yourself — this schedule only detects and reports.
 `;
 
 // templates/schedules/daily-workflow-health-audit/config.json
-var config_default60 = `{
+var config_default61 = `{
   "kind": "schedule",
   "name": "daily-workflow-health-audit",
   "displayName": "Daily Workflow Health Audit",
@@ -16669,7 +16835,7 @@ var config_default60 = `{
 `;
 
 // templates/schedules/daily-workflow-health-audit/content.md
-var content_default60 = `# Daily Workflow Health Audit
+var content_default61 = `# Daily Workflow Health Audit
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -16863,7 +17029,7 @@ Omit any section whose count is 0. **HARD CEILING 700 characters — not the 400
 `;
 
 // templates/schedules/gtm-weekly-review/config.json
-var config_default61 = `{
+var config_default62 = `{
   "kind": "schedule",
   "name": "gtm-weekly-review",
   "displayName": "Weekly GTM Metrics Review",
@@ -16880,7 +17046,7 @@ var config_default61 = `{
 `;
 
 // templates/schedules/gtm-weekly-review/content.md
-var content_default61 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
+var content_default62 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
 
 # Weekly GTM Metrics Review
 
@@ -16961,7 +17127,7 @@ This is part of your team's GTM goal; update the goal statement before enabling
 `;
 
 // templates/schedules/weekly-code-health-reports/config.json
-var config_default62 = `{
+var config_default63 = `{
   "kind": "schedule",
   "name": "weekly-code-health-reports",
   "displayName": "Weekly Code Health Reports",
@@ -16978,7 +17144,7 @@ var config_default62 = `{
 `;
 
 // templates/schedules/weekly-code-health-reports/content.md
-var content_default62 = `# Weekly Code Health Reports
+var content_default63 = `# Weekly Code Health Reports
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{SCOPE_PATH}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -17043,7 +17209,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 `;
 
 // templates/schedules/weekly-dependabot-triage/config.json
-var config_default63 = `{
+var config_default64 = `{
   "kind": "schedule",
   "name": "weekly-dependabot-triage",
   "displayName": "Weekly Dependency Triage",
@@ -17060,7 +17226,7 @@ var config_default63 = `{
 `;
 
 // templates/schedules/weekly-dependabot-triage/content.md
-var content_default63 = `# Weekly Dependency Triage
+var content_default64 = `# Weekly Dependency Triage
 
 Template parameters: {{SLACK_CHANNEL_ID}}, {{REPO_URL}}, {{TIMEZONE}}
 
@@ -17114,7 +17280,7 @@ Call \`store-progress\` with status \`completed\` and an output summary listing
 `;
 
 // templates/schedules/weekly-dora-metrics/config.json
-var config_default64 = `{
+var config_default65 = `{
   "kind": "schedule",
   "name": "weekly-dora-metrics",
   "displayName": "Weekly DORA Metrics",
@@ -17131,7 +17297,7 @@ var config_default64 = `{
 `;
 
 // templates/schedules/weekly-dora-metrics/content.md
-var content_default64 = `# Weekly DORA Metrics
+var content_default65 = `# Weekly DORA Metrics
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{TAG_PATTERN}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -17197,7 +17363,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 `;
 
 // templates/schedules/weekly-harness-upgrade-check/config.json
-var config_default65 = `{
+var config_default66 = `{
   "kind": "schedule",
   "name": "weekly-harness-upgrade-check",
   "displayName": "Weekly Harness Upgrade Check",
@@ -17214,7 +17380,7 @@ var config_default65 = `{
 `;
 
 // templates/schedules/weekly-harness-upgrade-check/content.md
-var content_default65 = '# Weekly Harness Upgrade Check\n\nThis is a topology-preserving, anonymized port of the live Sunday schedule. It keeps its bundle, deduplication, baseline, partial-fallback, and CI acceptance behavior.\n\n```json\n{"cron":"0 16 * * 0","timezone":"UTC","agentRole":"lead","enabled":true}\n```\n\n**Weekly Harness Upgrade — self-hosted repository Dockerfile.worker**\n\nRepo: `{{REPO_URL}}` (working dir: `/workspace/repo`)\nFile: `Dockerfile.worker`\n\nThe worker image pins these harnesses via `ARG`. Each week, check upstream for new versions and open ONE PR bundling ALL outdated harness bumps together ({{PR_REVIEWER}}\'s preference — bump ALL in one PR per run, do NOT stagger one-per-run).\n\n| ARG | Source | Sync requirement |\n|---|---|---|\n| `CLAUDE_CODE_VERSION` | npm `@anthropic-ai/claude-code` | none |\n| `PI_CODING_AGENT_VERSION` | npm `@earendil-works/pi-coding-agent` | MUST match `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` in `package.json` (family-pin, all same version) — bump all together |\n| `CODEX_VERSION` | npm `@openai/codex` | MUST match direct `@openai/codex` in `package.json` (enforced by `scripts/check-codex-default-model.sh`) |\n| `OPENCODE_VERSION` | npm `@opencode/sdk` | Installs both `@opencode/cli` and `@opencode/sdk`. MUST match `@opencode/sdk` and `@opencode/plugin` in `package.json` devDependencies. OpenCode 2 ships under the `@opencode/*` scope; never take a version from `opencode-ai`, `@opencode-ai/sdk`, or the `sst/opencode` GitHub releases (still the 1.x line, which would be a downgrade) |\n\n## Steps\n\n1. `cd /workspace/repo && git fetch origin && git checkout main && git pull --ff-only`\n2. Read current pinned versions from `Dockerfile.worker` (the `ARG` lines) and from `package.json` (for the pi family + `@openai/codex` + `@opencode/sdk`).\n3. For each harness, fetch the latest version:\n   - npm claude-code: `npm view @anthropic-ai/claude-code version`\n   - npm pi: `npm view @earendil-works/pi-coding-agent version` (use the SAME version for `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` — they\'re a family pin)\n   - npm codex: `npm view @openai/codex version`\n   - npm opencode: `npm view @opencode/sdk version` (one version for `@opencode/cli`, `@opencode/sdk`, `@opencode/plugin`)\n4. Check for an existing open bundled PR — `gh pr list --search "harness upgrade in:title" --state open --repo {{REPO_URL}}`. Look at the branch prefix `harness-upgrade/`. If one is already open AND was created within the last 48h (sibling schedule may have just opened it), skip and complete with `"Skipped: sibling harness upgrade PR already open"` + the existing PR URL.\n5. Collect ALL outdated harnesses. If none are outdated, complete with output `"All harnesses up to date as of YYYY-MM-DD"` (no PR).\n6. Branch: `harness-upgrade/weekly-YYYY-MM-DD` (e.g. `harness-upgrade/weekly-2026-06-03`).\n7. Edit `Dockerfile.worker` — bump every outdated ARG. Also update `package.json`:\n   - Codex: bump direct `@openai/codex` to match `CODEX_VERSION`.\n   - Pi family: bump `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` to the same new version as `PI_CODING_AGENT_VERSION`.\n   - Opencode: bump `@opencode/sdk` and `@opencode/plugin` (devDependencies) to match `OPENCODE_VERSION`.\n   Then re-run `bun install` so `bun.lock` updates.\n8. Local verification (all must pass before pushing):\n   ```bash\n   bun install --frozen-lockfile\n   bun run lint\n   bun run tsc:check\n   bun test\n   bash scripts/check-db-boundary.sh\n   ```\n   For Codex bumps: also run `bash scripts/check-codex-default-model.sh` (CI runs it too). It fails when `ARG CODEX_VERSION` differs from the direct `@openai/codex` pin in `package.json`, or when the Dockerfile\'s baseline `model = "..."` differs from `CODEX_DEFAULT_MODEL` in `src/providers/codex-models.ts`.\n   Note: do NOT run `docker build -f Dockerfile.worker .` locally — the runner lacks docker. CI\'s `docker-worker-build` job is the acceptance gate.\n9. If any local check fails, apply the **partial-bundle fallback** before giving up — one harness must never block the others:\n   **BASELINE FIRST — do this before ANY isolation work.** A red gate does NOT mean the bumps broke anything. Re-run the EXACT failing command on a pristine `origin/main` worktree with zero bumps applied (`git worktree add /tmp/hb-baseline origin/main && cd /tmp/hb-baseline && bun install --frozen-lockfile`) and compare. If the SAME checks fail with the SAME assertions and the same pass/skip/fail totals, the failure is **PRE-EXISTING and unrelated to the bumps** ⇒ it does NOT block this PR, and you must NOT attempt isolation for it. Proceed to step 10, open the PR, and add a `## Pre-existing failures (also fail on origin/main)` section quoting the verbatim error plus both totals (baseline vs branch) so the reviewer can see they match. Only a failure that is RED on your branch and GREEN on baseline was caused by a bump — apply a–d below to that failure ONLY. A gate that is red on origin/main is never a reason to skip the weekly bump.\n   a. Isolate which harness\'s bump caused it. The error usually names the package; if not, revert bumps one at a time until the step-8 gate passes.\n   b. Revert ONLY that harness — its `Dockerfile.worker` ARG **and** its `package.json` pins (respect the family/sync requirements in the table above) — then re-run `bun install` and the FULL step-8 gate.\n   c. Gate green ⇒ open the PR with the remaining harnesses and add a `## Held back` section naming the excluded harness, current → attempted version, and the VERBATIM error. Name it in your `store-progress` output too.\n   d. Gate still red with that harness reverted, OR the failure cannot be isolated to one harness ⇒ do NOT open a PR; report via `store-progress` with `failureReason`.\n   Migrating an upstream API break (a removed option, a renamed export, a moved type) is still OUT OF SCOPE for this routine — hold that harness back per (c) rather than changing code here.\n10. Push the branch and open a PR:\n    - Title: `chore(docker): bump harnesses (weekly YYYY-MM-DD)` — or list the bumps, e.g. `chore(docker): bump claude-code, pi, opencode (weekly YYYY-MM-DD)`.\n    - Body: include a table of current → new versions for every harness bumped, link to each upstream changelog (e.g. https://github.com/anthropics/claude-code/releases/tag/v<X.Y.Z>), and the local verification output (or "all green").\n    - Add `{{PR_REVIEWER}}` as a reviewer.\n    - DO NOT merge — {{PR_REVIEWER}} reviews and merges.\n11. Verify CI on the PR — wait for the merge-gate workflow to start, confirm at least the `docker-worker-build` job is queued/passing. If CI fails, comment on the PR with the failure log and leave the branch for human review.\n\n## Constraints\n\n- **ONE bundled PR per run.** Bump every outdated harness in the same PR — do not stagger one-per-run. The ONLY permitted exclusion is a harness held back by the step-9 partial-bundle fallback, which must be declared in the PR body.\n- **No `--no-verify`, no force pushes.**\n- If a harness has a major-version bump (e.g. 2.x → 3.x), still bundle it but flag clearly in the PR description that this is a major bump and may need extra review.\n- Pi family-pin: all three pi packages MUST be the same version. If they drift in the lockfile, fix the drift in the same PR.\n\n## Sibling-schedule coordination\nThis schedule has a sibling — `weekly-harness-upgrade-check-wed` (Wednesday 05:00 BCN). If a sibling-opened PR is OPEN and `< 48h` old, step 4 skips. This is the dedup gate. Don\'t change branch-naming heuristics in a way that breaks the dedup.\n\n## Output\n\n`store-progress` with `status: "completed"` and `output` containing:\n- The PR URL (if one was opened) + the table of harnesses bumped, OR\n- "No-op: all harnesses up to date as of YYYY-MM-DD" with the version table, OR\n- "Skipped: sibling harness upgrade PR already open" with the existing PR URL.\n';
+var content_default66 = '# Weekly Harness Upgrade Check\n\nThis is a topology-preserving, anonymized port of the live Sunday schedule. It keeps its bundle, deduplication, baseline, partial-fallback, and CI acceptance behavior.\n\n```json\n{"cron":"0 16 * * 0","timezone":"UTC","agentRole":"lead","enabled":true}\n```\n\n**Weekly Harness Upgrade — self-hosted repository Dockerfile.worker**\n\nRepo: `{{REPO_URL}}` (working dir: `/workspace/repo`)\nFile: `Dockerfile.worker`\n\nThe worker image pins these harnesses via `ARG`. Each week, check upstream for new versions and open ONE PR bundling ALL outdated harness bumps together ({{PR_REVIEWER}}\'s preference — bump ALL in one PR per run, do NOT stagger one-per-run).\n\n| ARG | Source | Sync requirement |\n|---|---|---|\n| `CLAUDE_CODE_VERSION` | npm `@anthropic-ai/claude-code` | none |\n| `PI_CODING_AGENT_VERSION` | npm `@earendil-works/pi-coding-agent` | MUST match `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` in `package.json` (family-pin, all same version) — bump all together |\n| `CODEX_VERSION` | npm `@openai/codex` | MUST match direct `@openai/codex` in `package.json` (enforced by `scripts/check-codex-default-model.sh`) |\n| `OPENCODE_VERSION` | npm `@opencode/sdk` | Installs both `@opencode/cli` and `@opencode/sdk`. MUST match `@opencode/sdk` and `@opencode/plugin` in `package.json` devDependencies. OpenCode 2 ships under the `@opencode/*` scope; never take a version from `opencode-ai`, `@opencode-ai/sdk`, or the `sst/opencode` GitHub releases (still the 1.x line, which would be a downgrade) |\n\n## Steps\n\n1. `cd /workspace/repo && git fetch origin && git checkout main && git pull --ff-only`\n2. Read current pinned versions from `Dockerfile.worker` (the `ARG` lines) and from `package.json` (for the pi family + `@openai/codex` + `@opencode/sdk`).\n3. For each harness, fetch the latest version:\n   - npm claude-code: `npm view @anthropic-ai/claude-code version`\n   - npm pi: `npm view @earendil-works/pi-coding-agent version` (use the SAME version for `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` — they\'re a family pin)\n   - npm codex: `npm view @openai/codex version`\n   - npm opencode: `npm view @opencode/sdk version` (one version for `@opencode/cli`, `@opencode/sdk`, `@opencode/plugin`)\n4. Check for an existing open bundled PR — `gh pr list --search "harness upgrade in:title" --state open --repo {{REPO_URL}}`. Look at the branch prefix `harness-upgrade/`. If one is already open AND was created within the last 48h (sibling schedule may have just opened it), skip and complete with `"Skipped: sibling harness upgrade PR already open"` + the existing PR URL.\n5. Collect ALL outdated harnesses. If none are outdated, complete with output `"All harnesses up to date as of YYYY-MM-DD"` (no PR).\n6. Branch: `harness-upgrade/weekly-YYYY-MM-DD` (e.g. `harness-upgrade/weekly-2026-06-03`).\n7. Edit `Dockerfile.worker` — bump every outdated ARG. Also update `package.json`:\n   - Codex: bump direct `@openai/codex` to match `CODEX_VERSION`.\n   - Pi family: bump `@earendil-works/pi-agent-core`, `@earendil-works/pi-ai`, and `@earendil-works/pi-coding-agent` to the same new version as `PI_CODING_AGENT_VERSION`.\n   - Opencode: bump `@opencode/sdk` and `@opencode/plugin` (devDependencies) to match `OPENCODE_VERSION`.\n   Then re-run `bun install` so `bun.lock` updates.\n8. Local verification (all must pass before pushing):\n   ```bash\n   bun install --frozen-lockfile\n   bun run lint\n   bun run tsc:check\n   bun test\n   bash scripts/check-db-boundary.sh\n   ```\n   For Codex bumps: also run `bash scripts/check-codex-default-model.sh` (CI runs it too). It fails when `ARG CODEX_VERSION` differs from the direct `@openai/codex` pin in `package.json`, or when the Dockerfile\'s baseline `model = "..."` differs from `CODEX_DEFAULT_MODEL` in `src/providers/codex-models.ts`.\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_db3();
@@ -17236,7 +17402,7 @@ function resolveSeededEnabled(params) {
 }
 
 // templates/workflows/alerts-triage/config.json
-var config_default66 = `{
+var config_default67 = `{
   "kind": "workflow",
   "name": "alerts-triage",
   "displayName": "Alerts Triage",
@@ -17253,7 +17419,7 @@ var config_default66 = `{
 `;
 
 // templates/workflows/alerts-triage/content.md
-var content_default66 = `# Alerts Triage
+var content_default67 = `# Alerts Triage
 
 The Slack handler emits \`slack.message\`; this workflow keeps the event-driven path and deduplicates work after the channel filter.
 
@@ -17273,7 +17439,7 @@ The Slack handler emits \`slack.message\`; this workflow keeps the event-driven
 `;
 
 // templates/workflows/autopilot/config.json
-var config_default67 = `{
+var config_default68 = `{
   "kind": "workflow",
   "name": "autopilot",
   "displayName": "Autopilot Feature Pipeline",
@@ -17290,7 +17456,7 @@ var config_default67 = `{
 `;
 
 // templates/workflows/autopilot/content.md
-var content_default67 = `# Autopilot Feature Pipeline
+var content_default68 = `# Autopilot Feature Pipeline
 
 Template parameter: {{REPO_URL}}
 
@@ -17302,7 +17468,7 @@ Use this workflow as a canonical feature delivery pipeline. Customize roles and
 `;
 
 // templates/workflows/claude-code-changelog-watch/config.json
-var config_default68 = `{
+var config_default69 = `{
   "kind": "workflow",
   "name": "claude-code-changelog-watch",
   "displayName": "Claude Code Changelog Watch",
@@ -17319,10 +17485,10 @@ var config_default68 = `{
 `;
 
 // templates/workflows/claude-code-changelog-watch/content.md
-var content_default68 = '# Claude Code Changelog Watch\n\nThis topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow\'s nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.\n\nPrerequisite: the `check` and `commit` nodes run the global script `claude-code-changelog-check`, which is not seeded. Author it before enabling the workflow, or every run fails at the first node.\n\n```json\n{"name":"claude-code-changelog-watch","description":"Changelog watcher with deduplication: fetch, gate on a new version, publish an in-app receipt plus any configured delivery providers, then commit the version marker.","nodes":[{"id":"check","type":"swarm-script","label":"Fetch changelog + compare vs KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"check"}},"next":"gate"},{"id":"gate","type":"property-match","label":"Gate: only continue on a new version","config":{"mode":"all","conditions":[{"field":"check.result.isNew","op":"eq","value":true}]},"next":{"true":"post"}},{"id":"post","type":"agent-task","label":"Post new version to Slack","config":{"model":"sonnet","tags":["changelog","claude-code","workflow"],"priority":50,"template":"**Claude Code new version announcement**\\n\\nA new Claude Code version was detected by the claude-code-changelog-watch workflow.\\n\\nNew version: {{check.result.latestVersion}} (released {{check.result.releaseDate}}, previous known: {{check.result.lastKnown}})\\n\\nRaw release notes:\\n{{check.result.section}}\\n\\nSteps:\\n1. ONE `slack-post` to the configured Slack notification target, **max 400 chars**:\\n\\n```\\n:rocket: *Claude Code {{check.result.latestVersion}}* — <the one change that matters to us, one line>\\n<https://code.claude.com/docs/en/changelog|changelog>\\n```\\n\\nRules:\\n- **One line.** Pick the single item that affects how we run the swarm (a fix we were hitting, a flag we use, a breaking change). Not 3-5 bullets.\\n- If a second item genuinely matters, one more bullet. Never more than two.\\n- **Routine release with nothing relevant to us ⇒ still post, but the one line is just the headline feature.** Never paste the release notes.\\n- No preamble, no \\"is out!\\", no per-surface breakdown (VSCode/CLI/SDK), no closing line.\\n\\n2. Complete with output \\"Posted Claude Code {{check.result.latestVersion}} to in-app activity and configured delivery providers.\\" plus the charCount.\\n\\nDo NOT update any version state — the workflow\'s commit node handles that after you complete. Do NOT post more than once."},"next":"commit","inputs":{"check":"check"}},{"id":"commit","type":"swarm-script","label":"Commit new version to KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"commit","version":"{{check.result.latestVersion}}"}},"inputs":{"check":"check"}}],"onNodeFailure":"fail"}\n```\n\n\n\n\n';
+var content_default69 = '# Claude Code Changelog Watch\n\nThis topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow\'s nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.\n\nPrerequisite: the `check` and `commit` nodes run the global script `claude-code-changelog-check`, which is not seeded. Author it before enabling the workflow, or every run fails at the first node.\n\n```json\n{"name":"claude-code-changelog-watch","description":"Changelog watcher with deduplication: fetch, gate on a new version, publish an in-app receipt plus any configured delivery providers, then commit the version marker.","nodes":[{"id":"check","type":"swarm-script","label":"Fetch changelog + compare vs KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"check"}},"next":"gate"},{"id":"gate","type":"property-match","label":"Gate: only continue on a new version","config":{"mode":"all","conditions":[{"field":"check.result.isNew","op":"eq","value":true}]},"next":{"true":"post"}},{"id":"post","type":"agent-task","label":"Post new version to Slack","config":{"model":"sonnet","tags":["changelog","claude-code","workflow"],"priority":50,"template":"**Claude Code new version announcement**\\n\\nA new Claude Code version was detected by the claude-code-changelog-watch workflow.\\n\\nNew version: {{check.result.latestVersion}} (released {{check.result.releaseDate}}, previous known: {{check.result.lastKnown}})\\n\\nRaw release notes:\\n{{check.result.section}}\\n\\nSteps:\\n1. ONE `slack-post` to the configured Slack notification target, **max 400 chars**:\\n\\n```\\n:rocket: *Claude Code {{check.result.latestVersion}}* — <the one change that matters to us, one line>\\n<https://code.claude.com/docs/en/changelog|changelog>\\n```\\n\\nRules:\\n- **One line.** Pick the single item that affects how we run the swarm (a fix we were hitting, a flag we use, a breaking change). Not 3-5 bullets.\\n- If a second item genuinely matters, one more bullet. Never more than two.\\n- **Routine release with nothing relevant to us ⇒ still post, but the one line is just the headline feature.** Never paste the release notes.\\n- No preamble, no \\"is out!\\", no per-surface breakdown (VSCode/CLI/SDK), no closing line.\\n\\n2. Complete with output \\"Posted Claude Code {{check.result.latestVersion}} to in-app activity and configured delivery providers.\\" plus the charCount.\\n\\nDo NOT update any version state — the workflow\'s commit node handles that after you complete. Do NOT post more than once."},"next":"commit","inputs":{"check":"check"}},{"id":"commit","type":"swarm-script","label":"Commit new version to KV","config":{"scriptName":"claude-code-changelog-check","scope":"global","args":{"mode":"commit","version":"{{check.result.latestVersion}}"}},"inputs":{"check":"check"}}],"onNodeFailure":"fail"}\n```\n\n\n\n\n';
 
 // templates/workflows/competitor-radar/config.json
-var config_default69 = `{
+var config_default70 = `{
   "kind": "workflow",
   "name": "competitor-radar",
   "displayName": "Competitor Radar",
@@ -17339,7 +17505,7 @@ var config_default69 = `{
 `;
 
 // templates/workflows/competitor-radar/content.md
-var content_default69 = `# Competitor Radar
+var content_default70 = `# Competitor Radar
 
 This self-hosted port retains the scheduled, fixture, extraction, gap-analysis, litmus, cooldown, and bounded-report behavior. Its pinned GSC helper is embedded in the workflow, so it does not fetch executable code from Desplega infrastructure.
 
@@ -17349,7 +17515,7 @@ This self-hosted port retains the scheduled, fixture, extraction, gap-analysis,
 `;
 
 // templates/workflows/docs-site-releases/config.json
-var config_default70 = `{
+var config_default71 = `{
   "kind": "workflow",
   "name": "docs-site-releases",
   "displayName": "Documentation Release Notes",
@@ -17366,7 +17532,7 @@ var config_default70 = `{
 `;
 
 // templates/workflows/docs-site-releases/content.md
-var content_default70 = `# Documentation Release Notes
+var content_default71 = `# Documentation Release Notes
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -17381,7 +17547,7 @@ This topology-preserving self-hosted port removes installation-specific identiti
 `;
 
 // templates/workflows/gsc-topic-miner/config.json
-var config_default71 = `{
+var config_default72 = `{
   "kind": "workflow",
   "name": "gsc-topic-miner",
   "displayName": "Search Topic Miner",
@@ -17398,7 +17564,7 @@ var config_default71 = `{
 `;
 
 // templates/workflows/gsc-topic-miner/content.md
-var content_default71 = `# Search Topic Miner
+var content_default72 = `# Search Topic Miner
 
 This template uses only the configured GSC and agent-fs integrations. The deferred seeder creates the weekly schedule binding; no installation-specific schedule ID is shipped.
 
@@ -17408,7 +17574,7 @@ This template uses only the configured GSC and agent-fs integrations. The deferr
 `;
 
 // templates/workflows/linear-drain-loop/config.json
-var config_default72 = `{
+var config_default73 = `{
   "kind": "workflow",
   "name": "linear-drain-loop",
   "displayName": "Linear Drain Loop",
@@ -17430,7 +17596,7 @@ var config_default72 = `{
 `;
 
 // templates/workflows/linear-drain-loop/content.md
-var content_default72 = `# Linear Drain Loop
+var content_default73 = `# Linear Drain Loop
 
 Template parameter: {{LINEAR_PROJECT_ID}}
 
@@ -17475,7 +17641,7 @@ Blocked and ambiguous items are explicitly left alone — the dispatch node surf
 `;
 
 // templates/workflows/llm-safe-release-context/config.json
-var config_default73 = `{
+var config_default74 = `{
   "kind": "workflow",
   "name": "llm-safe-release-context",
   "displayName": "LLM-Safe Release Context",
@@ -17492,7 +17658,7 @@ var config_default73 = `{
 `;
 
 // templates/workflows/llm-safe-release-context/content.md
-var content_default73 = `# LLM-Safe Release Context
+var content_default74 = `# LLM-Safe Release Context
 
 Template parameters: {{ORG_ID}}, {{REPO_URL}}
 
@@ -17566,7 +17732,7 @@ This avoids the common failure mode where a large \`context.json\` fills the mod
 `;
 
 // templates/workflows/pr-review-status-sweep/config.json
-var config_default74 = `{
+var config_default75 = `{
   "kind": "workflow",
   "name": "pr-review-status-sweep",
   "displayName": "PR Review Status Sweep",
@@ -17583,7 +17749,7 @@ var config_default74 = `{
 `;
 
 // templates/workflows/pr-review-status-sweep/content.md
-var content_default74 = `# PR Review Status Sweep
+var content_default75 = `# PR Review Status Sweep
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -17598,7 +17764,7 @@ Prerequisite: the \`sweep\` node runs the agent-scoped script \`pr-review-status
 `;
 
 // templates/workflows/ralph-loop/config.json
-var config_default75 = `{
+var config_default76 = `{
   "kind": "workflow",
   "name": "ralph-loop",
   "displayName": "Iterative Review Loop",
@@ -17615,7 +17781,7 @@ var config_default75 = `{
 `;
 
 // templates/workflows/ralph-loop/content.md
-var content_default75 = `# Iterative Review Loop
+var content_default76 = `# Iterative Review Loop
 
 Template parameter: {{REPO_URL}}
 
@@ -17666,19 +17832,19 @@ The \`maxIterations\` parameter is declarative: the reviewer signals PASS when d
 init_db3();
 var asText2 = (value) => value;
 var BUILT_IN_WORKFLOW_SOURCES = [
-  { config: asText2(config_default66), content: asText2(content_default66) },
   { config: asText2(config_default67), content: asText2(content_default67) },
+  { config: asText2(config_default68), content: asText2(content_default68) },
   {
-    config: asText2(config_default68),
-    content: asText2(content_default68)
+    config: asText2(config_default69),
+    content: asText2(content_default69)
   },
-  { config: asText2(config_default69), content: asText2(content_default69) },
   { config: asText2(config_default70), content: asText2(content_default70) },
   { config: asText2(config_default71), content: asText2(content_default71) },
   { config: asText2(config_default72), content: asText2(content_default72) },
   { config: asText2(config_default73), content: asText2(content_default73) },
   { config: asText2(config_default74), content: asText2(content_default74) },
-  { config: asText2(config_default75), content: asText2(content_default75) }
+  { config: asText2(config_default75), content: asText2(content_default75) },
+  { config: asText2(config_default76), content: asText2(content_default76) }
 ];
 function sortJson(value) {
   if (Array.isArray(value))
@@ -17794,34 +17960,34 @@ var workflowsSeeder = createWorkflowsSeeder();
 // src/be/seed/schedules-seeder.ts
 var asText3 = (value) => value;
 var BUILT_IN_SCHEDULE_SOURCES = [
-  { config: asText3(config_default55), content: asText3(content_default55) },
+  { config: asText3(config_default56), content: asText3(content_default56) },
   {
-    config: asText3(config_default56),
-    content: asText3(content_default56)
+    config: asText3(config_default57),
+    content: asText3(content_default57)
   },
-  { config: asText3(config_default57), content: asText3(content_default57) },
   { config: asText3(config_default58), content: asText3(content_default58) },
-  {
-    config: asText3(config_default59),
-    content: asText3(content_default59)
-  },
+  { config: asText3(config_default59), content: asText3(content_default59) },
   {
     config: asText3(config_default60),
     content: asText3(content_default60)
   },
-  { config: asText3(config_default61), content: asText3(content_default61) },
   {
-    config: asText3(config_default62),
-    content: asText3(content_default62)
+    config: asText3(config_default61),
+    content: asText3(content_default61)
   },
+  { config: asText3(config_default62), content: asText3(content_default62) },
   {
     config: asText3(config_default63),
     content: asText3(content_default63)
   },
-  { config: asText3(config_default64), content: asText3(content_default64) },
   {
-    config: asText3(config_default65),
-    content: asText3(content_default65)
+    config: asText3(config_default64),
+    content: asText3(content_default64)
+  },
+  { config: asText3(config_default65), content: asText3(content_default65) },
+  {
+    config: asText3(config_default66),
+    content: asText3(content_default66)
   }
 ];
 function parseScheduleSource(source) {