agent-pipeline Β· git:20260828.3a93688 Β· 2026-08-28 Β· sha256 dae9cde8c0442d88

agent-pipeline git:20260828.3a93688A

Immutable. This exact content is served forever at /api/v1/blob/dae9cde8c0442d88.

---
name: agent-pipeline
description: Reference for how BDB structures autonomous software engineering work β€” the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.
category: bdb-core
---

# πŸ”„ BDB Software Engineering Pipeline

When orchestrating or executing autonomous software development, follow the
lifecycle below β€” but the **real, runnable implementation is
[`.agents/graph.md`](../../../.agents/graph.md)**, invoked via `/startcycle-graph`
(see [`skills/basic/startcycle-graph/SKILL.md`](../../basic/startcycle-graph/SKILL.md)).
This file is a lifecycle summary, not a second spec β€” if it and `graph.md`
ever disagree, `graph.md` is right.

```
 define        plan          build          verify + review        ship
 β”Œβ”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
 β”‚ Goal β”‚ ─▢ β”‚ Plan β”‚ ─▢ β”‚ UI/UX,     β”‚ ─▢ β”‚ Reviewer     β”‚ ─▢ β”‚ Shippingβ”‚
 β”‚      β”‚    β”‚      β”‚    β”‚ Engineering,β”‚    β”‚ (adversarial)β”‚    β”‚ (gate)  β”‚
 β”‚      β”‚    β”‚      β”‚    β”‚ Media/Eventβ”‚    β”‚              β”‚    β”‚         β”‚
 β””β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
 Architect   TechLead     the build nodes    no-progress guard   requires GO
                          run in parallel     repairs loop back   to actually ship
```

There is no separate `/spec`, `/plan`, `/build`, `/test`, `/review`, or
`/ship` slash command β€” an earlier version of this file described those and
a `Planner_Orchestrator` agent that no longer exists (split into Architect +
TechLead; see `graph.md`'s Nodes section for why). The whole lifecycle above
runs through the single `/startcycle-graph` entry point, which invokes each node
in turn per `graph.md`'s edge table:

| Stage | Node(s) | Reads | Writes |
|---|---|---|---|
| Define + Plan | Architect, TechLead | `state.goal` | `state.artifacts.plan` |
| Build | Godmode_UI_UX, Godmode_Engineering, Godmode_Media_EventTech (if needed) | the plan | their own artifacts |
| Verify + Review | Reviewer | build artifacts + contract only, never the implementer's claim | `state.findings` |
| Ship | Godmode_Shipping | all artifacts, findings | `state.gate`, requires a human `GO` |

**The one rule, unchanged from `graph.md`:** these nodes never invoke each
other. A dispatcher β€” the `/startcycle-graph` workflow, or the main session acting
as one β€” reads `production_artifacts/state.json` after each node returns and
decides what runs next.

## 1. Overview
This file exists so anyone (human or agent) asking "what's the BDB software
lifecycle?" gets the real shape of it, without re-deriving it from `graph.md`
line by line. It is descriptive, not an alternate entry point.

## 2. When to Use
- Use when you need the lifecycle framing (define β†’ plan β†’ build β†’ verify β†’
  ship) to structure a conversation or a manual walkthrough.
- To actually run the pipeline autonomously, invoke `/startcycle-graph` β€” don't
  hand-simulate the stages here.
- Exclude when standard tool execution is sufficient for the task at hand.

## 3. Core Process
1. Read `.agents/graph.md` for the current node/edge contract before
   assuming anything about how a stage works β€” this file summarizes it, it
   does not own it.
2. If autonomous execution is needed, invoke `/startcycle-graph` rather than
   manually working through the stages above.
3. Verify exit codes, file modifications, or state.json contents to
   guarantee a stage's side effects actually happened before reporting
   completion.

## 4. Common Rationalizations
| Rationalization | Reality |
|---|---|
| "The code change was small, so I skipped updating OpenWiki docs." | Every state change must be reflected in the relevant system records. |
| "The ingest script exited without an error, so the memB index must be updated." | Silent failures happen; explicit verification of the side effect is mandatory. |
| "I'll let /startcycle-graph proceed without a defined rollback path." | Proceeding without a rollback path corrupts the workflow integrity and safety. |
| "This file's stage descriptions look complete, so I'll follow them 'in spirit' instead of invoking /startcycle-graph." | Exactly the failure this file was rewritten to stop β€” see `graph.md` and `SESSION-HANDOVER-v3.13.md` for the incident where a duplicated pipeline description caused a model to skip the real dispatcher entirely. |

## 5. Red Flags
- Referencing `/spec`, `/plan`, `/build`, `/test`, `/review`, or `/ship` as
  if they are real slash commands in this repo β€” they are not.
- Referencing `Planner_Orchestrator` as a current agent β€” it was split into
  Architect and TechLead.
- One node's output instructing another node directly instead of the
  dispatcher deciding the next step from `state.json` (the hand-off pattern
  `graph.md` (F-17) rules out).
- Bypassing the verification step after a script execution.

## 6. Verification
- [ ] Verified script exit codes are explicitly checked.
- [ ] Confirmed target files or `state.json` reflect the expected change.
- [ ] Ensured no silent failures were ignored before reporting success.