Dynamic SDLC Orchestration Platform

BMAD · SDLC Playbook

A complete step-by-step guide for transforming raw requirements into a production-ready application through 8 AI-orchestrated stages — from product requirements through live deployment verification.

Stages

Roles

12+

BMAD Agents

100%

Artifact Coverage

🧭

What is BMAD-SDLC?

BMAD-SDLC is an AI-powered full-lifecycle software development orchestration system that lives inside Claude Code. It turns business requirements into deployable software through 8 sequential stages, each run by specialist BMAD agents, enforced by quality auditors, and gated by role-based approvals.

🌱 Greenfield Mode

Start a brand-new project from scratch. System scaffolds the entire codebase, directory structure, and deployment pipeline.

🔄 Brownfield Mode

Analyze an existing codebase first (Stage 0), then layer new features or improvements while preserving existing patterns.

📐 System Architecture

Layer	Technology	URL / Port
Frontend	Next.js 14 + React + TypeScript + Tailwind CSS	`http://localhost:3000`
Backend	NestJS 10 + Node.js	`http://localhost:3001/api/v1`
Database	PostgreSQL 16	`localhost:5432`
Cache	Redis 7	`localhost:6379`
Queue	RabbitMQ	`localhost:5672`

Note: Java + Spring Boot is always offered as an alternative to NestJS during intake (Step 4).

🛠

Prerequisites

Before You Start

Node.js

v20 LTS or higher

Required for frontend (Next.js) and backend (NestJS)

Java JDK

21 (LTS)

Required for Spring Boot option and PlantUML diagram rendering

PostgreSQL

Default database; Flyway migrations auto-applied

Redis

Session cache, rate limiting, token blacklisting

Python

3.13.6

C:\Program Files\Python313\python.exe — python-docx 1.2.0 must be installed

PlantUML

plantuml.jar

Place at tools\plantuml.jar; renders diagrams via java -jar

Claude Code

Latest

All interactions happen through the Claude Code CLI or IDE extension

Apache Tomcat

Local instance

CI/CD deployment target (local, not cloud or Docker)

⚠ Never use Docker or docker-compose anywhere in this application — not at startup, not for deployment. Deploy exclusively to local Apache Tomcat.

👥

Roles & Permissions Matrix

Access Control

Six roles are available. Each stage has a designated approver — only that role can unlock the next stage. The same person cannot provide both L1 and L2 approval on the same stage.

Stage	Developer	BA	Architect	Tech Lead	Test Lead	PM
1 · PRD	—	✅ L1	—	—	—	—
2 · FRS	—	✅ L1	—	—	—	—
3 · User Stories	—	✅ L1	—	—	—	—
4 · Design Docs	—	—	✅ L1	✅ L2	—	—
5 · Code	—	—	✅ L2	✅ L1	—	—
6 · Unit Tests	—	—	—	—	✅ L1	—
7 · CI/CD	—	—	✅ L1	—	—	—
8 · Verify	—	—	—	—	✅ L1	—

⛔ Role enforcement is strict. If your logged-in role is not the designated approver, the system blocks the approval and shows a denial box before prompting for a name. A BA cannot approve Stage 4 or above.

ℹ Every approval captures: Approver Full Name + Role + Timestamp — recorded in docs/sdlc/session.md under the stage entry.

🚀

Session Startup

Step 0

When you open Claude Code in the dynamic-sdlc project directory, the system auto-starts immediately — no confirmation gate. The startup hook runs silently and the welcome screen appears.

Open Claude Code in the project directory ~/projects/dynamic-sdlc
The startup-hook.ps1 fires automatically — reads docs/sdlc/session.md to detect session state
The SDLC Banner (from assets/banner.txt) is displayed as the first output
System reads the session file and shows the correct welcome screen

Welcome Screen — Existing Session

