Crew task delivery

What it is

A crew's work ends up in three different places, and until now nothing joined them: the task row in the app, the branch on disk, and the lander's own verdict. So "done" was whatever somebody wrote in the task's outcome, and the app took their word for it.

Delivery closes that gap. A task carries a kind — code, research or design — and, for code, an explicit link: the session that delivered it, the branch, and up to three commits.

The app then derives a stage on every read, never storing it:

• Working — a code task with no commit linked yet.
• Committed — a linked commit exists, nothing has been tagged ready.
• Ready to land — the branch carries a ready-to-merge tag the lander has not acted on yet.
• Held by the lander — the lander refused it, and the row shows the lander's own words and its reason kind, unedited. A fresh tag after the repair moves it back to ready.
• With the landing desk — the branch would not land and its author is on a crew, so it sits in the one shared landing desk every crew shares instead of going back to its author or its lead. The row shows the desk's own reason. The branch landing wins: a land newer than the desk item reads as landed.
• Landed — the integration branch holds it.
• Not code — a research or design task, which has no delivery chain to follow.

Two answers are deliberately kept apart: landed means master holds the commit; live means the build you are running contains it. A task can be landed and not live, and the table says so rather than implying the change is in front of you.

A row that existed before this field did is left unspecified: it keeps the close behaviour it always had and is shown as unspecified on the table, so no crew is judged by a rule its work was never written for. You can re-type such a task at any time to opt it in.

A code task closes as done only when its own linked commit has landed. Prose in the outcome is not consulted for a code task at all — which is what stops an older land, quoted from an unrelated piece of work, from closing a task nothing has shipped. A code task with no link is refused, and the refusal names both ways forward: send the link and the close in one call, or re-type the task as research if it was never code.

The readiness rule is bounded in both directions: a branch's landed event counts only when it is newer than the instant the link was declared, so work committed afterwards on an already-landed branch reads as committed rather than landed.

Where to find it

• The crew dashboard, in the Overseers hub, in the Delivery section: one row per crew member with its current task, its Dev Pipeline phase, what it is waiting on, its delivery stage (and the lander's refusal text when it is held), and when that row's evidence last moved. A line under the table counts the crew's open tasks that have no live owner, so no open code task can be invisible.
• GET /crew/status — the same read for an agent, bounded and paged (?limit, ?offset).
• GET /crew/tasks and PATCH /crew/tasks/:ref carry the new kind and delivery fields.

How it behaves

• The stage is derived on every read and never stored, so it cannot go stale and no agent can write one. It comes from the ready tag, the lander's own event rows, the worktree ledger's last observed ready claim, the dev pipeline's run events, and the commit this build was cut from.
• A refusal outranks a tag, and a newer tag outranks the refusal. When the lander has refused a branch the row shows its reason verbatim; once the branch is repaired and tagged again the row reads ready again, so a repaired branch never keeps showing a stale veto.
• A land only counts if it is newer than the link. Work committed afterwards on an already-landed branch reads as committed rather than landed.
• A land this box cannot attribute answers "cannot tell", not "not live". A squash or patch-id land, or a running build that names no commit, leaves the live answer blank rather than claiming the change is absent.
• A held branch is read from the crew's own repository. A same-named branch in another project never contributes its outcome.
• The read is bounded. The table pages by member and says when it is showing a slice; the git work behind it is capped per read, and a row past the cap answers "cannot tell" rather than spawning more.
• It is not a second record. No lander fact, ready-tag time or pipeline phase is copied onto a task row. It changes nothing about the lander, the ready mint or the task store's other rules.
• The link is the agent's to declare; the stage never is. There is no field an agent can write to make a task read as landed.

Related

• Crew task delivery contract — the invariants this page describes, each with the check that guards it.
• Agent Crews · Agent Crews — part 2 · Agent Crews — for agents
• Judged checks — the other way a crew proves a promise the app can read.
• The lander's own history, in the Dev Pipeline panel's auto-lander section.