🔨

The Worker

The hand of the work

Where the other four roles in Rulership coordinate, judge, ratify, and watch, the Worker is the role that actually produces. Ruler decides. Planner drafts. Contractor binds. Foreman manages. None of them write a file, compose a paragraph, or take a civic action. The Worker does. They execute leaf work under the contracts in force, and they're the only role whose output is artifact rather than coordination.

The producing role

Every other role in TreeOS is shaped around coordination. Making decisions about decomposition, scope, flow, ratification. The Worker is shaped around production. The Worker is the role where the abstract substrate meets concrete output. A file lands on disk. A chapter gets written. A civic agreement gets drafted. Until the Worker runs, nothing has actually been built.

This is also the role where TreeOS's general substrate becomes domain specific. Ruler, Planner, Contractor, Foreman are all domain neutral. Same primitive whether the work is code, prose, or civic coordination. The Worker is where workspace extensions specialize the substrate for their domain. The general role is the same. The tools, validators, and outputs are domain specific.

A specialized role

The Worker has a base mode that any workspace can extend. The base mode handles the role's universal mechanics. Read the briefing, read the contracts in force, read the local tree state, produce the output, emit completion. What gets specialized per workspace.

Tools

What the Worker can actually do. code workspace adds workspace-add-file, workspace-edit-file, package-add-dependency, run-test. book workspace adds chapter-write, character-define, timeline-update. civilization adds proposal-draft, agreement-publish, jurisdiction-define.

Validators

What counts as conformance to ratified contracts. code workspace validates syntax, type signatures, contract conformance, smoke tests. book workspace validates voice continuity, character consistency, timeline coherence. civilization validates jurisdictional authority, agreement legibility, precedent fit.

Output shape

What the Worker actually emits. code workspace emits files. book workspace emits chapters and metadata. civilization emits documents and recorded agreements. The shape is whatever the domain produces.

Briefing language

How the Worker is told what to build. code workspace briefings reference contracts by name and specify file paths. book workspace briefings reference character arcs and chapter positions. civilization briefings reference jurisdictions and prior agreements.

The other four roles see none of this specialization. A Planner drafting a code project produces the same shape of plan as a Planner drafting a book. The specialization lives at the leaves, where work meets domain.

Philosophy

Three principles shape every Worker run.

Production within ratified bounds

The Worker doesn't decide what to build. The Ruler ratified that. The Worker doesn't decide what to share. The Contractor committed that. The Worker builds within those bounds. Their judgment is bounded to how to produce something that conforms to the contracts and serves the plan, not whether to do this work or what to do at all.

Domain expertise lives here

The base Worker primitive doesn't know what good code looks like, what good prose feels like, or what well formed civic agreements require. That knowledge is in the workspace's specialized tools and validators. The Worker is where domain specific expertise enters the architecture. Everywhere else it's deliberately absent.

Output speaks for itself

The Worker doesn't synthesize for the user. The Ruler does that. The Worker doesn't explain its choices in prose. The artifact is the explanation. A file that compiles, a chapter that flows, an agreement that holds. The Worker's value is what they leave behind, not what they say about it.

What the Worker does

One job, four phases, then exit.

1

Read the briefing

The Worker is invoked at a leaf step in a plan with a briefing from the Ruler. What specifically to build, what scope, what constraints from the plan and parent context.

2

Read the contracts in force

The Worker reads every contract that applies at this scope. The canonical names, the wire shapes, the storage keys, the agreed upon terms. Their output must conform.

3

Produce the output

Using the workspace's specialized tools, the Worker writes the file, drafts the chapter, files the agreement. This is where the actual work happens.

4

Emit completion

The Worker signals what was produced and exits. Validators run. If conformance fails, the Foreman handles retry or escalation.

Workspaces specializing the Worker

Three current and forthcoming workspace extensions show what specialization looks like. The architecture is shaped to support all three (and others) through the same Worker specialization pattern. Implementation state varies. Be aware of which is what.

💻 code workspace

Fully built today.

