lakshmi app

An AI financial-agent service shell (apps/lakshmi/ai-agents), and the most self-honest scaffold in the area — its src/index.ts docstring states the agents (scenario modeling, recommendations, NL query, bill negotiation, tax advisory) are "NOT yet implemented in this service — this process currently serves health checks only." What is real is resolveConfiguredModelProviders, which inspects the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, and Google/Gemini keys) and reports the subset of foundation-model providers actually configured, rather than asserting connections that may not exist. The health payload also surfaces the configured embedding model and agent concurrency. Beyond /health and /ready, there is no agent logic here.

The Hono HTTP/WebSocket front door (apps/lakshmi/api-gateway), and by far the most complete service in the area. Its edge layer is real and production-grade: JWT verification via jose (HS256) with subscription-tier RBAC (free/premium/family → permission sets) and per-route OAuth scope enforcement in src/middleware/auth.ts; Redis-backed rate limiting; a machine-generated OpenAPI 3.1 document and OAuth authorization-server metadata built from a 44-endpoint catalog in src/public-rest-api.ts; a typed idempotent Kafka producer in src/kafka.ts; and a room-based WebSocket manager in src/websocket.ts. The 44 /v1 route handlers in src/app.ts, however, are intentionally hollow — they validate input with Zod, enforce auth/scopes, then return empty placeholder payloads (e.g. c.json({ accounts: [] })) annotated with // Domain service call will be implemented in @lakshmi/<domain> library. So: the gateway is a working, secured, observable API surface, but the finance data behind it is not yet wired.

A Chrome Manifest V3 browser extension (apps/lakshmi/browser-extension) that shows budget/price/coupon/cashback context while shopping. Several parts are real: src/shared/shopping-context.js is a genuine client-side analysis library (budget arithmetic, coupon ranking by estimated savings, best-offer and best- cashback selection, currency formatting, and price-text parsing); the background/service-worker.js handles install-time storage defaults and a runtime.onMessage settings query; and scripts/build.js packages src/ into dist/chrome/ while validating that the manifest is MV3 with a popup and content scripts (scripts/validate-extension.js is wired as the typecheck target, and Playwright as e2e). The honest caveat is the data and the injected overlay: DEFAULT_PROFILE is sample/seed data (example merchants like "Threadline"), and the injected content/content-script.js overlay uses hardcoded sample figures (spent 34000, budget 40000, a fixed best price) and does not yet call the shared analyzeShoppingContext analyzer or any live account data. So the extension is a working MV3 package with a real analysis module, but its on-page experience is currently a demo wired to placeholder numbers.

The BullMQ repeatable-job scheduler (apps/lakshmi/scheduler), and — alongside the worker's queue layer — one of the genuinely functional pieces of the area. src/schedules.ts builds five recurring tasks against the same five queue names the worker consumes, each with a real repeat policy (interval-based for the account-sync and categorization sweeps, cron-based for daily AI recommendations, daily report rollups, and hourly export maintenance) and env-overridable timing via getSchedulerConfigFromEnv. src/index.ts registers them with queue.upsertJobScheduler, which is a live Redis operation, and exposes a health endpoint reporting the registered task count, last registration time, and state. The data each scheduled job carries is system-level seed data (e.g. userId: 'system', connectionId: 'due-connections') since the worker side that would fan these out per-user is not yet implemented, but the scheduling mechanism itself is real and complete.

A service shell for account synchronization (apps/lakshmi/sync-engine). Its module docstring describes orchestrating open-banking provider polling (Plaid, Yodlee, MX, Finicity, Tink), transaction ingestion, and balance refresh, but the implemented code in src/index.ts is only a Node http server that answers /health and /ready. The provider list it reports is a static array inside createSyncEngineHealthPayload, and the sync interval/concurrency are read from env vars — there is no polling, ingestion, or Kafka publishing in the service yet. Honest status: a health-serving scaffold awaiting the actual sync implementation.

The BullMQ background-job processor (apps/lakshmi/worker). The queue infrastructure in src/queues.ts is real and substantial: five typed queues plus five matching dead-letter queues, per-queue retry counts and back-off strategies (exponential for sync/categorize/AI, fixed for report/export), typed enqueue helpers with deduplicating job IDs, a QueueEvents-based DLQ forwarder that moves permanently-failed jobs (attempts exhausted) into the DLQ with failure metadata, and a typed createWorker factory wrapping processors in structured start/complete/fail logging. src/index.ts boots one worker per queue at domain-specific concurrencies with a graceful shutdown that drains workers, events, and queues. The five job processors (processAccountSync, processTransactionCategorize, processAiRecommendation, processReportGeneration, processDataExport) are the scaffolded part: they log each phase and call job.updateProgress(...) but replace the actual work with // Real implementation: ... comments referencing @lakshmi/integrations, @lakshmi/db, embeddings, and MinIO. So the BullMQ runtime is genuine; the finance work inside the jobs is deferred.