name: d3-f-pipeline
description: The pipeline — a project's work items, passed between people and agents by role. Get skills only from /api/v2/skills/d3.
feature: pipe
concepts: [item, queue, processing, ticket, touches, handover, release, check]
tags: #skill #feature #d3skill #wip

d3-f-pipeline¶

Intro¶

The pipeline: work passed between people and agents by role.

The pipeline is a project's work list: items filed for a role (a person or <role> agent), taken by one holder, moved through states to done, with dependencies, reviews, handovers and releases. It is how agents get work and pass it on. Spec: Spec › pipeline.

Essentials¶

R-pipe-1 MUST take an item before working it, under your own agent name, sending as: "<your role>" on every pipeline write.
R-pipe-2 MUST keep its status true; a held item is always visible in Waiting with a one-line note saying what it waits for.
R-pipe-3 NEVER park, unpark, drop, rank, promote, demote or mark important unless your person says so — then send askedBy: "<their handle>"; otherwise suggest it.
R-pipe-4 A dependency is links.waitsOn, never prose.
R-pipe-5 Hand back on the same item (note it, redirect it) — before closing; a done item never reopens.
R-pipe-6 Priorities come only through the pipeline (important, rank, order), never from a board message.
R-pipe-7 To a person, name an item as a link (/pipeline/P-n) plus a few words, never a bare number.
R-pipe-8 Read narrow: your own work, filtered; one item whole only when you're about to work it.

Concepts¶

item¶

