Memory Index

Memory files are post-implementation artifacts — what actually happened. They are the authoritative source of truth for system behavior and design decisions, maintained by /fab-continue (hydrate) after each change is completed.

Contrast with docs/specs/index.md: specs are pre-implementation — what you planned. Specs capture conceptual design intent and are human-curated.

Generated by fab memory-index — do not hand-edit. Re-run after any memory write; the output is byte-stable. Per-file descriptions live in each file's description: frontmatter.

New here? Start with the README for setup and a walkthrough. For terminology, see the Glossary.

Domain	Description
_shared	Cross-cutting concerns spanning all domains — config.yaml/constitution/5 Cs and the context-loading convention (always-load layer, SRAD, selective loading)
distribution	How the kit is packaged, shipped & configured — .kit/ structure, three-binary architecture, Homebrew, releases, migrations, /fab-setup bootstrap
memory-docs	Authoring docs/memory & docs/specs — the hydrate skills (ingest + generate), spec backfill, artifact/memory templates, and the specs index
pipeline	The change pipeline — stage lifecycle & state machine, planning/clarify/execution skills, schemas, preflight (intake → apply → review → hydrate → ship → review-pr)
runtime	Agent & process runtime — fab pane primitives + the @rk_pane_agent_state tmux pane-option agent-state reader (agent-state production divested to run-kit; .fab-runtime.yaml deleted) + the operator coordination skill (tmux-bound interactive path), the interactive-spawn shell fallback (; exec $SHELL) and agent_exited operator delta, and fab dispatch, the two-mode manager for CLI-dispatched stages (headless, or a tmux-pane worker in a carved worker column, resolved per invocation)