07e4d838ed
Scanned all 15 workspace repos for TODOs, disabled features, stubs. - 12 actionable TODOs in platform-service (delivery, exports, broadcasts, surveys, waitlist, diagnostics, telemetry) - 3 identical error.tsx telemetry TODOs across dashboards - 3 package-level TODOs (feedback-client tests, create-app template) - All 9 product backends + webs are TODO-free - Prioritized into P0-P3 with impact/benefit analysis and sprint plan
15 KiB
15 KiB
Workspace TODO / Disabled Feature Audit
Generated: 2026-03-22 Scope: All 15 workspace repos — platform-service, dashboards, packages, 9 product backends + webs Method: Automated grep scan for
TODO,FIXME,HACK, disabled features, stubs,console.log
Executive Summary
| Area | Actionable TODOs | False Positives | Priority Items |
|---|---|---|---|
| platform-service | 12 | 0 | 5 |
| admin-web | 1 | 0 | 1 |
| tracker-web | 1 | 0 | 1 |
| user-dashboard-web | 1 | 0 | 1 |
| shared packages | 3 | 2 (test/template) | 1 |
| product backends (9 repos) | 0 | 0 | 0 |
| product webs (9 repos) | 0 | 0 | 0 |
| Total | 18 | 2 | 8 |
Verdict: The codebase is in strong shape. All 9 product backends and webs are TODO-free. The 18 actionable items are concentrated in platform-service (the largest service with 37+ modules). Most are low-risk "wire integration" tasks that don't block core functionality.
Findings by Priority
P0 — High Impact, Low Effort (address now)
| # | Location | TODO | Impact if NOT Addressed | Benefit of Addressing | Effort |
|---|---|---|---|---|---|
| 1 | admin-web/src/app/error.tsx:13 |
// TODO: send to telemetry once wired |
Uncaught errors in admin console are silently swallowed — no visibility into production crashes | Ops gets crash telemetry for the admin dashboard | S (5 lines) |
| 2 | tracker-web/src/app/error.tsx:13 |
// TODO: send to telemetry once wired |
Same as above for tracker dashboard | Same — crash visibility for tracker | S (5 lines) |
| 3 | user-dashboard-web/src/app/error.tsx:13 |
// TODO: send to telemetry once wired |
Same for user portal | Same — crash visibility for user portal | S (5 lines) |
Recommendation: Address all 3 — they're identical patterns. Wire @bytelyst/telemetry-client reportError() in the useEffect. ~15 minutes total.
P1 — Medium Impact, Medium Effort (address in next sprint)
| # | Location | TODO | Impact if NOT Addressed | Benefit of Addressing | Effort |
|---|---|---|---|---|---|
| 4 | platform-service/modules/delivery/subscribers.ts:112 |
[delivery/subscriber] Payment failed — email delivery requires user lookup (TODO) |
Users whose payments fail get NO email notification — they may not know their payment was rejected | Users get proactive "please update your card" emails, reducing involuntary churn | M (needs user lookup → email dispatch) |
| 5 | platform-service/modules/delivery/subscribers.ts:126 |
[delivery/subscriber] Trial expiring — email delivery requires user lookup (TODO) |
Users about to lose their trial get no warning email | Significantly improves trial→paid conversion rate | M |
| 6 | platform-service/modules/delivery/subscribers.ts:134 |
[delivery/subscriber] Trial expired — email delivery requires user lookup (TODO) |
Users whose trial just expired get no notification | Win-back opportunity via "your trial ended" email | M |
| 7 | platform-service/modules/surveys/routes.ts:544 |
// TODO: Integrate with billing/subscriptions module to grant pro_days or credits |
Survey incentives (promised credits/pro days) are marked as "claimed" but never actually granted | Users complete surveys expecting rewards but don't receive them — trust issue | M (wire billing API call) |
Recommendation: Items 4–6 are closely related — all need a user lookup step before email dispatch. Implement once as a shared helper. Item 7 is a trust issue with end users — should be prioritized if surveys are actively running.
P2 — Low Impact, Medium Effort (schedule for later)
| # | Location | TODO | Impact if NOT Addressed | Benefit of Addressing | Effort |
|---|---|---|---|---|---|
| 8 | platform-service/modules/telemetry/repository.ts:35 |
// TODO: Group by pk and use bulk operations for same-partition batches |
Telemetry upserts are O(n) individual writes instead of bulk — higher RU cost and latency at scale | ~50% fewer Cosmos RU/s for telemetry ingestion at high volume | M |
| 9 | platform-service/modules/exports/routes.ts:52 |
// TODO: Queue actual export processing via jobs module |
Data exports are accepted but never actually processed — the job is created and marked "processing" but nothing happens | Users can actually download their exported data | L (wire jobs module) |
| 10 | platform-service/modules/broadcasts/repository.ts:397 |
// TODO: Implement real query against users/subscriptions containers |
Broadcast audience estimation returns mock data — admins see fake reach numbers | Admins see real user counts before triggering broadcasts | M |
| 11 | platform-service/modules/broadcasts/routes.ts:190 |
// TODO: Trigger async delivery job via event bus |
Broadcasts are "triggered" but no actual delivery happens — it's a no-op | Admins can actually send broadcasts to users | L (wire event bus + delivery) |
| 12 | platform-service/modules/waitlist/routes.ts:125 |
// TODO-1: CAPTCHA validation |
No bot protection on public waitlist signup form | Prevents spam/bot signups on the waitlist | M (needs provider API keys) |
| 13 | platform-service/modules/waitlist/routes.ts:426 |
// TODO-3: Auto-generate invitation codes via invitations module |
Waitlist entries marked "invited" don't actually get invitation codes | Full waitlist → invite → onboarding pipeline works end-to-end | S (wire invitations repo) |
Recommendation: Item 9 (export processing) is the highest impact here — data exports are silently broken. Item 11 (broadcast delivery) is similar. Both should be addressed before those features go live.
P3 — Operational / Nice-to-Have (defer)
| # | Location | TODO | Impact if NOT Addressed | Benefit of Addressing | Effort |
|---|---|---|---|---|---|
| 14 | platform-service/modules/diagnostics/subscribers.ts:123 |
// TODO: Notify admin who started the session |
Debug session cancellation doesn't notify the requesting admin | Admin gets notified when their debug session is cancelled | S |
| 15 | platform-service/modules/diagnostics/subscribers.ts:154 |
// TODO: Email summary to admin who created the session |
Debug session completion doesn't send summary email | Convenience — admin gets results emailed | S |
| 16 | platform-service/modules/diagnostics/subscribers.ts:210 |
// TODO: Send PagerDuty/Slack alert for on-call engineer |
FATAL logs during debug sessions don't trigger external alerts | Critical — but requires PagerDuty/Slack integration setup | L |
| 17 | packages/feedback-client/src/integration.test.ts:10 |
TODO-4: Requires blob storage to be available in test environment |
Integration test skipped without blob storage | Test runs in CI with blob storage configured | S (infra) |
| 18 | packages/feedback-client/src/gdpr.test.ts:138 |
TODO-7: Azure lifecycle policy purges blob within 90 days |
Blob cleanup relies on Azure lifecycle policy, not explicit deletion | Documentation / acceptance — not a code fix | XS |
Recommendation: Items 14–15 are nice-to-have notifications. Item 16 (PagerDuty/Slack for FATAL logs) is important for production but requires external service integration. Items 17–18 are test/infra items, not functional gaps.
Items Explicitly NOT TODOs (Excluded)
These were found in scans but are not actionable gaps:
| Location | Content | Why Excluded |
|---|---|---|
packages/create-app/src/lib/templates.ts:276 |
// TODO: Register your route modules here |
Template placeholder for create-app scaffolding — intentional |
packages/feedback-client/src/gdpr.test.ts:23 |
describeIntegration('GDPR Deletion Compliance (TODO-5)') |
Test suite name contains TODO — it's a label, not missing work |
user-dashboard-web/.../sessions/[id]/page.tsx:695 |
['list', 'todo', 'task', 'priority'...] |
String data containing the word "todo" — not a code TODO |
All *.test.ts files with "mock" |
Test mocks using vi.fn() / vi.mock() | Standard test pattern, not production stubs |
Repos With Zero TODOs (Clean)
These backends and webs have no actionable TODOs — fully implemented:
| Repo | Backend | Web | Notes |
|---|---|---|---|
| ActionTrail | ✅ 0 | ✅ 0 | Production-ready, v1.0.0 |
| NoteLett | ✅ 0 | ✅ 0 | MCP tools complete |
| FlowMonk | ✅ 0 | ✅ 0 | Scheduler complete |
| JarvisJr | ✅ 0 | ✅ 0 | Voice + agents |
| ChronoMind | ✅ 0 | — | Timers + cascades |
| PeakPulse | ✅ 0 | — | Adventure tracker |
| NomGap | ✅ 0 | — | Fasting app |
| Local Memory GPT | ✅ 0 | — | Local AI chat |
| MindLyst | ✅ 0 | — | KMP shared module |
| LysnrAI (backend) | ✅ 0 | — | 62 tests |
| extraction-service | ✅ 0 | — | Python sidecar |
| mcp-server | ✅ 0 | — | MCP protocol |
Recommended Action Plan
Sprint A (1–2 days) — Quick Wins
- Wire telemetry
reportError()in all 3 dashboarderror.tsxfiles (~15 min) - Wire waitlist → invitations module for auto-generated invite codes (~30 min)
Sprint B (3–5 days) — User-Facing Gaps
- Implement user lookup helper for delivery subscribers (payment_failed, trial_expiring, trial_expired)
- Wire survey incentive fulfillment to billing/subscriptions module
- Wire export job processing through the jobs module
Sprint C (deferred) — Operational Excellence
- Implement real broadcast audience estimation query
- Wire broadcast delivery via event bus
- Add CAPTCHA validation to waitlist signup
- Telemetry bulk upsert optimization
- PagerDuty/Slack integration for FATAL diagnostic logs
Methodology
Scanned 15 repos across:
- 3 dashboards (admin-web, tracker-web, user-dashboard-web)
- 3 services (platform-service, extraction-service, mcp-server)
- 14+ shared packages
- 9 product backends (LysnrAI, ActionTrail, NoteLett, FlowMonk, JarvisJr, ChronoMind, PeakPulse, NomGap, Local Memory GPT)
- 9 product webs
Search patterns: TODO, FIXME, HACK, STUB, XXX, console.log, disabled, stub, placeholder, not implemented, noop
Excluded: test file mocks/stubs, template placeholders, data strings containing "todo", console.error in catch blocks (acceptable browser error logging)