Plan File Schema · v1.8.4

Fixed spine, adaptive flesh

Pick your atom's archetype and risk tier, flip the flags that describe the work, and watch the plan assemble itself. A fixed spine of sections is always present (the live count is in the summary below). Every other section switches on only when its trigger fires, and stays out entirely otherwise. This is the whole idea of the schema, made clickable.

Archetype (pick one)

The surface you are building. It sets the length band, the diagram, and which sections switch on for you.

Risk tier (pick one)

How bad it is to get this wrong: blast radius times reversibility, not difficulty or size. It sets the scrutiny and which safety sections switch on.

Rigor (pick one)

How finished this must be, from a throwaway spike to a mission-critical deliverable. Orthogonal to risk. It scales the completeness sections; it never strips a safety section that risk turned on.

Traits (flip any that apply)

Your plan's sections

Every row of the schema's §8 quick reference, in document order (so the "Position" column is the row order plus the ↳ nesting). Spine (◆) is always present; a conditional shows a check when its trigger fires, or the trigger it waits on when it does not. The colored badge is the Agent Feed: EXECUTE feed the implementation agent, GUARD feed if budget allows, STRIP governance only, never fed. The dotted "as needed" row is the inline step-level templates.

This archetype

Where cross-atom dependencies and relationships live

Dependencies are not one section. They are a metadata pair plus four places in the body. Together they answer: what does this atom need, what does it block, and who else is affected.

what this atom needs

depends_on: in the metadata (a list of atom IDs), expanded in Context to Dependencies (§2.3.4) with each dep's status, complete or blocking. A blocking dep means the plan cannot be executed yet.

what this atom unblocks

blocks: in the metadata: the downstream atoms waiting on this one to land.

done, but needs wiring

Implementation dependencies (§2.3.6): structurally complete, yet only fully effective once another system is wired in. Kept separate from blocking deps so nobody mistakes "it compiles" for "it works end to end".

the shape of the reuse

Integration diagram (§2.3.7): what you own, the surfaces you reuse (grouped by the atom that owns them), and the downstream consumers that import you. The picture; the prose ripple is Cross-Cutting.

who breaks if you change a shared surface

Cross-Cutting Impact Ledger (§2.12a): one row per affected consumer, each with a disposition (no-op / update-in-this-plan / follow-up atom / accepted breaking). "Unknown blast radius" blocks approval at high risk.

the graph stays buildable

Dependency-Graph Integrity (§6.1, rule V-049, Error): depends_on and blocks form a DAG. No cycles (a cycle is unbuildable), no orphan deps (a reference to an atom that does not exist). The validator walks the edges and rejects both.

AMPHAREgoverned autonomy

the kit · the method · shapes · explorer · review · soak

This mirrors the schema's own rule set: the spine is §1, the conditional triggers are the §8 quick-reference and the per-section "When to include" rules, and the archetype notes are §7. The section list is advisory, not a validator: it tells you which sections a plan for this shape usually carries. When in doubt, the full reference is docs/PLAN_FILE_SCHEMA.md and the 5-minute on-ramp is docs/PLAN_QUICKSTART.md.