name: feature-validator description: Validate all features against 6 core business requirement documents (BRD, FRD, MRD, PRD, SRS, BUSINESS_MODEL). Use when implementing any new feature, user story, or capability. Enforces requirements traceability and alerts on undocumented features.
Feature Alignment Validator
Purpose
Ensure all features align with documented business requirements
Reference Documents (MUST CHECK ALL)
Core Business Docs (6 Required):
- BRD -
docs/business/brd.md- Business Requirements - FRD -
docs/business/FRD.md- Functional Requirements - MRD -
docs/business/mrd.md- Market Requirements - PRD -
docs/business/PRD.md- Product Requirements - SRS -
docs/business/srs.md- Software Specifications - BUSINESS_MODEL -
docs/business/BUSINESS_MODEL.md- Revenue model
Supporting Documentation:
docs/business/FREE_FOR_BUYERS.md- Free buyer philosophydocs/technical/SELLER_LISTING_FLOW_ANALYSIS.md- Feature flowsdocs/DOCUMENTATION_INDEX.md- Full doc inventorydocs/PROJECT_OVERVIEW.md- High-level summary
AI Workflow for New Features
🔴 STEP 0: VALIDATE USER REQUEST (MANDATORY)
- Read user's exact words - What feature do they want?
- Understand their intent - Why do they want this feature?
- Check for business conflicts - Does this match FREE_FOR_BUYERS.md and BUSINESS_MODEL.md?
- Identify pricing implications - Will this be free or paid?
- Ask clarifying questions - If uncertain, ask BEFORE searching docs
-
📝 Feature Request Received
-
🔍 Search ALL 6 docs for matching requirement
-
Decision Tree:
Feature in docs? ├─ ✅ YES → Proceed with implementation └─ ❌ NO → Follow "Undocumented Feature Protocol"
Undocumented Feature Protocol
When feature is NOT in any of the 6 docs:
- 🛑 PAUSE implementation
- 📋 INFORM user:
- "This feature is not documented in BRD/FRD/MRD/PRD/SRS/BUSINESS_MODEL"
- "Searched: [list what you searched for]"
- "Results: Not found"
- 💡 SUGGEST next steps:
- Option A: Add feature to appropriate doc first (recommend which doc)
- Option B: Skip this feature (explain why it might not fit)
- Option C: Proceed anyway (explain risks)
- ⏸️ WAIT for user decision
- ✅ Proceed only after user confirms
Validation Checklist
- Feature exists in at least ONE of the 6 docs?
- Implementation matches documented requirements?
- No conflicting requirements across docs?
- User stories/use cases covered?
- Business logic aligns with BUSINESS_MODEL?
- Technical specs match SRS?
- Functional behavior matches FRD?
Core Business Logic (Always Validate Against)
From BUSINESS_MODEL.md:
- ✅ FREE for Buyers - All customer features must be free
- ✅ Paid for Sellers - Revenue comes from promoters/sellers only
- ✅ Offline-First - Must work without internet
- ✅ Dual-Mode - Support both SQLite (offline) and Supabase (online)
- ✅ Lead Generation - Maximize seller leads, not buyer friction
Red Flags (Alert User Immediately)
- 🚫 Feature charges buyers money
- 🚫 Feature breaks offline mode
- 🚫 Feature conflicts with "free for buyers" model
- 🚫 Feature requires always-online connection
- 🚫 Feature not in any of the 6 reference docs