Claude Project Tracker

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

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.

Testable (Pramora) · testable-platform · by saravanan@scrumclaw.ai

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

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.

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