What's pending across every project
8 open · sorted by priority then due-date
Filtered by tag decision clear
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
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