Skip to content

Build status

The Build page shows whether each artefact on Main is built: not started, planned, in dev, merged, on an environment, verified, outdated or rolled back.

The Build page answers one question for the whole project: which parts of the agreed spec are coded, deployed and verified. It always reads Main. Nothing is typed in: each status is derived from work items, merges and deployments every time you look.

The states

StateMeaning
Not startedNo implement item has delivered it, and none is open.
PlannedAn implement item for it is To do, such as "Planned · T-12.1".
In devAn implement item for it is Doing.
MergedAn implement item delivered the revision Main has.
On envThat delivery was deployed to an environment, such as On staging.
VerifiedA verify or uat item passed on that environment.
OutdatedMain changed since it was built: the delivered revision is not the one on Main.
Rolled backThe environment now runs a build older than the one that carried it.

The headline names the furthest environment, in the order of the flow template. Rolled back outranks Verified.

How a status is worked out

  • The delivered revision. When an implement item becomes Done, by a merge or by a person, SpecsGraph records which revision of each of its artefacts it delivered: the one the task agreed. It never guesses from Main. When there is none, the row says Needs confirmation.
  • Main first. A delivery that matches Main wins over one whose spec has not landed yet. Code merged for a change still in a workstream shows as "merged · spec not on Main yet".
  • Outdated compares content. Changes that only add links or summaries, such as a feature's use cases, a context map or a summary, do not make an artefact Outdated. Any other edit on Main does, until it is built again or a person marks it implemented.
  • Environments come from the same task. Deployments and passed results of the task's deploy, verify and uat items, after the delivery, set On env and Verified.

Which kinds have a status

Role on the pageKinds
A row with a statusAggregate, value object, enum, use case, event handler, scheduled job, data contract, read model, integration event, constraint
A group with a rollupSubdomain, bounded context, feature
No statusTerm, role, decision; shown with Show untracked kinds

The Build page

  • State chips with counts across the top, each one a filter.
  • Group by Context (the default), Subdomain, Feature, Milestone, Kind or None. Each group shows a bar by state and "18 of 31 merged or better"; merged or better means Merged, On env or Verified. A feature group opens to its scenarios, each with its own count.
  • Filters for kind, context, subdomain, feature, milestone, environment, Has open item, archived and untracked kinds, and search.
  • Rows show the state, one cell per environment, the item that delivered it with its pull request, the delivered revision against Main (r7 to r9 when outdated) and hints such as the open item or the home milestone.
  • The detail drawer shows the steps from Planned to Verified, what changed on Main when it is outdated, with a link to compare the revisions, open items, every delivery and the constraints that apply to it.

On Main, an artefact's header carries its build status, which opens the drawer. On a task, the implement row says "built r7 · Main r9" or Needs confirmation.

Mark as implemented

For code that already exists, select rows and choose Mark as implemented. It states that the code implements the current Main revision, optionally live in some environments, and needs a note. It is recorded with your name.

  • Only a person does it: an Editor or above who may edit the project. No agent and no MCP tool can, even with Agent autonomy on.
  • It never claims Verified. Later implement work on a newer revision takes over from it.
  • Use it on an Outdated row when the code already matches, for example after a wording change. Revoke takes it back.

Agents and build status

Agents read the same rows with build_status, filtered by state, kind, context, feature, milestone or environment, to find what still needs code or to check that a change reached staging. They cannot mark anything as implemented.

Next steps