Vision, then chunks, then pieces. A session claims a piece so nobody duplicates it, plans it if it needs a plan, builds it, and submits it. A person accepts it or returns it.
The shape
| Part | What it is | Who owns it |
|---|---|---|
| Vision | What the project is for, as versioned text. Every brief opens on it, and changing it is a decision only people make. | The owners |
| Chunk | A large slice of the work, with a scope (the paths it covers), tags, and the chunks it depends on. | One named person, always, even while an agent works on it |
| Piece | A small, self-contained part of a chunk, with a brief: the goal, what done means and the tests to write first. | Whoever claims it, inside the chunk's rules |
| Review | A piece of its own, published when a build is submitted, for another member to take. | A member other than the builder |
| Request | A small job about one chunk or piece, such as a question to research. One session takes it and answers in the item's room. | Whoever has usage to spare |
An agent can be given a chunk to run, but it can never be the one accountable for it. When an agent's claim lapses, the chunk stays with its person.
How a piece moves
Plan first, when it needs a plan
Some work can't start until the work before it is thought through. Anacreon treats planning as work of its own: claimed, submitted and accepted like a build.
- UnplannedWaiting for someone to plan it.
- PlanningA session has claimed it for planning.
- Plan submittedShort by rule, so a reviewer can judge it at a glance.
- PlannedA person accepted it. Never the plan's own writer.
Small pieces skip this: an owner marks them plan not needed. A plan names the interfaces its work provides and uses. Once accepted, changing one of those is no longer the planner's call: it becomes a proposal to everyone whose work depends on it. That is how accepted plans hold the map in place.
Ready means one thing
Every list, claim and explanation reads one definition of ready, so they never disagree. A dependency says what it needs from the item it points at.
| To do this | This must be true |
|---|---|
| Plan an item | Every item it depends on is at least planned. |
| Build an item | The item is planned, or marked plan not needed. Each dependency meets its kind: needs done means finished and accepted, needs planned means its plan is accepted, which is enough to build against its interfaces. A piece's chunk is planned too. |
| Take it at all | Nobody holds it, no open question or proposal holds it back, and your AI vendor is one the project allows. |
When something isn't ready, Anacreon says why and names the first thing to do. "To build step 3: plan step 1, which is open for planning." An agent looking for step 3 is offered that planning work first.
Who can do what
| Role | Can |
|---|---|
| Owner | Runs the project: sets the vision, authors chunks, invites people, sets roles, answers questions, accepts work. |
| Decision-maker | Answers the project's questions. Roles are given by an owner; nobody declares themselves one. |
| Member | Plans and builds, raises questions, proposes changes, reviews others' work. |
| Worker | Builds published pieces only. A worker's session is shown only the tools that work needs. |
The exact rules: claims Deeper
- A claim is renewed by the session's activity: its client renews it while it makes tool calls, and posting progress renews it too.
- An hour with neither lapses the claim. The item goes back to open with its branch and last progress kept, so the next taker resumes.
- Another session may force-release a holder that has been quiet for 15 minutes.
- A claim stops renewing once the session's commitment is spent, so a helper's hour really ends.
- Claiming takes the item atomically: two sessions racing for one piece can't both get it.
The exact rules: the plan standard Deeper
- A summary of one or two sentences, and links to the concepts around it rather than prose.
- At most seven numbered steps, one line each.
- A done-when someone outside can check, the tests, and what is out of scope.
- The whole plan within 2,500 characters. Builder detail belongs in the pull request.
- One refusal names every part that fails, so a writer fixes it in one pass.
- A chunk's plan is accepted by its accountable person or an owner. A piece's plan may also be accepted by a plan acceptor its chunk names. The writer may revise or withdraw a plan while it waits; each revision is kept.
The exact rules: submitting and reviewing Deeper
- Posting progress with done ends the claim and submits the item.
- A submitted build publishes the reviews its requirements name, as pieces. An independent review is required only where security is at stake.
- Reviewing over MCP must be done by a member other than the builder.
- A review with blockers returns the build. Its follow-ups are gathered into one piece per pull request.
- A chunk is submitted only once all its pieces are done, and accepted only by a person.
- Each kind of work (plan, build, review) can require a class of model at a minimum effort. Claims and usage reports are checked against it.
When the work is bigger than the map Being built
Any session can find that a piece is really three, or that a dependency nobody drew exists. It records a map change: what it found, with evidence, the change it proposes, and a revised estimate. A change inside one chunk is that chunk's call. A change that touches other chunks is proposed to them. A new chunk nobody planned is a question for people. Original estimates are never overwritten, so the record can tell an estimate that was wrong from work that grew.