What's pending across every project
24 open · sorted by priority then due-date
todo
high
Verify v3.1 conversation_excerpt rendering
OVERDUE 54d
MORNING.md
claude-project-tracker
· claude-project-tracker
· by saravanan@scrumclaw.ai
from the conversationsaravanan: I want to see the excerpt actually show up in the dashboard.
claude: Captured a high-priority todo to test it.
59d ago
06-10 08:07
06-10 08:07
todo
high
Add POST /webhook/github endpoint to the Go server
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.
api-go/main.goapi-go/handlers_api.go
claude-project-tracker
· claude-project-tracker
· by saravanan@scrumclaw.ai
from the conversationclaude: Webhook handler (medium): Add /webhook/github to the tracker server; parse merged-PR bodies for Closes #<item_id> and call complete_item. Single HTTP handler + webhook secret.
saravanan: [agreed, this is the keystone feature]
58d ago
06-11 11:26
06-11 11:26
todo
high
Deploy nightly question-quality audit cron and confirm 7 consecutive clean runs (REQ-13.11)
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.
docs/QUESTION_QUALITY_CRON_SETUP.mddocs/BRD_V3_TRACKER.md
Adaptive SAT
· adaptive-sat
· by saravanan@scrumclaw.ai
💬 1 comment
56d ago
06-13 11:14
06-13 11:14
todo
high
Set GCP project ID in terraform/terraform.tfvars and run terraform apply
terraform/terraform.tfvars.exampleterraform/main.tf
RoadIntelix
· roadintelix
· by Prajith
from the conversationclaude: Terraform IaC written for GCS bucket, Artifact Registry, Cloud Run Job (L4 GPU), and IAM.\nprajith: identify and add open items into tracker\nclaude: Next step — copy terraform.tfvars.example to terraform.tfvars, fill in project_id, then run terraform apply.
51d ago
06-18 04:17
06-18 04:17
todo
high
Build and push Docker image to Artifact Registry
Dockerfile
RoadIntelix
· roadintelix
· by Prajith
from the conversationclaude: Dockerfile created with CUDA 12.1 + cuDNN 8, PyTorch cu121, ultralytics, and bundled YOLO weights.\nclaude: After terraform apply, run: docker build -t $IMAGE . && docker push $IMAGE
51d ago
06-18 04:20
06-18 04:20
todo
high
Ship Android to Google Play — build config DONE; account/store/parity pending
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.
docs/ANDROID_PLAY_STORE_RUNBOOK.mdmobile/eas.jsonmobile/app.json
Adaptive SAT
· adaptive-sat
· by saravanan@scrumclaw.ai
47d ago
06-22 03:03
06-22 03:03
todo
high
iOS 2nd rejection (2026-07-24) remediation → build 7 resubmit
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.
mobile/src/components/MobilePaywall.tsxmobile/src/screens/SettingsScreen.tsxmobile/src/screens/ExamStartScreen.tsxasc_submission/apple_reply_draft.md
Adaptive SAT
· adaptive-sat
· by saravanan@scrumclaw.ai
from the conversationsaravanan: [pasted Apple's 2nd rejection: 3.1.2c EULA, 2.1a Start Exam no action on iPad, 2.1b can't find IAP]
claude: Made the 3 code fixes + ASC EULA link; remaining = OpenAI check + build 7 + recording + resubmit with reply.
💬 2 comments
14d ago
07-25 04:08
07-25 04:08
todo
high
Fix float equality in webhook amount check (can silently reject real topups)
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.
internal/repositories/wallet_repo.go:100
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
8d ago
07-31 02:51
07-31 02:51
todo
high
Extend ledger reconciliation migration to handle negative balances
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.
migrations/0027_wallet_ledger_balance_reconcile.up.sqlinternal/repositories/wallet_repo.go:30-48
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
8d ago
07-31 02:51
07-31 02:51
todo
high
BRD v1: Walk-in UPI QR Pay for Charger Sessions
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>
outputs/vajra-walkin-qr-brd-v0.md
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
8d ago
07-31 03:24
07-31 03:24
todo
high
Design review: reconcile current technical design against locked BRD
Once BRD v1 is locked, walk through the WIP technical design (see WIP note) and confirm / update each element against BRD requirements. Identified areas that likely need change:
- Amount UX (fixed / preset / open)
- Plug-in sequence vs payment sequence
- Session termination criteria (money-out / SoC-100 / unplug / time-cap)
- Refund vs wallet-retention default policy
- Failure paths (gun offline, RemoteStart rejected, payment succeeded)
- SMS content templates (English / vernacular)
- Guest-mode web page scope (Phase 1 vs later)
- QR provisioning ops (batch API + printable exports)
- Walk-in → app-user claim/merge flow
Output: a delta list feeding into the TDD.</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
8d ago
07-31 03:24
07-31 03:24
todo
high
TDD: Walk-in UPI QR Pay — final technical design document
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
8d ago
07-31 03:24
07-31 03:24
todo
high
Register DLT entity + SMS templates for walk-in flow (English/Hindi/Tamil/Telugu/Kannada)
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
6d ago
08-02 11:44
08-02 11:44
decision
high
Phase 1 launches WITHOUT SMS — LED-only confirmation, SMS in Phase 1.5
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
6d ago
08-02 11:45
08-02 11:45
todo
high
Build minimal admin web page for walk-in ops (refunds, QR reprint, user lookup)
Chosen in BRD Q18 as the ops interface. Minimum scope for Phase 1:
- Login (reuse existing admin auth or add role gate)
- User lookup by phone / email / VPA / payment_id — show wallet balance, session history, walk-in vs app-registered
- Payment lookup by Razorpay payment_id / order_id — show status, ability to refund (full/partial)
- QR management: list all gun QRs, image download (for reprint), regenerate (close+create) button
- Simple audit log: which admin took which action, when
Can be a subroute of the existing Expo web app (feature-flagged /admin route) or a separate small React/Next admin app. Existing app already has JWT auth we can extend with a role claim.
1–2 weeks frontend work. Backend needs matching admin endpoints (~1 week).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:45
08-02 11:45
todo
high
Migration 0028: walk-in user schema (nullable phone + user_upi_handles)
Per BRD v1 §7.3 + Appendix B.\n\n- ALTER users ALTER COLUMN phone_number DROP NOT NULL\n- Recreate phone UNIQUE as partial index (WHERE phone_number IS NOT NULL)\n- CREATE TABLE user_upi_handles (per WIP schema in #51)\n- Register 'upi_walkin' as an accepted auth_provider value (no enum in Postgres — code-side check only)\n\nDoes NOT touch existing wallets/ledger/sessions/reservations tables.\n\nBlocked on TDD lock (#50).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
Migration 0029: charger_qr_codes table
Per BRD v1 §7.1 FR3.\n\nCREATE TABLE charger_qr_codes (\n id UUID PK,\n charger_id VARCHAR(50) NOT NULL,\n connector_id INT NOT NULL,\n razorpay_qr_id VARCHAR(100) UNIQUE NOT NULL,\n razorpay_qr_short_url TEXT,\n razorpay_qr_image_url TEXT,\n status VARCHAR(20) NOT NULL DEFAULT 'active',\n created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),\n UNIQUE (charger_id, connector_id)\n);\n\nBlocked on TDD lock (#50).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
UserRepository walk-in methods + resolveOrCreateUser logic
Per BRD v1 §7.3 FR10–FR15. New Go methods on UserRepository:\n\n- GetByVPA(vpa string) (*User, error) — JOIN with user_upi_handles\n- GetByEmail(email string) (*User, error) — if not already present\n- InsertUPIHandle(userID, vpa, source string, primary bool) error\n- TouchUPIHandle(userID, vpa string) error — bump last_seen_at + payment_count++\n- New service function resolveOrCreateUser(contact, email, vpa string) — implements the phone > email > VPA priority + backfill-on-match + walk-in creation logic\n\nBlocked on migration 0028 (#57) landing.</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
Razorpay QR admin provisioning endpoint (create + regen QR per gun)
Per BRD v1 §7.1 FR1–FR4.\n\nNew backend endpoints under /internal/admin/:\n\n- POST /admin/chargers/:id/connectors/:cid/qr — create if not exists; returns razorpay_qr_id + image_url\n- POST /admin/chargers/:id/connectors/:cid/qr/regen — close existing QR (via Razorpay POST /v1/payments/qr_codes/:id/close) and create new one; updates charger_qr_codes row\n- GET /admin/chargers/:id/connectors/:cid/qr — return current QR + image URL for reprint\n- GET /admin/chargers/qr — list all QRs across all stations, for admin console listing\n\nWraps Razorpay QR Codes API. All calls go server-to-server with Razorpay API key basic auth (reuse pattern in wallet_handler.go createRazorpayOrder).\n\nBlocked on Razorpay QR API enablement (#52) and TDD (#50).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
qr_code.credited webhook handler in existing PaymentWebhook
Per BRD v1 §7.2 FR6–FR9.\n\nExtend existing internal/handlers/wallet_handler.go PaymentWebhook to switch on hook.Event:\n\n switch hook.Event {\n case "payment.captured": // existing app topup path\n case "qr_code.credited": // NEW walk-in path\n h.handleQRCredit(payload)\n }\n\nhandleQRCredit implements:\n1. Lookup gun via notes.charger_id + notes.connector_id (cross-check charger_qr_codes row exists)\n2. Call resolveOrCreateUser(contact, email, vpa)\n3. Insert TOPUP ledger entry (idempotency key: qrpay:<payment_id>)\n4. Check OCPP status of connector — if Available, trigger RemoteStart via existing internal path with 3x5s retry (see #62)\n5. If not Available, credit persists in wallet only\n6. If WALKIN_QR_SMS_ENABLED flag on → dispatch appropriate SMS template (Phase 1.5)\n7. Return 200 to Razorpay\n\nBlocked on TDD (#50), migrations 0028–0029.</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
OCPP RemoteStart internal trigger — verify reusable for walk-in flow
The app-user "Start Charging" button calls some Go function that ultimately sends OCPP RemoteStartTransaction to the charger. Same code path needs to be triggerable from the webhook handler (server-initiated, no user JWT context).\n\nTasks:\n1. Locate the current Go function/method for starting a session (likely inside internal/handlers/charging_handler.go or an internal service).\n2. Confirm it can be called with (user_id, charger_id, connector_id, reserved_amount) purely from server code — no gin.Context assumption.\n3. If it currently requires a gin.Context, refactor to extract a pure service function chargingService.StartSession(...).\n4. Wire the walk-in webhook to call this shared entry point.\n5. Add 3x5s retry wrapper per BRD FR19.\n\nBlocked on TDD (#50).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
Admin ops API endpoints (user/payment/refund/QR mgmt)
Backend API for the admin web page (#55). Under /admin/* (or /internal/admin/*) behind role-gated middleware.\n\n- GET /admin/users?search=... — search by phone/email/VPA/user_id\n- GET /admin/users/:id — user detail including wallet balance, ledger, sessions, UPI handles\n- GET /admin/payments/:razorpay_payment_id — payment lookup\n- POST /admin/payments/:razorpay_payment_id/refund — full/partial refund via Razorpay Refunds API + REVERSAL ledger entry\n- QR management endpoints (see #61)\n- GET /admin/audit — recent admin actions log\n\nRole gate: reuse existing JWT + add role claim, or a dedicated admin_users table. TDD to decide.\n\nBlocked on TDD (#50).</body>
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
6d ago
08-02 11:52
08-02 11:52
todo
high
Pilot: end-to-end test on real UPI apps (BHIM/GPay/PhonePe/Paytm) at VAJRA0001
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
6d ago
08-02 11:53
08-02 11:53
todo
high
Ops: pilot station rollout at VAJRA0001 (2 QR stickers)
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
6d ago
08-02 11:53
08-02 11:53