Appendix B — Glossary

Terms with local meaning — reach for this when a word is doing more work than it seems to.

• Blast radius — the scope of consequences if an action goes wrong; used to decide whether to confirm with the user before running a destructive command. See §9.
• Blue-green deploy — a deployment pattern that runs the new version ("green") alongside the old ("blue"), health-checks it, flips traffic, and keeps the old version warm for rollback. (See DevOps Playbook Phase 4.)
• Conventional commits — a commit-message convention (feat:, fix:, chore: …) that machine tools can parse to decide version bumps and changelog sections. (See DevOps Playbook Phase 5.)
• Health endpoint — an HTTP endpoint that reports the service's own dependency status and build identity (git SHA, version), distinct from a lightweight status check used by load balancers. (See DevOps Playbook Phase 7.1 and Gotcha #8.)
• release-please — a GitHub Action that reads conventional commits, opens Release PRs, and publishes GitHub Releases automatically. (See DevOps Playbook Phase 5 and Gotchas #3–#5.)
• Brainstorm — the second step of the loop; a skill invocation that turns a vague idea into a written spec. See §5.
• Diagnostic surface (the lab) — the persisted traces, replay playgrounds, and exportable diagnostics that let a bug be diagnosed by reading evidence instead of re-reasoning about source. Built before the fix when a bug class recurs. See §10.
• Elicitation — a pre-code session in which the human makes the agent state its model of the product out loud, grills it, and corrects it while corrections cost one sentence. See §4.
• Explore — the first step of the loop; the greps, directory listings, and survey-agent passes that reconcile the plan with the actual codebase before planning begins. See §5.
• Instructions file (CLAUDE.md, AGENTS.md) — the project-instructions file the harness loads automatically as system context at the start of every conversation. CLAUDE.md in Claude Code; AGENTS.md is the emerging cross-tool convention (honored by Codex, opencode, and a growing list); GEMINI.md and .cursorrules fill the same role elsewhere. The playbook says "instructions file" in rules and CLAUDE.md in field notes — that's what the file was called when the scar formed. See §2 and §3.
• Field note — a short inline vignette that grounds a rule in a real event from the case studies; appears in the human layer of every two-layer chapter. See How to read this playbook.
• File-boundary parallelism — a parallel-agent coordination model where each agent owns a disjoint set of files, assigned before any work begins, with shared touchpoints deferred to a post-parallel merge pass. The alternative to branch-level or worktree-level isolation. See §13.
• Flexible skill — a skill whose steps are guidelines to adapt to context, as opposed to a rigid skill that must be followed exactly. See §7.
• Hook — a shell command the harness executes automatically on a named event (e.g., post-tool-use, pre-commit) without waiting for an explicit agent invocation. See §3.
• Memory — one of four typed persistent notes (user, feedback, project, reference) that an agent writes and reads across conversations to preserve context beyond a single session. See §6.
• Model tier — the capability/price class of the model doing a given piece of work; chosen by the shape of the work (mechanics go cheap behind gates, voice and synthesis go expensive), not by diff size. See §2.
• Probe — the command whose output proves a belief about the system (the API call that returns the branch-protection object, the test error that arrives in the tracker). Beliefs about protections carry their probes; audits re-run them. See §6 and §15.
• Merge point — a shared file (config registry, main entrypoint, integration test, dependency manifest) that every parallel agent's work eventually has to touch. In a well-planned fan-out, merge points are owned by a single single-threaded pass after the parallel phase finishes, not edited by the parallel agents. See §13.
• Pin — a one-sentence extractable lesson marked inline with *Pin:*. The distilled version of a chapter's argument, written to survive when the surrounding narrative is forgotten — small enough to remember, specific enough to act on, structured so an agent can lift it into memory unchanged. When a pin contradicts the surrounding prose, the pin wins. See How to read this playbook.
• Plan — a written, step-by-step implementation guide derived from a spec that defines how to build something before any code is touched. See §14.
• Report-only fleet — a set of parallel agents dispatched to audit and report (docs-vs-code, security, debt, devops) without fixing; isolated from the working tree because "report-only" describes the assignment, not the side effects. See §13 and §15.
• Rescue protocol — the three-horizon recovery playbook (next hour, next day, next week) for teams whose agent partnership has broken down. Not an essay — a checklist. See §12.
• Revert question — "would these tests pass if the change were reverted?" — the ten-second check that separates verification from verification theater. See §8.
• Rigid skill — a skill whose steps must be followed exactly in order, with no discretionary adaptation. See §7.
• settings.json — the harness-level configuration file that controls which tools are available, what permissions are granted, and which hooks are registered. See §3.
• Skill — an invokable, named procedure with a defined discipline; the harness construct, not the colloquial sense of "ability." See §7.
• Spec — a written design contract that describes what to build, captured before planning begins; a plan covers how to satisfy a spec. See §14.
• Subagent — a fresh child agent dispatched with a curated context window, used to protect the parent's context or to run isolated work in parallel. See §13.
• Two-stage review — the delegated-work review pattern: a spec-compliance reviewer (does the diff deliver every requirement, and does the verification witness it?) followed by a code-quality reviewer (what is wrong now or will be wrong someday?), neither fed the implementer's self-report. See §13.
• The loop — the canonical development cycle: explore → brainstorm → plan → TDD → verify → commit → retro; every feature passes through every step. See §5.
• Three-layer thesis — the playbook's core division of labor: the pipeline handles mechanics, the agent handles elaboration, the human handles craft. Every rule in the document is, at root, a maneuver to keep each layer in its lane. See The thesis.
• Two-layer format — the playbook's chapter convention: an imperative rule at the top (the agent layer) followed by narrative explanation and a field note (the human layer). See How to read this playbook.
• Wave pattern — a parallel-work rhythm in which the cheapest, most mechanical items run first — as a load test for the build, config, and test harness — before committing agents to heavyweight implementations. "Check the parachute before jumping." See §13.