braidlisted

## Inputs - Files: a human-authored **braid plan** (JSON) describing a decomposition tree. Schema: [references/plan-format.md](references/plan-format.md). - Env: `RELAY_HOME` (defaults to `~/.relay`) locates relay run manifests; `--repo-slug` (or `BRAID_REPO_SLUG`) selects the repo's runs directory. - Script: `${RELAY_SKILL_ROOT:-skills}/braid/scripts/braid.js` (the only I/O boundary; the `lib/` fold and plan modules are pure). # braid > **v0 — experimental, read-only.** braid decomposes work deep and executes it flat. It does **not** dispatch, supervise, or couple to any runtime; ordinary `relay` runs do the work at the leaves and braid folds their durable evidence back up. Resuming braid in a new session? Start with [references/roadmap.md](references/roadmap.md); full rationale in [references/design.md](references/design.md). ## The idea **Decompose deep, execute flat.** One accepted goal becomes a *cheap* tree: internal nodes are pure structure with no lifecycle, and every leaf is one relay-able unit. A leaf is `done` only when its relay run reached durable truth (merged PR + closed issue) — never from a `worker_done` signal. A parent is `done` only when **every** child is `done`. That "done = fold of children's durable evidence" is braid's whole thesis; it is a recursive fold, not a state machine. ## Use when - You have one accepted goal that is too big for a single `relay` run and naturally splits into a tree of smaller relay-able pieces, and you want to track roll