The six stations

Every specd project runs the same six stations in the same order. This is the opposite of a workflow builder, and the constraint is the feature: there is nothing to assemble, and nothing to mis-wire.

Connect → Ground → Spec → [HUMAN] → Build → Learn
   01       02       03      04       05      06
                                              └──→ feeds 02

Only station 01 takes configuration — which repositories, which model, which tracker. Stations cannot be added, skipped or removed, and the gate at 04 is structural rather than a setting someone can turn off.

01 · Connect

You point specd at the things it will work with: one or more repositories, a model credential, and optionally a tracker. Repositories can be a local path, a GitHub App installation or a GitLab access token. Nothing is copied — specd records which repository, and reads it when it needs to.

Details: Connect a repository, Bring your own model, Jira.

02 · Ground

A read-only scan of the repository produces your first knowledge base, delivered as a setup pull request carrying AGENTS.md and a knowledge/ tree. Tables of commands, pipelines, services, configuration and entities are quoted from the files they name. The judgement around them is drafted for you to correct, and anything the scan could not ground says UNVERIFIED.

Merging that pull request is adoption. specd indexes knowledge/ the moment the webhook lands. Details: Ground your repository.

03 · Spec

A ticket becomes a draft spec. The SpecAgent retrieves from your knowledge base — not from the model's memory of open-source code — and writes requirements, a cited design, and tasks. Every design claim is either cited or flagged. Details: Specs and citations.

04 · The human gate

A named person approves a specific version. This is the station that makes the other five safe, and it is enforced in three independent places — the state machine, the API boundary and a database CHECK constraint. Details: The human gate.

No agent may approve its own input, and the server refuses an unapproved spec no matter who asks.

05 · Build

The build agent implements the tasks in order, one commit each, on the spec's own spec/<id>-<slug> branch, and opens a pull request. It gets editing tools only — never a shell — and it never touches your working tree or pushes to a default branch. Details: Build and ship.

06 · Learn

You merge. The webhook fires, the as-built spec is filed into knowledge/specs/, the index refreshes, and station 02's corpus is one delivered spec richer. Details: The learning loop.

Why the line is fixed

A configurable pipeline is a pipeline where the gate is a step someone can remove under deadline pressure. Three things follow from making the line structural:

• Nothing can be mis-wired. There is no state where Build runs before an approval exists, because there is no way to express that state.
• The gate cannot be optimised away. It is not a setting, a policy or a lint rule — it is the shape of the system.
• Every project is legible to everyone. A reviewer moving between projects reads the same six stations, not somebody's bespoke graph.

The cost is real: if your process genuinely needs a seventh station, specd will not give you one. That trade is recorded as a decision in this repository's own knowledge base, at knowledge/decisions/0001-adopt-spec-driven.md.

What runs where