BMad Validation Report — PRD «4 комнаты»

prd.md · reviewers: review-rubric-bmad.md, review-freelancer-handoff-bmad.md
Poor / broken for handoff

Gate verdict: broken / not ready for external freelance handoff.

The PRD has useful raw material, but it is not a standalone build contract for a freelancer who does not know the business. It assumes context, depends on external files, mixes MVP with future architecture, and leaves launch-critical payment/subscription decisions unresolved.

Dimension Verdicts

Decision-readiness
broken
Substance over theater
thin
Strategic coherence
broken
Done-ness clarity
thin
Scope honesty
thin
Downstream usability
broken
Shape fit
broken

Critical Findings

criticalPayment/subscription decision is delegated out of the PRD. Payment controls access, renewal, founder status, auto-kick, balance, refunds, and metrics, so it cannot remain “freelancer proposes” in a ready handoff.

criticalPRD is not standalone. Required meaning is pushed into output/..., input/..., review, legal, marketing, and payment-comparison files.

criticalMissing product/problem brief. A new reader does not get a plain explanation of «4 комнаты», the user pain, hotel pain, business model, and bot ownership.

criticalMissing end-to-end value journeys. The PRD covers bot entry and channel access, but not the full value path from deal discovery to booking/use of discount.

criticalCore subscriber flow lacks full state/event matrix. Visitor, lead, phone, payment, story-trial, subscriber, grace, revoked, blocked, refunded, and reactivated states need explicit transitions.

criticalNo glossary or ecosystem map. Domain terms and actors are load-bearing but undefined for an outsider.

criticalShape is a workshop log, not a freelancer spec. The file preserves BMad process history instead of leading with a buildable handoff.

Required Rewrite

  1. Replace opening process sections with standalone product primer and handoff contract.
  2. Add “How the business works”: money, hotel offers, subscriber value, «Зелёная Тропа», and off-bot operations.
  3. Add actor/responsibility table and glossary.
  4. Extract launch-critical facts from external references into the PRD.
  5. Resolve or bound the payment decision.
  6. Split scope into MVP-build-now, feature-flagged, data-model-only, and phase-2.
  7. Rewrite FRs into global IDs with acceptance criteria and testable consequences.
  8. Add state machines, dependency matrix, admin/backoffice requirements, and blocker-classified open questions.

BMad-Aligned Handoff Structure

# PRD — Telegram-бот «4 комнаты»
## 0. Document Purpose and Handoff Contract
## 1. Product Overview
## 2. Actors and Responsibilities
## 3. Glossary
## 4. Scope and Release Plan
## 5. Key User Journeys
## 6. Feature Requirements
## 7. Data Model and Events
## 8. Integrations and External Dependencies
## 9. Non-Functional Requirements
## 10. Success Metrics and Reporting
## 11. Freelancer Deliverables and Definition of Done
## 12. Open Questions and Assumptions Index
## Appendix A. Approved User-Facing Copy Bank
## Appendix B. Source/Audit Notes, Not Required For Build
## Appendix C. Future Phase Notes