Claude Project Tracker

refreshed 2026-08-08 19:52:22Z

What's pending across every project

51 open · sorted by priority then due-date
priority all urgent high low
blocker urgent
Revoke exposed GitHub PAT shared in chat session
RoadIntelix · roadintelix · by Prajith
from the conversationprajith: [shared GitHub PAT in chat to clone private repo]\nclaude: Please revoke this token immediately — GitHub Settings → Developer settings → Fine-grained tokens → delete it.
51d ago
06-18 04:24
todo urgent
Rotate Razorpay webhook secret — 'hopewell' is guessable
The RAZORPAY_SECRET_WEBHOOK value in /opt/ocpp/.env on the production VM is literally 'hopewell' — a common English word, effectively no protection. HMAC verification against a guessable secret means anyone who learns the plaintext can forge webhook calls and credit any wallet. Fix: 1. Razorpay Dashboard → Settings → Webhooks → regenerate a long random secret (32+ char base64). 2. Update /opt/ocpp/.env on the VM (SMTP_PASSWORD-style edit). 3. sudo systemctl restart ocpp.service. 4. Send a test webhook from Razorpay dashboard and confirm it verifies. This is the single most impactful hardening we can do.
/opt/ocpp/.envinternal/handlers/wallet_handler.go:239-254↗ https://dashboard.razorpay.com/app/webhooks
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
from the conversationclaude: RAZORPAY_SECRET_WEBHOOK=hopewell in .env is weak - anyone who guesses the plaintext can forge webhooks (i.e., forge topups). Regenerate a long random secret in the Razorpay dashboard and update .env, then restart the service. This is the single most impactful hardening you can do. saravanan: put them in my project tracker - scrumclaw.ai
8d ago
07-31 02:51
blocker urgent
Enable Razorpay QR Codes product on merchant account
The Razorpay QR Codes API (`POST /v1/payments/qr_codes`) requires activation on your merchant account. Ping Razorpay support: "Please enable Payment Handle / QR Codes API on account acc_XXXX". Typically enabled within 24–48 hours, no additional cost for UPI QR. Confirmed during BRD Q15 as "not enabled". Blocks Phase 1 pilot — we can build the backend, but cannot create even the first test QR without this.</body>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 11:44
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
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 #&lt;item_id&gt;` or `Fixes #&lt;item_id&gt;` 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 #&lt;item_id&gt; and call complete_item. Single HTTP handler + webhook secret. saravanan: [agreed, this is the keystone feature]
58d ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
decision
Extend the tracker plugin itself for GitHub integration (not a separate MCP)
Three approaches were considered: (a) install the generic github/github-mcp-server, (b) extend this plugin, (c) build a custom MCP between the two. Chose (b) because the plugin already runs git commit/push at session_end — adding "comment on linked PR when a todo completes" and "auto-close items when PR with `Closes #<item_id>` merges" sits naturally there. Phased rollout: install GitHub MCP for ad-hoc access first, then plugin frontend badges, then webhook handler, then optional issue mirror.
claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai
from the conversationsaravanan: can we build [a GitHub integration] so it is useful for project tracker? saravanan: [chose] Extend the tracker plugin itself to call GitHub APIs. The plugin already runs on commit/push during tracker_session_end. Adding hooks like "stamp the commit SHA on the latest update" (already exists), "comment on linked PR when a todo completes", "auto-close items when a PR with Closes #<item_id> merges" lives more naturally there than in a separate MCP.
58d ago
06-11 11:26
todo
Render refs[] as clickable PR/issue badges on the dashboard
Pure frontend change in the Go templates. When a ref looks like a GitHub URL (github.com/.../pull/N or .../issues/N), render it as a styled badge with the PR/issue number. Other refs render as code chips like today. Templates touched: detail.html, pending.html, possibly dashboard.html log lines.
api-go/templates/detail.htmlapi-go/templates/pending.html
claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai
from the conversationclaude: Tracker plugin tweak (small): Make the existing refs field render GitHub URLs as PR/issue badges on the dashboard. Pure frontend. saravanan: [agreed, included in plan]
58d ago
06-11 11:26
todo
Plugin hook: comment on linked PR when a todo is completed
In tracker_complete_item, if the item's refs[] contains a GitHub PR URL and a GITHUB_TOKEN is configured, POST a comment to the PR like "✅ tracker item #&lt;id&gt; ('&lt;title&gt;') marked done by &lt;user&gt;". Best-effort — log on failure, don't block the tracker update. Requires the plugin to know the GitHub token (new optional env var or read from gh CLI config).
plugin/mcp/server.py
claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai
from the conversationclaude: [feature in scope] comment on linked PR when a todo completes saravanan: [agreed, part of plugin-side hooks]
58d ago
06-11 11:26
todo
Run deferred QA walkthroughs once shipped: Rush (15.8), Vocab mastery (18.7), Planner scratch→dashboard (19.6), dashboard <500ms p50 (14.8), report→queue→DELETE (13.10)
These BRD v3.0 acceptance items are code-complete but marked Ready for QA / Pending QA — manual walkthroughs and the prod p50 latency measurement were deferred until ship.
docs/BRD_V3_TRACKER.md
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
56d ago
06-13 11:14
todo
Upload test video and Location.csv to GCS inputs/ folder
RoadIntelix · roadintelix · by Prajith
from the conversationclaude: Job reads VIDEO_BLOB and GPS_BLOB from GCS bucket.\nclaude: gsutil cp your_video.mp4 gs://$BUCKET/inputs/ && gsutil cp Location.csv gs://$BUCKET/inputs/
51d ago
06-18 04:21
todo
Technical debt: test enforcement + quality gates + silent-failure/dead-code cleanup
Consolidated tech-debt item (full register: docs/TECH_DEBT.md). Verified against the repo after a whitebox gate report (run 61e7d93e, commit 11639ae) whose own scores were unreliable. Sev1 (test enforcement): backend 51 pytest files but conditional-skip → no-op in CI (seed DB + key/mock); frontend+mobile have 0 unit tests; tsc --noEmit + lint not required PR checks (TS6133 noise). Sev2 (silent failures): bare except:pass in exam_service.py:175/194 + note_service.py:278; insights_service.py:479 most_improved/needs_attention hard-coded None (parent digest degrades). Sev3 (gates): no pre-commit secret scanning (gitleaks), no npm audit/pip-audit in CI. Sev4 (cleanup): delete mobile/App.tsx.full duplicate; remove dead comingSoon/*_ENABLED branches. Sequence Sev1→4; each ships as a small PR. No feature impact.
docs/TECH_DEBT.mdbackend/app/services/exam_service.py:175backend/app/services/insights_service.py:479mobile/App.tsx.full
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
47d ago
06-22 02:17
todo
Mobile exam: add passage highlighting (parity with web PassageHighlighter, REQ-9.2)
Web has frontend/src/app/components/PassageHighlighter.tsx (Bluebook-style select-to-highlight + per-highlight notes, char-offset ranges). Mobile ExamSessionScreen renders question_text as a plain <Text> (line ~503) with no highlight/annotate. Gap noticed by owner while testing the full exam on mobile. Non-trivial in RN: no DOM selection; needs a custom passage renderer (tappable/selectable spans → highlight ranges), persisted per-question highlights, optional notes, erase/clear. NOT an App Store blocker — sequence AFTER the build-7 resubmission clears review. Ref: mobile/src/screens/ExamSessionScreen.tsx, frontend/src/app/components/PassageHighlighter.tsx.
mobile/src/screens/ExamSessionScreen.tsxfrontend/src/app/components/PassageHighlighter.tsx
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
💬 1 comment
11d ago
07-27 21:18
todo
Fix topup amount range mismatch (min=1 vs error message '100')
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
internal/handlers/wallet_handler.go:29-30internal/handlers/wallet_handler.go:87
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
8d ago
07-31 02:51
todo
Fix Razorpay prefill.contact — uses email as fallback, breaks UPI autofill
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, }
app/(tabs)/profile/add-money.tsx:178-192
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
8d ago
07-31 02:51
todo
Rate-limit / IP-allowlist /webhooks/payment endpoint
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.
internal/routes/routes.go:161-163internal/handlers/wallet_handler.go:239-303/etc/nginx/sites-available/vajraev
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
8d ago
07-31 02:51
decision
Adopt BRD → design-review → TDD workflow for walk-in QR-pay feature
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
8d ago
07-31 03:24
todo
Design print-ready A5 QR sticker with station+gun ID + typical-cost hint
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>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 11:45
todo
Migration 0030: session_code column on charging_sessions
Per BRD v1 §7.6 FR26 — for phone-less walk-in recovery.\n\nALTER TABLE charging_sessions ADD COLUMN session_code VARCHAR(10);\nCREATE UNIQUE INDEX charging_sessions_session_code_idx ON charging_sessions (session_code) WHERE session_code IS NOT NULL;\n\nOnly populated for walk-in sessions where contact is missing. Short human-readable code (e.g. V-4F2A9) customer can quote to support.\n\nBlocked on TDD lock (#50).</body>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 11:52
todo
Feature flag config: WALKIN_QR_ENABLED + WALKIN_QR_SMS_ENABLED
Both flags default false, set via /opt/ocpp/.env:\n\n- WALKIN_QR_ENABLED — master gate. When false, /webhooks/payment ignores qr_code.credited events (returns 200 "ignored"). Enable per station rollout.\n- WALKIN_QR_SMS_ENABLED — separate switch for Phase 1.5. When true, dispatch SMS via Fast2SMS on start/end/etc.\n\nAdd to internal/config/config.go loader. Wire into wallet_handler.go and any SMS-sending code.\n\nAllows Phase 1 → Phase 1.5 rollout without redeploy.</body>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 11:52
todo
SMS templates + Fast2SMS integration for walk-in (Phase 1.5)
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>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 11:52
todo
Admin console: "list payments for QR" endpoint (Razorpay debug aid)
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>
scrumclaw#61scrumclaw#65
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 12:10
todo low
Background poll: mirror GitHub issues as tracker items
Deferred until items #4 and #5 (the close-on-merge webhook and the PR badges) prove valuable. When ready: a background goroutine in the Go server polls `GET /repos/:owner/:repo/issues` every N minutes and upserts each issue as a tracker item (linking via parent_item_id or a new `external_id` column). Two-way write-back on completion. Per-project repo config in claude_projects (probably a new repo_url is already there).
api-go/main.go
claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai
from the conversationclaude: Issue mirror (larger): Background job that polls GET /repos/:owner/:repo/issues and upserts. Defer until 1–3 prove valuable. saravanan: [agreed, defer]
58d ago
06-11 11:26
note low
5 items captured in other session landed under project_id 'outputs' — orphans to clean up
The claude-collab session captured 1 decision + 4 todos on the GitHub integration, but they were stamped with project_id='outputs' because the plugin's cwd in that session was Cowork's outputs folder, not the project folder. The v3.4 ephemeral-folder guard prevents this for tracker_init_project but doesn't retroactively fix existing rows. Cleanup options: (a) DELETE FROM claude_projects WHERE project_id='outputs' CASCADE in Studio, accepting the loss of those originals (they're now duplicated under claude-project-tracker by this digest), or (b) UPDATE the 5 rows to set project_id='claude-project-tracker'.
claude-project-tracker · claude-project-tracker · by saravanan@scrumclaw.ai
58d ago
06-11 11:26
todo low
Implement real PDF score-report parser (REQ-19.7, currently stub + manual entry)
BRD v3.0 REQ-19.7 is Deferred. A stub parser ships with manual-entry fallback so users aren't blocked; the real ≥90%-extraction PDF parser is outstanding.
docs/BRD_V3_TRACKER.md
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
56d ago
06-13 11:14
note low
#20 Ask AI Tutor (REQ-20.1–20.7) deferred to v3.1 per decision D6
All 7 Ask AI Tutor requirements are intentionally Deferred (decision D6, 2026-05-17). v3.0 scope is 13 enhancements (#9–#22 minus #20), 108 in-scope REQs. Tracking as a note so it isn't mistaken for unplanned work.
docs/BRD_V3_TRACKER.md
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
56d ago
06-13 11:14
todo low
[Phase TBD] Add iPad support for iOS app (deferred — not required for initial launch)
Per decision on 2026-06-13, iPad support is not required for the initial App Store submission (iPhone-only). Revisit in a future phase: iPad layout/adaptivity pass + iPad screenshots in App Store Connect. No target date.
docs/BRD5_PHASE_5A_5B_NOTES.md
Adaptive SAT · adaptive-sat · by saravanan@scrumclaw.ai
56d ago
06-13 11:19
todo low
Remove deprecated Razorpay 'payment_capture: 1' from order create
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.
internal/handlers/wallet_handler.go:340
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
8d ago
07-31 02:51
note low
WIP walk-in user schema (from initial design — NOT locked)
Snapshot of the initial ad-hoc design so it isn't lost during the BRD/TDD process. May be revised or discarded. **Users table change:** - ALTER users ALTER COLUMN phone_number DROP NOT NULL - Recreate UNIQUE index as partial (WHERE phone_number IS NOT NULL) so multiple NULLs are allowed - New auth_provider value: 'upi_walkin' **New table user_upi_handles** — many VPAs per user, source-tagged: id UUID PK, user_id UUID FK, vpa VARCHAR(100), first_seen_at, last_seen_at, payment_count INT, source VARCHAR(30), is_primary BOOL, UNIQUE(user_id, vpa), INDEX on LOWER(vpa) **Match priority (webhook → user):** phone (contact) → email → vpa → else create walk-in **Repository additions:** UserRepository.GetByVPA(vpa) UserRepository.InsertUPIHandle(userID, vpa, source, primary) UserRepository.TouchUPIHandle(userID, vpa) **Auth claim flow (later):** OTP login on existing walk-in phone → attach, don't duplicate Flip auth_provider from 'upi_walkin' → 'password' Wallet balance + history preserved This design has open gaps around amount UX, plug/pay order, session termination, and failure handling — see the BRD-vs-design review todo.</body>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
8d ago
07-31 03:24
note low
Reference: Razorpay VPA + customer data extraction from qr_code.credited
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>
Vajra Volt Mobile App · vajra-mobile-app · by saravanan@scrumclaw.ai
6d ago
08-02 12:10

Add an item