Appendix

Glossary

Terms as used in this manual.


Levels of Work

Problem: An undefined challenge to solve. No clear solution yet. Requires discovery to define what success looks like.

Initiative: A defined objective that solves a Problem. Weeks or months of work. Decomposes into Epics.

Epic: A major phase of an Initiative. Delivers a meaningful milestone. Runs through P-Cubed. Produces Tasks.

Task: A specific action. 1-2 days of focused work. Clear acceptance criteria.


P-Cubed

P-Cubed: Prepare → Prove → Produce. A mnemonic for executing an Epic; each phase has an exit criterion.

Prepare: The phase where you build understanding, surface tradeoffs, and plan the work. Exits when the critical unknowns are named, each with the evidence that would resolve it.

Prove: The phase where you validate load-bearing decisions before committing. Exits when the highest-risk unknown has a meaningful answer, and "no" counts.

Produce: The phase where you execute tasks, verify against criteria, and ship. Exits when the capability exists and the proof artifacts are deleted, isolated, or consciously promoted.

Discovery: The sub-phase of Prepare where you explore the problem space, ask questions, and build understanding.

Spike: A time-boxed experiment to validate a technical assumption or approach.


Architecture & Design

Load-Bearing: A decision that's hard to change after you build on top of it. Requires extra rigor upfront.

Architecture: The structural decisions in a system. Database schema, service boundaries, core abstractions. Hard to change.

Design: The surface decisions in a system. API shape, UI components, implementation details. Easier to change.

Tradeoff: What you give up when you choose one approach over another. There's no free lunch.


The Body Plan

Body Plan: Organism-level design: what parts exist, where the joints are, what connects to what, and what each part refuses to know. Architecture is the load-bearing subset of the body plan.

DNA: Implementation inside a part: methods, data structures, conditionals.

The Drawing Test: "Can I draw this system?" A hidden body plan, tangled arrows, or one box with every arrow are each a diagnosis.

Refusal List: What an object declines to know. An object without one is not designed yet; it is merely named.

Joint: A designed, visible connection or substitution point where the body plan intends one part to connect to another. Constructor injection is the common form, not the only one.

Seam: Feathers' term: any place you can alter behavior without editing the code there, often found rather than designed. Not a synonym for joint or contact surface.

Contact Surface: The one genuinely new boundary where the system first receives from, emits to, or translates for something outside itself or across a new path. The walking skeleton proves it first. More than one per feature is a scope warning.

The Second Nervous System: The body-plan failure mode: a parallel structure grown beside the one that already exists. Two ways to route the same kind of request.

Rockdrill / Walking Skeleton: Rehearse before you execute; the Prove phase made concrete. The walking skeleton (Cockburn) is the thinnest end-to-end implementation exercising every layer, and it is the rockdrill of a feature: it targets the contact surface first.

Anatomy of Tests: Sort tests by what each proves, not what type it is. An acceptance test proves the body moves; a unit test proves a joint or reflex; a contract spec proves socket compatibility; a fake proves your code can use the socket without the real limb; a live run proves the outward write lands.

Contract Spec: A test that proves socket compatibility between two parts. The real adapter and its substitute run the same examples; CI goes red if they diverge.

Fake / Stub / Mock: A fake is a working substitute; a stub is a canned answer; a mock is an expectation on an outgoing send. Not interchangeable words.

Gamed Green: A spec that builds the object differently from production, or asserts something a hard-code can satisfy. The green lies about what it proves.

Unverifiable Green: An honest-red assertion placed mid-example prevents everything after it from executing. The green lies about what even ran.

Latent vs Live: Triage for hazards. Live if a current path can reach it; latent if reachable only through legacy or raw paths. Guarding a latent hazard is defensive hardening, not an incident fix.


Practices

TDD: Test-Driven Development. Write the test first, then implement to make it pass.

GOOS: Growing Object-Oriented Software, Guided by Tests. Outside-in, mockist-style TDD.

Trunk-Based Development: Short-lived branches, frequent integration to main. Every commit is deployable.


General

Done: The acceptance criteria are met. Not "feels done." Criteria met.

Acceptance Criteria: The specific, checkable conditions that define when a Task is complete.

Mental Model: Your internal representation of how a system works. How you predict behavior.


Notes

Add terms as you encounter them.