What's pending across every project
6 open · sorted by priority then due-date
Filtered by tag architecture clear
todo
high
Generalise per-asset hard-coding — prerequisite for stocks, commodities and indexes
Each coin has its own table family (pricedata, ohlcv, predictiondata, indicators, indicators_plus + view). Coin list is hard-coded in CASE statements in getcryptodata, getpricedataforcurrencies, getcurrencydetails, and in crypto_id == 1 or ... lists in ml-core-service and CoinTrends_Python. Design an asset-agnostic schema (asset master + long-format tables keyed by asset_id) and drive code from cryptomaster/asset master.
dbo.getcryptodatadbo.getpricedataforcurrenciesdbo.getcurrencydetailsml-core-service/main.py::func
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: what are the issues you identified in cointrends?
claude: Coin-specific logic is hard-coded everywhere; adding any asset means editing many places by hand.
saravanan: create cointrends in tracker and push these items there
10d ago
10-16 19:09
10-16 19:09
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
todo
Route the webapp through web-service only (stop calling core-service directly)
crypto538-webapp uses REACT_APP_COIN_DATA_BASE_URL pointing at the public core-service Cloud Run URL, bypassing web-service auth/plan checks. Needed before core-service can be made private.
crypto538-webapp/.env.production::REACT_APP_COIN_DATA_BASE_URL
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: what are the issues you identified in cointrends?
claude: The webapp calls the core service directly, bypassing the web service's authentication layer.
saravanan: create cointrends in tracker and push these items there
10d ago
10-16 19:09
10-16 19:09
todo
Revisit the 12-models-per-asset design before scaling to new asset classes
One DARNN per 5-minute offset (desired_minute 0..55) → 12 models per coin, 120 today. Consider one model per asset with minute-of-hour as a feature, and a horizon suited to each asset class (e.g. daily for stocks/indexes).
CoinTrends_Python/trigger_updated.py
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
from the conversationsaravanan: what are the issues you identified in cointrends?
claude: Each asset needs 12 models (one per 5-minute offset), which multiplies training cost and makes the model count grow fast.
saravanan: create cointrends in tracker and push these items there
10d ago
10-16 19:09
10-16 19:09
todo
PR "Open Markets": extend the platform to stocks, indexes, commodities and FX (after Coin Roster)
Design in cointrends/plans/PR-open-markets.md (also in project docs). Main pieces: per-asset prediction config (horizon, step, offsets, feature set); calendar-aware sampling for markets that close; versioned feature sets with model metadata; context data as roster assets (replaces the frozen marketindex/metalsdata); pluggable data providers with locally computed indicators; site routes and entitlements per asset class. Open decisions: pilot assets, data provider and budget, URL scheme, subscriptions model.
plans/PR-open-markets.mdplans/PR-coin-roster.md#130
CoinTrends.ai
· cointrends
· by saravanan@scrumclaw.ai
6d ago
10-20 12:55
10-20 12:55