╔══════════════════════════════════════════════════════════╗ ║ ⚙ DYNAMIC SDLC ORCHESTRATION PLATFORM ║ ╠══════════════════════════════════════════════════════════╣ ║ 📁 Project : CreditCard Platform ║ ║ 🗓 Started : 2026-06-01 | Last Saved: 2026-06-14 ║ ╠══════════════════════════════════════════════════════════╣ ║ Stage Progress: ║ ║ ✅ 1 · Requirements (PRD) Approved — John BA ║ ║ ✅ 2 · Functional Req (FRS) Approved — John BA ║ ║ 🔄 3 · User Stories In Progress ║ ║ 🔒 4 · Design Documents Locked ║ ║ 🔒 5–8 · (Locked) ║ ╠══════════════════════════════════════════════════════════╣ ║ [C] Continue existing session ║ ║ [N] Start a new project ║ ╠══════════════════════════════════════════════════════════╣ ║ EXIT → type 'exit' at any time ║ ╚══════════════════════════════════════════════════════════╝

ℹ The welcome screen always reads docs/sdlc/session.md first — it shows ✅ for truly approved stages, never relying on stale system-prompt memory.

Welcome Screen — No Session (First Run)

If no session file exists, the system skips straight to the 5-step Project Intake sequence.

📋

Project Intake (5 Questions)

Step 1 of Session Setup

For new projects, the system asks exactly 5 sequential questions — one at a time, each in a styled ╔══╗ box. The 5-step intake is mandatory and cannot be skipped. Every question includes numbered answer options, a "✏️ Type my own answer" option, and EXIT.

Question 1 of 5 — Project Name

╔══════════════════════════════════════════════════════════╗ ║ Question 1 of 5 · 4 remaining ║ ╠══════════════════════════════════════════════════════════╣ ║ 📌 What is the name of this project? ║ ╠══════════════════════════════════════════════════════════╣ ║ 1. CreditCard Platform ║ ║ 2. HR Management System ║ ║ 3. Inventory Tracker ║ ║ ✏️ Type my own answer ║ ║ 5. TBD — I'll decide later ║ ╠══════════════════════════════════════════════════════════╣ ║ EXIT → type 'exit' ║ ╚══════════════════════════════════════════════════════════╝

Question 2 of 5 — Mode

Greenfield — Brand-new project; full scaffold from scratch
Brownfield — Existing codebase; system runs Stage 0 (codebase analysis) first
✏️ Type my own answer
TBD
🔁 Correct the previous answer (Q2 onward)

Question 3 of 5 — Application Type

7 options including: Web App, Mobile App, API/Microservice, Desktop App, CLI Tool, Data Pipeline, Embedded System

Question 4 of 5 — Language / Framework

Options always include: React + Spring Boot (Java), React + NestJS (Node), Vue + FastAPI (Python), Angular + .NET (C#), Next.js (Full Stack), ✏️ Type my own answer, TBD.

ℹ Java + Spring Boot must always appear as an explicit option in Step 4 — this is enforced by the system.

Question 5 of 5 — Requirements Input Method

Exactly 5 numbered options are always shown:

📝 Paste requirements as free text now
📁 Provide a file path (.txt, .md, .docx)
🎤 Provide an MP4 recording path (auto-transcribed via Whisper)
📸 Describe from scribble / whiteboard notes
⏳ TBD — Move on and add requirements later

ℹ MP4 files are silently auto-transcribed via Whisper (imageio-ffmpeg) — no confirmation prompt shown.

After Intake Completes

System saves docs/sdlc/session.md with project metadata
Role selection prompt is shown (6 role options)
Main Menu appears with Stage 1 unlocked

🗂

Main Menu

Navigation Hub

╔══════════════════════════════════════════════════════════╗ ║ ⚙ SDLC MAIN MENU · [Role: BA] ║ ╠══════════════════════════════════════════════════════════╣ ║ # Stage Status Artifact ║ ╠══════════════════════════════════════════════════════════╣ ║ 1 · Requirements (PRD) ✅ Approved 01-prd ║ ║ 2 · Functional Req (FRS) ✅ Approved 02-frs ║ ║ 3 · User Stories 🔄 In Prog 03-stories ║ ║ 4 · Design Documents 🔒 Locked ║ ║ 5 · Code Creation 🔒 Locked ║ ║ 6 · Unit Tests 🔒 Locked ║ ║ 7 · CI/CD Pipeline 🔒 Locked ║ ║ 8 · Verify Application 🔒 Locked ║ ╠══════════════════════════════════════════════════════════╣ ║ 9 · Run All Stages (Auto) ║ ╠══════════════════════════════════════════════════════════╣ ║ 10 · Exit & Save ║ ╚══════════════════════════════════════════════════════════╝

Stage progress is always displayed as a bordered ASCII table (#·Stage·Status·Artifact columns)
✅ = Approved, 🔄 = In Progress, 🔒 = Locked (prerequisite incomplete)
After every action (save, approve, redo, correct) the main menu re-appears automatically
For every approved stage, BMAD++ appears as option B in its own section on the menu

📄

Stage 1 — Requirements (PRD)

Product Requirements Document

Requirements — Product Requirements Document

Transform raw input into a structured PRD via elicitation → generation → audit → approval

bmad-agent-pm bmad-create-prd Approver: BA

Step-by-Step Flow

Invoke BMAD PM Agent: System calls Skill: bmad-agent-pm — never executes stage work directly
Elicitation (≤7 questions): PM agent asks focused questions about vision, users, features, constraints — one at a time in ╔══╗ boxes. Total count declared on Q1. Numbered options always shown.
Vision Discovery: Questions use numbered options (not open-ended text prompts) for scope, user personas, market positioning, and success criteria
PRD Generation: System calls Skill: bmad-create-prd with all gathered context
Enforcer Audit: agent-s1-prd-enforcer runs automatically — verifies completeness, auto-fixes gaps (verify-s1.md → enhance-s1.md)
Stage Completion Screen: Accuracy %, token utilization (input+output), TBD count displayed — saved to session.md
Present for Review: Draft shown inside ╔══╗ box — never as plain markdown
BA Approval: BA enters their full name; role + timestamp recorded in session.md
Stage 2 Unlocks after approval

Mandatory PRD Sections (100% Standard Required)

Functional Requirements → Journey Traceability Matrix (FR↔journey mapping)
Stakeholder Matrix (role, interest, influence, action)
Acceptance Criteria stubs for each feature
Regulatory Risk Register (GDPR, PCI-DSS, SOX etc. as applicable)
Structured Competitive Analysis (not freeform prose)

Artifacts: docs/sdlc/{ProjectName}_01-prd.md docs/sdlc/{ProjectName}_01-prd.docx

⚡ BMAD++ Option Available After Generation

After standard PRD is generated, system shows:
A · Approve Standard | B · Generate BMAD++ | R · Revise | M · Menu

BMAD++ is never auto-triggered — only on user picking B. Produces a separate enhanced file. Accuracy score can exceed 100% (target 110%–130%), calibrated to project complexity.

ℹ PRD question count must be ≤5–7 focused questions. Total count is declared on Q1. Never ask anything inferable from context.

📑

Stage 2 — Functional Requirements (FRS)

Functional Requirements Specification

Derive detailed feature behaviours and business rules directly from the approved PRD

bmad-agent-analyst Approver: BA

⚠ No clarifying questions for Stage 2+. Artifacts are generated directly from approved upstream documents. At most 1 question if something is truly ambiguous.

Invoke BMAD Analyst Agent: System calls Skill: bmad-agent-analyst
Direct Generation: Agent reads approved PRD (01-prd.md) — no elicitation sequence
FRS Content Generated:
- Feature Specification (behaviour per feature from PRD)
- Business Rules catalogue
- Functional Workflow diagrams (textual)
- Data Dictionary (field names, types, constraints, validation)
- Role × Feature Access Matrix
- Integration Contracts (API surface for each external dependency)
FRS Enforcer Audit: agent-s2-frs-enforcer validates FR traceability back to PRD
Stage metrics shown: accuracy %, tokens, TBD count
BA Review and Approval — name + timestamp saved to session.md
Stage 3 unlocks

Artifacts: docs/sdlc/{ProjectName}_02-frs.md docs/sdlc/{ProjectName}_02-frs.docx

📖

Stage 3 — User Stories & BDD Test Cases

Epics · Stories · Acceptance Tests

User Stories + BDD Business Test Cases

Decompose FRS into Epics → Stories → BDD-style acceptance test scenarios

bmad-create-epics-and-stories bmad-testarch-atdd Approver: BA

Invoke Epic/Story Skill: System calls Skill: bmad-create-epics-and-stories — reads approved FRS
Stories Generated: All features decomposed into epics and user stories with acceptance criteria
Invoke ATDD Skill: System calls Skill: bmad-testarch-atdd — generates BDD scenarios for every story
BDD Format: Given/When/Then style test cases covering happy path, edge cases, and negative scenarios
Stories Enforcer Audit: agent-s3-stories-enforcer verifies story coverage and BDD traceability back to FRS
Jira Upload: Approved stories uploaded to Jira via MCP connector (Stage 3 only)
BA Approval — name + timestamp saved
Stage 4 unlocks

Artifacts: docs/sdlc/{ProjectName}_03-epics-stories.md docs/sdlc/{ProjectName}_03-epics-stories.docx docs/sdlc/{ProjectName}_03b-business-test-cases.md docs/sdlc/{ProjectName}_03b-business-test-cases.docx

🏗

Stage 4 — Design Documents

HLD · LLD · Enterprise Architecture

High-Level Design · Low-Level Design · Architecture

Three independent design documents with embedded PlantUML diagrams — dual approval required

bmad-agent-architect bmad-create-architecture L1: Architect · L2: Tech Lead

⚠ Stages 3 & 4 require L1 + L2 dual approval. The next stage is locked until both approve. The same person cannot provide both signatures.

Invoke Architect Agent: System calls Skill: bmad-agent-architect → Skill: bmad-create-architecture
Generate HLD — High-Level Design document
Generate LLD — Low-Level Design document
Generate Arch — Enterprise Architecture document
PlantUML Diagrams rendered — java -jar tools\plantuml.jar -tpng — embedded in each .docx via add_picture()
Design Enforcer Audit: agent-s4-design-enforcer reviews all three docs for completeness
Architect L1 Approval — name + timestamp saved
Tech Lead L2 Approval — name + timestamp saved; Stage 5 unlocks

Document Contents

Document	Sections	Diagrams (PlantUML)
HLD	§1 Overview, §2 Flow (Fig 1), §3 Components (Fig 2), §4 Tech Stack, §5 Security, §6 Scalability	Fig 1: Overall Flow (`sequence`) · Fig 2: Component Architecture (`component`)
LLD	§1 DB Schema, §2 API Contracts, §3 Feature Sequences (one per PRD feature), §4 Error Handling	ERD (`class` w/ `<<entity>>`) · One sequence diagram per feature (Figs 3–9)
Arch	§1 Enterprise Context, §2 Deployment Zones (Fig 10), §3 Integration Points, §4 Governance	Fig 10: Enterprise Architecture (`deployment` or `component` with zones)

PlantUML Pipeline Rules

.puml sources saved under docs/sdlc/diagrams/ — text-diffable in git
Rendered to PNG via java -jar plantuml.jar -tpng {file}.puml
PNG embedded in the correct section of each .docx via add_picture()
SMETANA layout engine used (no Graphviz dependency needed)
Close Word files before generating — python-docx will fail if the file is open
Never use matplotlib, draw.io, or Mermaid — only PlantUML

Artifacts (6 files): {ProjectName}_HLD.md · .docx {ProjectName}_LLD.md · .docx {ProjectName}_Arch.md · .docx docs/sdlc/diagrams/*.puml + *.png

💻

Stage 5 — Code Creation

Scaffolding · Generation · Review · Security

Code Creation — Full Application Build

Scaffold → Generate → Senior Review (Phase B) → OWASP Security Audit (Phase C)

bmad-agent-dev bmad-quick-dev L1: Tech Lead · L2: Architect

Invoke Dev Agent: System calls Skill: bmad-agent-dev → Skill: bmad-quick-dev
Greenfield Scaffold: Creates project directory structure, package.json/pom.xml, config files, Docker-free startup scripts
Phase A — Code Generation (layer order must be respected):
1. Configuration & Environment
2. Data Layer (models, migrations, repositories)
3. Service Layer (business logic)
4. API Layer (controllers, routes, DTOs, validators)
5. Integration Layer (external APIs, message queues)
6. Entry Point & startup wiring
Phase B — Senior Code Review: Checks correctness, architecture conformance, and operability (logging, error handling, observability)
Phase C — OWASP Top 10 Security Audit: Maps each vulnerability category (injection, broken auth, XSS, IDOR, etc.) against the generated code; Critical & High findings auto-fixed before proceeding
Code Enforcer Audit: agent-s5-code-enforcer reviews for residual issues
Tech Lead L1 Approval
Architect L2 Approval → Stage 6 unlocks

Artifacts: docs/sdlc/{ProjectName}_05-code-creation.md · .docx src/ (all source files)

ℹ Auth uses JWT RS256 (15-min access tokens + 7-day refresh cookie). Never store tokens in localStorage. Never generate secrets in code — always use environment variables.

🧪

Stage 6 — Unit Tests

Comprehensive Test Suite

Unit Test Suite — Full Coverage

Generate comprehensive tests matched to the language & framework chosen in intake

bmad-tea bmad-testarch-test-design Approver: Test Lead

Invoke Test Agent: System calls Skill: bmad-tea → Skill: bmad-testarch-test-design + bmad-testarch-framework
Framework Selection matches language: Jest (React/Node), JUnit 5 + Mockito (Java/Spring Boot), pytest (Python), Vitest (Vite projects)
Coverage Targets:

Layer Coverage Target

Service Layer 90% line + branch

API / Controller Layer 85%

Data / Repository Layer 80%
Test Types Generated: Unit tests, integration tests, contract tests, edge case tests, negative path tests
Tests Enforcer Audit: agent-s6-tests-enforcer validates coverage reports
Test Lead Approval → Stage 7 unlocks

Layer	Coverage Target
Service Layer	90% line + branch
API / Controller Layer	85%
Data / Repository Layer	80%

Artifacts: docs/sdlc/{ProjectName}_06-unit-tests.md · .docx tests/unit/ (all test files)

🔄

Stage 7 — CI/CD Pipeline

Build · Deploy · Release

CI/CD Pipeline Configuration

GitHub Actions workflows + deployment to local Apache Tomcat

bmad-testarch-ci Approver: Architect

Invoke CI Skill: System calls Skill: bmad-testarch-ci
CI Workflow (ci.yml): Triggered on push/PR — runs lint, unit tests, build, SAST scan
CD Workflow (cd.yml): Triggered on merge to main — builds artifact, deploys to local Tomcat
Deployment Runbook generated — step-by-step deployment instructions
Environment configuration documented — secrets management, env var injection
CI/CD Enforcer Audit: agent-s7-cicd-enforcer reviews pipeline configuration
Architect Approval → Stage 8 unlocks

Artifacts: docs/sdlc/{ProjectName}_07-cicd.md · .docx .github/workflows/ci.yml .github/workflows/cd.yml

⚠ Deployment target is local Apache Tomcat only. Never AWS, Azure, GCP, or Docker. CI/CD pipelines must not reference any cloud provider or container orchestration.

✅

Stage 8 — Verify Application

Smoke Tests · Health Checks · Sign-off

Application Verification & Final Sign-Off

Validate the deployed application end-to-end before final acceptance

bmad-agent-dev Approver: Test Lead

Read Deployment Artifact: System reads 07-cicd.md to determine deployed app location and start commands
Smoke Test Suite: Invokes Skill: bmad-agent-dev to execute smoke tests against deployed app
Endpoint Verification: All API endpoints from LLD validated (GET /api/v1/health, auth, core features)
Log Review: No critical errors in application logs
Performance Baseline: Response time benchmarks captured
Verify Enforcer Audit: agent-s8-verify-enforcer validates the verification report
Test Lead Approval — all 8 stages now complete

✅ Final Summary Screen — Displayed after Stage 8 approval:
• Stage status table (bordered ASCII) with all 8 stages marked ✅
• Frontend: http://localhost:3000
• Backend: http://localhost:3001/api/v1
• Note: The app is NOT auto-started. Type start app to launch it.

Artifact: docs/sdlc/{ProjectName}_08-verify.md · .docx

⚡

BMAD++ Accuracy Boost

Optional Enhancement

BMAD++ is an optional enhancement layer available after every stage. It never auto-triggers. Selecting it generates a superset document that includes all standard content plus additional depth markers.

╔══════════════════════════════════════════════════════════╗ ║ Stage 1 — PRD Complete ║ ╠══════════════════════════════════════════════════════════╣ ║ Standard Accuracy: 100% | Tokens: 12,450 in / 8,230 out ║ ║ TBD Count: 0 ║ ╠══════════════════════════════════════════════════════════╣ ║ [A] Approve Standard Version ║ ║ [B] Generate BMAD++ Enhanced Version ║ ║ [R] Revise — I want changes ║ ║ [M] Return to Main Menu ║ ╠══════════════════════════════════════════════════════════╣ ║ EXIT → type 'exit' ║ ╚══════════════════════════════════════════════════════════╝

BMAD++ Rules

Accuracy score is dynamic and multi-dimensional — calibrated to project type and complexity
Score can exceed 100% (target range: 110%–130%) — no fixed ceiling, never a fake number
BMAD++ document is fully self-contained — includes ALL standard content + enhancements; never says "See Standard §X — unchanged"
Additions marked with [B++] inline throughout the document
Every BMAD++ doc opens with: (1) full TOC with [B++] markers, (2) Enhancements Summary table
Both standard and BMAD++ versions saved separately as *-bmad.md and *-bmadpp.md
On the Main Menu, BMAD++ remains as option B for every approved stage — never disappears
Word docs: BMAD++ gets teal banner + green [B++] row tinting in tables

ℹ A comparison table is always shown after BMAD++ is generated — allowing the user to see what was added vs the standard version before choosing which to approve.

🔏

Approval Workflow

3-Step Chain Per Stage

Every stage follows the same 3-step approval chain. The chain is sequential — the next step does not start until the current one passes.

① Claude Auto-Review

→

② Human Approval (role-gated)

→

③ Stage Locked → Unlocked

Step 1 — Claude Auto-Review

Stage-specific enforcer agent runs (e.g., agent-s1-prd-enforcer)
Checks artifact against quality criteria from verify-s{n}.md
Auto-fixes issues using enhance-s{n}.md instructions
Only presents to human once APPROVED internally

Step 2 — Human Approval

System checks logged-in role against designated approver — blocks if mismatch
For Stages 4 & 5: dual L1+L2 required (two separate named approvers)
Approver types their full name; role + timestamp recorded in session.md
Partial artifacts (from early EXIT) can be approved as TBD-gap versions

Step 3 — Post-Approval

Stage marked complete in session.md
Next stage unlocked on Main Menu
Stage 3 only: stories uploaded to Jira via MCP
Main Menu re-displayed automatically after approval

🔁

Redo Any Stage

Non-Destructive Re-Run

Any stage can be redone at any time — even after approval. This is always allowed and is never blocked.

Type redo {n} (e.g., redo 2) from the Main Menu or during any stage
System re-runs the stage from the beginning using current session context
Downstream stages are flagged (⚠ may need re-approval) but not deleted
Previous artifact files are preserved — new versions appended with a timestamp suffix
After redo completes, Main Menu is re-displayed

⚠ Redoing Stage 1 (PRD) may cause downstream stages to drift. The system flags but never auto-deletes dependent artifacts.

🚪

Exit & Save

4 Exit Paths

EXIT is available everywhere. It always appears in its own visually distinct ╔══╗ section — never mixed with action options.

Exit Path	Trigger	Behaviour
Main Menu	Select option 10	Confirmation dialog → Save session + all artifacts → Goodbye message
During Question	Type `exit`	Confirmation → Generate partial artifact (TBD gaps marked) → BA approval prompt → Goodbye
During Approval	Type `E`	Confirmation → Mark stage as pending-approval in session.md → Goodbye
Terminal Close (✕)	Window close / Ctrl+C	`close-guard.ps1` intercepts → Native Windows dialog → Auto-save via Stop hook (`stop-hook.ps1`)

ℹ After partial save on EXIT during questions, the system shows a BA approval prompt before goodbye — so the BA can approve the partial artifact and allow downstream stages to proceed. Options: A (Approve+exit), R (Reject+exit), S (Skip/stay locked).

✅ Downstream stages are NOT blocked by TBD gaps in partial artifacts. Exception: the 5-step intake sequence is mandatory and cannot be partially saved.

⌨

Keyword Commands

Anywhere in Session

Command	Effect
menu	Display the Main Menu from any context
status	Show current session state and stage progress table
role	Switch your active role (prompts role selection again)
redo {n}	Redo stage number N (e.g., `redo 3` re-runs Stage 3)
start app	Verify all 8 stages complete → read deployment artifact → launch frontend + backend
exit	Exit with save (confirmation prompt shown)

📁

Artifact Reference

All Output Files

ℹ All artifacts are saved as both .md AND .docx. Every filename is prefixed with the project name: {ProjectName}_{artifact}. Example: CreditCard_01-prd.md.

Stage	Artifact Files	Approver
1 · PRD	`{Name}_01-prd.md` · `.docx` `{Name}_01-prd-bmadpp.md` · `.docx` (optional)	BA
2 · FRS	`{Name}_02-frs.md` · `.docx`	BA
3 · User Stories	`{Name}_03-epics-stories.md` · `.docx` `{Name}_03b-business-test-cases.md` · `.docx`	BA
4 · Design	`{Name}_HLD.md` · `.docx` `{Name}_LLD.md` · `.docx` `{Name}_Arch.md` · `.docx` `docs/sdlc/diagrams/.puml` · `.png`	Arch + Tech Lead
5 · Code	`{Name}_05-code-creation.md` · `.docx` `src/` (all source files)	Tech Lead + Arch
6 · Unit Tests	`{Name}_06-unit-tests.md` · `.docx` `tests/unit/`	Test Lead
7 · CI/CD	`{Name}_07-cicd.md` · `.docx` `.github/workflows/ci.yml` `.github/workflows/cd.yml`	Architect
8 · Verify	`{Name}_08-verify.md` · `.docx`	Test Lead
Session	`docs/sdlc/session.md`	Auto-managed

Document Quality Standards (All .docx)

TOC on page 2
Headers and footers (project name + date + page number)
Document properties set (title, author, subject)
Styled tables: navy header row + alternating row shading
PlantUML diagrams embedded with figure captions
BMAD++ docs: teal banner on cover + green [B++] row tinting

API Endpoints (Backend)

Method	Endpoint	Purpose
POST	`/api/v1/auth/login`	JWT authentication
GET	`/api/v1/projects`	List all projects
POST	`/api/v1/projects`	Create new project
GET	`/api/v1/projects/{id}`	Project detail + stage status
POST	`/api/v1/projects/{id}/stages/{n}/start`	Start a stage
POST	`/api/v1/projects/{id}/stages/{n}/submit`	Submit for approval
POST	`/api/v1/stages/{stageId}/approvals`	Approve or reject
GET	`/api/v1/projects/{id}/stream`	SSE live event stream

Default User Logins

Username	Role
`ba`	Business Analyst
`developer`	Developer
`architect`	Architect
`tech_lead`	Tech Lead
`test_lead`	Test Lead
`pm`	Project Manager

⚡

Quick Reference — Full Pipeline at a Glance

#	Stage	Primary BMAD Agent	Enforcer	Approver(s)	Key Output
1	PRD	`bmad-agent-pm` `bmad-create-prd`	`agent-s1-prd-enforcer`	BA (L1)	Product Requirements Document
2	FRS	`bmad-agent-analyst`	`agent-s2-frs-enforcer`	BA (L1)	Functional Requirements Spec
3	User Stories	`bmad-create-epics-and-stories` `bmad-testarch-atdd`	`agent-s3-stories-enforcer`	BA (L1)	Epics + Stories + BDD Tests
4	Design	`bmad-agent-architect` `bmad-create-architecture`	`agent-s4-design-enforcer`	Arch (L1) + TL (L2)	HLD + LLD + Enterprise Arch
5	Code	`bmad-agent-dev` `bmad-quick-dev`	`agent-s5-code-enforcer`	TL (L1) + Arch (L2)	Full application source
6	Unit Tests	`bmad-tea` `bmad-testarch-test-design`	`agent-s6-tests-enforcer`	Test Lead (L1)	Test suite (90%/85%/80% coverage)
7	CI/CD	`bmad-testarch-ci`	`agent-s7-cicd-enforcer`	Architect (L1)	GitHub Actions + Tomcat deploy
8	Verify	`bmad-agent-dev`	`agent-s8-verify-enforcer`	Test Lead (L1)	Verification report