@desplega.ai/agent-swarm 1.152.2 → 1.154.0

package/dist/{index-tfsdxyv6.js → index-j5wrf1yw.js}

@@ -6,21 +6,21 @@ import {
   extractArgsJsonSchema,
   extractScriptSignature,
   typecheckScript
-} from "./cli-wpv5rgg2.js";
+} from "./cli-abp3g4ax.js";
 import {
   getScript,
   require_dist,
   upsertScriptByName,
   validateDefinition,
   validateScriptImports
-} from "./cli-fmy65jdn.js";
+} from "./cli-pf1v8xhb.js";
 import"./cli-epan13p1.js";
 import"./cli-y89t4nca.js";
 import"./cli-f14fvzag.js";
-import"./cli-56h18ng2.js";
-import"./cli-gpqcs935.js";
-import"./cli-jew3jda5.js";
-import"./cli-fm4ytsdk.js";
+import"./cli-n62atwh9.js";
+import"./cli-e3cyf59d.js";
+import"./cli-hws0vn86.js";
+import"./cli-g2h29qar.js";
 import"./cli-aehm1rbq.js";
 import"./cli-2658f6at.js";
 import {
@@ -39,15 +39,17 @@ import {
   updateSkill,
   updateWorkflow,
   upsertSkillFiles
-} from "./cli-zvgj5zg8.js";
-import"./cli-ht5rs63n.js";
-import"./cli-z61ykvam.js";
+} from "./cli-ge67p080.js";
+import"./cli-4k7jazkq.js";
+import"./cli-0e31nm4n.js";
+import"./cli-wg04s9kr.js";
+import"./cli-v4en75c5.js";
 import"./cli-dv6cdjs2.js";
-import"./cli-c2mk1kgf.js";
+import"./cli-n7h1kqpf.js";
 import"./cli-ej6gbxfb.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-zvkq5csn.js";
