What's Changed

• feat: add createXxxDeps factories for all 12 Batch 2 commands (#769)

Summary

• Extract readUpstreamExtensions to src/infrastructure/persistence/upstream_extensions.ts so it can be imported from libswamp without reaching into CLI code
• Add createXxxDeps() factory functions to all 12 Batch 2 libswamp generators, following the same pattern as createDataGetDeps() from Batch 1
• Simplify all 12 CLI handlers to ~20-line wrappers: parse args → factory → renderer → consumeStream()
• Rewrite workflowSchema generator to import Zod schemas directly (pure computation, no deps needed)

Factories added

Any consumer can now import { dataList, createDataListDeps } from "libswamp/mod.ts" and have a fully working operation without importing domain internals.

Test Plan

• deno check src/ — passes (0 errors)
• deno lint — passes (737 files)
• deno fmt --check — passes (798 files)
• deno run test — all 3361 tests pass
• deno run compile — binary compiles successfully

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.232456.0-sha.01a4aa77/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/v20260318.232456.0-sha.01a4aa77/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/v20260318.232456.0-sha.01a4aa77/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/v20260318.232456.0-sha.01a4aa77/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: handle broken extensions with missing source files from older publishes (#768)

Summary

• Skip _-prefixed directories (_lib/, _internal/) in discoverFiles() across all four loaders (model, vault, driver, datastore) — these are helper modules imported by entry points, not standalone types that should be individually bundled
• Strip ANSI escape codes from deno bundle error messages and CLI startup warnings so users see clean text instead of raw escape sequences
• Validate source completeness during extension pull — after extraction, resolve imports from entry-point .ts files and warn if referenced source files are missing, with guidance to ask the author to re-publish

Context

Extensions published before the multiline import regex fix (commit 4955f3d2, March 16) may have incomplete source files. For example, @stack72/letsencrypt-certificate was published March 4 and is missing _lib/acme.ts because the old single-line regex in local_import_resolver.ts couldn't match multiline imports during publish.

When users pulled these extensions, discoverFiles() found helper files in _lib/ and tried to bundle them independently, which failed because their imports were unresolvable. Users saw raw deno bundle errors with ANSI escape codes — a confusing experience since the pre-built JS bundle actually works fine.

User impact

Before this fix, pulling @stack72/letsencrypt-certificate produced confusing bundle errors with ANSI garbage. After this fix, users see:

WRN Extension has incomplete source files (1 missing). The pre-built bundle will be used.
WRN To fix, ask the extension author to re-publish with swamp 20260316 or later.
WRN   missing: _lib/acme.ts

And swamp model type describe @stack72/letsencrypt-certificate works correctly via the pre-built bundle.

Test plan

• New test: UserModelLoader skips _-prefixed directories in discoverFiles — creates _lib/helper.ts alongside a valid model and verifies it never appears in result.failed or result.loaded
• New test: renderExtensionPullMissingSources outputs JSON in json mode — verifies JSON output format for missing source file warnings
• All 3363 existing tests pass
• Manual verification: swamp init && swamp extension pull @stack72/letsencrypt-certificate && swamp model type describe @stack72/letsencrypt-certificate — shows missing source warning, no bundle errors, type describe works

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.222412.0-sha.ea3d7b68/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/v20260318.222412.0-sha.ea3d7b68/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/v20260318.222412.0-sha.ea3d7b68/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/v20260318.222412.0-sha.ea3d7b68/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: handle shorthand configSchema property syntax in extension extractor (#767)

Summary

• Bug: The extension content extractor failed to detect configSchema when using ES shorthand property syntax (configSchema, instead of configSchema: value). The regex /configSchema\s*:/ required a colon, so shorthand was silently ignored.
• Fix: Updated hasConfigSchema detection to /configSchema\s*[:,}]/ and added a shorthand fallback in the named-ref resolution branch that looks up const configSchema = z.object({ in the full file content when shorthand syntax is detected.
• Scope: Applied identically to all three extraction blocks — vaults (~line 265), drivers (~line 647), and datastores (~line 716).

Test plan

• All 30 existing tests pass (deno run test src/domain/extensions/extension_content_extractor_test.ts)
• Type checking passes (deno check)
• Binary recompiled (deno run compile)

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.215201.0-sha.3f5812f1/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/v20260318.215201.0-sha.3f5812f1/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/v20260318.215201.0-sha.3f5812f1/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/v20260318.215201.0-sha.3f5812f1/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: add swamp extension trust CLI commands (#766)

Summary

Adds CLI commands to manage trusted collectives for extension auto-resolution, solving a discoverability problem where the feature was completely invisible to both users and AI agents.

The Problem

A user asked Claude about trusted collectives in their swamp repo, and Claude responded: "The trusted collectives feature doesn't exist in swamp yet." Despite the feature being fully implemented (PRs #725 and #727), it was only configurable by manually editing .swamp.yaml — no CLI command, no --help text, no discoverability path.

The Solution

Four new commands under swamp extension trust:

swamp extension trust list                # Show explicit, membership, and resolved collectives
swamp extension trust add <collective>    # Add a collective to the trusted list
swamp extension trust rm <collective>     # Remove a collective from the trusted list
swamp extension trust auto-trust <on|off> # Enable/disable membership auto-trust

The list command shows the full picture — explicit collectives from .swamp.yaml, membership collectives from auth, and the resolved/merged effective list. This means even on a fresh repo with no config, a user sees that swamp and si are trusted by default.

Architecture

Follows the libswamp + renderer pattern (issue #739):

Refactoring

• Extracted resolveTrustedCollectives() from src/cli/mod.ts into src/libswamp/extensions/trust.ts — it was domain logic living in the CLI layer
• Moved 8 tests from src/cli/mod_test.ts to src/libswamp/extensions/trust_test.ts to follow the code
• Single TrustModifyEvent shared by both trust_add and trust_rm generators (identical event shapes, no reason for separate types)
• DEFAULT_TRUSTED defined once, used everywhere

Documentation Updates

• design/extension.md — documents CLI commands in "Trusted Collectives" section
• design/repo.md — cross-references CLI commands from trustedCollectives config
• 7 skill files updated with swamp extension trust references for discoverability

Test Plan

• 26 generator tests (src/libswamp/extensions/) — all pass
• 16 renderer tests (src/presentation/renderers/trust_*_test.ts) — all pass
• 8 resolveTrustedCollectives tests moved to proper location — all pass
• Existing mod_test.ts tests still pass (57 tests, down from 65 after moving 8)
• deno check passes on all files
• deno lint passes
• deno fmt applied

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.210703.0-sha.c7e8f28f/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/v20260318.210703.0-sha.c7e8f28f/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/v20260318.210703.0-sha.c7e8f28f/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/v20260318.210703.0-sha.c7e8f28f/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: port Batch 2 commands to libswamp + renderer pattern (#765)

Summary

• Port ~12 List/Versions/Validate/Stats commands to the async generator + renderer architecture (part of #739)
• Migrated: data list, data versions, vault list-keys, extension list, model validate, workflow validate, workflow schema, workflow history logs, model method history logs, model output logs, model output data, telemetry stats
• Each command gets a typed event generator in src/libswamp/, Log+Json renderers in src/presentation/renderers/, and unit tests for both layers
• Old src/presentation/output/ files and their tests removed

Test Plan

• All 3319 existing tests pass
• New generator unit tests verify event streams with fake deps
• New renderer tests verify log and JSON output parity
• deno fmt, deno lint, deno check all pass

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.203746.0-sha.e3308e87/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/v20260318.203746.0-sha.e3308e87/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/v20260318.203746.0-sha.e3308e87/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/v20260318.203746.0-sha.e3308e87/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: add --content-type filter to extension search (#764)

Summary

Closes #754

Adds a --content-type filter flag to swamp extension search so users can narrow results by content type (models, workflows, vaults, datastores, drivers). This leverages the new contentType query parameter added to the swamp-club API in swamp-club#281.

What changed

• API client: Added contentType?: string[] to ExtensionSearchParams and contentTypes?: string[] to ExtensionSearchEntry. The searchExtensions method serializes content type values as repeated query params (same pattern as platform and label).
• CLI: Added --content-type <contentType:string> option with collect: true. Values are validated against the allowed set with a clear error message on invalid input.
• Presentation: Content types are displayed in the interactive detail view and included in JSON output (omitted when empty, matching the platforms/labels pattern).

User impact

Before this change, users had no reliable way to find extensions containing specific content types — they had to rely on keyword matching which was unreliable. Now they can run:

# Find all extensions that contain models
swamp extension search --content-type models

# Find extensions with both workflows and datastores
swamp extension search --content-type workflows --content-type datastores

# Combine with other filters
swamp extension search --content-type models --platform aws --label networking

Test plan

• deno check — type checking passes
• deno lint — no lint errors
• deno fmt — formatting correct
• deno run test — all 38 tests pass (7 new tests added)
• deno run compile — binary compiles

New tests cover:

• Invalid content type value throws UserError
• Valid content type values are accepted
• contentType array params appended correctly to URL
• contentTypes renders in JSON output when present
• contentTypes omitted from JSON when empty

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.193004.0-sha.bf464c17/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/v20260318.193004.0-sha.bf464c17/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/v20260318.193004.0-sha.bf464c17/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/v20260318.193004.0-sha.bf464c17/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: allow multi-line Zod chain methods in content extractor (#763)

Summary

• Fix parseZodObjectFields chain-method regex to allow whitespace/newlines
  before chained method calls (e.g. .min(), .describe())
• Add test covering multi-line vault configSchema with chained validators and
  descriptions

Problem

When extension authors write Zod schemas across multiple lines:

configSchema: z.object({
op_vault: z.string()
    .min(1, "Vault name is required")
    .describe("The 1Password vault to use"),
})

The chain-method regex ^.\w+( failed to match because the newline and
indentation before .min( meant the ^ anchor saw whitespace, not a dot.
The chain loop broke immediately, so .describe() was never reached and
field descriptions were silently empty.

Fix

^\.\w+\( → ^\s*\.\w+\( in parseZodObjectFields (line 420).

Test plan

• New test: extracts vault configSchema descriptions with chained validators
• All 30 existing extractor tests pass
• Verified end-to-end: pushed 1Password vault extension, descriptions render on extension page

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.183528.0-sha.8855e7df/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/v20260318.183528.0-sha.8855e7df/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/v20260318.183528.0-sha.8855e7df/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/v20260318.183528.0-sha.8855e7df/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• feat: port Batch 0 and Batch 1 commands to libswamp + renderer pattern (#762)

Implements Batches 0 and 1 from the CLI refactor plan (closes #739 partial):

Batch 0 - Infrastructure:

• Add shared error factories to src/libswamp/errors.ts: notFound(), alreadyExists(), validationFailed(), with full unit tests

Batch 1 - Simple Read-Only Gets (10 commands):

• model get, model output get, model method describe, model method history get
• workflow get, workflow history get
• vault get, vault describe
• data get
• type describe

For each command:

• Define typed event union with resolving/completed/error kinds
• Define XxxDeps interface + createXxxDeps() factory wiring real infrastructure
• Implement async function* generator (zero presentation logic)
• Implement LogXxxRenderer + JsonXxxRenderer via Renderer interface
• Update CLI handler to pure orchestration via consumeStream()
• Export from src/libswamp/mod.ts, remove old src/presentation/output/ files
• Generator unit tests with fake deps

Also fixes design compliance issues:

• Add _ctx: LibSwampContext as first param to all 9 Batch 1 generators
• Use writeOutput() in LogDataGetRenderer (not console.log) for semantic consistency with other log-mode renderers

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.171704.0-sha.15076fa0/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/v20260318.171704.0-sha.15076fa0/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/v20260318.171704.0-sha.15076fa0/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/v20260318.171704.0-sha.15076fa0/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• fix: collective validator error message omits drivers and datastores (#761)

Summary

Fixes #755.

When swamp extension push fails collective validation, the error message only mentioned "model types, vault types, and workflow names" — it did not mention drivers or datastores. This was confusing for users whose push failed due to a driver or datastore type not matching the extension collective.

Changes:

• src/cli/commands/extension_push.ts — updated the user-facing UserError message to include "driver types, and datastore types"
• src/domain/extensions/extension_collective_validator.ts — updated the JSDoc comment to reflect that drivers and datastores are also validated

No logic changes; the validator already correctly checked driver and datastore types.

User Impact

Before this fix, a user pushing an extension with a mismatched driver or datastore type would see:

All model types, vault types, and workflow names must use the same collective as the extension.

…with no mention of drivers or datastores, leaving them uncertain what was actually wrong.

After this fix, the message reads:

All model types, vault types, workflow names, driver types, and datastore types must use the same collective as the extension.

Test Plan

• deno check — passes
• deno lint — passes
• deno fmt --check — passes
• deno run test — 3198 tests pass

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.162717.0-sha.f1293de2/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/v20260318.162717.0-sha.f1293de2/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/v20260318.162717.0-sha.f1293de2/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/v20260318.162717.0-sha.f1293de2/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/

What's Changed

• docs: document custom datastore and driver extensibility (#756)

Summary

The design docs (datastores.md, execution-drivers.md, extension.md) only documented built-in backends but the codebase fully supports user-defined datastores and drivers via the extension system. This gap meant contributors and advanced users reading design docs had no understanding of the plugin architecture — even though the code, type registries, loaders, and bundling are all in place.

Why this matters

• Contributor onboarding: Someone reading design/datastores.md to understand the architecture would conclude swamp only supports filesystem and S3. They'd miss that the entire system is pluggable via DatastoreProvider and DriverTypeRegistry. This makes it harder for contributors to extend swamp correctly.
• Design doc ↔ code drift: The skills (swamp-extension-datastore, swamp-extension-driver) teach users how to create custom backends, but the design docs didn't explain the architecture behind the extensibility. Design docs should be the authoritative source for architectural decisions.
• Discoverability: Custom datastores and drivers are a major capability. Without design doc coverage, users discovering swamp through the docs would never know these extension points exist.

Changes

• design/datastores.md — Added "Custom Backends" section covering: type registry singleton, DatastoreProvider interface (5 methods), UserDatastoreLoader bundling pipeline, configuration with custom types, and implementation files table
• design/execution-drivers.md — Added "Custom Drivers" section covering: DriverTypeRegistry singleton, ExecutionDriver interface, UserDriverLoader bundling pipeline, resolution priority with custom types, and implementation files table
• design/extension.md — Added "Vaults, Drivers, and Datastores" subsection explaining the bundling strategy and export validation schemas for all three content types, plus "Collective Validation" subsection

All interface details and file paths were verified against the current source code.

Test plan

• Verified all referenced source files exist and type-check
• Confirmed interface details match actual code (DatastoreProvider, ExecutionDriver, registries, loaders)
• No duplication with skills — design docs explain architecture, skills explain workflow
• Review for accuracy and completeness

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

curl -L https://github.com/systeminit/swamp/releases/download/v20260318.021802.0-sha.3848499d/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/v20260318.021802.0-sha.3848499d/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/v20260318.021802.0-sha.3848499d/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/v20260318.021802.0-sha.3848499d/swamp-linux-aarch64 -o swamp
chmod +x swamp && sudo mv swamp /usr/local/bin/