Claude Project Tracker

VajraCMS went live at https://cms.vajravolt.com on 2026-09-07. The seed account created by VajraBackendGo/migrations/0033_cms_user.up.sql is admin@vajravolt.in / admin123 — the plaintext password is written in the migration, so anyone with repo access has working credentials to the production CMS. Saravanan chose to defer this on the day. Not blocking anything, but it should not sit for long. If there is no change-password UI yet, on the VM: UPDATE "CMSUser" SET password_hash = crypt('NEW', gen_salt('bf',10)) WHERE email='admin@vajravolt.in'; (pgcrypto bcrypt matches what the CMS auth controller compares against) Verify the old one stops working: curl -s -o /dev/null -w '%{http_code}\n' -X POST https://cms-api.vajravolt.com/api/v1/auth/login \ -H 'Content-Type: application/json' -d '{"email":"admin@vajravolt.in","password":"admin123"}' Expect 401.</body>

added 09-07 22:20 · by saravanan@scrumclaw.ai · claude-cowork

Physical rollout for Phase 1 pilot.\n\n- Confirm which station is the pilot (default VAJRA0001)\n- Send print design (#56) to signage vendor (#Q17 answer: existing vendor)\n- Receive 2 laminated A5 stickers (Gun 1 + Gun 2)\n- Physically apply to gun/panel\n- Coordinate with ops staff to be on-site during pilot testing window\n- Document station-owner communications (landlord awareness of pilot)\n\nBlocked on #56 (design finalized) + Razorpay QR issued (#52 + #61).</body>

added 08-02 11:53 · by saravanan@scrumclaw.ai · claude-cowork

Pre-launch gate for Phase 1. Test matrix:\n\n- App: BHIM, Google Pay, PhonePe, Paytm, WhatsApp Pay (5 apps)\n- Amount: ₹100, ₹500, ₹1000 (3 amounts)\n- Scenario: happy path, gun offline (simulate), gun already charging, RemoteStart rejected (simulate)\n\nTotal ~30 test runs at pilot station. Log any UPI-app-specific quirks (BHIM in particular has stricter parsing).\n\nWhoever pilots — use throwaway UPI-linked phone number so we can also validate the walk-in-user creation path (not an existing app user's phone).\n\nBlocked on Phase 1 implementation complete + QR sticker printed.</body>

added 08-02 11:53 · by saravanan@scrumclaw.ai · claude-cowork

DLT SMS registration is NOT done. 2–4 weeks external timeline. Track in parallel to Phase 1 build. Templates needed (send via Fast2SMS post-approval): - **wk_session_start** — "Vajra Volt: Charging started at {station}·Gun {gun}. ₹{reserved} reserved. Support: 88831-61155." - **wk_session_low_balance** — "Vajra Volt: Wallet running low (₹{remaining}). Scan QR to add money and keep charging." - **wk_session_end** — "Vajra Volt: Session complete. Used {kwh} kWh, cost ₹{cost}. Balance ₹{remaining}. Reply CLAIM to link this account." - **wk_payment_gun_busy** — "Vajra Volt: Payment ₹{amount} received but Gun {gun} is unavailable. Amount saved to your wallet. Support: 88831-61155." - **wk_refund_initiated** — "Vajra Volt: Refund of ₹{amount} initiated to your UPI. Reflects in 1–3 business days." All 4 languages (Q11 answer). English variants can be filed immediately; regional translations need vendor. Phase 1 launches WITHOUT SMS (see decision item). SMS goes live in Phase 1.5 once DLT approved.</body>

added 08-02 11:44 · by saravanan@scrumclaw.ai · claude-cowork

After BRD + design review are locked, produce the formal technical design doc covering: - Sequence diagram (customer → Razorpay → backend → OCPP → charger) - Data model changes (schema migration text) - API contracts (webhook handler, admin QR provisioning, guest-mode read endpoints) - Idempotency + concurrency model - Failure/retry semantics (webhook re-fires, gun offline, RemoteStart rejected, refund flow) - SMS content + provider integration details - Observability (metrics + logs to add) - Test plan (unit + integration + one live pilot station) - Rollout / rollback plan - Estimated effort per phase Commit finalized TDD to docs/TDD-walkin-qr.md in the backend repo. Only after this ships do we start implementation items.</body>

added 07-31 03:24 · by saravanan@scrumclaw.ai · claude-cowork

Migration 0027 only inserts positive ADJUSTMENT entries when `wallets.balance > 0 AND gap.amount >= 0.01`. Users whose legacy wallets.balance is 0 (never populated) but who accumulated CHARGE entries end up with negative ledger balances and no automatic reconciliation. Concrete case: saravanan.hp@gmail.com currently shows balance = -11152.52. Ledger has CHARGE entries but no matching TOPUP history was migrated in. Options: (a) Backfill missing legacy topups from external Razorpay reports before running the reconcile. (b) Add a companion migration that reconciles from a manually-curated CSV of legacy balances. (c) Add an admin credit tool + audit trail so support can fix these case-by-case. Track down the actual topup history for affected users (query Razorpay payments API filtered by our account) and decide the right long-term reconciliation approach.

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

ProcessTopupWebhook uses `if topup.Amount != amount` — direct float64 equality. A tiny rounding drift (e.g., 500.00 stored vs 499.99999998 derived from Razorpay's paise/100) will falsely reject the webhook as 'amount mismatch', leaving the user paying but not credited. Change to: if math.Abs(topup.Amount - amount) > 0.01 { ... } Or better: store amount as int64 paise everywhere and compare integers.

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

Useful for ops debugging (missing webhook, dispute lookup, reconciliation). Wraps Razorpay: GET https://api.razorpay.com/v1/payments/qr_codes/:qr_id/payments Backend endpoint: GET /admin/chargers/:charger_id/connectors/:connector_id/payments Returns array of payments captured against that gun's QR (all-time), each with vpa, contact, email, amount, timestamp, status. Enables ops to answer "who paid at this gun today" without querying our DB. Small addition to the admin endpoints in #65. Roughly 1 hour of Go + admin console UI work.</body>

added 08-02 12:10 · by saravanan@scrumclaw.ai · claude-cowork

Behind WALKIN_QR_SMS_ENABLED flag. 5 templates × 4 languages (see #53).\n\nBackend changes:\n- Templates stored in Go source (map[templateKey]map[lang]string) with DLT template IDs from #53\n- Language selection: prefer user.preferred_language if set; fallback to English\n- Dispatch service reuses existing Fast2SMS integration (already in codebase for OTP)\n- Fire-and-forget from webhook handler (async goroutine); log failures but don't block webhook response\n\nBlocked on DLT approval (#53).</body>

added 08-02 11:52 · by saravanan@scrumclaw.ai · claude-cowork

BRD Q8 spec locked: - A5 landscape (5.8" × 8.3"), vinyl, laminated for outdoor durability - Contents: Razorpay QR image (large, centered) + human-readable station+gun ID (e.g., "Vajra Volt · VAJRA0001 · Gun 2") + typical-cost hint ("Typical 30-min charge ≈ ₹150–300") - Support phone number visible - English only (Q20 answer) - Print files: SVG + PDF at 300 DPI - Vendor: existing signage vendor already identified (Q17) Sample layout: [ Vajra Volt logo ] [ QR CODE 4"x4" ] VAJRA0001 · Gun 2 Scan any UPI app to pay Typical charge ≈ ₹150–300 Support: 88831-61155 Deliverable: printable design ready for vendor.</body>

added 08-02 11:45 · by saravanan@scrumclaw.ai · claude-cowork

The webhook endpoint currently accepts any POST from anywhere. HMAC signature check is the only defense — cryptographically sound, but each invalid request still triggers signature compute + JSON parse + DB lookup, so it's a cheap DoS vector. Two things worth adding (nginx-level is easiest): 1. Restrict source IPs to Razorpay's published webhook IPs (they publish a list): allow only those in the nginx server block for /webhooks/*. 2. Rate-limit /webhooks/* at nginx (limit_req_zone). Even a modest 20 rps burst limit stops volumetric noise. Doesn't change functionality, just hardens.

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

Frontend passes `me.phone_number || storedEmail || ''` into Razorpay's prefill.contact. That field expects a phone number and is used to auto-detect UPI apps. Passing an email makes checkout look wrong and skips UPI autofill. Fix: only set prefill.contact when we have an actual phone number; put the email into prefill.email instead. prefill: { name: userName, contact: me?.phone_number?.trim() || undefined, email: storedEmail || undefined, }

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

Backend constant minTopupAmount is 1 but the error message and frontend both say the minimum is 100. Change minTopupAmount to 100 so the backend actually enforces what the message claims — otherwise a bespoke client can top up ₹1 (bypasses the intended floor). - const minTopupAmount = 1 + const minTopupAmount = 100

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

Razorpay deprecated the payment_capture parameter for the Orders API — capture behavior is now controlled at the account/merchant level. Not a functional bug today, but noise, and Razorpay may eventually reject unknown fields in future API versions. Drop the key from the payload in createRazorpayOrder.

added 07-31 02:51 · by saravanan@scrumclaw.ai · claude-cowork

DLT registration is 2–4 weeks. Rather than delay walk-in launch, Phase 1 will ship with LED-based confirmation only: - Customer knows charging started when the green LED on the gun activates (Q5 confirmed). - No SMS on session start, low balance, or session end for Phase 1 walk-ins. - App users still get all their existing notifications (unaffected). - After DLT approval + template registration, Phase 1.5 patches SMS in as a config flip — no schema change needed. Trade-off: walk-in session-end UX is worse. If a customer left their car and walked away, they won't know when charging finished. Mitigation: - Set the 2-hour hard cap (Q6) so guns don't stay locked forever. - Print the phone number on the QR sticker so customers can call to check status. - Auto-stop threshold of ₹50 remaining (Q7) reduces the "session died silently" scenario for underpayers. If DLT lands earlier than expected we'll enable SMS immediately.</body>

added 08-02 11:45 · by saravanan@scrumclaw.ai · claude-cowork

Chose to mount walkin's routes on the main API router instead of deploying cmd/walkin-service on port 8082. Reason: Saravanan did not want two processes to supervise on a 2GB VM, and the "microservice" boundary was not real — same DB, same .env, same host, same webhook secret. Commit c17a33a, merged to app as 3f826d7. cmd/walkin-service deleted in b3b0fa7 with docs updated. Trade-off accepted: forwardWalkinQRCredit in wallet_handler.go still makes an HTTP round-trip to this same process (WALKIN_SERVICE_URL and API_BASE_URL both = http://127.0.0.1:8080). Both are deliberately loopback, NOT https://api.vajraev.com — routing back out through nginx during webhook handling can tie up nginx workers waiting on a process that is waiting on nginx. Cleanup owed: collapse the self-call into a direct service-method call and drop both env vars. Deferred because it touches the payment path. Whoever wrote cmd/walkin-service has NOT been told it was removed — worth asking whether there was a reason for the split that the docs never recorded.

added 09-07 22:19 · by saravanan@scrumclaw.ai · claude-cowork

Where to find each customer field in the qr_code.credited webhook payload. Confirmed from Razorpay official docs (docs/webhooks/qr-codes). **Payload path for VPA:** `payload.payment.entity.vpa` **Trimmed sample:** ```json { "event": "qr_code.credited", "contains": ["payment", "qr_code"], "payload": { "payment": { "entity": { "id": "pay_HO2fEpc9JeOQU5", "amount": 200, "method": "upi", "vpa": "gauri.kumar@okhdfcbank", "email": "gauri.kumari@example.com", "contact": "+919000090000", "customer_id": "cust_HKsR5se84c5LTO", "notes": {}, "acquirer_data": { "rrn": "116812981837" } } }, "qr_code": { "entity": { "id": "qr_HO2e0813YlchUn", "notes": { "charger_id": "VAJRA0001", "connector_id": "2" } } } } } ``` **Two subtle gotchas:** 1. **Two separate `notes` blocks** — `payload.payment.entity.notes` is per-payment (usually empty for QR), and `payload.qr_code.entity.notes` is the QR's notes (where we set charger_id + connector_id at QR creation). Read the second one for gun identification. 2. **VPA presence:** always present for QR-triggered payments (method is always upi). Fallback: null. **Go struct extraction:** see TDD §4.3 `qrCreditedPayload`. **Fallback retrieval (webhook lost):** - `GET /v1/payments/pay_XXX` — fetch single payment; includes vpa - `GET /v1/payments/qr_codes/qr_XXX/payments` — list all payments for a QR (great for admin ops "show all payments to this gun") Sources: - https://razorpay.com/docs/webhooks/qr-codes/ - https://razorpay.com/docs/webhooks/payloads/payments/</body>

added 08-02 12:10 · by saravanan@scrumclaw.ai · claude-cowork