| ํญ๋ชฉ | ๋ด์ฉ |
|---|---|
| Invoke | /solutioning-gate-check |
/solutioning-gate-check โ ์ค๊ณ ํฉ๊ฒฉ ์ ๊ฒ#
ํ๋ง๋๋ก#
๋ณธ๊ฒฉ์ ์ผ๋ก ๊ฐ๋ฐ์ ๋ค์ด๊ฐ๊ธฐ ์ ์, ์ค๊ณ ๋๋ฉด์ด ๋น ์ง ๊ณณ ์์ด ์ ๊ทธ๋ ค์ก๋์ง ์ต์ข ๊ฒ์ฌํ๋ ๋จ๊ณ์ ๋๋ค. ๊ณต์ฌ๋ฅผ ์์ํ๊ธฐ ์ ๊ฑด์ถ ๋๋ฉด์ ์ ๊ฒํด "์ด๋๋ก ์ง์ด๋ ๋๊ฒ ๋ค / ๋ณด์์ด ํ์ํ๋ค"๋ฅผ ํ์ ํ๋ ๊ฒ๊ณผ ๊ฐ์์.
๋๊ฐยท์ธ์ ์ฐ๋์#
- ์ํคํ ์ฒ(์ค๊ณ) ๋ฌธ์๋ฅผ ๋ค ๋ง๋ค๊ณ , ๋ค์ ๋จ๊ณ์ธ ๊ฐ๋ฐ(๊ตฌํ)๋ก ๋์ด๊ฐ๊ธฐ ์ง์ ์ธ ๊ฒฝ์ฐ
- "์๊ตฌ์ฌํญ์ด ์ค๊ณ์ ๋น ์ง์์ด ๋ฐ์๋๋์ง" ๊ฐ๊ด์ ์ผ๋ก ํ์ธํ๊ณ ์ถ์ ๋
- System Architect ์ญํ ๋ก ์งํํ๋ฉฐ, ๋ณดํต 15~30๋ถ ์ ๋ ๊ฑธ๋ฆฝ๋๋ค.
๐ ๋์: ์ํคํ
์ฒ๊ฐ ์๋ ํ๋ก์ ํธ(Level 2 ์ด์). ์ค๊ณ ๋ฌธ์๊ฐ ์์ผ๋ฉด ๋จผ์ /architecture๋ฅผ ์คํํด์ผ ํฉ๋๋ค.
๋ฌด์์ ํด์ฃผ๋์#
์ค๊ณ๊ฐ ์๊ตฌ์ฌํญ์ ์ผ๋ง๋ ์ ๋ด์๋์ง ์ ์๋ฅผ ๋งค๊ธฐ๊ณ , ํฉ๊ฒฉ/์กฐ๊ฑด๋ถ ํฉ๊ฒฉ/๋ถํฉ๊ฒฉ์ ํ์ ํ ๋ณด๊ณ ์ ํ์ผ์ ๋ง๋ค์ด ์ค๋๋ค.
- ์ ๊ฒ ๊ฒฐ๊ณผ๋
{output_folder}/solutioning-gate-check-{ํ๋ก์ ํธ์ด๋ฆ}-{๋ ์ง}.mdํ์ผ๋ก ์ ์ฅ๋ฉ๋๋ค. - ๋ณด๊ณ ์์๋ ๊ธฐ๋ฅ ์๊ตฌ์ฌํญ(FR)ยท๋น๊ธฐ๋ฅ ์๊ตฌ์ฌํญ(NFR)์ด ์ค๊ณ์ ์ผ๋ง๋ ๋ฐ์๋๋์ง(%), ์ค๊ณ ํ์ง ์ฒดํฌ๋ฆฌ์คํธ ์ ์, ๋งํ ๋ฌธ์ (Blocker), ๊ฐ์ ๊ถ๊ณ ๊ฐ ๋ด๊น๋๋ค.
- ํฉ๊ฒฉ์ด๋ฉด ๋ค์ ๋จ๊ณ(
/sprint-planning)๋ก, ๋ถํฉ๊ฒฉ์ด๋ฉด ๋ณด์ ํ ๋ค์ ์ ๊ฒํ๋๋ก ์๋ดํฉ๋๋ค.
์ด๋ป๊ฒ ์ฐ๋์#
# ์ค๊ณ ํฉ๊ฒฉ ์ ๊ฒ ์คํ
/solutioning-gate-check
์คํํ๋ ค๋ฉด ๋ฏธ๋ฆฌ ๋ ๊ฐ์ง ๋ฌธ์๊ฐ ์์ด์ผ ํฉ๋๋ค.
- ์ค๊ณ ๋ฌธ์:
.bmad/architecture-*.md(์์ผ๋ฉด/architecture๋ฅผ ๋จผ์ ์คํ) -
์๊ตฌ์ฌํญ ๋ฌธ์:
.bmad/prd-*.md๋๋.bmad/tech-spec-*.md(๋ ๋ค ์์ผ๋ฉด ์ ๊ฒ ์งํ ๋ถ๊ฐ)
์์์ ๋ฌด์จ ์ผ์ด ๋ฒ์ด์ง๋์#
ํฌ๊ฒ ์๊ตฌ์ฌํญ์ ๊บผ๋ด โ ์ค๊ณ์ ๋์กฐ โ ํ์ง ์ฑ์ โ ํฉ๊ฒฉ ํ์ ์์ผ๋ก ์งํ๋ฉ๋๋ค.
- ๋ฌธ์ ์ฝ๊ธฐ โ ์ค๊ณ ๋ฌธ์์ ์๊ตฌ์ฌํญ ๋ฌธ์๋ฅผ ๋ถ๋ฌ์ ํต์ฌ ํญ๋ชฉ(์๊ตฌ์ฌํญ ๋ชฉ๋ก, ๊ธฐ์ ์คํ, ๋ฐ์ดํฐยทAPI ์ค๊ณ ๋ฑ)์ ์ ๋ฆฌํฉ๋๋ค.
- ๊ธฐ๋ฅ ์๊ตฌ์ฌํญ(FR) ๋์กฐ โ ๊ฐ ๊ธฐ๋ฅ ์๊ตฌ์ฌํญ์ด ์ค๊ณ์ ์ด๋ ๋ถํ(์ปดํฌ๋ํธ)์ ์ฐ๊ฒฐ๋๋์ง ํ์ธํ๊ณ , ๋น ์ง ํญ๋ชฉ์ ์ฐพ์ ๋ฐ์๋ฅ (%)์ ๊ณ์ฐํฉ๋๋ค.
- ๋น๊ธฐ๋ฅ ์๊ตฌ์ฌํญ(NFR) ๋์กฐ โ ์ฑ๋ฅยท๋ณด์ยทํ์ฅ์ฑ ๊ฐ์ ํ์ง ์๊ตฌ์ฌํญ์ด ์ค์ ๋ก ํด๊ฒฐ์ฑ ๊ณผ ํจ๊ป ๋ด๊ฒผ๋์ง, ํด๊ฒฐ์ฑ ์ด ์ถฉ๋ถํ์ง ํ๊ฐํฉ๋๋ค.
- ์ค๊ณ ํ์ง ์ฑ์ โ ์์คํ ์ค๊ณยท๊ธฐ์ ์คํยท๋ฐ์ดํฐยทAPIยท๋ณด์ยทํ์ฅ์ฑยท์ ๋ขฐ์ฑยท๋ฐฐํฌยท์ถ์ ์ฑ ๋ฑ ํญ๋ชฉ๋ณ ์ฒดํฌ๋ฆฌ์คํธ๋ก ์ ์๋ฅผ ๋งค๊น๋๋ค.
- ํฉ๊ฒฉ ํ์ ๋ณด๊ณ ์ ์์ฑ โ FR/NFR ๋ฐ์๋ฅ ๊ณผ ํ์ง ์ ์๋ฅผ ์ข ํฉํด ํฉ๊ฒฉ(PASS)ยท์กฐ๊ฑด๋ถ ํฉ๊ฒฉ(CONDITIONAL PASS)ยท๋ถํฉ๊ฒฉ(FAIL) ์ค ํ๋๋ก ํ์ ํ๊ณ ๋ณด๊ณ ์๋ฅผ ์ ์ฅํฉ๋๋ค.
-
์ํ ์
๋ฐ์ดํธ์ ๋ค์ ๋จ๊ณ ์๋ด โ ํฉ๊ฒฉ์ด๋ฉด ์งํ ์ํ๋ฅผ ๊ฐฑ์ ํ๊ณ ์คํ๋ฆฐํธ ๊ณํ(
/sprint-planning)์ผ๋ก, ๋ถํฉ๊ฒฉ์ด๋ฉด ๋ณด์ ํ ์ฌ์คํ์ ์๋ดํฉ๋๋ค.
ํ์ ๊ธฐ์ค ์์ฝ: ํฉ๊ฒฉ์ FR 90% ์ด์ยทNFR 90% ์ด์ยทํ์ง 80% ์ด์ยท์น๋ช ์ ๋งํ ์์, ์กฐ๊ฑด๋ถ ํฉ๊ฒฉ์ ๊ฐ๊ฐ 80%ยท80%ยท70% ์ด์์ด๋ฉฐ ๋งํ ๋ฌธ์ ์ ๋์ ๊ณํ์ด ์์ ๋, ๊ทธ ๋ฏธ๋ง์ด๊ฑฐ๋ ํด๊ฒฐ ์ ๋ ์น๋ช ์ ๋ฌธ์ ๊ฐ ์์ผ๋ฉด ๋ถํฉ๊ฒฉ์ ๋๋ค.
โ๏ธ ์์ธ ์ต์ ยท์คํ ๋ช ์ธ (๊ฐ๋ฐ์ / AI ์์ด์ ํธ์ฉ)
Workflow Overview#
Goal: Validate architecture completeness and quality before moving to implementation
Phase: 3 - Solutioning (Gate)
Agent: System Architect
Inputs: Architecture document, PRD or tech-spec
Output: Validation report with pass/fail and detailed findings
Duration: 15-30 minutes
Required for: Level 2+ projects (or any project with architecture)
Pre-Flight#
- Load context per
helpers.md#Combined-Config-Load - Check status per
helpers.md#Load-Workflow-Status - Verify architecture exists:
- Check for:
.bmad/architecture-*.md - If not found, ask user for path or inform that /architecture must run first
- Check for:
- Load requirements document:
- Check for PRD:
.bmad/prd-*.md - If no PRD, check for tech-spec:
.bmad/tech-spec-*.md - If neither, gate check cannot proceed
- Check for PRD:
Validation Process#
Use TodoWrite to track: Pre-flight โ Load Docs โ Extract Requirements โ Validate Coverage โ Check Quality โ Generate Report โ Update Status
Approach: Thorough, systematic, quality-focused.
Part 1: Load and Parse Documents#
Load Architecture Document:
- Read architecture document from
.bmad/architecture-*.md - Extract key sections:
- Architectural drivers
- System components
- Technology stack
- Data architecture
- API design
- NFR coverage sections
- FR traceability
- NFR traceability
Load Requirements Document:
- Read PRD or tech-spec
- Extract all FRs (Functional Requirements)
- For PRD: Look for FR-001, FR-002, etc.
- For tech-spec: Extract from requirements list
- Extract all NFRs (Non-Functional Requirements)
- For PRD: Look for NFR-001, NFR-002, etc.
- For tech-spec: Extract from performance, security, other NFR sections
Create baseline:
Requirements Baseline:
- Total FRs: {count}
- Total NFRs: {count}
- Critical FRs (Must Have): {count}
- Epics (if PRD): {count}Part 2: Validate FR Coverage#
For each FR from requirements:
Check if FR is mentioned in architecture
- Search for FR-{ID} in architecture document
- Check FR traceability matrix (if present)
- Check system components section
Verify component assignment
- Does the FR map to specific components?
- Is the implementation approach clear?
- Are dependencies identified?
Record findings:
FR-{ID}: {Name} โ Covered | โ Missing Components: {list} Notes: {any concerns}
Generate FR Coverage Report:
### Functional Requirements Coverage
**Total FRs:** {total}
**Covered:** {covered_count} ({percentage}%)
**Missing:** {missing_count}
**Missing FRs:**
{list of FRs not addressed in architecture}
**Partial Coverage (needs clarification):**
{list of FRs with incomplete coverage}Part 3: Validate NFR Coverage#
For each NFR from requirements:
Check if NFR has dedicated section
- Look for "NFR-{ID}" in architecture
- Check if architectural solution is provided
- Verify implementation notes exist
- Check if validation approach is defined
Assess solution quality:
- Is the solution specific (not generic)?
- Does it address the measurable target?
- Are trade-offs documented?
- Is it implementable?
Record findings:
NFR-{ID}: {Name} โ Fully Addressed | โ Partially Addressed | โ Missing Solution Quality: Good | Fair | Poor | N/A Notes: {assessment}
Common NFR categories to check:
- Performance (response time, throughput)
- Security (auth, encryption, compliance)
- Scalability (concurrent users, data volume)
- Reliability (uptime, failover)
- Maintainability (code quality, documentation)
- Usability (accessibility, UX)
- Compatibility (browsers, devices, platforms)
Generate NFR Coverage Report:
### Non-Functional Requirements Coverage
**Total NFRs:** {total}
**Fully Addressed:** {full_count} ({percentage}%)
**Partially Addressed:** {partial_count} ({percentage}%)
**Missing:** {missing_count}
**Missing NFRs:**
{list of NFRs not addressed}
**Needs Improvement:**
{list of NFRs with weak or generic solutions}Part 4: Architecture Quality Checks#
Technical Completeness:
Run systematic checklist:
### Architecture Quality Checklist
**System Design:**
- [ ] Architectural pattern is clearly stated and justified
- [ ] System components are well-defined (3-10 components)
- [ ] Component responsibilities are clear
- [ ] Component interfaces are specified
- [ ] Dependencies between components are documented
**Technology Stack:**
- [ ] Frontend technology is selected and justified
- [ ] Backend framework is selected and justified
- [ ] Database choice is explained with rationale
- [ ] Infrastructure approach is defined
- [ ] Third-party services are identified
- [ ] Trade-offs are documented for major tech choices
**Data Architecture:**
- [ ] Core data entities are defined
- [ ] Entity relationships are specified
- [ ] Database design is described
- [ ] Data flow is documented
- [ ] Caching strategy is defined (if applicable)
**API Design:**
- [ ] API architecture is specified (REST, GraphQL, etc.)
- [ ] Key endpoints are listed (10-20 for Level 2, more for 3-4)
- [ ] Authentication method is defined
- [ ] Authorization approach is specified
- [ ] API versioning strategy is stated
**Security:**
- [ ] Authentication design is comprehensive
- [ ] Authorization model is defined
- [ ] Data encryption (at rest and in transit) is addressed
- [ ] Security best practices are documented
- [ ] Secrets management is addressed
**Scalability & Performance:**
- [ ] Scaling strategy is defined (horizontal/vertical)
- [ ] Performance optimization approaches are listed
- [ ] Caching strategy is comprehensive
- [ ] Load balancing is addressed
**Reliability:**
- [ ] High availability design is present
- [ ] Disaster recovery approach is defined
- [ ] Backup strategy is specified
- [ ] Monitoring and alerting are addressed
**Development & Deployment:**
- [ ] Code organization is described
- [ ] Testing strategy is defined (unit, integration, e2e)
- [ ] CI/CD pipeline is outlined
- [ ] Deployment strategy is specified
- [ ] Environments are defined (dev, staging, prod)
**Traceability:**
- [ ] FR-to-component mapping exists
- [ ] NFR-to-solution mapping exists
- [ ] Trade-offs are explicitly documented
**Completeness:**
- [ ] All major decisions have rationale ( " why " )
- [ ] Assumptions are stated
- [ ] Constraints are documented
- [ ] Risks are identified
- [ ] Open issues are listedCount:
- Total checks: {total}
- Passed: {passed} ({percentage}%)
- Failed: {failed}
Part 5: Generate Gate Check Report#
Create comprehensive report:
# Solutioning Gate Check Report
**Date:** {date}
**Project:** {project_name}
**Reviewer:** {user_name} (Winston - System Architect)
**Architecture Version:** {version}
---
## Executive Summary
**Overall Assessment:** {PASS | CONDITIONAL PASS | FAIL}
**Summary:**
{2-3 sentence summary of architecture quality and readiness}
**Key Findings:**
- {Finding 1}
- {Finding 2}
- {Finding 3}
---
## Requirements Coverage
### Functional Requirements
- **Total FRs:** {total}
- **Covered:** {covered} ({percentage}%)
- **Missing:** {missing}
{Details from Part 2}
### Non-Functional Requirements
- **Total NFRs:** {total}
- **Fully Addressed:** {full} ({percentage}%)
- **Partially Addressed:** {partial} ({percentage}%)
- **Missing:** {missing}
{Details from Part 3}
---
## Architecture Quality Assessment
**Score:** {passed}/{total} checks passed ({percentage}%)
{Failed checks with details}
---
## Critical Issues (if any)
**Blockers (must fix before proceeding):**
{list of critical gaps}
**Major Concerns (strongly recommend addressing):**
{list of significant issues}
**Minor Issues (nice to have):**
{list of minor improvements}
---
## Recommendations
{3-5 specific recommendations for improvement}
---
## Gate Decision
**Decision:** {PASS | CONDITIONAL PASS | FAIL}
**PASS Criteria:**
- โฅ90% FR coverage
- โฅ90% NFR coverage (fully or partially addressed)
- โฅ80% quality checks passed
- No critical blockers
**CONDITIONAL PASS Criteria:**
- โฅ80% FR coverage
- โฅ80% NFR coverage
- โฅ70% quality checks passed
- Blockers have mitigation plans
**FAIL Criteria:**
- < 80% FR or NFR coverage
- < 70% quality checks passed
- Critical blockers without mitigation
**Status:** {PASS/CONDITIONAL/FAIL}
**Rationale:** {why this decision}
**Conditions (if conditional pass):**
{list of items that must be addressed during implementation}
---
## Next Steps
{recommendations based on gate decision}
**If PASS:**
โ Architecture approved! Proceed to Phase 4 (Implementation)
Next: Sprint Planning
Run /sprint-planning to:
- Break epics into detailed stories
- Estimate story complexity
- Plan sprint iterations
- Begin implementation
**If CONDITIONAL PASS:**
โ Architecture approved with conditions
You may proceed to implementation, but must address:
{list of conditions}
Review these items during sprint planning and early sprints.
**If FAIL:**
โ Architecture needs significant work before implementation
Required actions:
{list of required improvements}
Re-run /solutioning-gate-check after addressing these issues.
---
## Appendix: Detailed Findings
{Full details of all checks, FR/NFR mappings, quality assessment}
---
**This report was generated using BMAD Method v6 - Phase 3 (Solutioning Gate)**Save report:
- Path:
{output_folder}/solutioning-gate-check-{project-name}-{date}.md - Use Write tool
Display Summary to User#
Show concise summary:
โ Solutioning Gate Check Complete!
Architecture Assessment:
- FR Coverage: {percentage}%
- NFR Coverage: {percentage}%
- Quality Score: {percentage}%
Gate Decision: {PASS | CONDITIONAL PASS | FAIL}
{Brief rationale}
Full report: {file_path}Update Status#
If PASS or CONDITIONAL PASS:
Per helpers.md#Update-Workflow-Status:
- Update
solutioning-gate-checkstatus to "PASS" or "CONDITIONAL" - Add gate check report path
- Save status file
If FAIL:
- Update status to "FAIL"
- Do NOT proceed to Phase 4
- User must address issues and re-run
Recommend Next Steps#
If PASS:
Excellent! Your architecture is solid and complete.
โ Ready for Phase 4: Implementation
Next: Run /sprint-planning to:
- Break epics into detailed user stories
- Estimate story points
- Plan sprint iterations
- Begin development with confidence
Your planning documentation is complete:
โ Product Brief
โ PRD
โ Architecture (validated)If CONDITIONAL PASS:
Your architecture is approved with minor conditions.
โ Proceed to implementation, but track these items:
{list of conditions}
Next: Run /sprint-planning
Address conditions during early sprints.If FAIL:
Architecture needs improvement before implementation can begin.
Required actions:
{top 3-5 issues}
After addressing these:
1. Update architecture document
2. Re-run /solutioning-gate-check
3. Then proceed to /sprint-planningHelper References#
- Load config:
helpers.md#Combined-Config-Load - Load status:
helpers.md#Load-Workflow-Status - Save document:
helpers.md#Save-Output-Document - Update status:
helpers.md#Update-Workflow-Status - Recommend next:
helpers.md#Determine-Next-Workflow
Validation Logic#
FR Coverage Calculation:
Covered FRs = FRs with component assignments
Coverage % = (Covered / Total) * 100NFR Coverage Calculation:
Fully Addressed = NFRs with complete architectural solutions
Partially Addressed = NFRs mentioned but solution incomplete
Coverage % = ((Fully + Partial) / Total) * 100Quality Score Calculation:
Quality % = (Passed Checks / Total Checks) * 100Pass Thresholds:
- PASS: FRโฅ90%, NFRโฅ90%, Qualityโฅ80%, No blockers
- CONDITIONAL: FRโฅ80%, NFRโฅ80%, Qualityโฅ70%, Mitigated blockers
- FAIL: Below conditional thresholds or critical blockers
Tips for Effective Gate Checks#
Be Objective:
- Apply consistent criteria
- Document findings clearly
- Don't let personal preferences override standards
Be Constructive:
- Identify issues specifically
- Suggest concrete improvements
- Acknowledge what's done well
Be Pragmatic:
- Perfect is the enemy of good
- CONDITIONAL PASS is often appropriate
- Some issues can be addressed during implementation
Be Thorough:
- Don't skip NFR coverage check
- Quality checklist matters
- Traceability ensures nothing is forgotten
Notes for LLMs#
- Approach: thorough, systematic, quality-focused
- Use TodoWrite to track 6 validation parts
- Apply objective pass/fail criteria (no subjective judgment)
- Generate comprehensive report even if architecture fails
- If FAIL, provide specific, actionable feedback
- CONDITIONAL PASS is valid when core architecture is solid but details need work
- Reference helpers.md for all common operations
- Update workflow status based on gate decision
- Hand off to Scrum Master only if PASS or CONDITIONAL PASS
Remember: The gate check protects implementation quality. Better to catch architectural gaps now than discover them mid-development when they're expensive to fix.