run-listlisted

<!-- ENGINE FILE — one source, two cuts. Installation-specific values (path roots, hooks, governance rule names, reference docs) are referenced generically as `cfg:<key>` and resolved by the config layer: `config/house-config.md` (house cut) or `config/house-config.example.md` (public example). Shared pipeline vocabulary lives in `shared/pipeline-conventions.md`. The copy-in template lives at `assets/template.md` beside this file. Refresh trigger: change to the run-list disciplines, the section shape, or the house patterns it references. --> # Build Run-List ## What this is, and why it works A build run-list is **one durable markdown file** that plans, drives, and logs a multi-session build. You write it once at kickoff and maintain it as sessions land. It is the single source of truth for "what are we building, in what order, and where does each piece stand." The reason to spend the upfront effort: this one file does four jobs at once. 1. **It plans** — a dependency graph + an ordered session table means you never have to re-derive "what's next" or "what's this waiting on." 2. **It drives** — each session carries a *paste-ready prompt*, so a fresh work session self-orients from the file instead of you re-explaining the seam every time. 3. **It logs** — verified-completion ticks + commit hashes turn the plan into a build log as you go, with zero extra writing. 4. **It becomes the artifact** — a finished run-list is clean raw material for a