Claude Project Tracker

Accepts GitHub webhook events (configure on the repo with a shared secret). When a pull_request event with action=closed and merged=true comes in, parse the PR body for `Closes #<item_id>` or `Fixes #<item_id>` patterns and call the existing complete_item path for each. Add: HMAC-SHA256 signature verification using `GITHUB_WEBHOOK_SECRET` env var. Route lives in main.go alongside the other public POST endpoints. Probably one new file github_webhook.go.

claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai

BRD v3.0 REQ-13.11 is Pending Deploy. Runbook with ready-to-paste gcloud commands exists; needs the Cloud Scheduler job created and 7 days of error-free runs to close the acceptance.

Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai

RoadIntelix · roadintelix · by Prajith

RoadIntelix · roadintelix · by Prajith

Was deferred; now started. Same Expo codebase as iOS. DONE in code/config: eas.json Android build profiles (APK dev/preview, AAB production) + submit track:internal; app.json android block already complete (package com.hopewellpartners.adaptivesat, adaptive icon, App Links intent filters) — no change needed (appVersionSource:remote manages versionCode). Apple Sign-In correctly iOS-gated; Google sign-in works on Android. PENDING (owner): Google Play Developer account ($25); `eas build --platform android --profile preview` then production AAB; Android OAuth client (SHA-1 → add to GOOGLE_OAUTH_CLIENT_IDS); App Links assetlinks.json (SHA-256) on adaptivesat.ai; Play Console listing + IARC content rating (teen audience) + Data Safety + privacy URL; service account + eas submit. Follow-ons: Google Play Billing IAP (source='google' already supported), FCM push (deferred). Full steps: docs/ANDROID_PLAY_STORE_RUNBOOK.md.

Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai

Apple rejected build 6 (reviewed on iPad Air M3, iPadOS 26.5.2). Four items. CODE FIXES DONE (mobile, typecheck clean, not yet committed/built): (1) 3.1.2(c) MobilePaywall now has tappable Terms of Use (EULA) + Privacy Policy links and shows title/length/price; (2) 2.1(b) SettingsScreen has a visible 'Upgrade to Premium' row opening the paywall so reviewers can locate the IAP; (3) 2.1(a) ExamStartScreen adds a 30s timeout + clear retry error so 'Start Exam' can't silently hang. ASC METADATA DONE: EULA link added to App Description (saved), Privacy Policy URL confirmed (adaptivesat.ai/privacy). PENDING (owner): check/top-up OpenAI credits (prime suspect for the iPad 'Start Exam did nothing' hang) and retest on iPad; commit+push mobile changes via ship.sh; new EAS production build (build 7); fresh screen recording (Start Exam works + Settings→Upgrade to Premium paywall + sandbox purchase); paste reply (asc_submission/apple_reply_draft.md) in Resolution Center; resubmit app+subscription+group together. Refs: MobilePaywall.tsx, SettingsScreen.tsx, ExamStartScreen.tsx.

Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai

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.

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

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.

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

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>

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

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>

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

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>

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

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>

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

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>

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

Owner noticed the full exam has no back/forth between answered questions. Root cause: exam engine is forward-only by design. Backend get_next_exam_question serves the next UNSEEN question and immediately consumes it (status→ANSWERED); /answer records a single Attempt; no endpoint to re-fetch a prior question, change an answer, or list the module; ExamQuestionStatusEnum has only UNSEEN/ANSWERED/SKIPPED (no FLAGGED/REVIEW). Same limitation on WEB (frontend ExamSession.tsx) since it's the same backend — whole-product gap, not mobile-only. Real Digital SAT (Bluebook) allows free within-module navigation, changing answers, and a question navigator with mark-for-review until the module timer ends. SCOPE (multi-day, cross-cutting): backend — serve whole module, mutable per-question answers until module submit/timer, add flag/review state, add submit-module step (stop consume-on-serve); web+mobile — question navigator UI (grid + flags), Back/Next, module answer state, submit at module end. NOT an App Store blocker — sequence AFTER build 7 clears review. Refs: backend/app/services/exam_service.py (get_next_exam_question, submit_exam_answer), backend/app/models/exam_module_question.py, mobile/src/screens/ExamSessionScreen.tsx, frontend/src/app/pages/ExamSession.tsx.

Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai