Claude Project Tracker

Draft the business requirements document covering: - Executive summary + business rationale - Success metrics/KPIs - Scope (in / out / later) - Personas (New walk-in, Returning walk-in, App user, Ops) - User journeys (happy path + 3-5 unhappy paths) - Functional requirements (FR1–FRn) — business-level, not code - Non-functional (latency, SMS SLA, PII, KYC/PPI) - Business rules (min/max payment, wallet retention policy, refund SLA, expiry, etc.) - Dependencies (Razorpay QR product, Fast2SMS, OCPP, physical print vendor, legal) - Risks & mitigations - Rollout phases - Open questions requiring product/business owner decision v0 draft lives in this session's outputs/vajra-walkin-qr-brd-v0.md. Once user answers the OPEN QUESTIONS in v0, we cut v1 and commit to docs/BRD-walkin-qr.md in the backend repo.</body>

Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai

The initial ad-hoc technical sketch for walk-in QR-pay (schema + matching logic) surfaced multiple design gaps around amount UX, session termination policy, plug-in sequence, failure handling, and refund/wallet retention. Rather than iterate on code, we're switching to: 1. Write BRD → capture business requirements + explicit open questions 2. Review current technical design against BRD → find gaps 3. Iterate design; lock via TDD (technical design doc) 4. Only then implement (migration, repo logic, handlers, etc.) This prevents rework and ensures every stakeholder is aligned before code is written. All future items in this feature reference the eventual TDD.</body></priority>

Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai