Beads turn one feature into bounded work.

One note, one root

One independently mergeable feature gets one Yesod note and one root Bead. The root represents the complete planned outcome; its children break that outcome into units an agent can execute and verify.

This keeps the factory from confusing a long checklist with several independently deliverable features.

Child Beads and dependency order

Child Beads should be small enough to have a clear result, but substantial enough to represent meaningful progress. Dependencies between them make the execution order explicit—for example, define a data shape before wiring the interface that consumes it.

The result is a tree, not a flat to-do list:

feature note
└── root Bead: deliver the accepted feature
    ├── child: establish the underlying contract
    ├── child: implement the behavior
    └── child: verify acceptance and documentation

When work becomes another note

If a child can be accepted, delivered, or merged independently—and especially if other work should depend on it as a separate outcome—it should usually become its own feature note with its own root Bead. Cross-feature dependencies belong between notes; within-feature ordering belongs between Beads.

Why the note remains

Beads describe execution. They do not replace the original request, its provenance, discussion, status, or eventual outcome. The note remains the durable lifecycle record while Bead completion and run evidence accumulate around it.

Next: see how the planned tree receives a complexity classification.