Tools. workspace-add-file, workspace-edit-file, workspace-delete-file, package-add-dependency, run-test, run-build, get-file-content.

Validators. Syntax (does it parse?). Type signatures (do they match contract interfaces?). Import conformance (do you use canonical names from the contracts?). Smoke tests (does the file at least load?). Behavioral tests if specified.

Output. Files in the project filesystem with auto sync to working tree.

Briefing language. References contracts by name, specifies file paths and structure.

📖 book workspace

Partially built today.

Tools. chapter-write, chapter-revise, character-define, character-update, timeline-update, terminology-add, scene-draft, beat-record.

Validators. Voice continuity (does this match the established narrator?). Character consistency (does this character act like themselves?). Timeline coherence (does the chronology hold?). Vocabulary conformance (are the canonical terms used consistently?).

Output. Chapter prose with associated metadata (character beats, timeline updates, terminology references).

Briefing language. References character arcs, story beats, and prior chapter positions.

🏛️ civilization

Forthcoming. Speculative example.

Tools. proposal-draft, agreement-publish, jurisdiction-define, dispute-file, precedent-cite, vote-record, ratification-confirm.

Validators. Jurisdictional authority (does this scope have authority over what's proposed?). Agreement legibility (can affected parties understand and verify?). Precedent fit (does this contradict prior agreements at this jurisdiction?). Participant standing (do the parties have standing to commit?).

Output. Ratified agreements, proposals, recorded votes, dispute filings.

Briefing language. References jurisdictions, prior agreements, and standing parties.

Each workspace's Worker is a specialization of the same base primitive. The role's architecture (bounded judgment, contract conformance, validator driven correctness) stays uniform. What varies is the domain content the Worker produces and the domain specific tools they use to produce it.

The base mode is real

The Worker base mode (tree:governing-worker) is functional standalone, even without workspace specialization. It can read briefings, read contracts, emit completion. What it can't do is produce domain artifacts. That's what specialization adds. A workspace extension declares its Worker variant by registering tools and validators that extend the base. The substrate provides the structure. The workspace provides the substance.

This is what makes TreeOS a general substrate. A new domain can be added by writing a workspace extension that specializes Worker for its specific output shape. The Ruler primitive doesn't need updating. The Planner primitive doesn't need updating. The Contractor primitive doesn't need updating. The Foreman primitive doesn't need updating. Only the Worker. The role at the leaves where work meets domain.

An example run

Continuing the Flappy Bird Battle Royale example. Contracts ratified, dispatch fired, sub Rulers running. Inside the core sub Ruler's plan, step 1 is a leaf. "Create render.js with the canvas rendering loop, using the contracts event:tick and dom:gameCanvas." Here's what the Worker does.

1

Reads the briefing

File path (core/render.js), purpose (canvas rendering loop), contracts to honor (event:tick listener, dom:gameCanvas reference).

2

Reads the contracts in force

tick fires every game frame. gameCanvas is the DOM id for the canvas element.

3

Produces the file

Imports the tick event. Queries gameCanvas. Sets up the rendering loop using requestAnimationFrame. Attaches the listener. Defines the render function with the entity rendering hooks left abstract for the entities branch to fill in.

4

Emits completion

workspace-add-file with the contents. Auto sync schedules. Validators run. Syntax passes. Contract conformance passes (uses canonical names). Smoke test passes (file loads).

One LLM call, one artifact. The Worker exits. The next step's Worker takes over.

Why the Worker is the bottom

The recursion ends here. Workers don't promote to Rulers. Workers don't dispatch sub branches. If a Worker discovers the leaf work was actually compound (too big to handle as one production), they emit branches via [[BRANCHES]] and their own node retroactively promotes to Ruler. But that's a different lifecycle event. The Worker that discovered the compound nature has exited. A new sub Ruler takes over with its own Planner, Contractor, dispatch.

The Worker is the bottom of the recursion in the same sense that leaves are the bottom of a tree. The work happens here. Everything else is structure.

The hand of the work produces what the architecture coordinated toward. The other roles arrange the conditions. The Worker makes them concrete. When the artifact lands, the work is real.