What's Changed

• fix: command/shell throws on non-zero exit codes (#615)

Summary

Fixes #614 — workflows reported "succeeded" even when shell commands failed (e.g., nvidia-smi: command not found).

Problem

command/shell captured exit codes as data but never threw on non-zero values. The workflow engine determines step success by whether the method throws, so every shell step was treated as successful regardless of the command's actual outcome.

Why this approach

The simplest correct fix is to make command/shell throw before writing any data when the exit code is non-zero:

• Throw before data writes — failed commands should not persist incorrect or misleading result data. If the command failed, there's nothing useful to store as a "result".
• No engine changes needed — the existing workflow engine try/catch chains already handle stepRun.fail(), allowFailure, and error logging. Making the model throw is the standard convention for signaling failure.
• ignoreExitCode opt-out — an optional ignoreExitCode: true attribute is available for definitions where non-zero exits are expected and the caller wants data persisted regardless.

Changes

• src/domain/models/command/shell/shell_model.ts — Added ignoreExitCode (optional boolean) to ShellInputAttributesSchema. Throws Error before writeResource/createFileWriter when exit code is non-zero and ignoreExitCode is not set.
• src/domain/models/command/shell/shell_model_test.ts — Updated 4 tests to expect assertRejects, added 3 new tests (ignoreExitCode suppression, exit 0 normal return, no data on failure).
• integration/keeb_shell_model_test.ts — Updated failing-command test to expect CLI exit code 1.
• integration/workflow_new_architecture_test.ts — Fixed 15 model definitions that used invalid shell commands (bare strings like "Hello from model" instead of "echo 'Hello from model'"). These were silently failing before but passing because exit codes were swallowed.
• integration/input_override_validation_test.ts — Fixed CEL expression test input to be a valid shell command.
• Skill docs (SKILL.md, references/api.md, references/examples.md) — Added error handling guidance establishing the convention: check for failure first, throw before writing data, only persist data on success.

User impact

• Breaking change for workflows using command/shell with commands that exit non-zero. These workflows will now correctly report as failed instead of falsely succeeding.
• Opt-out available: Add ignoreExitCode: true to any shell model definition that intentionally uses commands with non-zero exit codes.
• allowFailure: true on workflow steps continues to work — the engine catches the exception and allows the workflow to proceed.

Test Plan

• deno check — passes
• deno lint — passes
• deno fmt — passes
• deno run test — 2692 passed, 0 failed
• deno run compile — binary compiles

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.174423.0-sha.791ef0b9/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.174423.0-sha.791ef0b9/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.174423.0-sha.791ef0b9/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.174423.0-sha.791ef0b9/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: update AWS SDK and Azure deps to resolve vulnerabilities (#616)

Summary

• Update @aws-sdk/client-cloudcontrol and @aws-sdk/client-secrets-manager from 3.993.0 → 3.1002.0
• Update @azure/identity from 4.8.0 → 4.13.0 and @azure/keyvault-secrets from 4.9.0 → 4.10.0

Vulnerabilities Fixed

• GHSA-fj3w-jwp8-x2g3 (Low severity): fast-xml-parser stack overflow DoS via @aws-sdk/client-cloudcontrol → fast-xml-parser@5.3.6. Fixed in fast-xml-parser@5.3.8+, pulled in by the AWS SDK update.
• GHSA-869p-cjfg-cm3x (High severity): jws HMAC signature verification flaw via @azure/identity → @azure/msal-node → jsonwebtoken@9.0.2 → jws@3.2.2. The Azure update resolves jsonwebtoken to 9.0.3 which depends on jws@^4.0.1 (patched).

Test plan

• deno check passes
• deno run test — all 2689 tests pass
• scripts/audit_deps.ts reports no known vulnerabilities after update

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.173959.0-sha.791ef0b9/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.173959.0-sha.791ef0b9/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.173959.0-sha.791ef0b9/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.173959.0-sha.791ef0b9/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: add rules preventing AI agents from generating UUIDs (#613)

Summary

• Added "CRITICAL: Creation Rules" sections to workflow, model, and vault skills explicitly prohibiting manual UUID generation (uuidgen, crypto.randomUUID(), etc.)
• Replaced all fake placeholder IDs (abc-123, run-456, def-456, ghi-789, jkl-012, output-789, data-789, etc.) with valid UUIDs across all skill files and references
• Removed duplicate "Never modify the id field" lines from Edit sections (now covered by the top-level rules)

Fixes #612

Test plan

• deno fmt passes
• deno lint passes
• deno run test passes (2689 tests, 0 failures)
• Verified no fake IDs remain via grep sweep

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.154608.0-sha.745c2449/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.154608.0-sha.745c2449/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.154608.0-sha.745c2449/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.154608.0-sha.745c2449/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: externalize all npm packages in extension bundler (#611)

Fixes #609

Summary

• Replace --external npm:zod@4 --external npm:zod with --external npm:* in the extension bundler so all npm packages are externalized
• Update docs and skill references to reflect the new bundling behavior

Problem

When extensions import npm packages like @aws-sdk/client-s3 that transitively depend on tslib (a CJS module), deno bundle inlines the package and wraps the CJS code in a __toESM bridge. This bridge produces import_tslib.default === undefined, causing runtime destructuring failures:

Cannot destructure property '__extends' of 'import_tslib.default' as it is undefined.

Fix

Use --external npm:* to externalize all npm packages. They are left as npm: specifiers in the bundled output and resolved at runtime by Deno's native npm resolver, which handles CJS/ESM interop correctly.

Why --external npm:* and not --packages external

The original plan was to use --packages external, which is documented in deno bundle --help. However, testing on deno 2.6.8 showed it does not actually externalize npm packages — it silently inlines everything (510KB bundle for a file that only imports zod). The --external npm:* wildcard flag achieves the intended behavior and actually works.

Why JSR imports are unaffected

--external npm:* only targets npm packages. JSR (jsr:) and HTTPS imports are still bundled and inlined. This is correct because:

• JSR packages are native ESM — they don't have CJS interop issues
• JSR packages don't need instance sharing — unlike zod, there's no instanceof concern
• They're self-contained — inlining them keeps bundles portable

What this means for extension bundles

npm packages are cached by deno bundle during bundling and reused at runtime — no extra download step.

Test plan

• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run test src/domain/models/bundle_test.ts — all 4 bundle tests pass
• deno run test — full suite (2689 tests) passes
• deno run compile — binary compiles successfully

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.124013.0-sha.c6be936d/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.124013.0-sha.c6be936d/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.124013.0-sha.c6be936d/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.124013.0-sha.c6be936d/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: accept both US and UK English for summarise command (#610)

Summary

• Adds .alias("summarize") to the summarise command so both swamp summarise and swamp summarize work
• Audited all CLI commands — summarise is the only command using a -ise/-ize verb. All others use dialect-neutral verbs (init, create, delete, run, search, validate, evaluate, describe, edit, get, push, pull, list, update, etc.)
• The only built-in model method (execute on command/shell) is also dialect-neutral
• Internal code and filenames remain unchanged — this is purely an input alias

Closes #608

Test Plan

• Verified swamp summarize --help resolves correctly
• Verified swamp summarise --help still works
• All 2689 tests pass, deno fmt, deno lint, and deno check clean

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.123455.0-sha.650b8ad0/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.123455.0-sha.650b8ad0/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.123455.0-sha.650b8ad0/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.123455.0-sha.650b8ad0/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: invalidate bundle cache when local dependencies change (#607)

Summary

Fixes #605.

When iterating on extensions, swamp serves stale bundled code because bundleWithCache only checks the entry point file's mtime against the cached bundle. If a locally imported dependency changes, the cache is incorrectly treated as fresh — the dependency change is invisible to the cache check.

The fix

Replace the single-file mtime check with a full dependency graph mtime check:

1. Stat the cached bundle to get its mtime
2. Use resolveLocalImports() to walk the entry point's local import graph and collect all .ts dependencies
3. Stat every dependency and find the newest mtime
4. Only use the cache if the bundle is newer than all dependencies

This is correct because resolveLocalImports already existed and is well-tested — it recursively follows relative import/export statements within a boundary directory, which is exactly the set of files that deno bundle would process.

Architecture boundary

resolveLocalImports previously lived in extensions/. Importing it directly into models/ would have introduced a new extensions <-> models mutual dependency, caught by the architecture boundary ratchet test. To avoid this, the function was moved to models/local_import_resolver.ts (a natural home alongside bundle.ts), with extensions/extension_import_resolver.ts re-exporting for backward compatibility. No new cross-context dependencies.

Future optimisation

The current approach re-resolves the import graph on every cache check by reading each dependency file to parse its imports. For small-to-moderate extensions this is negligible, but for large dependency trees with many files it adds I/O. A future optimisation would be to persist the resolved dependency list alongside the cached bundle (e.g. a .deps.json sidecar file), so cache checks only need stat calls rather than file reads + regex parsing. This would reduce the cache-hit path to N stat calls with no file reads. This isn't necessary today but is a clear path forward if profiling shows it matters.

Test plan

• New test: model loader invalidates cache when dependency file changes
• New test: vault loader invalidates cache when dependency file changes
• All 2689 existing tests pass
• Architecture boundary ratchet test passes (no new mutual dependencies)
• deno check, deno lint, deno fmt all pass
• deno run compile succeeds

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.011558.0-sha.b591ba6a/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.011558.0-sha.b591ba6a/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.011558.0-sha.b591ba6a/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.011558.0-sha.b591ba6a/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: bundle missing skill files in repo init and upgrade (#606)

Summary

• Add swamp-extension-model/references/publishing.md and swamp-vault/references/user-defined-vaults.md to BUNDLED_SKILLS — these files existed on disk but were never copied during swamp repo init or swamp repo upgrade
• Add a formatting requirement callout to the publishing guide so agents know swamp extension fmt is a hard gate before push

Test Plan

• deno fmt --check passes
• deno lint passes
• deno run test passes (2674/2674)
• Run swamp repo init in a fresh directory and verify both files are present

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.002807.0-sha.56e4175a/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.002807.0-sha.56e4175a/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.002807.0-sha.56e4175a/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260305.002807.0-sha.56e4175a/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: add swamp summarise command (#604)

Summary

Closes #460

Adds a new swamp summarise command that gives users a single, high-level overview of all repo activity over a configurable time window — method executions, workflow runs, and data produced. Previously, understanding what happened in a repo required running multiple siloed commands.

Usage

swamp summarise [--since <duration>] [-v] [--json]

• --since: Time window (e.g. 1h, 1d, 7d, 1w). Defaults to 7d.
• -v: Verbose mode — shows per-run detail beneath each group.
• --json: Full structured JSON output for scripting/integration.

Default output

Activity summary (last 7d)

Direct Model Method Executions (6 total: 6 succeeded)
  Model: echo-test (command/shell)
    execute   ✓ 5
  Model: list-files (command/shell)
    execute   ✓ 1

Workflow Runs (2 total: 2 succeeded)
  test-pipeline   ✓ 2

Data (4 items, 12 versions, 2 models)

Verbose output (-v)

Activity summary (last 7d)

Direct Model Method Executions (6 total: 6 succeeded)
  Model: echo-test (command/shell)
    execute   ✓ 5
      2026-03-04 19:26  succeeded  11ms  workflow
      2026-03-04 19:26  succeeded  12ms  workflow
      2026-03-04 19:25  succeeded  11ms  manual
      2026-03-04 19:25  succeeded  11ms  manual
      2026-03-04 19:25  succeeded  14ms  manual
  Model: list-files (command/shell)
    execute   ✓ 1
      2026-03-04 19:25  succeeded  12ms  manual

Workflow Runs (2 total: 2 succeeded)
  test-pipeline   ✓ 2
    2026-03-04 19:26  succeeded
      main > example (echo-test)  succeeded  15ms
    2026-03-04 19:26  succeeded
      main > example (echo-test)  succeeded  17ms

Data (4 items, 12 versions, 2 models)
  command/shell                  4 items, 12 versions

Design decisions

• Model-centric grouping: Method executions are grouped by model name (e.g. echo-test), not by underlying type (command/shell.execute). Users think in terms of their models. Uses DefinitionRepository to resolve definition IDs to names.
• Workflow step breakdown: Verbose mode shows job/step detail within each workflow run, including which model each step invoked and its duration. Uses WorkflowRepository to map step names back to their task definitions.
• Domain layer purity: A DataRepositoryReader interface is defined in the domain layer to avoid importing UnifiedDataRepository from infrastructure (enforced by DDD ratchet tests).
• Version-aware data counting: totalVersions sums each item's version field (version N = N versions exist), giving accurate data churn visibility.
• Load-all-then-filter: Consistent with other commands; fine for local repo scale.

Test plan

• deno check passes
• deno lint passes
• deno fmt passes
• deno run test passes (2681 tests, 0 failures)
• deno run compile succeeds
• End-to-end tested with compiled binary: log, verbose, JSON, and empty window modes
• DDD layer ratchet tests pass (presentation→infra bumped 36→37 for logger consistency)

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.213352.0-sha.2bb8ca15/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.213352.0-sha.2bb8ca15/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.213352.0-sha.2bb8ca15/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.213352.0-sha.2bb8ca15/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: allow all namespaces for local model and vault loading (#603)

Summary

• Remove reserved namespace blocking from local model and vault loaders
• All namespace combinations (@swamp/*, @si/*, swamp/*, si/*, myorg/*) are now valid for local loading
• Only validation remaining is the minimum 2-segment requirement (e.g., myorg/my-model)

Why

This is a follow-up to #600. That PR relaxed the @ prefix requirement but still blocked swamp/* and si/* without @ prefix locally, and blocked @swamp/*/@si/* for vaults. The model loader already allowed @swamp/* and @si/* for local development, but the vault loader didn't — and neither loader allowed bare swamp/* or si/*.

For local development, developers need to build and test extensions with any namespace. Reserved namespace enforcement should only happen at the extension push boundary, not during local loading.

What still blocks reserved namespaces

The extension push pipeline is unchanged and still blocks @swamp/*, @si/*, swamp/*, and si/* when publishing to the registry:

• src/domain/extensions/extension_manifest.ts — manifest validation
• src/domain/extensions/extension_namespace_validator.ts — content namespace validation
• src/domain/extensions/extension_dependency_resolver.ts — dependency resolution

This separation allows developers to build and test extensions locally with any namespace while preventing unauthorized use of reserved namespaces in the public registry.

Changes

Test plan

• deno check — type checking passes
• deno lint — clean
• deno fmt — clean
• deno run test — all 50 tests pass (41 model loader + 9 vault loader)

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.212925.0-sha.65fba57a/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.212925.0-sha.65fba57a/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.212925.0-sha.65fba57a/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.212925.0-sha.65fba57a/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: relax namespace validation for local models and vaults (#600)

Summary

• Remove the @ prefix requirement for user-defined extension model and vault types
• Non-@ types like digitalocean/app-platform are now valid (implicitly @swamp/digitalocean/app-platform)
• Reserved namespaces (swamp/*, si/*) remain blocked for non-@ types
• @swamp/* and @si/* remain allowed for local development

Why

Swamp-managed extensions are moving from @swamp/aws/ec2 to just aws/ec2 — a missing @ namespace is implicitly treated as @swamp. This means user-defined extension models without the @ prefix should also be valid, but loading extensions/models/app_platform.ts with type: "digitalocean/app-platform" previously failed with "Model type must use '@' prefix".

This change is scoped to local model/vault loading only. Extension push validation (manifest, namespace validator) is deferred.

Changes

Test plan

• deno check — type checking passes
• deno lint — clean
• deno fmt — clean
• deno run test — all 50 tests pass (41 model loader + 9 vault loader)
• deno run compile — binary compiles
• Verified no UAT tests broken by this change

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.202030.0-sha.3596ccf4/swamp-darwin-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

macOS (Intel):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.202030.0-sha.3596ccf4/swamp-darwin-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (x86_64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.202030.0-sha.3596ccf4/swamp-linux-x86_64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

Linux (aarch64):

curl -L https://github.com/systeminit/swamp/releases/download/v20260304.202030.0-sha.3596ccf4/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/