Skip to main content

Swamp Adoption

@webframp/swamp-adoptionv2026.07.26.1· 6d agoMODELS
01README

Guides new users through mapping their domain onto swamp primitives. Conducts structured discovery interviews, produces versioned extension designs, and generates implementation scaffolds.

Uses swamp to teach swamp — the adoption journey itself is modeled as typed, versioned state.

02Release Notes

2026.07.26.1

Changed: Extensions scaffolded by this model now pin @systeminit/swamp-testing at 0.20260604.20, the current release, instead of 0.20260504.10. The old pin was hard-coded in the generated deno.json, so every extension created through the adoption workflow started life on a test library that was three releases behind and inconsistent with the rest of the repo.

Upgrade note: Nothing to do for extensions already scaffolded — they keep the pin they were created with. Update their deno.json and regenerate deno.lock with deno install if you want them on the current version.

03Models1
@webframp/swamp-adoptionv2026.07.18.2swamp-adoption/mod.ts
fn discover()
Conduct a structured discovery interview to map the user's domain landscape. Guide the conversation through these phases: 1. SYSTEMS INVENTORY Ask: "What systems do you interact with daily? Include APIs, databases, SaaS platforms, CLI tools, and internal services." For each system, capture: name, type, and how they authenticate. 2. INTERACTION PATTERNS For each system, ask: "What do you DO with this system?" Capture verbs (read, write, deploy, monitor, rotate, audit), direct
fn design(system?: string)
Design a swamp extension based on the discovered landscape. Guide the conversation through these phases: 1. SCOPE CONFIRMATION Read the landscape resource. Present suggestedFirstExtension and reasoning. Ask: "Does this match your priority? If not, which system should we tackle first?" If a 'system' argument is provided, use that as the target. 2. METHOD DISCOVERY For the target system, review its interactions from the landscape. Map each verb to a method name (e.g., "read certi
ArgumentTypeDescription
system?stringTarget system name from landscape (uses suggestedFirstExtension if omitted)
fn scaffold(outputFormat: enum)
Generate implementation files from an extension design. Reads the extensionDesign resource and produces: - manifest.yaml with proper CalVer version, labels, platforms - deno.json with standard task configuration - extensions/models/<name>/mod.ts with Zod schemas, resource definitions, method stubs - extensions/models/<name>/mod_test.ts with structure and argument validation tests The scaffold provides a working starting point that passes deno check and deno lint. Each generated file includes T
ArgumentTypeDescription
outputFormatenumWhether to write files as a resource or print to stdout
fn next()
Suggest the next extension to build based on landscape analysis and the current design. Reads the landscape and the current extensionDesign resource. Filters out the system covered by the current design, then ranks remaining systems by: 1. Pain level (blocking > significant > minor > none) 2. Uses the highest pain across all interactions per system Logs advisory output with the recommendation and reasoning. Does not write any resource — purely advisory.

Resources

landscape(infinite)— Discovered system landscape from the user's domain interviews
extensionDesign(infinite)— Versioned extension design produced from landscape analysis
scaffold(24h)— Generated file scaffold for an extension design
04Previous Versions5
2026.07.18.2

2026.07.18.2

Added: An upgrades array entry (no-op) to mod.ts for proper typeVersion tracking on existing instances. No schema or behavior changes.

2026.07.18.1

Changed: Added @module-level JSDoc documentation to mod.ts. No runtime behavior change.

2026.07.18.1

2026.07.18.1

Changed: Added @module-level JSDoc documentation to mod.ts. No runtime behavior change.

2026.06.23.1
2026.06.15.1
2026.06.05.1
05Stats
A
100 / 100
Downloads
7
Archive size
16.7 KB
  • Has README or module doc2/2earned
  • README has a code example1/1earned
  • README is substantive1/1earned
  • Most symbols documented1/1earned
  • No slow types (deprecated)1/1earned
  • Dependencies pass trust audit2/2earned
  • Has description1/1earned
  • Platform support declared (or universal)2/2earned
  • License declared1/1earned
  • Verified public repository2/2earned
06Platforms
07Labels