Plan and workflow records
Plan objects, task state, changes, and session lineage stay readable in the control layer.
Workflow Doctrine
The agent is not the whole system by itself. The workflow matters because it gives the developer a repeatable way to shape, refine, verify, and land work instead of stopping at generated output.
The first step is to make the work honest. That means clarifying scope, constraints, risks, and the next executable slice before implementation starts.
The local loop is the lowest-cost way to learn the system. It keeps the first path understandable, avoids unnecessary infrastructure, and preserves a clean line between first-run learning and later shared coordination.
The workflow keeps planning records, code-history metadata, and object payload storage separate enough to inspect without turning the first loop into a storage lecture.
Plan objects, task state, changes, and session lineage stay readable in the control layer.
One local repo, two readable stores.
The split keeps planning lineage and code history inspectable without pretending every byte belongs in one database.
Snapshots, trees, blobs, and pack metadata describe the code-side object graph cleanly.
Honest progress means the developer can see what was attempted, what changed, what was verified, what still blocks acceptance, and whether the slice is truly ready to land.
Later paths add shared review, shared policy visibility, broader deployment surfaces, and public proof material. They extend the workflow, but they do not outrank the first local loop in the learning order.