What's pending across every project
3 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
6d ago
08-02 11:45
08-02 11:45
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
06-11 11:26
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
07-31 03:24