What's Changed

• fix: complete reports integration across extension push, pull, and search (#792)

Summary

PR #790 added reports as a top-level extension primitive, but several extension system paths were not updated to handle them consistently with other extension types. This PR fixes bugs and consistency gaps across push, pull, and search.

Bug fixes

• Report bundles compiled without bundleOptions — Reports using bare specifiers or deno.json import maps would fail to compile during extension push because bundleOptions (denoConfigPath/packageJsonDir) was not passed to bundleExtension(). All other extension types correctly received these options.
• Reports excluded from bare specifier detection — When determining whether a package.json is needed for bundling, report entry points were not checked. If a report was the only file using bare specifiers, packageJsonDir would never be set, causing a bundling failure.
• validateSourceCompleteness skipped reports on pull — After pulling an extension, source completeness validation checked models, vaults, drivers, and datastores but not reports. Missing report dependencies would go unwarned.
• --content-type reports rejected by CLI — The extension search command had a hardcoded content type validation list that didn't include "reports", so swamp extension search --content-type reports would error.

Consistency fixes

• Manifest validation error message now includes "report" as a valid extension type
• Collective validation error messages and docstrings now mention reports
• Content metadata debug log now includes report count
• Help text for --content-type flag lists reports

Test plan

• deno run test src/domain/extensions/extension_manifest_test.ts — passes with updated error message
• deno run test src/domain/extensions/extension_collective_validator_test.ts — passes
• deno run test src/domain/extensions/extension_content_extractor_test.ts — passes
• deno check on all modified files — clean

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: add reporting as a top level primitive (#790)

Summary

• Add a reports system: user-defined TypeScript extensions in extensions/reports/ that analyze model/workflow execution results and produce markdown + JSON output, automatically persisted as versioned data artifacts
• Three report scopes (method, model, workflow) with a three-level control model: model-type defaults, definition YAML reports.require/reports.skip, and CLI flags (--report, --skip-report, --report-label, --skip-report-label, --skip-reports)
• New CLI commands: report describe, report get, report search (with interactive fuzzy-search TUI)
• Integrate reports into model method runs and workflow runs, extension push/pull, and add a swamp-report skill
• Add markdown-to-terminal renderer for rich report output

Test Plan

• Unit tests for all new domain modules (report registry, execution service, data handles, report selection)
• Unit tests for libswamp generators (describe, get, search) and presentation renderers
• Integration tests updated for architecture boundary and DDD layer rules
• All 3474 tests pass, deno check, deno lint, deno fmt clean
• Binary compiles successfully via deno run compile

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• The Machine: Skip Claude hooks in CI reviews (#789)

Installation

macOS (Apple Silicon):

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

What's Changed

• The Machine: Ensure we don't run Stop hook without changes (#786)

Installation

macOS (Apple Silicon):

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

What's Changed

• fix: delete methods return last known state data (#788)

Summary

Closes #636

When a model's delete method succeeds, the deletion marker (tombstone) now includes the last known active state attributes merged with the deletion metadata. This fixes two problems reported in the issue:

• Delete responses now include dataArtifacts — Previously the JSON response had no data field, making it impossible to confirm what was deleted without a separate query. Now the response includes the full resource attributes alongside deletedAt/deletedByMethod.

• data.latest() resolves original attributes after deletion — Previously, tombstones only contained {deletedAt, deletedByMethod}, which broke CEL expressions like data.latest("x", "y").attributes.RouteTableId on workflow re-runs. Now those expressions resolve correctly, enabling idempotent re-runs of complex delete workflows.

Design decisions

Enrich the tombstone, not data.latest() — We considered making data.latest() lifecycle-aware (skip tombstones, return last active version) but rejected it because:

1. It would be a breaking change for anyone checking data.latest() to detect deletion
2. Users would need to update existing CEL expressions to use a new function
3. The enriched tombstone approach requires zero changes to existing workflows on both sides — delete detection (deletedAt is still there) and re-runs (original attributes are still there)

Flat merge, accepted collision risk — Deletion metadata (deletedAt, deletedByMethod) is merged into the same JSON object as resource attributes. We considered namespacing (e.g. _deleted.at) but accepted the theoretical collision risk since cloud APIs don't use these field names, and the added complexity wasn't justified.

Deletion markers as data handles — Rather than adding special-case logic in run.ts, deletion markers are appended to currentHandles in method_execution_service.ts so they flow through the existing data artifact pipeline. This means run.ts, the JSON renderer, and all presentation code required zero changes.

Before

{
  "modelId": "ca9547ff-...",
  "modelName": "test-volume",
  "type": "@stack72/digitalocean/volume",
  "methodName": "delete",
  "dataArtifacts": []
}

After

{
  "modelId": "ca9547ff-...",
  "modelName": "test-volume",
  "type": "@stack72/digitalocean/volume",
  "methodName": "delete",
  "dataArtifacts": [
    {
      "name": "main",
      "attributes": {
        "id": "8290fa55-...",
        "name": "swamp-crud-test-vol",
        "region": "us-east-1",
        "status": "active",
        "deletedAt": "2026-03-20T00:02:15.524Z",
        "deletedByMethod": "delete"
      }
    }
  ]
}

Changes

Test plan

• All 3402 tests pass
• E2E verified: create → delete returns enriched tombstone with full attributes
• E2E verified: re-create after delete still works
• Tombstone on disk contains merged state for data.latest() resolution
• Graceful degradation when active content is missing (marker-only metadata)
• CI passes

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• The Machine: Writing the plan rather than presenting it slows the machine (#787)

Installation

macOS (Apple Silicon):

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

What's Changed

• fix: upgrade AWS SDK to resolve fast-xml-parser vulnerabilities (#785)

Summary

• Upgrades @aws-sdk/client-cloudcontrol and @aws-sdk/client-s3 from ^3.1002.0 to ^3.1013.0
• This pulls in @aws-sdk/xml-builder@3.972.14 (up from 3.972.10) which depends on fast-xml-parser@5.5.6 instead of the vulnerable 5.4.1
• Resolves two transitive dependency vulnerabilities flagged by our dependency audit:
  • GHSA-8gc5-j5rx-235r
  • GHSA-jp2q-39xq-3w4g

Details

The vulnerability chain was:

@aws-sdk/client-cloudcontrol@3.1002.0
  → @aws-sdk/core@3.973.19
    → @aws-sdk/xml-builder@3.972.10
      → fast-xml-parser@5.4.1 ← vulnerable

After the upgrade:

@aws-sdk/client-cloudcontrol@3.1013.0
  → @aws-sdk/core@3.973.22
    → @aws-sdk/xml-builder@3.972.14
      → fast-xml-parser@5.5.6 ← patched

No code changes were required — this is a version bump in deno.json and the resulting deno.lock update. Type-checking (deno check) passes cleanly.

Test plan

• deno check main.ts passes
• CI passes (type-check, lint, tests)
• deno run audit no longer flags fast-xml-parser

🤖 Generated with Claude Code

Installation

macOS (Apple Silicon):

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

What's Changed

• feat: warn when model definitions use env var expressions (#784)

Summary

Closes #759.

When a model definition uses ${{ env.* }} expressions, it's easy to
accidentally run a prod-named model against dev infrastructure (or vice versa)
because env vars silently change which environment the model targets. Data
artifacts stored under that model name then contain results from the wrong
environment, contaminating workflows that reference data.latest("prod-jenkins", ...).

This PR adds validation warnings (not failures) that surface env var usage
in two places:

• swamp model validate — lists which fields reference which env vars
• swamp model method run — emits warnings before execution starts

What it looks like

Log mode (model validate):

Validating: prod-jenkins (command/shell)
  ✓ Definition schema
  ✓ Global arguments
  ✓ Method arguments
  ✓ Expression paths
  ✓ Check selection
  ⚠ Environment variables detected
    globalArguments.shell uses JENKINS_SHELL
    methods.execute.arguments.run uses JENKINS_BASE_URL
    → Data stored under this model will vary depending on these
      environment variables at runtime. Consider using separate
      models per environment, or vault.get() for sensitive values.
Summary: 5/5 validations passed, 1 warning
Result: PASSED

JSON mode (model validate --json):

{
  "warnings": [
    {
      "name": "Environment variables detected",
      "message": "Data stored under this model will vary...",
      "envVars": [
        { "path": "globalArguments.shell", "envVar": "JENKINS_SHELL" },
        { "path": "methods.execute.arguments.run", "envVar": "JENKINS_BASE_URL" }
      ]
    }
  ]
}

Method run warnings:

WRN  Environment variables detected in model definition
WRN    "globalArguments.shell" uses "JENKINS_SHELL"
WRN    "methods.execute.arguments.run" uses "JENKINS_BASE_URL"
WRN  "Data stored under this model will vary..."

Design decisions

• Warning, not error — env vars are a legitimate feature, we just want
  visibility. Validation still passes.
• Shows field paths and env var names, but not values — values could be
  secrets.
• Suggests alternatives — separate models per environment, or vault.get()
  for sensitive values.
• Surfaces during method run too — so agents/users see the warning even if
  they skip validation.

Changes

New files:

• src/domain/models/env_var_detector.ts — standalone function that scans
  definitions for ${{ env.* }} patterns
• src/domain/models/env_var_detector_test.ts — 6 unit tests

Domain layer:

• validation_service.ts — added ValidationWarning value object,
  EnvVarUsageDetail interface, ModelValidationOutcome return type.
  validateModel() now returns {results, warnings}.
• execution_service.ts — updated to destructure the new return type

Application layer (libswamp):

• validate.ts — added ValidationWarningData type, warnings field to
  ModelValidateData, totalWarnings to ModelValidateAllData
• run.ts — added env_var_warning event to ModelMethodRunEvent, emitted
  after model resolution
• mod.ts — exported new types

Presentation layer:

• model_validate.ts — renders warnings with yellow ⚠ markers in log mode,
  includes warning count in summary
• model_method_run.ts — handles env_var_warning event in both log and JSON
  renderers

Skill update:

• .claude/skills/swamp-model/SKILL.md — added "Handling Validation Warnings"
  section instructing AI agents to STOP and ask the user before proceeding when
  warnings are present. Updated workflow steps and method run docs.

User impact

• Existing models without env vars: zero change — no warnings, same output
• Models with env vars: validation now shows a yellow warning with actionable
  guidance. Validation still passes.
• AI agents (Claude, etc.): the skill update and CLI warnings together ensure
  agents pause and confirm with the user before running models that depend on
  environment variables — which was the original reporter's key concern.

Test plan

• 3401 existing tests pass (no regressions)
• 6 new unit tests for env var detection
• 1 new integration test for warning propagation
• Manual verification with compiled binary:
  • model validate on clean model → no warnings
  • model validate on model with env vars → warning with paths + var names
  • model validate --json → structured warnings array
  • model validate (all) → warning count in summary
  • model method run with env vars → warnings before execution

🤖 Generated with Claude Code

Co-authored-by: Blake Irvin blakeirvin@me.com

Installation

macOS (Apple Silicon):

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

What's Changed

• The Machine: Fixup issues with the machine (#783)

Installation

macOS (Apple Silicon):

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

What's Changed

• The Machine: Improving the machine that builds the machine (#782)

Cleaning up claude.md and adding hooks and updating CI

Installation

macOS (Apple Silicon):

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