What's pending across every project
12 open · sorted by priority then due-date
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
85d ago
08-02 11:45
08-02 11:45
decision
high
Decide on 58dd2aaf2 before promoting dev to QA — it hides why a tool failed
Commit 58dd2aaf2 adds taxonomyGatePublicErrorNote, collapsing any note starting "Tool failure" or "Tool execution failed" to the bare string "Tool failed", in both the on-screen display and the downloaded HTML export.
Hiding internal tool names from a customer-facing report is defensible. The problem is that it is applied to the only artifact QA uses for diagnosis. Every root cause in the consolidated fix plan was read out of that exact string: jscpd-cs tool_not_ready:MISSING_BINARY, semgrep tool_not_ready:FAILED_STARTUP_CHECK:VERSION_MISMATCH, dotnet_restore_failed:, lizard VERSION_MISMATCH.
It also cuts against fix-plan items 4.1 and 4.2, which ask for MORE provenance per row (tool name, artifact path, raw value), not less.
Recommendation: keep the detail behind an internal or admin view, or export an internal variant alongside the customer one. Do not let the only artifact lose it. This is a product decision, not an engineering one — make it deliberately rather than shipping it by default.
58dd2aafrontend/web-console/src/lib/confidence-engine/taxonomy-gate-display.ts:379-406frontend/web-console/src/lib/confidence-engine/taxonomy-gate-html-export.ts:107,247
Testable (Pramora)
· testable-platform
· by saravanan@scrumclaw.ai
27d ago
09-29 16:26
09-29 16:26
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.
137d ago
06-11 11:26
06-11 11:26
decision
Walk-in QR runs in-process in cmd/api, not as a separate walkin-service
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.
internal/routes/routes.gointernal/handlers/wallet_handler.go::forwardWalkinQRCreditc17a33a3f826d7b3b0fa7
Vajra Volt Mobile App
· vajra-mobile-app
· by saravanan@scrumclaw.ai
from the conversationsaravanan: No lets merge it together - i dont want two different things
claude: Merging is ~6 lines — mount walkin's internal endpoint and health route on the main API router, and point WALKIN_SERVICE_URL at 127.0.0.1:8080. Honest tradeoff: it keeps a pointless HTTP round-trip to itself; the fully clean version deletes forwardWalkinQRCredit, which touches the payment path.
49d ago
09-07 22:19
09-07 22:19
decision
Dropped Razorpay for CoinTrends — Stripe via web-service is the only billing path
Razorpay was only used for the VajraEV experiment. Code kept for now with deprecation comments (PR #70); deletion later.
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: i think razorpay is an experiment - you can drop it
saravanan: no i was using vajraev related only.
claude: Stripe through web-service + CryptoUserBilling_Prod is the only billing path.
10d ago
10-16 19:10
10-16 19:10
decision
Keep CoinTrends_Python (training code) outside git until secrets are stripped
The folder holds the DB password, public DB IP and an SA key in every script. Revisit after the secret-rotation items are done.
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: right now - let it sit outside of the repo - due to the secrets it contains.
claude: Recorded; it stays out of the repos for now.
10d ago
10-16 19:10
10-16 19:10
decision
Model training moves to Cloud Run Jobs with GPU (NVIDIA L4) — replaces the local Windows GPU box
Chosen over Vertex AI custom jobs: same platform as the rest of the stack (Cloud Run, Artifact Registry, Cloud Build, Scheduler), pay-per-execution, task-index fan-out fits the asset × minute-offset model grid. Parent work item: #90.
#90
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: where is the model training to be moved to CloudRun (GPU based)
claude: It's #90; recorded Cloud Run Jobs with GPU as the target and broke it into subtasks.
10d ago
10-16 19:11
10-16 19:11
decision
No changes to running systems until a final, step-by-step cleanup phase with validation and rollback
Saravanan 2026-10-19: do not stop or change anything that is running (schedulers, Cloud Run services, DB rows such as slices 1-23, live models). Findings and fixes are collected now; all production changes happen together at the end as an ordered cleanup plan where every step has a validation check and a rollback.
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: Keep all the changes to later stage - i do not want to stop anything that is running. we need a clean up step by step with proper validation and rollback at the end of all our work
claude: Recorded; production stays untouched until the final cleanup phase.
💬 1 comment
7d ago
10-19 14:19
10-19 14:19
decision
Staging stays retired — production-only, with local tests, pre-release backup, live validation and a ready rollback
Only production runs in the cloud. Leftovers: 3 idle staging Cloud Run services in prj-crypto538-stage-443113 (no triggers deploy to them), stage.cointrends.ai LB commented out in terraform, CryptoTrack_Stage / CryptoUserBilling_Stage DBs on the prod instance. Merging to the `stage` branch deploys nothing; `master` deploys prod. Leftovers can be reviewed in the final cleanup.
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: we stopped staging environmnt - its only production is enabled in cloud
claude: Confirmed; offered to log a cheap staging revival.
saravanan: leave staging retired
💬 1 comment
7d ago
10-20 01:45
10-20 01:45
decision
Model training runs as GCP Batch jobs on GPU (Spot L4), not Cloud Run — supersedes #111
Saravanan 2026-10-20: train on GPU using Google Cloud Batch. Shape: same ml-training container (CUDA build) in Artifact Registry; Batch job with one task per asset (BATCH_TASK_INDEX), g2-standard-4 (1x L4) Spot VMs, installGpuDrivers, parallelism ≤ quota (L4: 8 on-demand / 8 preemptible in us-central1), dedicated service account, DB via Cloud SQL connector, password from Secret Manager, logs to Cloud Logging. Triggered by Cloud Scheduler calling the Batch jobs API. Batch API not yet enabled. Updates #113/#114/#116.
#90#111#113#114#116
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: Lets use GPU to train - I want the batch process in gcp - not the cloud run with GPU
saravanan: tell me how to deploy that way
7d ago
10-20 01:51
10-20 01:51
decision
Monetization strategy: build additively on existing platform, no repositioning or tier changes
Keep Basic/Standard $10/Premium $15, 120-min horizon, current architecture. Make tiers worth paying for using features already half-built (all coins, alerts, scorecard, Genie-on-own-data, paper trading, API key). Extra channels: exchange affiliate links, newsletter sponsorship, B2B API = existing core endpoints behind an API key. Open Markets later as designed (additive). Estimates: crypto-only TAM ~$0.3-0.6B, multi-asset $3-6B; SAM $150-300M crypto / $1B+ with Open Markets; SOM $200-600k ARR on current architecture.
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: I believe your suggestions would break what we built - I wanted something built on what we already have to fill the gaps.
claude: reframed as additive gap-fill on existing components, same tiers and horizon.
5d ago
10-22 02:44
10-22 02:44
decision
Decide whether a parent can upload a score report for their student
UX review item 15 asks for a parent read-only Home "with Upload button". The read-only summary shipped; the button did not, because POST /api/study-plan/from-score-report is gated require_student. A parent cannot write today.
This is a permissions decision, not a UI one: the endpoint writes into user_skill_state, which drives weak-skill detection and question selection for the student. Options:
1. Leave it. Parent summary says "reports are uploaded from <name>'s account". Zero risk, but parents are often the ones holding the PDF, which is the whole reason the review asked.
2. Add a parent-scoped write endpoint gated on the accepted guardianship, same pattern as the existing read endpoints, and record the uploader on score_reports so the provenance is visible to the student.
3. Parent uploads but it lands as a pending report the student confirms — slowest, safest, and consistent with the review-and-correct principle in REQ-23.3.
My read: option 2 with uploader provenance. Option 3 adds a state machine for a problem nobody has reported yet.
docs/UX_REVIEW_2026_10_24.mdbackend/app/api/routes/planner.pybackend/app/api/routes/parent.pyfrontend/src/app/components/parent/ParentHomeSummary.tsx
Adaptive SAT
· adaptive-sat
· by saravanan@scrumclaw.ai
2d ago
10-24 17:59
10-24 17:59