@desplega.ai/agent-swarm 1.152.2 → 1.153.0

package/src/utils/context-window.ts

@@ -29,6 +29,7 @@ const CONTEXT_WINDOW_DEFAULTS: Record<string, number> = {
   // Anthropic Fable / Mythos tier
   "claude-fable-5-1": 1_000_000,
   "claude-mythos-5-1": 1_000_000,
+  "claude-opus-5-5": 1_000_000,
   "claude-opus-5": 1_000_000,
   "claude-fable-5": 1_000_000,
   "claude-mythos-5": 1_000_000,

package/src/utils/credentials.ts

@@ -8,6 +8,7 @@ export const CREDENTIAL_POOL_VARS = [
   "OPENAI_API_KEY",
   "CODEX_OAUTH",
   "DEVIN_API_KEY",
+  "DEEPSEEK_API_KEY",
 ] as const;
 
 /**
@@ -26,6 +27,7 @@ export const PROVIDER_CREDENTIAL_VARS: Record<string, readonly string[]> = {
   pi: ["OPENROUTER_API_KEY", "ANTHROPIC_API_KEY", "OPENAI_API_KEY"],
   codex: ["OPENAI_API_KEY", "CODEX_OAUTH"],
   devin: ["DEVIN_API_KEY"],
+  dsh: ["OPENROUTER_API_KEY", "DEEPSEEK_API_KEY"],
   opencode: ["OPENROUTER_API_KEY", "ANTHROPIC_API_KEY", "OPENAI_API_KEY"],
 };
 
@@ -57,6 +59,10 @@ const SLASH_MODEL_PROVIDERS = new Set(["opencode", "pi"]);
 export function getModelAwareCredentialVars(provider: string, model?: string): readonly string[] {
   const base = PROVIDER_CREDENTIAL_VARS[provider];
   if (!base) return CREDENTIAL_POOL_VARS;
+  // dsh has exact prefix routing; the generic slash rule only filters OpenAI keys.
+  if (provider === "dsh" && model) {
+    return model.startsWith("openrouter/") ? ["OPENROUTER_API_KEY"] : ["DEEPSEEK_API_KEY"];
+  }
   if (!SLASH_MODEL_PROVIDERS.has(provider) || !model) return base;
   if (model.includes("/")) {
     return base.filter((v) => v !== "OPENAI_API_KEY");
@@ -82,6 +88,8 @@ export function deriveProviderFromKeyType(keyType: string): string {
     case "OPENAI_API_KEY":
     case "CODEX_OAUTH":
       return "codex";
+    case "DEEPSEEK_API_KEY":
+      return "dsh";
     case "DEVIN_API_KEY":
       return "devin";
     default:

package/src/utils/internal-ai/complete-structured.ts

@@ -284,6 +284,14 @@ export async function completeStructured<TZod extends z.ZodTypeAny>(
     return null;
   }
 
+  // Dynamic IDs can be absent even though the typed catalog overload is non-nullable.
+  if (!model) {
+    console.error(
+      scrubSecrets(`internal-ai: unknown model ${provider}/${modelId} (callerTag=${callerTag})`),
+    );
+    return null;
+  }
+
   // The builtin catalog hardcodes openrouter.ai; OPENROUTER_BASE_URL reroutes
   // through a gateway (pi-ai's stream path uses `model.baseUrl` verbatim).
   // Resolved from the caller's session env when provided — swarm_config

package/src/utils/internal-ai/models.ts

@@ -17,10 +17,10 @@ export type CredentialKind = "openrouter" | "anthropic" | "openai" | "openai-cod
  * shellout, not pi-ai's `getModel`.
  */
 export const DEFAULT_MODEL: Record<CredentialKind, string> = {
-  openrouter: "openrouter/google/gemini-3-flash-preview",
+  openrouter: "openrouter/deepseek/deepseek-v4.1-flash",
   anthropic: "anthropic/claude-haiku-4-5",
-  openai: "openai/gpt-5.4-mini",
-  "openai-codex": "openai-codex/gpt-5.4-mini",
+  openai: "openai/gpt-6-luna",
+  "openai-codex": "openai-codex/gpt-6-luna",
   "claude-cli": "haiku",
 };
 
@@ -35,8 +35,8 @@ export function resolveModelString(kind: CredentialKind): string {
 
 /**
  * Split a `provider/model-id` string on the FIRST `/` so that OpenRouter
- * compound IDs like `openrouter/google/gemini-3-flash-preview` parse as
- * `("openrouter", "google/gemini-3-flash-preview")`. Mirrors the existing
+ * compound IDs like `openrouter/deepseek/deepseek-v4.1-flash` parse as
+ * `("openrouter", "deepseek/deepseek-v4.1-flash")`. Mirrors the existing
  * convention in `src/providers/pi-mono-adapter.ts:161-170`.
  */
 export function parseModelStr(modelStr: string): [provider: string, modelId: string] {

package/templates/schedules/daily-status-report/content.md

@@ -55,26 +55,39 @@ Use the setup milestone data already retrieved from `/status`. Report only integ
 
 ---
 
-## 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.

package/templates/schedules/daily-workflow-health-audit/content.md

@@ -170,7 +170,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.
 
 ---
 

package/templates/skills/swarm-extensions/content.md

@@ -8,9 +8,13 @@ Do not use an extension for work that one task, one script, or one schedule can
 
 `extension-install` and `extension-list`. They are deferred. Load them with your harness tool search before the first call.
 
-`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.
+`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.
 
-Installing a bundle with the same name and changed files stores a new version. The active version does not change until an operator activates it.
+Workers 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.
+
+A 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.
+
+Installing 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.
 
 ## Get the contract before you write hooks
 
@@ -58,7 +62,7 @@ The bundle is a manifest plus a files map. Version 1 accepts one file, the `asse
 Rules for `hooks.ts`:
 
 - Import only from `swarm-extension`, `zod`, and `stdlib`. Relative imports, other packages, and dynamic imports are rejected.
-- Export the extension as `default`. Export `config` (a Zod schema) when the extension takes configuration. The install validates `config` against it.
+- Export the extension as `default`. Export `config` (a Zod schema) when the extension takes configuration. Activation validates `config` against it.
 - Return `block(reason)` or `modify(data)` from pre hooks. Return nothing to continue.
 - Keep handlers fast. A handler is cancelled after 5 seconds. Five consecutive failures auto-disable the extension.
 - 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).
@@ -107,7 +111,7 @@ export default extension;
 ## Verify
 
 1. Call `extension-list` and confirm the name, version, and `enabled: false`.
-2. Report the enable step. After an operator enables it, the dashboard run log shows every dispatch with its result (`continue`, `modify`, `block`, or `error`).
+2. 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`).
 3. Trigger the event once and confirm the effect (for example, a blocked REST task returns HTTP 422 with your reason).
 
 ## Common mistakes
@@ -116,5 +120,5 @@ export default extension;
 - Using `import` from a package other than `swarm-extension`, `zod`, or `stdlib`.
 - Returning a plain object instead of `block(...)` or `modify(...)`.
 - Modifying fields the event does not allow. Read the `*Modify` type for that event.
-- Expecting the extension to run after install. It runs only after an operator enables it.
+- Expecting the extension to run after install. It runs only after a lead or operator enables it.
 - Blocking tasks from every origin. Check `event.origin` so schedules, workflows, and follow-ups keep working unless you mean to block them.