One unit of work for a role. Also called: task (people's word; use it when talking to them), ticket (a coder item). Fields: id (P-12), title (one short sentence, ≤60 characters — R-pipe-13), summary (one sentence ≤200, always set: the detail the title leaves out), doc (markdown: the ask, then decisions; never opens with a # heading repeating the title), kind (spec, design, impl, code, test, bug, task, admin, question, idea, suggestion, review, handover, release), forRole / forName, status, size (small | medium | large), important, rank, feature, codes, touches, supersedes, alone, links (waitsOn, follows, changes, handover, asks; collides and mayCollide are d2's). States: new → in-progress → done | review | waiting | waiting-input | failed; review → done (accepted) or back; new ↔ parked (person's call); paused, dropped, moved, todo, waiting-error; waiting-release (a code item built, waiting for the release that carries it). status=open = not done, dropped or moved. Roles: user, designer, coder, tester, administrator, maker, dispatcher, guardian, monitor, ops, support, each also <role> agent; a project adds its own with roles: in Settings:PROJECT. Work for an agent is for <role> agent; a bare role is the person in that role.

item_file¶

Summary: file for your own person's lanes only; summary always set.
When: new work, a follow-up, a question for your person.
Needs: title, summary, kind, forRole (<role> agent for agent work), size.
Call: POST /api/v2/pipeline {title, summary, kind, forRole, forName?, doc|prompt, size, …} → the item.
Rules: R-pipe-13 for the title. You file only for your own person or their agent roles. prompt is your person's words: d2 stores it as a quote under ## Prompt; a document you wrote goes in doc. A change to a done feature is a new item with links.changes, naming feature and codes. Notices about it go only after the write returned, naming the id from the reply.
Errors: E_SCOPE → not your person's lane · E_ARG → a bad field (summary over 200).
Gotchas: Why: four items filed with askedBy: <person> and a bare coder landed in the person's own lane — with askedBy, file for coder agent explicitly. d2 re-points a bare role to its agent otherwise (N_PIPE_AGENT_ROLE).

item_read¶

Summary: one item whole, only when you're about to work it.
When: after taking it, or to answer a question about it.
Needs: the id.
Call: GET /api/v2/pipeline/<id> (markdown; ?format=json for the record).
Rules: R-pipe-8, R-pipe-12 (background agents).
Errors: E_NOT_FOUND → wrong id.
Gotchas: —

item_take¶

Summary: take before working; locked to you.
When: before any work on it; a batch at once with the batch call.
Needs: the id(s) from pickable; your board status posted (up).
Call: POST /api/v2/pipeline/<id>/take {as, name} Also: batch: POST /api/v2/pipeline/take {items: […], as, name} → the item(s), in-progress, with collides / mayCollide.
Rules: R-pipe-1. A taken item is locked to its holder; to add to it, file a follow-up (links.follows). Take whatever you hold before reading a handover.
Errors: E_TAKEN → pick another · E_IN_PROGRESS → follow-up · E_STOPPED → processing is stopped: finish what you hold, take nothing new, post idle with processing stopped; an item your person named for you waits too — tell them it is refused until they press Start processing · E_ALONE_* → a refactor runs alone · E_SCOPE → your role's pipeline.start doesn't allow it, or you're past ~70% context.
Gotchas: without name, d2 uses your board status in that role — post up first. A name that isn't your token's is refused, except a dispatcher's take on behalf of the coder it starts — don't "fix" that to the dispatcher's name. Back to work after waiting: post working with the item so the board isn't stale.

item_note¶

Summary: short running comments; the body is the doc.
When: progress, a question answered, coming back to an item ("what about Z?"), recording an approval.
Needs: —
Call: POST /api/v2/pipeline/<id>/note {text}.
Rules: When your person OKs something in chat, note approved by in , . A note never changes the status.
Errors: E_IN_PROGRESS → someone else holds it: file a follow-up.
Gotchas: —

item_edit¶

Summary: edit the doc with PATCH; never rewrite a taken or done item's doc.
When: writing or fixing an item you hold or that's untaken; Look at: at the top.
Needs: the current doc.
Call: PATCH /api/v2/pipeline/<id> {doc | summary | touches | size | …, as} (JSON, encoder-escaped).
Rules: Look at: goes before the first ## (a designer's Look at first: stays above yours). Size is fixed when filed: raise it, never lower it unless your person asks. Taken by someone else, or done → add a note instead; an item you hold yourself you may edit (a builder adds its own Look at: this way).
Errors: E_IN_PROGRESS · E_ARG.
Gotchas: Why: a designer reshaped an item minutes after a dispatcher had committed a coder to it — check nobody holds it and no dispatcher's status names it before reshaping.

item_redirect¶

Summary: hand back on the same item: note why, change its role.
When: a design call, a missing ticket part, a ruling, touches missing.
Needs: the reason, in a note first.
Call: PATCH /api/v2/pipeline/<id> {forRole: "<role> agent", as}.
Rules: R-pipe-5. A ruling goes on the same item, which is then redirected back to its builder — no new item.
Errors: E_STATUS → it's already done (too late; file a follow-up).
Gotchas: —

item_ask¶

Summary: ask up the chain; you wait, the answer lands on your item.
When: coder, tester or guardian → designer; designer → person.
Needs: one clear question.
Call: POST /api/v2/pipeline/<id>/ask {question} → a question item (links.asks), yours waiting on it.
Rules: Never guess at a design question.
Errors: —
Gotchas: —

item_handoff¶

Summary: yours done, the next made, linked both ways.
When: your part is finished and another role continues.
Needs: the next role and a note.
Call: POST /api/v2/pipeline/<id>/handoff {forRole, note}.
Rules: —
Errors: —
Gotchas: —

item_finish¶

Summary: done with links to what changed; your role's pipeline.finish decides if it goes to review.
When: the work is complete and pushed.
Needs: the links (commit sha for code); an acceptedIf comment resolved.
Call: PATCH /api/v2/pipeline/<id> {status: "done", as, note, commit?}.
Rules: Set commit after your final rebase/merge, never a hash that's on no remote. The reply says where it went: done, review, or — where built work waits for its release — waiting-release with hint: N_PIPE_BUILT. Any of them is finished for you: post done, don't close it again or wait. pipeline.finish for your role and size: asks → review (your person Accepts or Sends back; items waiting on it unlock only on Accept); tells → done and on their to-look-at list; free → done. Accepted with a comment (acceptedIf): resolve it and say how in the note. Sent back (reviewAgain): answer and finish; it returns to the reviewer.
Errors: E_ARG → finishing an acceptedIf item without its note · E_STATUS → closing a waiting-release item again.
Gotchas: a code item is known by the files in its touches: closed with a commit but none named, it reads done at once, before anything ships (P-1175, 2026-10-10) — → touches_declare first.

item_return¶

Summary: send an item back to its builder with a note.
When: an accepted-with-comment item you can't resolve, or work that came back wrong.
Needs: the note.
Call: POST /api/v2/pipeline/<id>/return {note} → back for its role, new and first in Next up.
Rules: —
Errors: —
Gotchas: —

item_fail¶

Summary: when it defeats you, fail it with why — never just stop.
When: a test you can't pass, contradictory docs, a build you can't get through.
Needs: why, concretely.
Call: POST /api/v2/pipeline/<id>/fail {why}.
Rules: A second fail by another agent makes it failed for its asker; nobody re-dispatches a failed item. Dying or running out of spend is not a fail.
Errors: —
Gotchas: —

item_putdown¶

Summary: stop holding it; back to new, first in Next up.
When: you stop before it's done.
Needs: you hold it; a note of where it stands.
Call: POST /api/v2/pipeline/<id>/putdown {note}.
Rules: —
Errors: E_NOT_YOURS → you don't hold it.
Gotchas: —

item_wait¶

Summary: held items are visible: waiting-input on a person, waiting on another item, always with a note.
When: a person must answer, or another item must finish first.
Needs: who or what it waits for.
Call: PATCH /api/v2/pipeline/<id> {status: "waiting-input", waitingOn: "<person>", note} Also: PATCH {links: {waitsOn: ["P-7"]}} (makes it waiting, off pickable) · a live handover: waitingOn: "self".
Rules: R-pipe-2, R-pipe-4. Back to new once resolved. Holding is park or waitsOn, never pause; park supersedes pause.
Errors: —
Gotchas: Why: an important item sat new for hours while only a dispatcher's status said it was held. Why: pausing dependents cost the person an approval each while pipeline.park is asks.

item_park¶

Summary: only when your person says so, with askedBy.
When: your person says "park it", "later", "no time now" — for an existing item or an idea (file it first).
Needs: your person's words (they go in askedBy and, for a new idea, the prompt).
Call: PATCH /api/v2/pipeline/<id> {status: "parked", askedBy} · unpark: {status: "new", askedBy}.
Rules: R-pipe-3. Parked is never picked; never pause a parked item. Give your person the link.
Errors: E_SCOPE → naming anyone but your person · 202 {approval: "A-n"} → waiting for their approval: don't retry.
Gotchas: —

item_personsCall¶

Summary: drop, demote, promote, mark important, rank — only when told, always with askedBy.
When: your person tells you.
Needs: their words.
Call: drop POST /api/v2/pipeline/<id>/drop {reason, askedBy} Also: demote to a to-do POST /api/v2/pipeline/<id>/demote · promote a to-do POST /api/v2/pipeline/promote · important / rank / order PATCH {important | rank | move: "up"|"down", askedBy}.
Rules: R-pipe-3, R-pipe-6. Moving work between to-dos and the pipeline is always your person's.
Errors: E_SCOPE · 202 {approval}.
Gotchas: —

item_suggest¶

Summary: when you only think something should happen, file a suggestion for your person.
When: park / drop / reorder / promote ideas you weren't told to do.
Needs: each item or to-do with what you suggest.
Call: POST /api/v2/pipeline {kind: "suggestion", forRole: "user", forName: "<their handle>", title, prompt}.
Rules: —
Errors: —
Gotchas: —

item_forPerson¶

Summary: what a person must look at opens with Check: <link>; what they must answer is waiting-input on them.
When: review or to-look items about something visible.
Needs: the link to click.
Call: doc starts Check: <link> (one per thing, before any other text) → shown as a Check button.
Rules: The waiting-on-you flag follows startedBy up the chain (coder → dispatcher → monitor → person).
Errors: —
Gotchas: —

item_report¶

Summary: an answer your person wants as a page is a Report topic.
When: your person asks for a report.
Needs: the ask (prompt, who, when).
Call: a Report:<role>-<slug>-<date> topic (tags report, <role>, ephemeral for one-offs; frontmatter askedBy), starting with a quoted Asked: line.
Rules: Reports stay out of search and the wiki; ephemeral ones can be dismissed.
Errors: —
Gotchas: —

queue¶

A role's work as d2 orders it. Also called: Next up. Batch: the items one agent takes together, within the budget — how much work fits in one agent's head, not how many items exist (queue_batch). Fields (pickable answer): ids in pick order (a handover, released items, important, rank, oldest), batch (d2's suggestion), release (auto, the open release item, done-since count), processing (stopped).

queue_mine¶

Summary: your own open work, filtered, never the whole list.
When: at start and after each item.
Needs: your role.
Call: GET /api/v2/pipeline?forRole=<role>%20agent&status=open&fields=id,title,status,rank.
Rules: R-pipe-8.
Errors: —
Gotchas: —

queue_pickable¶

Summary: what you may take, in order; take within your budget.
When: before taking; after each batch.
Needs: your role, your person.
Call: GET /api/v2/pipeline?forRole=<role>%20agent&pickable=1 (the lane's items carry no name; add &forName=<person> only for items named for one person, and it leaves the unnamed ones out; an item your person names for you is taken by its id, in the list or not; &size=small to batch small ones; &pickFor=<your name> puts what follows up your own work first; ?fields= to narrow).
Rules: Budget per agent (Spec ^pipe-40): up to eight small items, or one medium with related small ones; a large one alone. Sizes (Spec ^pipe-65): Small: one place, obvious, easy to undo, nothing new promised. Medium: one feature in one component, with new or changed behaviour a person sees. Large: crosses components, changes a contract (API, data model, permissions, security), or is hard to undo. In doubt, the larger. ★ only means "pick me first". alone: true blocks everything else coder-side. Pick order is a preference: skip what can't run now and go on, taking only what doesn't collide with what waits. Starting the next one follows your role's pipeline.start: person — never take; asks — propose, wait for the nod, take with askedBy; tells — take in order, report per batch; free — take, no reports.
Errors: E_ALONE_NEXT / E_ALONE_BUSY / E_ALONE_RUNNING → finish what you hold, take nothing new.
Gotchas: —

queue_batch¶

Summary: batch to the budget; what collides goes to one agent; decide each row from its flags.
When: you start other agents and are planning a round.
Needs: the pickable rows with collides, mayCollide, size, important; what is in flight; your free slots.
Call: queue_pickable → group so no two batches touch the same files → item_take each batch under its agent's name, before writing its prompt.
Rules: Released items first; merging and stuck count as in flight. Per row: no flags → take · small + small → take · small + large → skip this round · large + any → separate (when its collisions are done, or it is all that's left) · mayCollide → half a collision (fine for a small, a skip for a large) · one slot → take, into the running batch. A skipped item doesn't hold the walk: go on, taking only what doesn't collide with the one waiting; a small one skipped twice is taken anyway; a large one waits. Small ★ design merges go together at the head of a run, in branch order. Tell each agent its collides and mayCollide. The round's plan is one notice: every item taken or skipped, with the line that decided it.
Errors: E_TAKEN → taken meanwhile: next row.
Gotchas: Why: a prompt written before its take cost four minutes when the take was refused. The table is a starting point: a skip that reads wrong in the notice is a line to change.

queue_paused¶

Summary: a paused queue is not an empty one — check before saying "nothing to do".
When: pickable is empty.
Needs: —
Call: GET /api/v2/pipeline?role=<role>&status=paused&fields=id → say queue paused (n items).
Rules: Never resume a queue yourself.
Errors: —
Gotchas: —

queue_free¶

Summary: Next up minus what collides with work in progress — for an agent nobody dispatched.
When: a chat agent picking by hand.
Needs: —
Call: GET /api/v2/pipeline?role=<role>&free=1.
Rules: A filter, not a fence.
Errors: —
Gotchas: —

queue_summary¶

Summary: counts and ids, never content — the monitor's one pipeline view.
When: each watch cycle.
Needs: —
Call: GET /api/v2/pipeline/pickable?summary=1&role=<role> → {role, count, bySize, ids, handover, alone, paused, release}.
Rules: An item waiting on itself is normal, never stuck.
Errors: —
Gotchas: —

processing¶

A project-wide switch a person holds: while it is stopped, nobody takes a new pipeline item. Also called: processing stopped, a stop, a frozen pipeline. While stopped: finish what you hold, take no new pipeline item, post idle with processing stopped; every take answers E_STOPPED. It stops the pipeline, not the agents: reading, notes and drafts go on, and so do your person's chats, thoughts and streaks — answer them and turn them into tasks as usual (filing is not taking); a background agent is still started for them. Only a person starts it again, from their own session (Start processing): an agent's try is refused, so tell your person instead. It is not a paused queue (queue_paused), which holds one role's items.

ticket¶

A coder item written by a designer: self-contained, checked by the server. Also called: coder ticket, coder task. Design call: what a build can't settle alone — it changes a promise, contradicts the design or makes a design test wrong; it goes on the item itself (item_ask, or a note and item_redirect), never a guess (ticket_decided for the small things you do settle). Required parts: Look at (links; for visual work the CDN mockup first when one exists), Read only these (each a section read /api/v2/topics/<T>?section=<anchor>, /drafts/ while only drafted), Code pointers (files and functions from the repo), Decided for you (every small call), Changes (a bullet per code added or changed with its new line, or none), Done when (the exact tests). Fields: summary, size, touches, supersedes (existing codes it changes, or none), codes, feature.

ticket_write¶

Summary: self-contained, under ~15K with its reads; docs first; held until send.
When: a design your person is happy with needs code.
Needs: the design and its Spec/SpecUi/Design/Testing lines drafted; the repo read (touches and Code pointers from the tree); open points closed with your person.
Call: POST /api/v2/pipeline {kind: "impl", forRole: "designer", forName: "<person>", …} (held in your person's lane) → on send: PATCH {forRole: "coder agent", askedBy}.
Rules: Six required parts, in this order: Look at, Read only these, Code pointers, Decided for you, Changes, Done when — the ticket concept says what each holds. Nothing goes to coders until the person says send — a "yes" to a design isn't a send. Quotes over links. Every Spec/SpecUi line changed has its Testing line in the same change; UI changes carry a layout test; Design ends with Routes and codes. One feature per item. size by effort for the builder (small: one place, easy to undo; medium: one feature, visible new behaviour; large: crosses components or a contract; in doubt, larger). touches: every file incl. tests, nothing when none, never empty. Doc tasks (implementation notes, test links, Help) may go without approval.
Errors: E_TICKET → every missing part listed, with what to put · E_TICKET_WARN → looks wrong (existing code under Changes not in supersedes, dead link, too big, unknown test): fix, or resend with verified once checked.
Gotchas: Never add verified unchecked. A model ticket: Look at the mockup; Read only these two ?section= links; Code pointers topicsweb.ts putDraft(); Decided for you "409 reuses E_DRAFT_CHANGED"; Changes ^drf-4; Done when DRF-4a, DRF-4b; size: small, touches: src/topicsweb.ts, test/drafts.test.ts, supersedes: ^drf-4.

ticket_fold¶

Summary: fold a small change into an open untaken ticket in the same area; fewer, bigger tickets.
When: a small change in an area with an open ticket.
Needs: the open ticket untaken (taken → a note).
Call: item_edit its doc (untaken) or item_note (taken).
Rules: Don't split work on the same code; aim for batches of five or more.
Errors: —
Gotchas: Why: each ticket pays a coder's start-up, reading and checkpoint.

ticket_check¶

Summary: check the ticket before building; hand back what's missing.
When: after taking a coder item, before any code.
Needs: the ticket.
Call: read it; fetch each Read only these link exactly and nothing else — the feature's Design section and its design tests first.
Rules: Required parts, links, touches, supersedes, and the codes present in Spec/SpecUi/Design/Testing. Missing or inconsistent → item_redirect to the designer saying what's missing. A doc you had to change outside the list goes in a Decided: line.
Errors: E_NO_SECTION → a wrong anchor; the reply lists the topic's section ids.
Gotchas: —

ticket_decided¶

Summary: the builder decides small things and writes them down; anything bigger is a design call.
When: while building and at close.
Needs: —
Call: a Decided: <what, why> line in the commit and the closing note; the As built list as a note at close: what was built and where (files, routes, codes, tests and whether each passes), then suggested updates, one per line (Design#pipeline-stop: E_STOPPED is 409).
Rules: What changes a promise, contradicts the design or breaks a design test is a design call (item_redirect to the designer). The builder never edits Spec, SpecUi, Design, Testing or Routes; it keeps its implementation's own docs. The run's Decided: lines are collected into one Decided in v item for the designer at each release.
Errors: —
Gotchas: —

touches¶

The files an item edits — top-level field, how d2 sees collisions. Also called: collisions (collides and mayCollide on a row or a take). Rules of thumb: two open items collide when entries match (a dir/ covers what's under it); only files collide (topics are worth naming; d2 merges drafts).

touches_declare¶

Summary: no touches, no take; nothing is a declaration; add what the build finds.
When: filing (designer), and while building (taker).
Needs: the repo tree.
Call: PATCH /api/v2/pipeline/<id> {touches: [...]}.
Rules: An item with empty touches goes back to the designer untaken (item_redirect, note touches missing).
Errors: —
Gotchas: Why: undeclared items collided with nothing, so d2 reported no collisions and the dispatcher grepped by hand every round.

touches_collisions¶

Summary: a collision is a fact, not a refusal — read the named items before you merge.
When: after a take; before merging.
Needs: the take's collides / mayCollide.
Call: item_read each named item; read notes on open and just-closed items sharing your touches.
Rules: collides = same files, in progress; mayCollide = overlap unknown (one side undeclared). The code on the work branch is the truth until the designer folds the As built lists in.
Errors: —
Gotchas: —

handover¶

What an agent leaves when it stops with work unfinished. Fields: kind: handover, forRole (your own), the next chat's name and start prompt.

handover_write¶

Summary: only for what's unfinished; a screenful; then handing-over.
When: stopping with work left, or past ~70% context.
Needs: what's left, in order: unfinished items, decisions not yet written, codes in use; the next chat's name (<role>: …) and start prompt.
Call: post status handing-over, then POST /api/v2/pipeline {kind: "handover", forRole: "<your role> agent", …}.
Rules: Finished cleanly → post done, no handover. History stays on the items. handing-over or gone releases your items to your role.
Errors: —
Gotchas: —

handover_take¶

Summary: take it before reading it; close it only when nothing in it is left.
When: a new chat for a role starts.
Needs: the handover id.
Call: item_take → read → work → item_putdown when you stop, or done nothing left: P-x, P-y done.
Rules: —
Errors: E_NOT_YOURS on putdown.
Gotchas: —

handover_released¶

Summary: released items lead the next agent's pickable list; note where each stands first.
When: an agent's token ended, or it went handing-over / gone.
Needs: branch, last commit, pushed or not.
Call: item_note on each.
Rules: The dispatcher or the person decides who continues it. After a pause, GET /agents/changes?since= names the skills changed, so you re-read only those.
Errors: —
Gotchas: —

release¶

Moving finished work into the released version: full suite, work branch → main, deploy, box suite. Fields (pick answer): release.auto (the person's Auto-release toggle), release.open (the open release item).

release_ask¶

Summary: a person asks with ↑ Release, or just says it — to the dispatcher in its chat, or to the monitor.
When: the person wants a release.
Needs: —
Call: POST /api/v2/pipeline/release {note?} → a kind: release item for the dispatcher; asked again while open → the old one dropped (replaced by P-m).
Rules: The item lists what's done since the last release. A person may ask without it: directly, in the dispatcher's chat, or through the monitor, which passes it on as a release-only order; then there is no item, and the dispatcher records the release in its round's notice. An AI asking while one is open → E_EXISTS (a person's ask replaces it instead).
Errors: E_EXISTS.
Gotchas: —

release_check¶

Summary: check for a release at every batch end and every wake-up — never once at start.
When: every round, batch end and idle wake-up.
Needs: the pick answer's release, or GET /api/v2/pipeline's; your board messages (a system release asked).
Call: GET /api/v2/pipeline?forRole=…&pickable=1 → release.
Rules: Release only when release.auto is true, a release item is open, or your person asks you for one — directly in your chat, or through the monitor that started you — checked before the full suite too. Off → leave the work on the work branch; report not released: auto-release off; you and your coders run only the tests the work touches, never the full suite or the box suite. An open release item goes first, before starting any agent.
Errors: —
Gotchas: Why: a dispatcher read auto once and released four times after it was turned off. Why: a release item sat 65 minutes because a dispatcher watched only the coder queue — watch your own lane too.

release_run¶

Summary: take the release item, release, close it with version and box.
When: after release_check says go, with nobody merging or stuck.
Needs: the release item taken, when there is one (only a release item carries version and box: with none, the tasks it ships keep no version, and the notice is the record).
Call: post working checkpoint → full suite → work branch → main → deploy once → box suite → VIS-1 (R-tests-9) → PATCH {status: "done", version, box} or failed with error → the answer's released and stillWaiting (built after the release was cut) go in the release report, the box suite as box: <pass>/<fail>.
Rules: Check main hasn't moved under you; flag commits with no P-n; publish only drafts your agents touched that nobody else edited since; VIS-1 failing on live content (not the release): keep the item open, name the cause and who fixes it on the item and to whoever started you, re-run VIS-1 when told it's fixed, then close; refresh what the project's process says at each release; collect the run's Decided: lines (ticket_decided).
Errors: pending: true → the repository didn't answer, d2 retries: don't close again · E_STATUS → the item was replaced: stop where you are (never half-merge — if work → main isn't pushed, don't push it) and take the new one.
Gotchas: —

check¶

A guardian's look at the pipeline's work. Also called: watch (spec, watcher). Run and report rules: d3-f-guard-reports.

check_doneItems¶

Summary: first every run: items done since your last report were done properly; oldest first, 20 per run, save every 5.
When: the start of every spec-watch run.
Needs: the through of your newest spec report (a date in the start prompt wins; else the last 30 done).
Call: GET /api/v2/pipeline?status=done&format=json (leave out releases, handovers, reports), in doneAt order.
Rules: Per item: every test it names is a Testing line with its code (no reused code); a noticeable change has its Spec/SpecUi line; every rule, route, field, setting and E_ code is in its Design section and Routes and codes; the implementation's As built carries it; every Decided and suggested update is folded or declined. Look forward first: a later item that supersedes it (its supersedes lists the code, or they share codes or anchors) → judge against the newest, list under Superseded. Every coder item filed since has supersedes and ## Changes; an existing code under Changes missing from supersedes is a finding. Findings go in ## Done items not carried {#not-carried} (one ### P-n each, the suggested line quoted, where it belongs, Recommend:), closed by one suggested item for the designer for all of them. An item you can't check goes under Couldn't check; through moves past it.
Errors: —
Gotchas: Why: ten coder items in a row shipped with suggested doc lines that never reached the docs. Why: folding an old item's lines after a later one changed the same behaviour would put obsolete text in the spec.

check_dayWork¶

Summary: the watcher reads the day's item histories for process slips.
When: the watcher's run.
Needs: the day's item histories and topic histories.
Call: GET /api/v2/pipeline?… + topic history for each item's in-progress time.
Rules: Look for: priorities set through the board, or important/rank by an AI without askedBy; work for a bare role; items changed by an agent that hadn't taken them; items handed back and forth more than twice; scope creep (a section changed outside the item's feature) and shortcuts (a named code no doc picked up); reviews not honoured (sent-back items not returned, accepted-with-comment closed without how). Also the median per step of the dispatchers' run timings and the slowest run. Quote the ask and the change.
Errors: —
Gotchas: —

Rules¶

R-pipe-13 A title is one short sentence. At most 60 characters, aim for about 40: what changes, in plain words (Serve the CDN from S3, Reset a forgotten password by email). No lists, no "X: a, b and c", no em-dash tails, no ids, dates, versions or kind prefixes (Review:, Design:, Later: — kind and status show those). Everything else goes in summary (one sentence) and doc; the doc starts with Look at:, not a heading repeating the title. Retitling an open item you may edit is fine; keep the old wording in summary if it held detail. Why: Razie, 2026-10-09: titles had grown to 90–130 characters ("X: a, b and c — d"), so an item's page heading and the board's cards were walls of text, "screaming at you"; 125 open items were retitled.
R-pipe-9 Every commit names its item (P-n), merges too; code itself carries feature ids and behaviour codes, never P-n.
R-pipe-11 History lives on the item: every change is recorded there (when, who, what, why); send a one-line why with a write when the reason isn't obvious. Status moves across items are on Log:PipelineChanges; nothing goes to ProjectLog.
R-pipe-10 MCP tools carry the same calls under their own tool names (not skill actions, so not pullable): pipeline_list (queue_mine), pipeline_get (item_read), pipeline_create (item_file), pipeline_take (item_take), pipeline_update (item_edit), pipeline_handoff (item_handoff), pipeline_return (item_return), pipeline_drop (item_personsCall).
R-pipe-12 Background agents work their lane, two ping-pongs at most. A background agent (started by the monitor, no person watching) doesn't stop at filing: after its incoming work (thoughts, streaks, handovers) it takes its own lane's pickable items, within budget, including items returned to it (a coder's design call, a failed or bounced task), unless an item waits on its person. Ping-pong limit: count the hand-backs on an item between roles (designer → coder → designer is one ping-pong) since its person last touched it (a comment, approval, edit or status from them). At 2, stop working it: set it waiting-input with forName your person, a note saying what bounced and why, and tell them through their channel (for a designer: one thread thought, ai-question, Stuck: P-n bounced twice, with the link and your recommendation). Never start a third round in the background; their word resets the count. d2 enforces it: the third hand-back answers 409 E_PINGPONG, keeps your note on the item, moves it to waiting-input and opens the Stuck thought itself; you just move on to other work. Why: Razie, 2026-10-09: designer-72 filed P-1090 (blurbs) and went idle instead of doing it; and a poison-pill item bouncing between agents unseen would burn tokens without end.

Errors¶

E_TAKEN (409) — someone took it first → pick another. see #item_take
E_IN_PROGRESS (409) — locked to its holder → file a follow-up. see #item_take
E_NOT_YOURS — you put down or changed what you don't hold. see #item_putdown
E_SCOPE (403) — not yours to do (another person's lane, a person-only action, a take pipeline.start doesn't allow, past ~70% context) → suggest it, or hand over. see #item_personsCall
202 {approval: "A-n"} — waiting for your person's approval → don't retry. see #item_park
E_STOPPED (409) — processing stopped on the project (the processing concept) → finish what you hold, take nothing new. see #item_take
E_ALONE_NEXT / E_ALONE_BUSY / E_ALONE_RUNNING — a refactor runs alone → finish what you hold. see #queue_pickable
E_TICKET / E_TICKET_WARN — the ticket check: a required part or field is missing or looks wrong; the message names each (the parts are in the ticket concept). see #ticket_write
E_PINGPONG (409) — a background third hand-back on an item since its person last touched it; d2 has kept your note and sent the item to them → leave it, take other work. see #rules (R-pipe-12)
E_EXISTS (409) — a second dispatcher for a role, or an AI asking for a release while one is open. see #release_ask
E_STATUS — the item changed state under you (a replaced release, a done or waiting-release item). see #release_run
N_PIPE_BUILT (hint) — your code item is built and waits for its release: you're done with it. see #item_finish
E_ARG — a bad field (summary over 200, a finish without its note on acceptedIf, version/box on a non-release item). see #item_finish
E_NO_SECTION — a wrong anchor; the reply lists the section ids. see #ticket_check
E_NOT_FOUND — no such item. see #item_read

d3-f-pipeline¶‹ PreviousNext ›