The worker fleet: registry, pipeline and dispatch contract

“Deploy workers” is a dispatch action with a checked declaration, not prose. The fleet is defined in workers/registry.json: nine worker verbs, each with a job, inputs, steps, outputs, a stop condition and an evidence field. The declaration is validated by the workers check in the deterministic gate, so a missing worker, a broken pipeline or an evidence-free entry fails the gate instead of shipping as intent.

The gate checks the declaration’s shape only. The truth of a worker’s evidence is read by the reviewer or the Lead that consumes it.

The nine workers

merge — Integrator

Integrate verified work into one reviewable change and prove the combined tree still passes the gate. The merge worker is the Lead, never a peer worker.

Inputs: accepted task reports with their evidence; the current branch or worktree diff and declared write scopes; the gate output from every source tree.
Evidence: the harness/check.mjs exit record on the integrated tree.
Stop: stop and report if the gate exits non-zero, if two writers touched one path, or if an accepted claim has no evidence.

expand — Capability grower

Grow a product or capability from verified research into one agreed, budgeted increment.

Inputs: consolidated research with citations; the product’s current surface, code map and declared gate; the decision naming what should get better.
Evidence: the increment and its acceptance command recorded as a report file under reports/.
Stop: stop when the increment can be built and falsified against a named acceptance command; stop early if the research does not support a behaviour change.

build — Slice implementer

Implement one scoped slice with tests and leave a green gate record on the real tree.

Inputs: an increment proposal with acceptance condition and write scope; the product source tree and code map; the product’s gate command and test conventions.
Evidence: the owning product’s declared gate command with its exit code.
Stop: stop when the declared gate exits 0 on the real tree; stop and report if the slice needs a path outside the declared write scope.

research — Desk researcher

Gather local and desk evidence for one falsifiable question, with a path for every observation.

Inputs: one falsifiable question with a named scope; the local repositories, logs and snapshots that could answer it; the task or decision that needs the answer.
Evidence: the finding log as a report file under reports/.
Stop: stop when the question is answered or every named local source is exhausted; never widen scope because the trail is interesting.

analyse — Mechanism analyst

Decompose a mechanism, its interfaces and its gaps so the next step is a decision, not a hunch.

Inputs: the finding log or code map for the target; the behaviour or failure to explain; the product’s contracts and declared gate.
Evidence: the mechanism map as a report file under reports/.
Stop: stop when every claimed mechanism is tied to a path or observation and every gap names a next probe.

assess — Maturity assessor

Score maturity, risk and confidence against named criteria so a claim can be challenged on the record.

Inputs: the claim, change or product to assess; the criteria and thresholds that define a pass; the evidence gathered by research, analyse or web-research.
Evidence: the scored assessment as a report file under reports/.
Stop: stop when every score carries evidence or an explicit unknown; never score to please the requester.

brainstorm — Option generator

Generate at least three genuinely different options and rank them against the stated constraints.

Inputs: the problem statement and hard constraints; evidence about the current state and prior attempts; the criteria that decide the ranking.
Evidence: the ranked option set as a report file under reports/.
Stop: stop when the ranking is defensible against the named criteria; do not add options after the direction is chosen.

web-research — External researcher

Gather external sources, cite every claim to a URL and keep the external facts checkable.

Inputs: a question whose answer lives outside the workspace; the allowed source scope and freshness window; the decision the evidence must support.
Evidence: the claim-to-URL table as a report file under reports/.
Stop: stop when every claim carries a URL or is marked unsupported; if the source is unreadable or the network is down, report that instead of guessing.

consolidate — Program consolidator

Merge findings and ranked options into one decision-ready program with an order and a stop point.

Inputs: finding logs, assessments and ranked options with their evidence; the constraints and the decision that must be taken; the current estate state and its gate records.
Evidence: the program and its acceptance commands as a report file under reports/.
Stop: stop when the program can be executed and falsified by its acceptance commands; leave rejected options out rather than blurring the decision.

The pipeline

The registry’s pipeline orders the verbs into five phases. Every worker must appear at least once; a worker may repeat when a later phase genuinely re-enters it.

gather — research, web-research. Collect local and external evidence before anyone forms a preference.
frame — analyse, brainstorm. Decompose the mechanism and generate options against the evidence.
decide — assess, consolidate. Score the claims, then choose one direction and write the ordered increments.
deliver — expand, build. Turn the decision into a scoped increment and implement it with tests and a green gate.
land — merge. Integrate the verified work into one reviewable change and re-run the full gate.

Reads may run in parallel; writes follow the pipeline order and the dependency order of the tasks. A later phase never starts on top of an unverified earlier one.

Dispatch protocol

The shared task board is the dispatch surface. A task names its read-first material, its write scopes and its acceptance command. Work that is not on the board is not dispatched.
Declared write scopes are a boundary, not a suggestion. One writer per path; two tasks that need the same file are ordered with a dependency or merged into one task.
Agent Teams for builds. The Lead owns the board and is the merge worker: it assigns disjoint scopes, collects each worker’s report and evidence, and re-runs the gate on the integrated tree. A worker reports a scoped result; it does not merge its peers.
Workflow fan-out for research. Read-only questions are the safe fan-out unit: many researchers may run at once because each writes only its own finding file under reports/. Fan out research, not writers.
Evidence travels with the claim. A report cites the command exit code, the path it read or the URL it fetched. The parent checks the gate, not the worker’s summary.
Out of scope means stop. A worker that cannot finish inside its declared scope stops and reports the missing scope; it does not widen the boundary.

What a worker must never do

Fabricate evidence, cite a path it did not read, or present a derived conclusion as an observation.
Push, deploy, commit or mutate a host or service without an explicit ask in the task; deploy authorization names one project and does not carry over.
Write outside its declared write scope, or overwrite a path another writer owns.
Print, persist or paste a credential value, token or secret into output, docs, memory or a report.
Lower a check, silence a warning or record a pass for a gate it did not run to make a result look green. Unavailable is honest; a false green is not.
Keep going past its stop condition because the work is interesting.

Changing the fleet

A fleet change is one changeset: the registry entry, the check that validates it, this contract and the two wiring arrays in harness/checks/index.mjs land together. The checks and expectedChecks arrays must agree, then run node harness/check.mjs and node --test harness/check.test.mjs. Adding or renaming a verb also updates the required set in harness/checks/workers.mjs; the registry and the check are the same contract expressed twice.