+import"./cli-myaxtgh8.js";
 import"./cli-r2ap2czm.js";
 import"./cli-zf8jjwex.js";
 import {
@@ -10541,7 +10543,7 @@ var config_default41 = `{
 `;
 
 // templates/skills/swarm-extensions/content.md
-var content_default41 = "# Swarm Extensions\n\nAn 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.\n\nDo not use an extension for work that one task, one script, or one schedule can do.\n\n## Tools\n\n`extension-install` and `extension-list`. They are deferred. Load them with your harness tool search before the first call.\n\n`extension-install` validates the bundle (manifest, imports, typecheck against the hook contract) and stores it. Only a lead agent, an operator, or a dashboard user may install. A worker gets `Forbidden` from the tool. When you are a worker, write and validate the bundle, then hand it to your lead with `send-task` (include the manifest, the hooks file, and the config) and report that in your output. Do not call the REST install route with the shared API key to get around the role check. The stored extension stays disabled. An operator enables it from the dashboard (Settings, Extensions) or with `POST /api/extensions/{id}/enable`. Say this in your task report and give the extension name.\n\nInstalling a bundle with the same name and changed files stores a new version. The active version does not change until an operator activates it.\n\n## Get the contract before you write hooks\n\nFetch the generated type definitions and read them. Do not guess event names or field names.\n\n```bash\ncurl -s \"$MCP_BASE_URL/api/extensions/type-defs\" \\\n  -H \"X-Agent-ID: $AGENT_ID\" -H \"Authorization: Bearer ${AGENT_SWARM_API_KEY:-$API_KEY}\"\n```\n\n`$MCP_BASE_URL`, `$AGENT_ID`, and `$AGENT_SWARM_API_KEY` (or `$API_KEY`) are in every worker environment. The response is the `swarm-extension` module declaration: every event, its payload, and what a `modify` result may change.\n\n## Events\n\n| Event | When | Result |\n|---|---|---|\n| `pre.task.create` | before any task is stored (REST, MCP, Slack, schedule, workflow, webhook, follow-up) | `block(reason)`, `modify({ priority, agentId, tags, description, ... })`, or nothing |\n| `pre.task.followUp` | before the lead follow-up task for a finished worker task | `block`, `modify({ description, priority, agentId })`, or nothing |\n| `pre.slack.route` | before a Slack message becomes a task | `modify({ target: { kind: \"agent\", agentId } })`, `{ kind: \"lead\" }`, `{ kind: \"broadcast\" }` |\n| `pre.heartbeat.remediate` | after the heartbeat sweep finds a stalled task | `modify({ proposedAction: \"record\" | \"fail\" | \"supersede-resume\" })` |\n| `pre.tool.call` | before an agent MCP tool call runs | `block(reason)` or `modify({ args })` |\n| `post.task.created`, `post.task.completed`, `post.task.failed`, `post.task.cancelled`, `post.task.superseded`, `post.task.progress` | after the change is committed | none |\n| `post.slack.message`, `post.tool.call` | after the message or tool call finished | none |\n\n`event.origin` on `pre.task.create` tells where the task comes from: `rest`, `app`, `mcp`, `slack`, `schedule`, `workflow`, `webhook`, `followUp`, or `extension:<name>`.\n\n## Bundle shape\n\nThe bundle is a manifest plus a files map. Version 1 accepts one file, the `assets.hooks` TypeScript file, and only `runtime: \"api\"`.\n\n```json\n{\n  \"manifest\": {\n    \"name\": \"require-ticket-ref\",\n    \"description\": \"Blocks REST and MCP tasks that do not name a ticket\",\n    \"version\": \"1.0.0\",\n    \"runtime\": \"api\",\n    \"assets\": { \"hooks\": \"hooks.ts\" }\n  },\n  \"files\": { \"hooks.ts\": \"<file content>\" },\n  \"config\": { \"pattern\": \"DES-\\\\d+\" }\n}\n```\n\nRules for `hooks.ts`:\n\n- Import only from `swarm-extension`, `zod`, and `stdlib`. Relative imports, other packages, and dynamic imports are rejected.\n- Export the extension as `default`. Export `config` (a Zod schema) when the extension takes configuration. The install validates `config` against it.\n- Return `block(reason)` or `modify(data)` from pre hooks. Return nothing to continue.\n- Keep handlers fast. A handler is cancelled after 5 seconds. Five consecutive failures auto-disable the extension.\n- Handlers run outside database transactions and must not assume ordering with other extensions. Use `priority` in `api.on(event, handler, { priority })` when order matters (lower runs first).\n\n## Minimal hooks file\n\n```ts\nimport { block, modify, type SwarmExtension } from \"swarm-extension\";\nimport { z } from \"zod\";\n\nexport const config = z.object({ pattern: z.string().default(\"DES-\\\\d+\") });\n\nconst manifest = {\n  name: \"require-ticket-ref\",\n  description: \"Blocks REST and MCP tasks that do not name a ticket\",\n  version: \"1.0.0\",\n  runtime: \"api\",\n  assets: { hooks: \"hooks.ts\" },\n  config,\n} as const;\n\nconst extension: SwarmExtension<typeof manifest> = (api) => {\n  api.on(\"pre.task.create\", (event, ctx) => {\n    if (event.origin !== \"rest\" && event.origin !== \"mcp\") return;\n    if (new RegExp(ctx.config.pattern).test(event.description)) return;\n    return block(`Task must reference a ticket matching ${ctx.config.pattern}`);\n  });\n\n  api.on(\"post.task.completed\", async (event, ctx) => {\n    await ctx.state.incr(\"completed\");\n    ctx.log.info(\"task completed\", { id: event.task.id });\n  });\n};\n\nexport default extension;\n```\n\n## Context (`ctx`)\n\n- `ctx.config`: the validated configuration.\n- `ctx.state`: per-extension key-value store (`get`, `set`, `incr`, `del`).\n- `ctx.swarm`: the swarm SDK. Call any script-exposed tool by name with underscores, for example `await ctx.swarm.slack_post({ channelId, message })` or `await ctx.swarm.task_send({ ... })`. Calls made from a hook carry the `ext:<name>` identity, which has lead privileges while the extension is enabled. Calls resolve with `{ success, status, data }` and do not throw on a tool error. Check `success` and throw when the hook must fail. The type definitions import `SwarmSdk` from `swarm-sdk`. Call the `script-query-types` tool (or `GET /api/scripts/type-defs`) to get `swarm-sdk.d.ts` with every method name and argument type before you use `ctx.swarm`.\n- `ctx.log`: structured logger. Entries appear in the extension run log on the dashboard.\n- `ctx.signal`: abort signal for the 5-second cap.\n\n## Verify\n\n1. Call `extension-list` and confirm the name, version, and `enabled: false`.\n2. Report the enable step. After an operator enables it, the dashboard run log shows every dispatch with its result (`continue`, `modify`, `block`, or `error`).\n3. Trigger the event once and confirm the effect (for example, a blocked REST task returns HTTP 422 with your reason).\n\n## Common mistakes\n\n- Guessing event names. Fetch the type definitions.\n- Using `import` from a package other than `swarm-extension`, `zod`, or `stdlib`.\n- Returning a plain object instead of `block(...)` or `modify(...)`.\n- Modifying fields the event does not allow. Read the `*Modify` type for that event.\n- Expecting the extension to run after install. It runs only after an operator enables it.\n- Blocking tasks from every origin. Check `event.origin` so schedules, workflows, and follow-ups keep working unless you mean to block them.\n";
+var content_default41 = "# Swarm Extensions\n\nAn 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.\n\nDo not use an extension for work that one task, one script, or one schedule can do.\n\n## Tools\n\n`extension-install` and `extension-list`. They are deferred. Load them with your harness tool search before the first call.\n\n`extension-install` validates the bundle (manifest, imports, typecheck against the hook contract) and stores it. Any authenticated agent, including a worker, can install a new bundle. Your agent is recorded as its owner in `createdByAgentId`; `extension-list` exposes that field. Always send your `X-Agent-ID` when using REST so ownership is attributed to you.\n\nWorkers may install subsequent versions only for their own extensions, and PATCH or DELETE their own disabled drafts. Ownership stays with the original creator; each version records its writer as `changedByAgentId`. Leads, operators, and dashboard users retain access to all bundles.\n\nA new install is disabled and inert. A lead, operator, or dashboard user must enable it with `extension-enable` or `POST /api/extensions/{id}/enable`. Workers cannot enable, disable, or activate versions. Report the extension name and the required activation step.\n\nInstalling changed files under your existing name stages a new version without activating it. Workers may stage code-only updates while an extension is enabled, but cannot PATCH or change its live config/priority. Ask a lead or operator to make those changes. `EXTENSION_ALLOW_LEAD_ACTIVATION=false` restricts activation to operators/dashboard users.\n\n## Get the contract before you write hooks\n\nFetch the generated type definitions and read them. Do not guess event names or field names.\n\n```bash\ncurl -s \"$MCP_BASE_URL/api/extensions/type-defs\" \\\n  -H \"X-Agent-ID: $AGENT_ID\" -H \"Authorization: Bearer ${AGENT_SWARM_API_KEY:-$API_KEY}\"\n```\n\n`$MCP_BASE_URL`, `$AGENT_ID`, and `$AGENT_SWARM_API_KEY` (or `$API_KEY`) are in every worker environment. The response is the `swarm-extension` module declaration: every event, its payload, and what a `modify` result may change.\n\n## Events\n\n| Event | When | Result |\n|---|---|---|\n| `pre.task.create` | before any task is stored (REST, MCP, Slack, schedule, workflow, webhook, follow-up) | `block(reason)`, `modify({ priority, agentId, tags, description, ... })`, or nothing |\n| `pre.task.followUp` | before the lead follow-up task for a finished worker task | `block`, `modify({ description, priority, agentId })`, or nothing |\n| `pre.slack.route` | before a Slack message becomes a task | `modify({ target: { kind: \"agent\", agentId } })`, `{ kind: \"lead\" }`, `{ kind: \"broadcast\" }` |\n| `pre.heartbeat.remediate` | after the heartbeat sweep finds a stalled task | `modify({ proposedAction: \"record\" | \"fail\" | \"supersede-resume\" })` |\n| `pre.tool.call` | before an agent MCP tool call runs | `block(reason)` or `modify({ args })` |\n| `post.task.created`, `post.task.completed`, `post.task.failed`, `post.task.cancelled`, `post.task.superseded`, `post.task.progress` | after the change is committed | none |\n| `post.slack.message`, `post.tool.call` | after the message or tool call finished | none |\n\n`event.origin` on `pre.task.create` tells where the task comes from: `rest`, `app`, `mcp`, `slack`, `schedule`, `workflow`, `webhook`, `followUp`, or `extension:<name>`.\n\n## Bundle shape\n\nThe bundle is a manifest plus a files map. Version 1 accepts one file, the `assets.hooks` TypeScript file, and only `runtime: \"api\"`.\n\n```json\n{\n  \"manifest\": {\n    \"name\": \"require-ticket-ref\",\n    \"description\": \"Blocks REST and MCP tasks that do not name a ticket\",\n    \"version\": \"1.0.0\",\n    \"runtime\": \"api\",\n    \"assets\": { \"hooks\": \"hooks.ts\" }\n  },\n  \"files\": { \"hooks.ts\": \"<file content>\" },\n  \"config\": { \"pattern\": \"DES-\\\\d+\" }\n}\n```\n\nRules for `hooks.ts`:\n\n- Import only from `swarm-extension`, `zod`, and `stdlib`. Relative imports, other packages, and dynamic imports are rejected.\n- Export the extension as `default`. Export `config` (a Zod schema) when the extension takes configuration. Activation validates `config` against it.\n- Return `block(reason)` or `modify(data)` from pre hooks. Return nothing to continue.\n- Keep handlers fast. A handler is cancelled after 5 seconds. Five consecutive failures auto-disable the extension.\n- Handlers run outside database transactions and must not assume ordering with other extensions. Use `priority` in `api.on(event, handler, { priority })` when order matters (lower runs first).\n\n## Minimal hooks file\n\n```ts\nimport { block, modify, type SwarmExtension } from \"swarm-extension\";\nimport { z } from \"zod\";\n\nexport const config = z.object({ pattern: z.string().default(\"DES-\\\\d+\") });\n\nconst manifest = {\n  name: \"require-ticket-ref\",\n  description: \"Blocks REST and MCP tasks that do not name a ticket\",\n  version: \"1.0.0\",\n  runtime: \"api\",\n  assets: { hooks: \"hooks.ts\" },\n  config,\n} as const;\n\nconst extension: SwarmExtension<typeof manifest> = (api) => {\n  api.on(\"pre.task.create\", (event, ctx) => {\n    if (event.origin !== \"rest\" && event.origin !== \"mcp\") return;\n    if (new RegExp(ctx.config.pattern).test(event.description)) return;\n    return block(`Task must reference a ticket matching ${ctx.config.pattern}`);\n  });\n\n  api.on(\"post.task.completed\", async (event, ctx) => {\n    await ctx.state.incr(\"completed\");\n    ctx.log.info(\"task completed\", { id: event.task.id });\n  });\n};\n\nexport default extension;\n```\n\n## Context (`ctx`)\n\n- `ctx.config`: the validated configuration.\n- `ctx.state`: per-extension key-value store (`get`, `set`, `incr`, `del`).\n- `ctx.swarm`: the swarm SDK. Call any script-exposed tool by name with underscores, for example `await ctx.swarm.slack_post({ channelId, message })` or `await ctx.swarm.task_send({ ... })`. Calls made from a hook carry the `ext:<name>` identity, which has lead privileges while the extension is enabled. Calls resolve with `{ success, status, data }` and do not throw on a tool error. Check `success` and throw when the hook must fail. The type definitions import `SwarmSdk` from `swarm-sdk`. Call the `script-query-types` tool (or `GET /api/scripts/type-defs`) to get `swarm-sdk.d.ts` with every method name and argument type before you use `ctx.swarm`.\n- `ctx.log`: structured logger. Entries appear in the extension run log on the dashboard.\n- `ctx.signal`: abort signal for the 5-second cap.\n\n## Verify\n\n1. Call `extension-list` and confirm the name, version, and `enabled: false`.\n2. Report the enable step. After a lead or operator enables it, the dashboard run log shows every dispatch with its result (`continue`, `modify`, `block`, or `error`).\n3. Trigger the event once and confirm the effect (for example, a blocked REST task returns HTTP 422 with your reason).\n\n## Common mistakes\n\n- Guessing event names. Fetch the type definitions.\n- Using `import` from a package other than `swarm-extension`, `zod`, or `stdlib`.\n- Returning a plain object instead of `block(...)` or `modify(...)`.\n- Modifying fields the event does not allow. Read the `*Modify` type for that event.\n- Expecting the extension to run after install. It runs only after a lead or operator enables it.\n- Blocking tasks from every origin. Check `event.origin` so schedules, workflows, and follow-ups keep working unless you mean to block them.\n";
 
 // templates/skills/swarm-scripts/config.json
 var config_default42 = `{
@@ -15451,29 +15453,42 @@ Use the setup milestone data already retrieved from \`/status\`. Report only int
 
 ---
 
-## Phase 2: Post one digest
+## Phase 2: Post one digest — EXCEPTION-ONLY, HARD CEILING 600 CHARACTERS
 
-Post to your configured admin channel (or the in-app fallback if none is configured). Keep it to one message; omit any section with nothing to report.
+Operator feedback, 2026-09-23, verbatim: "too verbose every day". Brevity is a requirement of this job, not a preference. Count the characters before posting; over 600 ⇒ cut until it fits. A long report is a failed run, not a thorough one.
 
-\`\`\`
-📊 Daily Status Report — [date]
+Post ONE message to your configured admin channel (in-app fallback if none configured).
 
-Waiting on you: [N] needs_setup automations — [name: missing parameters/integrations → fix URL].
+**Everything healthy ⇒ exactly this one line, nothing else:**
 
-Workflows: [X] enabled / [Y] total. [N] hard failures, [M] halted >24h in the last 24h.
-Schedules: [X] enabled / [Y] total. [N] hard failures, [M] didn't fire on time, [K] with ≥3 consecutive errors.
-Agents: [X] online / [Y] total. [names of any agent at/over capacity]. [N] agent-attributed failures in 7d.
-Task failures (7d): [N] needs_setup · [N] gate-refusal · [N] infra · [N] real-defect · [N] unclassified (no reason set).
-Integration setup: [missing credentials from /status], or all verified.
 \`\`\`
+📊 <MM-DD> — all clear. Workflows <X>/<Y> · schedules <X>/<Y> · agents <X>/<Y> · <N> failures 7d, <N> real defects. Nothing for you.
+\`\`\`
+
+**Add a line ONLY for something both TRUE and ACTIONABLE. Max 3 lines, one sentence each, no sub-bullets:**
+- an automation in \`needs_setup\` or an unverified integration — name + \`fixUrl\`
+- a workflow run halted >24h (Phase 1B)
+- a real defect, or a failure cluster on one agent / schedule / provider
+- a decision only the operator can make — state the options, end on the question
+
+More than 3 qualify ⇒ post the 3 that matter and put the rest in the task output.
+
+**NEVER in the Slack post** — all of this belongs in \`store-progress\` output, where the audit trail lives:
+- row counts and "read-only report" notes
+- methodology, query names, script names, phase narration
+- any zero ("0 halted", "all verified", "no data-quality gap") — silence means zero
+- week-over-week trend, unless a class crossed a threshold you name in the same line
+- a finding yesterday's report already carried unchanged
+- numbered explainers or paragraphs of reasoning
 
 ## Phase 3: Complete
-\`store-progress\` with \`status: "completed"\` and an output paragraph naming the counts above and the Slack message ts (if posted).
+\`store-progress\` with \`status: "completed"\`. **This is where the detail goes** — every count from Phase 1, the per-class failure breakdown, and the Slack message ts. The Slack post is the headline; the task output is the record. Cutting the post does not mean cutting the work.
 
 ## Anti-patterns
 - ❌ Modifying anything — this schedule reports, it doesn't fix (that's \`daily-workflow-health-audit\` for plumbing and \`daily-compounding-reflection\` for agent/skill/memory evolution).
 - ❌ Folding the unclassified-failure bucket into "real defect" to make the number look more actionable than it is.
-- ❌ Omitting the Waiting on you section — say explicitly when no automation is in \`needs_setup\` and all integrations are verified.
+- ❌ Narrating a zero. The all-clear line already covers \`needs_setup\` and integrations; only a non-verified integration or a real \`needs_setup\` automation earns its own line.
+- ❌ Exceeding 600 characters, or posting more than one message.
 `;
 
 // templates/schedules/daily-swarm-update-check/config.json
@@ -15745,7 +15760,7 @@ Otherwise:
 • schedule:<name> — consecutiveErrors=<n>, last error: <lastErrSnippet>
 \`\`\`
 
-Omit any section whose count is 0. Cap message at 4000 chars (Slack limit) — if longer, keep top 5 per section and add \`…and <K> more\` lines.
+Omit any section whose count is 0. **HARD CEILING 700 characters — not the 4000-char Slack limit.** (Operator feedback, 2026-09-23: "too verbose every day".) Keep at most the top 3 items across ALL sections combined, one line each; everything else goes in the \`store-progress\` output, not the post. Over 700 chars ⇒ cut until it fits. A long digest is a failed run, not a thorough one.
 
 ---