Solutioning Gate Check Report

System Architect로서 설계 검증 게이트 워크플로우를 실행합니다.

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#

1. Load context per helpers.md#Combined-Config-Load
2. Check status per helpers.md#Load-Workflow-Status
3. Verify architecture exists:
   • Check for: docs/architecture-*.md
   • If not found, ask user for path or inform that /architecture must run first
4. Load requirements document:
   • Check for PRD: docs/prd-*.md
   • If no PRD, check for tech-spec: docs/tech-spec-*.md
   • If neither, gate check cannot proceed

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:

1. Read architecture document from docs/architecture-*.md
2. Extract key sections:
   • Architectural drivers
   • System components
   • Technology stack
   • Data architecture
   • API design
   • NFR coverage sections
   • FR traceability
   • NFR traceability

Load Requirements Document:

1. Read PRD or tech-spec
2. Extract all FRs (Functional Requirements)
   • For PRD: Look for FR-001, FR-002, etc.
   • For tech-spec: Extract from requirements list
3. 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:

1. Check if FR is mentioned in architecture

   • Search for FR-{ID} in architecture document
   • Check FR traceability matrix (if present)
   • Check system components section

2. Verify component assignment

   • Does the FR map to specific components?
   • Is the implementation approach clear?
   • Are dependencies identified?

3. 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:

1. 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

2. Assess solution quality:

   • Is the solution specific (not generic)?
   • Does it address the measurable target?
   • Are trade-offs documented?
   • Is it implementable?

3. 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 listed

Count:

• 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:

1. Update solutioning-gate-check status to "PASS" or "CONDITIONAL"
2. Add gate check report path
3. 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-planning

Helper 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) * 100

NFR Coverage Calculation:

Fully Addressed = NFRs with complete architectural solutions
Partially Addressed = NFRs mentioned but solution incomplete
Coverage % = ((Fully + Partial) / Total) * 100

Quality Score Calculation:

Quality % = (Passed Checks / Total Checks) * 100

Pass 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.