The Layered Model
Darwinian Minds composes effective harness state from a fixed stack of layers, then materializes it into downstream agent tools. The layers compose deterministically; later layers override earlier ones for keys they touch.
Composition layers
- Packaged source.
registry/config.json,registry/mcp-servers.json, repo-native skills, and installed inventory content provide policy and available definitions. Availability is not activation. - Machine intent. Strict
drwn.machineV1 selects an immutable profile plus explicit skill and MCP IDs. Only approved policy fields merge into packaged policy. - Project roots. Cards compose into one Blueprint; a project installs root alternatives and selects at most one active Worker closure.
- Project overlays. Strict
drwn.project-configV1 may add explicit skills, MCP definitions, extensions, targets, and hook controls. Excludes win last. - Projection. Machine and project writes are separate pure projections with separate ownership records. Machine capabilities may remain ambient in a project session, but never become project declarations.
Effective state is computed by buildEffectiveState. Inside a configured project, machine capability intent is intentionally excluded: the base is packaged project-safe policy, then the selected Card closure and project overlays. Outside a configured project, explicit machine intent applies.
Write-time resolution rules
When drwn write resolves a skill name to a filesystem path, it consults three layers in fixed order:
- Locked card — any entry in
card.lockwhose manifest declares the skill name. Resolves to the immutable card store path. - Available inventory source — repo-native scope dirs (
skills/{shared,claude-only,codex-only,experimental}) then installed bundles. - Missing — surfaces as a typed write-time hard fail; no downstream mutation.
Cards win over other available sources at project write time. A Card that declares a skill in the selected closure shadows any same-named repo-native or package-backed source. The alternative source is announced as also available: in dry-run output but never written.
Layered reproducibility (the bigger picture)
drwn cards pin harness state — the skills, MCP servers, extensions, and downstream targets a project should run on. They do not pin the surrounding environment. For full environmental reproducibility, layer drwn with tools that own the other layers:
Layer 8: drwn cards — harness state (this tool)
Layer 6: Docker / Compose — service stack (Postgres, Redis, etc.)
Layer 4: Flox or Nix — Node, Python, system libs, shell hooks
Layer 3: asdf / mise / Flox — runtime / toolchain versions
Layer 2: pnpm / Cargo / pip — app dependencies + lockfile
What cards pin:
- card versions and content-tree integrity in
card.lock - per-card bundled skill attribution in
card.lock - inline content shipped in cards (skills, MCP server definitions) via sha256 content hashing
- the project overlay
What cards do not pin:
- agent tool versions (Claude Code, Codex, Cursor) — vendor-controlled distribution
- MCP server runtime resolution if a card's
argsusesnpx -y <pkg>without a version pin (the shipped registry pins these; card authors should too) - CLI dependencies of skills (
bd,markitdown,git, etc.) - runtime, system libraries, or shell environment
Recommended composition for full reproducibility: drwn apply for the harness, Flox/Nix (or asdf/mise) at the shell layer to pin Node/Python/system libs, and Docker Compose at the service layer for runtime dependencies. Each tool pins what it owns.
See also
- Local Store — what each path under
~/.agents/drwn/stores - Materialization — how effective state is written to downstream tools
- Ownership and Write Records — drwn-owned vs user-owned cleanup discipline
- Cards — the card subsystem in depth
.ai/knowledges/10_drwn-cli-architecture.md— full as-built architectural reference