Operator Runbooks¶
This index lists every operator runbook: a focused, step-by-step procedure for a routine task in a Brain Factory project. Use it to find the right guide, run it, and record the outcome in GitHub.
New to the project? Start with
How Brain Factory works for the five-minute
tour, then come back here. Runbooks are the how layer: they sit below the
what of docs/operating-model.md (how work flows day
to day) and the why of
docs/framework-continuity-and-memory.md
(the durable principles the system preserves across sessions).
Runbook flow¶
This diagram shows how an operator picks a runbook from this index, runs it, validates the result, and writes the outcome back to a durable artifact.
flowchart LR
A[Operator task] --> B[Open runbooks index]
B --> C{Select runbook}
C --> D[Execute procedure]
D --> E[Run required validation]
E --> F[Update linked issue or PR]
Available runbooks¶
-
Framework lifecycle map and operator journey — the end-to-end map of all eight operating stages, from first bootstrap through active work, handoff, and resume. Includes a quick-reference stage table and a "where am I?" self-check. Start here if you are unsure which other runbook you need. Pair it with Framework state milestones for event-style transition acknowledgments and Searchable continuity and artifact indexing guidance for fast artifact lookup.
-
Create continuity snapshot — create or refresh a structured continuity snapshot so handoff/resume state is explicit, inspectable, and linked to durable artifacts.
-
Resume from a handoff packet — resume paused work in a strict order, validate setup/readiness posture, reconcile blockers and deferred/queue posture, and select one next safe action.
-
Surface-specific startup guides — choose the shortest startup path by execution surface (GitHub cloud agent, local VS Code/Copilot, or lightweight mobile/operator oversight), with explicit limits and escalation guidance.
-
Local-first quickstart (solo developer) — the shortest path from a fresh clone to a ready-to-work solo setup: recommended default profile, minimum field edits, exact command sequence, readiness confirmation, and safe deferrals.
-
Apply setup — apply a setup intent and confirm a coherent "ready to work" state using
apply-setup.shandcheck-setup-readiness.sh. -
Apply framework setup — setup-productization discoverability entrypoint that links to the executable setup flow and readiness validation scripts.
-
Prompt-to-setup bootstrap — translate natural-language setup needs into setup intent/profile choices, then run setup application and readiness verification.
-
Start a framework change — kick off any change to the framework (doc, workflow, or ADR-worthy decision).
-
Open an issue — choose the correct issue template, fill required fields, and confirm execution readiness before assigning.
-
Handle a Dependabot PR — triage and merge the weekly GitHub Actions updates.
-
Run the framework health audit — re-run the audit captured in
docs/framework-health.md. -
Operate the framework task queue — maintain queue state and recover merge-driven next-task preparation.
-
Run the queue health check — detect and recover from queue drift using the drift-detection script and manual checklist.
-
Respond to a support intake — acknowledge, classify, and route a new support-intake issue.
-
Handle security-sensitive intake — triage potential vulnerabilities or sensitive findings with safe routing.
-
Promote an external AI artifact — normalize an external AI output (Claude Code, ChatGPT, transcript) into a durable repository artifact.
-
Close out a multi-agent handoff — confirm acknowledgement, verify charter handoff elements, and clean up branches/PRs.
-
Maintain framework alignment — run an upgrade review cycle, classify framework changes for your repo, and recover from missed queue/issue closure after merge.
-
Triage the stale-branch report — review the weekly dry-run output from the stale-branches workflow and decide what to do with each flagged branch.
Adding a new runbook¶
- Keep each runbook focused on one task, end to end.
- Use short numbered steps and checklists rather than prose.
- Cross-link the relevant operating-model doc, ADR, or charter section.
- Add the new runbook to the list above. CI checks that every runbook here stays linked, so do not remove or rename existing entries.