The cartographer of work
The Planner draws the map. Given a briefing and a domain, the Planner reads the terrain. The local tree, the available extensions, the precedent of nearby work. They propose a path. They don't walk it. They don't own it. They draft it, present it, exit. The Ruler walks the path. The Planner is the map maker who made it possible.
The Planner is not persistent. They run when hired, do their work, and exit. The next time the Ruler needs decomposition, a fresh Planner spawns with a fresh briefing. Plans persist. Planners don't.
This is deliberate. A persistent Planner would accumulate assumptions across cycles and start defending past plans. A transient Planner approaches each briefing fresh, with no ego attached to the prior plan. The Ruler holds continuity. The Planner brings fresh eyes.
This is the same principle that makes positions durable but occupants replaceable elsewhere in TreeOS. Plans persist as architectural facts. The cognition that produced them does not. Each new Planner is a fresh observer, free to see the work as it is rather than as it was framed.
Three principles shape every Planner emission.
The Planner doesn't know what code is, what a chapter is, what a civic action is. They know shape. Leaves vs branches, dependencies, scope, ordering. The workspace extension supplies the domain semantics. The Planner stays general.
This is what lets the same Planner primitive serve a code project, a book, a civic coordination. The Planner doesn't choose a different reasoning style for different domains. It reasons about decomposition shape, and the workspace extension provides the domain content the reasoning shapes itself around.
Every plan emission carries a reasoning block. The Planner explains why this decomposition, what alternatives were considered, what tradeoffs were accepted. The Ruler reads the reasoning before the steps. Without the reasoning, the plan is just a list.
A plan should reach a working state early and add layers. Core mechanics first, then variety, then edge cases. The Planner orders steps so each successful step leaves the work more functional, not just more complete.
This is depth then pullback applied to decomposition. Get to the core that makes the whole thing real, then layer outward.
One job, one tool. The Planner runs through four phases and exits.
The Ruler hires the Planner with a briefing. The user's request, the scope's lineage if sub Ruler, any parent contracts in force. The Planner reads it carefully.
The Planner calls get-tree-context to see what's already at this scope. Existing nodes, recent notes, the shape of nearby work. Plans build on what's there.
For sub Ruler scopes, the Planner also reads parent contracts in force at this scope and the lineage block showing which step of the parent's plan this sub Ruler is expanding. The Planner plans within those constraints. Sub plans build on the parent's plan, never contradict it.
The Planner thinks. What's the natural shape of this work? Where does it split? What stays as a leaf? What needs its own sub Ruler? What's the right ordering? The reasoning comes first. The steps follow from it.
The Planner calls governing-emit-plan with the reasoning and the structured step list. The plan persists to the Ruler's plan node. The Planner exits. Their work is done.
A plan has two parts. Reasoning, in prose. Steps, structured.
A paragraph explaining the decomposition. Why this split. What alternatives were considered. What's the ordering rationale. The Ruler and the user both read this before approving. It's the part that makes the plan reviewable rather than just a checklist.
Each step is either a leaf (concrete work done at this scope by a Worker) or a branch (sub domains that promote to sub Rulers and run their own full lifecycle). Steps run in order. Branch steps fan out in parallel.
Briefing. "build me a Flappy Bird battle royale game." Here's roughly what the Planner emits.
Reasoning
For a Flappy Bird Battle Royale, decomposing by separation of concerns. Core (rendering, physics, game loop), entities (player, AI, obstacles as data driven objects), and battle royale (arena, power ups, elimination). The split is by stability of contract. Core changes least, battle royale changes most. Considered a flat decomposition with all features at root, rejected because the entity system needs its own internal coordination (player and AI sharing physics) that would leak into core if not bounded. Top level files (index.html, package.json, vite.config.js) anchor the web stack. Progressive delivery. Core must produce a playable MVP first (single bird, gravity, pipes), then entities add obstacle variety, then battle royale layers arena shrinking and power ups. If we run out of time, MVP with just core is still a Flappy Bird. Without progressive delivery, we'd have a half built battle royale that doesn't fly.
Steps
The Ruler reads this, presents the plan card to the user, and waits for approval. On approval, the Ruler hires the Contractor to commit shared vocabulary across the three branches.
The Planner doesn't ratify, dispatch, or supervise. They draft and leave. This isn't laziness. It's a load bearing separation.
If the Planner stuck around to defend their plan, every revision would become an argument. If the Planner kept watch over execution, they'd start advocating for their decomposition over what the work was actually showing. Separating drafting from ratification keeps each role honest. The Ruler ratifies because they own the scope's outcomes. The Planner drafts because they see the shape clearly. Different judgment, different roles.
When the plan turns out to need changes, the Ruler hires a fresh Planner with a revised briefing. The new Planner reads the existing plan as context but isn't bound to defending it.
The cartographer drew the map. The map persists. The cartographer moves on. The next territory needs its own map, drawn fresh.