What's Changed

• fix: findBySpec() and findByTag() return only latest version (#502)

Summary

Fixes #497

data.findBySpec() and data.findByTag() iterated all versions of each data entry and returned every match. When used in a workflow forEach, this produced duplicate expanded steps with identical names, which corrupted the topological sort dependency graph and triggered a spurious "Cyclic dependency detected" error.

Both functions now use getLatestVersionSync() to return only the most recent version of each data entry — matching the pattern already established by data.latest().

What changed

findBySpec() (src/domain/expressions/model_resolver.ts)

• Replaced listVersionsSync() + version loop with a single getLatestVersionSync() call per data entry
• Added a seen Set for cross-coordinate deduplication (keyed by modelType:modelId:dataName, without version)

findByTag() (src/domain/expressions/model_resolver.ts)

• Same fix: replaced version iteration with getLatestVersionSync()
• Fixed the dedup key to exclude version — the old key (modelType:modelId:dataName:version) only deduplicated the exact same version appearing under different coordinates, not different versions of the same entry

Why this is correct

1. findBySpec and findByTag are discovery functions — they find distinct data entries matching criteria, not enumerate version histories. The docs describe them as "Find all data matching a tag" and "Find all data from a specific output spec", where "all" refers to distinct entries, not all versions of each.
2. Version access has its own API — data.version() and data.listVersions() exist specifically for accessing version history.
3. latest() sets the precedent — it already uses getLatestVersionSync(). The findBy* functions are semantically a filtered variant of latest() applied across multiple entries.
4. The only consumers are CEL expressions in workflows — specifically in forEach expansions where you want one step per logical data entry, not one step per version.

Binary testing

Verified the fix end-to-end using the compiled swamp binary at /tmp/fix-497:

Setup

• Initialized a fresh swamp repo
• Created 3 command/shell model instances: service-a, service-b, service-c
• Ran each model's execute method 3 times, creating 3 versions of result data per model (9 total data versions)

Test 1: findBySpec with single model

Created a workflow with forEach over data.findBySpec("service-a", "result"):

• Result: forEach expanded to 1 step (latest version only), workflow ran and succeeded
• Before fix: would expand to 3+ duplicate steps, causing cyclic dependency error

Test 2: findByTag across all models

Created a workflow with forEach over data.findByTag("specName", "result"):

• Result: forEach expanded to 3 steps (one per model, latest version only), all succeeded
• Before fix: would expand to 9+ steps with triplicate names, causing cyclic dependency error

Test plan

• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run test — 2248 tests pass (0 failed), including 2 new unit tests and 1 updated integration test
• deno run compile — binary recompiles successfully
• End-to-end binary testing with findBySpec forEach workflow
• End-to-end binary testing with findByTag forEach workflow

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• fix: extension pull writes workflows to configured workflowsDir (#501)

Summary

• extension pull now writes workflow files to the configured workflowsDir (default: extensions/workflows/) instead of the previously hardcoded workflows/ directory

This is a follow-up to #500 which added extensions/workflows/ support. Without this fix, extension pull would write workflows to workflows/ while workflow search and workflow run look in extensions/workflows/, meaning pulled extension workflows wouldn't be discoverable.

What changed

In src/cli/commands/extension_pull.ts:

• Added workflowsDir to the PullContext interface
• The command action now resolves workflowsDir using resolveWorkflowsDir(marker) (same priority chain: SWAMP_WORKFLOWS_DIR env var > .swamp.yaml workflowsDir > default extensions/workflows)
• The pullExtension() function uses the resolved workflowsDir for both conflict detection and file placement

Test plan

• deno check passes
• deno lint passes
• deno fmt passes
• All 2272 tests pass
• Binary compiles successfully

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add extension workflows support (extensions/workflows/) (#500)

Summary

Adds support for discovering and executing workflow YAML files from extensions/workflows/, mirroring the existing extensions/models/ pattern. This means extensions installed from third-party sources can now ship workflow files that are automatically discoverable and executable without manually copying them into .swamp/workflows/.

• Extension workflows are read-only — they cannot be deleted or overwritten via CLI commands
• Extension workflows are transparently merged with user workflows — workflow search, workflow run, and all other workflow commands see them alongside regular workflows
• Name conflicts are resolved by giving priority to primary workflows in .swamp/workflows/ — extension workflows with the same name are hidden
• The workflows directory is configurable via workflowsDir in .swamp.yaml or the SWAMP_WORKFLOWS_DIR environment variable (default: extensions/workflows)

What this means for users

Previously, if you installed an extension that included workflow YAML files, you had to manually copy those files into your .swamp/workflows/ directory. Now, extensions can place their workflows in extensions/workflows/ and they'll just work:

# Extension workflows are discoverable
swamp workflow search --json
# Returns workflows from both .swamp/workflows/ AND extensions/workflows/

# Extension workflows are executable
swamp workflow run my-extension-workflow
# Runs exactly like a regular workflow, creating runs in .swamp/workflow-runs/

# Extension workflows are read-only
swamp workflow delete my-extension-workflow
# Error: "Cannot delete extension workflow 'my-extension-workflow'. Extension workflows are read-only."

If you want to override an extension workflow, create one with the same name in .swamp/workflows/ — your version always takes priority.

Architecture: Composite Repository Pattern

Two new repository classes implement this transparently:

1. ExtensionWorkflowRepository — Read-only repo that recursively discovers *.yaml workflows from the configured extensions directory. Broken YAML files are logged as warnings and skipped (resilient loading).
2. CompositeWorkflowRepository — Wraps the existing YamlWorkflowRepository (primary/mutable) + ExtensionWorkflowRepository (secondary/read-only). All consumers use the WorkflowRepository interface, so this is a transparent change.

The RepositoryContext.workflowRepo type was widened from YamlWorkflowRepository to WorkflowRepository (the interface). This required no changes to downstream consumers since WorkflowExecutionService, SymlinkRepoIndexService, and all CLI commands already work against the interface.

Changes

New files

• src/cli/resolve_workflows_dir.ts — resolveWorkflowsDir() with priority: env var > config > default
• src/infrastructure/persistence/extension_workflow_repository.ts — Read-only workflow repo
• src/infrastructure/persistence/composite_workflow_repository.ts — Merges primary + extension repos

Modified files

• src/infrastructure/persistence/repo_marker_repository.ts — Added workflowsDir?: string to RepoMarkerData
• src/infrastructure/persistence/repository_factory.ts — Wired composite repo, widened workflowRepo type
• src/cli/repo_context.ts — Resolves workflowsDir from marker and passes to factory
• src/cli/completion_types.ts — Shell completions now include extension workflows
• src/cli/mod.ts — Re-exports resolveWorkflowsDir
• src/cli/commands/workflow_search.ts — Uses WorkflowRepository interface type
• src/cli/commands/workflow_delete.ts — Guards against deleting extension-only workflows
• src/cli/commands/workflow_edit.ts — Falls back to actual source file for extension workflows

Test plan

Automated tests (46 new tests, all 2272 pass)

resolveWorkflowsDir (5 tests in src/cli/mod_test.ts)

• Returns default extensions/workflows with null marker
• Returns default when marker has no workflowsDir
• Uses marker.workflowsDir when set
• SWAMP_WORKFLOWS_DIR env var takes priority over config
• SWAMP_WORKFLOWS_DIR env var takes priority over default

ExtensionWorkflowRepository (10 tests in extension_workflow_repository_test.ts)

• Discovers YAML workflows from a directory
• Discovers workflows in subdirectories (recursive walk)
• Returns empty array for empty directory
• Returns empty array for non-existent directory
• Skips broken YAML files with warnings (resilient loading)
• findByName returns matching workflow
• findByName returns null for non-existent name
• findById returns matching workflow
• save() rejects with UserError (read-only enforcement)
• delete() rejects with UserError (read-only enforcement)

CompositeWorkflowRepository (11 tests in composite_workflow_repository_test.ts)

• findByName checks primary first (precedence)
• findByName falls back to extension
• findByName returns null when not found in either
• findById checks primary first (precedence)
• findById falls back to extension
• findAll deduplicates by name, primary wins
• save delegates to primary
• delete delegates to primary
• Works with null extension repo (backwards compatibility)
• nextId delegates to primary
• getPath delegates to primary

Manual end-to-end testing (verified with compiled binary)

1. Created a fresh swamp repo with swamp repo init
2. Created a command/shell model named hello
3. Created extensions/workflows/greet.yaml with a workflow that runs echo 'Hello from extension workflow!'
4. swamp workflow search --json — confirmed the greet workflow appears in results with correct name, description, and job count
5. swamp workflow search --json greet — confirmed exact-match returns full workflow details
6. swamp workflow run greet — confirmed the workflow executes successfully, runs the shell command, prints "Hello from extension workflow!", saves data outputs, and completes with status "succeeded"

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add integrity verification to swamp extension pull (#498)

Summary

Part 2 of extension integrity verification. Part 1 (swamp-club PR #105) added server-side SHA-256 checksum computation during extension push and a GET .../checksum API endpoint. This adds client-side verification to swamp extension pull so the CLI computes the SHA-256 of the downloaded archive, fetches the expected checksum from the server, and compares them — blocking extraction on mismatch.

Why this design

API client: getChecksum(name, version) returns string | null

The nullable return keeps backward compatibility with extensions published before Part 1 added checksum support. A 404 or a null checksum in the response both gracefully degrade to an "unverified" warning rather than failing the pull. This matches the existing getLatestVersion() and getExtension() 404→null pattern in the same client class.

Verification placement: after download, before extraction

The integrity check runs after the archive bytes are fully downloaded and before any extraction happens. This ensures a tampered archive is never written to disk. It also means verifyChecksum() throws a UserError that the existing command error flow already handles — no new error rendering needed.

Reuse of existing utilities

computeChecksum (domain/models) and verifyChecksum (domain/update/integrity) already exist and are tested. No new crypto code was introduced.

Output: verified vs unverified

Two states, not three — mismatch is a hard failure (thrown UserError), so it never reaches the render function. "verified" logs at info level, "unverified" logs at warn level to flag legacy extensions that lack checksums.

Verified output

$ swamp extension pull @stack72/system-extensions
00:23:44.618   info    extension·pull       Pulling "@stack72/system-extensions"@"2026.02.26.2"
00:23:44.623   info    extension·pull       Description: "Few system extensions for system and disk usage"
00:23:47.026   info    extension·pull       Identity verified: "@stack72/system-extensions"@"2026.02.26.2"
00:23:47.050   info    extension·pull       Pulled "@stack72/system-extensions"@"2026.02.26.2"
00:23:47.050   info    extension·pull       Extracted 4 files:
00:23:47.051   info    extension·pull         "extensions/models/system_usage.ts"
00:23:47.051   info    extension·pull         "extensions/models/disk_usage.ts"
00:23:47.051   info    extension·pull         ".swamp/bundles/system_usage.js"
00:23:47.051   info    extension·pull         ".swamp/bundles/disk_usage.js"

Changes

Test plan

• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run test — all 2246 tests pass
• Manual: swamp extension pull @stack72/system-extensions shows "Identity verified"

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add swamp extension push command for publishing extensions (#494)

Summary

Add the swamp extension push command, which packages and publishes extension models and workflows to the swamp registry.

• Extension push command — manifest-driven three-phase push workflow (initiate, upload to S3, confirm) with --dry-run and -y flags
• Manifest validation — Zod-based schema validation with clear error messages for missing fields, bad CalVer versions, reserved namespaces, and missing models/workflows
• Safety analyzer — scans all files before push; blocks eval(), new Function(), symlinks, hidden files, oversized files; warns on Deno.Command(), long lines, base64 blobs
• Import/dependency resolution — auto-discovers local TypeScript imports and workflow-to-model dependencies
• Bundling — compiles each model entry point to standalone JS via deno bundle
• Version management — pre-flight CalVer version check with interactive bump on duplicates
• ExtensionApiClient — HTTP client for the registry API with HTML error page detection (returns clean message instead of raw HTML dump)
• Skill documentation — publishing guide added to swamp-extension-model skill with full manifest schema, examples, push workflow, safety rules, and common errors

Files changed

• src/cli/commands/extension.ts — Extension command group
• src/cli/commands/extension_push.ts — Push command implementation
• src/cli/mod.ts — Register extension command
• src/cli/unknown_command_handler.ts — Extension subcommand suggestions
• src/domain/extensions/extension_manifest.ts — Manifest schema and parser
• src/domain/extensions/extension_safety_analyzer.ts — Safety analysis rules
• src/domain/extensions/extension_import_resolver.ts — Local import resolver
• src/domain/extensions/extension_dependency_resolver.ts — Workflow dependency resolver
• src/domain/models/calver.ts — CalVer bump() support
• src/infrastructure/http/extension_api_client.ts — Registry HTTP client
• src/presentation/output/extension_push_output.ts — Push output rendering
• .claude/skills/swamp-extension-model/SKILL.md — Publishing section added
• .claude/skills/swamp-extension-model/references/publishing.md — Detailed publishing reference

Test plan

• All 2229 tests pass (deno run test)
• deno check passes
• deno lint passes
• deno fmt --check passes
• Integration tests: CLI help, manifest validation errors, auth errors, safety hard errors
• Unit tests: manifest parsing, safety analyzer, import resolver, dependency resolver, CalVer, API client, push output rendering
• Manifest validation runs before auth check so CI tests pass without credentials

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add swamp extension pull command for downloading extensions (#496)

Summary

Adds the swamp extension pull command, the counterpart to swamp extension push, allowing users to download published extensions from the swamp.club registry into their local swamp repository.

Usage

swamp extension pull @namespace/name           # pulls latest version
swamp extension pull @namespace/name@version   # pulls specific version
swamp extension pull @namespace/name --force   # overwrites existing files

Key Design Decisions

• Unauthenticated endpoints: All pull operations (search, metadata, version info, download) are unauthenticated — no swamp auth login required. This uses getExtension() (unauthenticated metadata endpoint that includes latestVersion) instead of getLatestVersion() (the /latest endpoint requires auth).

• Server URL resolution: Uses SWAMP_CLUB_URL env var or defaults to https://swamp.club — does not depend on stored auth credentials for the server URL.

• Models directory resolution: Uses resolveModelsDir() which respects SWAMP_MODELS_DIR env > .swamp.yaml modelsDir > default extensions/models — not hardcoded.

• Circular import fix: Extracted resolveModelsDir() to src/cli/resolve_models_dir.ts to break the circular import chain (extension_pull → mod → extension → extension_pull). The original mod.ts now imports and re-exports from the new file.

• Safety analysis: Runs analyzeExtensionSafety() on all downloaded .ts files before extracting to disk. Hard errors (e.g., Deno.run, eval) abort the pull; warnings are displayed but don't block.

• Recursive dependency pulling: If a manifest declares dependencies, each missing dependency is automatically pulled. Includes circular dependency guard (Set<string>) and max depth (10).

• Concurrency-safe tracking: upstream_extensions.json tracks pulled extensions with lockfile-based read-modify-write protection and atomicWriteTextFile() for crash-safe writes.

• Archive extraction mapping:

  • extension/models/* → {modelsDir}/
  • extension/bundles/* → .swamp/bundles/ (pre-compiled, immediately usable)
  • extension/workflows/* → workflows/
  • extension/files/* → {modelsDir}/ under extension subdirectory

New Files (6)

Modified Files (6)

Test Plan

• deno check passes
• deno lint passes
• deno fmt --check passes
• All 2246 tests pass (deno run test)
• deno run compile succeeds
• swamp extension pull --help shows usage
• swamp extension --help shows pull subcommand
• Invalid name format gives clear error
• Pull without initialized repo gives clear error
• Pull does not require authentication (connection error, not auth error)

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• fix: prevent deno.lock creation during extension bundling (#491)

Summary

Fixes #490.

PR #452 introduced deno bundle for extension model transpilation. The subprocess inherits the user's CWD and Deno's default lockfile behavior creates/updates a deno.lock in the user's project root — polluting their repo with an unexpected file.

Why --no-lock is the right fix

The --no-lock flag tells Deno to skip lockfile auto-discovery entirely. This is correct for swamp's bundling use case because:

1. Bundling is a build step, not a dependency install. Swamp bundles extensions at startup as an internal transpilation step. The user didn't ask Deno to manage their dependencies — swamp is doing it behind the scenes. Creating a deno.lock in their project is a side effect they never opted into.

2. npm resolution still works without a lockfile. Packages are fetched from the registry and fully inlined into the bundle. The lockfile only pins versions across runs — it doesn't enable resolution.

3. Version pinning is handled at the source level instead. Since there's no lockfile, users should pin explicit versions in their import specifiers (e.g., npm:lodash-es@4.17.21). The skill docs and examples are updated to reflect this guidance. This is actually more explicit and portable than relying on a lockfile that lives outside the extension source.

4. Alternative approaches are worse:

   • Setting cwd on the subprocess to a temp dir would break relative imports in extensions
   • Cleaning up deno.lock after bundling is fragile and races with other processes
   • Using --lock=<temp-path> still creates a lockfile (just elsewhere) for no benefit

Changes

• src/domain/models/bundle.ts — Add --no-lock to deno bundle args
• src/domain/models/bundle_test.ts — Add test: bundles npm imports successfully and verifies no deno.lock is created in the source directory
• .claude/skills/swamp-extension-model/SKILL.md — Add version pinning rule to Key Rules section
• .claude/skills/swamp-extension-model/references/examples.md — Pin versions in import examples table and text analyzer example

Test plan

• New test passes: deno run test src/domain/models/bundle_test.ts (4/4 pass)
• Full test suite passes: 2167 passed, 0 failed
• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run compile — binary compiles successfully

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• fix: resolve race condition in concurrent vault put (#487) (#488)

Summary

Fixes the race condition in refreshSecretsIndex that caused intermittent ENOTEMPTY errors when multiple vault put processes ran concurrently against the same vault.

Root cause

refreshSecretsIndex used a destructive remove+recreate pattern: it removed the entire vaults/{name}/secrets/ directory with Deno.remove({ recursive: true }) and rebuilt it from scratch on every vault put. When two processes collided, one would write symlinks into the directory while the other was trying to remove it, triggering ENOTEMPTY (os error 66).

This was the only index method using this pattern — indexModel and indexWorkflow both use idempotent ensureDir + atomic createSymlink without ever removing their parent directory.

Fix

Replaced the remove+recreate with an incremental sync that matches the existing model/workflow pattern:

1. Migration guard — only remove logicalSecretsDir if lstat shows it's an old-style symlink (not a directory), preserving backward compatibility
2. ensureDir() — idempotent directory creation, safe for concurrent calls
3. Build desired set — read actual .enc files to determine which keys should have symlinks
4. Create/update symlinks — via existing atomic createSymlink() (temp file + rename)
5. Remove stale entries — iterate logical dir and remove any symlinks not in the desired set, with NotFound tolerance for concurrent removals

This is convergent: any number of concurrent executions produce the same final state without interfering with each other.

Tests added

4 new test cases for refreshSecretsIndex:

• Basic secrets indexing — .enc files get symlinks created
• Incremental add — adding a new secret preserves existing symlinks
• Stale cleanup — removing a .enc file and re-indexing removes the stale symlink
• Migration — old-style symlink gets replaced with a directory of individual symlinks

Manual verification

Ran the exact reproduction scenario from the issue — 5 rounds of 5 concurrent vault put operations against a fresh repo using the compiled binary. All 25 operations completed successfully with all keys present, zero ENOTEMPTY errors.

Closes #487

Test plan

• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run test — all 2166 tests pass
• deno run compile — binary compiles
• Manual concurrent vault put stress test (5 rounds x 5 concurrent processes) — no errors

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add contract, property-based, and architectural fitness tests (#486)

Summary

Adds three new categories of tests (13 files, 77 tests) that catch classes of bugs our existing unit and integration tests cannot:

• Architectural fitness tests enforce DDD boundary rules automatically — no more accidental layering violations or circular dependencies between bounded contexts
• Contract tests verify behavioral invariants that cross-context consumers depend on — catches drift in shared interfaces before it causes runtime failures
• Property-based tests verify domain aggregate invariants hold across randomly generated inputs — catches edge cases that hand-picked examples miss

Why these tests matter

Our existing 2,085 tests are all unit or integration tests with hand-crafted inputs. This leaves three gaps:

1. Architectural erosion is invisible. A developer can add a domain → infrastructure import and nothing fails. Over time, the clean DDD layering degrades. The architectural fitness tests catch this immediately with ratchets — the current violation count is locked in, and any new violation fails CI.

2. Cross-context contracts drift silently. When ModelResolver.buildContext() changes what fields it exposes, expression consumers break at runtime, not at compile time. Contract tests lock down the behavioral interface consumers depend on.

3. Aggregate invariants aren't stress-tested. We test Definition.create() with 3-4 names, but never with randomly generated strings containing path traversal characters, unicode, or empty segments. Property tests run 100 random inputs per property, catching edge cases we'd never think to write by hand.

Architectural fitness tests (2 files)

The ratchet pattern means: fixing an existing violation makes the count go down (test still passes). Adding a new violation makes the count go up (test fails). No allow-lists to maintain.

Contract tests (5 files, 42 tests)

Each test verifies a behavioral invariant that consumers across bounded contexts depend on, with zero overlap with existing unit tests:

• EventBus (event_bus_contract_test.ts): Batch preserves publication order across event types, handler errors don't break subsequent handlers, type-specific and wildcard handlers both fire, batch error propagation cleans up state, post-batch events deliver immediately, unsubscribe is idempotent, selective unsubscribe only removes target handler
• Definition (definition_contract_test.ts): getMethodArguments() returns isolated copies (mutation-safe), nonexistent method returns empty object, withUpgradedGlobalArguments preserves identity fields, complex JSON Schema inputs survive serialization round-trip, globalArguments are immutable after create, setMethodArguments fully replaces
• Data (data_contract_test.ts): GC schema rejects zero/negative/float/zero-duration values, ownership schema enforces enum + non-empty ref, optional workflow fields behavior, withNewVersion preserves all inherited fields, toData() returns tag copies (not shared references), isOwnedBy ignores optional fields
• Workflow (workflow_contract_test.ts): Job ordering preserved through serialization round-trip, addJob appends in call order, create allows empty jobs but fromData rejects them, dependency structure survives round-trip, multi-step order preservation, Job.create rejects empty steps, tag isolation through fromData
• ModelResolver (model_resolver_contract_test.ts): resolveModel throws ModelNotFoundError for invalid name/UUID (not null), finds models by name and UUID, buildContext always includes env namespace, indexes models by both name and UUID, ModelData.input has stable interface (id, name, version, tags, globalArguments), self reference has correct fields, updateDefinitionInContext mutates context correctly

Property-based tests (5 files, 28 tests)

Uses fast-check to generate random inputs and verify invariants hold universally:

• ModelType (model_type_property_test.ts): Normalization is idempotent, always lowercase, no consecutive separators, no leading/trailing separators, equality by normalized form, empty input rejected
• Definition (definition_property_test.ts): Path traversal characters always rejected, version always positive, serialization round-trips, ID is always UUID, hash is deterministic, hash is content-sensitive
• Data (data_property_test.ts): Path traversal rejected, version positive, tags always include 'type', ownership check correctness, serialization round-trips, withNewVersion preserves identity
• DataMetadata (data_metadata_property_test.ts): Zero durations become "workflow", leading zeros become "workflow", non-zero durations pass through, named lifetimes pass through
• Workflow (workflow_property_test.ts): Empty jobs rejected by schema, duplicate job names rejected, version positive, serialization round-trips, getJob lookup works

Interesting findings during implementation

The contract tests revealed two real architectural facts worth documenting:

• Data.tags and Workflow.tags return direct references, not defensive copies. Mutating the returned object mutates the entity. This differs from Definition, which uses private fields + copy getters. The contract tests now document this actual behavior.
• Workflow.toData() passes tags by reference too, so fromData() is the isolation boundary (it goes through WorkflowSchema.parse which copies).

Files changed (14)

Test plan

• deno check — passes
• deno lint — passes
• deno fmt — passes
• deno run test — 2,162 tests pass (77 new), 0 failures
• deno run compile — binary compiles

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add dependency auditing CI gate with OSV-Scanner (#484)

Summary

Adds an automated dependency auditing job to the CI pipeline that catches
known vulnerabilities before they reach main. This is especially important
for a codebase that is entirely authored by AI agents, where no human is
manually reviewing changelogs or security advisories for each dependency
update.

Why this matters for an AI-authored codebase

AI agents are excellent at writing code but operate without awareness of the
broader security landscape of their dependencies. When an agent adds or
updates a dependency, it has no way to know whether that version has a
published CVE, has been deprecated due to a security incident, or pulls in
a transitive dependency with known vulnerabilities. This creates a blind spot
that compounds over time:

• Agents pick versions based on documentation and training data, not
  real-time vulnerability databases
• Automated dependency updates (from agents or Dependabot) can introduce
  vulnerable transitive dependencies without anyone noticing
• No human in the loop means no one is reading npm advisories, GitHub
  security alerts, or package changelogs
• Supply chain attacks targeting popular npm packages are increasingly
  common — a compromised transitive dependency could be pulled in without
  any agent or reviewer noticing

This CI gate acts as an automated security reviewer that fills the gap between
AI-generated code and the real-world vulnerability landscape.

Why a custom Deno script instead of existing tools

None of the established vulnerability scanners support deno.lock:

So we wrote scripts/audit_deps.ts — a lightweight Deno script that:

1. Reads deno.lock and extracts all 240 npm packages with their resolved versions
2. Batch-queries the OSV.dev API (the same vulnerability database that osv-scanner, Deps.dev, and GitHub Advisory Database use)
3. Reports any findings with advisory IDs, CVE references, and descriptions
4. Exits non-zero if any vulnerabilities are found

This approach needs no external tools — it runs with deno run using only
--allow-read and --allow-net=api.osv.dev (minimal permissions).

What's included

New deps-audit CI job (runs in parallel with test for zero added
latency on the happy path):

1. Vulnerability scanning via the OSV.dev API — scans all npm packages in
   deno.lock against the OSV database. This is a hard gate — any known
   vulnerability fails the pipeline.

2. Outdated dependency reporting via deno outdated — reports which
   dependencies have newer versions available as a GitHub Actions warning
   annotation. Intentionally non-blocking since upstream releases would
   otherwise break CI on unrelated PRs.

Pipeline integration:

• Runs in parallel with the test job (no sequential dependency)
• Both claude-review and auto-merge now require deps-audit to pass
• No PR can reach main with a known vulnerability in its dependency tree

Local development:

• deno run audit runs the same vulnerability scan + deno outdated locally

Already finding real issues

Running the script against our current deno.lock immediately found:

Found vulnerabilities in 1 package(s):

  jws@3.2.2
    - GHSA-869p-cjfg-cm3x: No description available

This is a transitive dependency: @azure/identity → @azure/msal-node →
jsonwebtoken → jws@3.2.2. An upstream fix is needed from the Azure SDK.

Test Plan

• deno fmt --check passes
• deno lint passes
• deno run test passes (2085 tests)
• Script runs locally and correctly identifies known vulnerabilities
• CI runs the new deps-audit job successfully on this PR

Installation

macOS (Apple Silicon):

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