Agent Pipeline

🔄 BDB Software Engineering Pipeline

When orchestrating or executing autonomous software development, follow the lifecycle below — but the real, runnable implementation is .agents/graph.md, invoked via /startcycle-graph (see skills/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:

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

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.