decapod 0.47.13

Decapod is the daemonless, local-first control plane that agents call on demand to align intent, enforce boundaries, and produce proof-backed completion across concurrent multi-agent work. 🦀
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

# STORE_MODEL.md - Store Purity and Threat Model

**Authority:** interface (store semantics + safety model)
**Layer:** Interfaces
**Binding:** Yes

This document defines store selection semantics and the safety model for preventing cross-store contamination.

---

## 1. Stores

Decapod has two stores (state roots):

- user store: `~/.decapod`
- repo store: `<repo>/.decapod/project`

The store is part of the request context. A command that mutates state is not well-defined unless the store is well-defined.

---

## 2. Assets (What We Protect)

- user store privacy: a user starts blank and should not inherit repo ideology or backlog
- repo store reproducibility: repo state should be deterministically rebuildable from repo-tracked artifacts where declared
- derived state integrity: derived artifacts should never be treated as source-of-truth
- provenance: every mutation should be attributable to an actor and a store context (planned: audit trail)

---

## 3. Threats (How Systems Die)

- accidental contamination: repo dogfood tasks appearing in user store
- ghost state: agent writes to a store without intending to (wrong root, implicit defaults)
- split brain: multiple "canonical" stores or parallel tooling
- provenance loss: mutations without a record of who/when/why

---

## 4. Guarantees (Contract)

All guarantees here are registered in `interfaces/CLAIMS.md`.

- blank-slate (claim: claim.store.blank_slate): a fresh user store has no tasks unless the user adds them
- no auto-seeding (claim: claim.store.no_auto_seeding): repo store content must never appear in the user store automatically
- explicit store selection (claim: claim.store.explicit_store_selection): `--store` is the preferred selector; `--root` is an escape hatch and must be treated as dangerous
- `.decapod` CLI-only access (claim: claim.store.decapod_cli_only): agents must not read/write `<repo>/.decapod/*` directly; use `decapod` commands

---

## 5. Red Lines (Unacceptable Behavior)

- writing repo backlog into user store
- silently switching stores mid-session
- creating alternate state roots outside `.decapod`
- direct read/write of `<repo>/.decapod/*` files outside `decapod` CLI surfaces
- claiming compliance/verification without running a proof surface

---

## 6. Routing (Where This Is Used)

- Control plane patterns: `interfaces/CONTROL_PLANE.md`
- Subsystem surfaces: `core/PLUGINS.md`
- Proof doctrine and authority: `specs/SYSTEM.md`

---

## Links

### Core Router
- `core/DECAPOD.md` - **Router and navigation charter (START HERE)**

### Authority (Constitution Layer)
- `specs/INTENT.md` - **Methodology contract (READ FIRST)**
- `specs/SYSTEM.md` - System definition and authority doctrine
- `specs/AMENDMENTS.md` - Change control

### Registry (Core Indices)
- `core/PLUGINS.md` - Subsystem registry
- `core/INTERFACES.md` - Interface contracts index

### Contracts (Interfaces Layer - This Document)
- `interfaces/CONTROL_PLANE.md` - Sequencing patterns
- `interfaces/DOC_RULES.md` - Doc compilation rules
- `interfaces/CLAIMS.md` - Promises ledger
- `interfaces/GLOSSARY.md` - Term definitions