LexConsumer

JIT Life OS

Exception-first subscription management for recurring-spend cleanup — research, monetization, metrics, instrumentation, and backend package foundations are underway while the runnable MVP is still forming

Competes with Rocket Money

IncubatingLexConsumer

Key metrics

Metrics being defined

Competitive Intel

0 entries

No competitive intel entries for this product yet.

Roadmap

121 items

Done120

`/variants/guided`, `/variants/inbox`, `/variants/cockpit`, and `/variants/trust` exist and render distinct placeholder shells.

`pnpm test`, `pnpm typecheck`, `pnpm build`, and `git diff --check` pass.

A local web app can be started and visited in the browser.

All four variant route trees are runnable in the browser.

All phase tests pass.

Browser review verifies desktop and mobile layouts are nonblank, navigable, and free of obvious overlap.

Core shared components render without production Plaid, Stripe, Resend, auth, or database dependencies.

Desktop and mobile layouts are browser-checkable for the shared shell.

Each variant demonstrates Free credit available, Free credit consumed, Plus trial, stale connection, no-exception/all-clear, and scan states.

Each variant includes landing, onboarding auth/connect/scan/results, app home, exception detail, subscriptions, and settings states.

Existing package tests continue to pass.

Focused route/component regression tests cover the new production surfaces after implementation.

Free, credit-consumed, Plus trial, stale connection, all-clear, scan/progress, and preliminary-results states are represented where the route needs them for first implementation.

Guided Autopilot is the production spine across landing, onboarding, app home, exception detail, subscriptions, settings, billing, and connections.

Live OAuth, Plaid, Stripe, Resend, durable database, and deployed secret work are not introduced in this phase.

No regressions in previous phase tests.

Production routes exist for the full MVP route map and render nonblank provider-neutral surfaces.

Provider and privacy copy matches `specs/ui-monetizable-mvp-production.md` and `specs/monetizable-mvp-runtime.md`.

Query states such as `?state=scan`, `?state=results`, `?state=stale`, `?state=credit-consumed`, and `?state=trial` are parsed into typed mocked UI state.

Route data is read through provider-neutral fixture/adapters rather than directly from prototype variant state.

Shared components remain reusable and do not fork unnecessarily.

Shared mocked data is centralized and reused by prototype components.

Step 1.1: Add failing tests for the namespaced phase-1 event dictionary and module conventions in `packages/core/src/instrumentation/events.test.ts`. **automated**

Step 1.2: Add failing tests for required event envelope fields and correlation helpers in `packages/core/src/instrumentation/envelope.test.ts`. **automated**

Step 1.3: Add failing tests for analytics-safe payload enforcement in `packages/core/src/instrumentation/privacy.test.ts`. **automated**

Step 1.4: Implement shared phase-1 event constants and module-aware taxonomy exports in `packages/core/src/instrumentation/events.ts` and `packages/core/src/instrumentation/index.ts`. **automated**

Step 1.5: Implement shared event envelope types and helper builders in `packages/core/src/instrumentation/envelope.ts`. **automated**

Step 1.6: Implement analytics payload allowlist and redaction helpers in `packages/core/src/instrumentation/privacy.ts`. **automated**

Step 1.7: Run the phase-1 instrumentation foundation tests and fix the shared APIs until they pass. **automated**

Step 1.8: Verify the phase-1 event dictionary covers onboarding, Plaid link, scan lifecycle, exception lifecycle, notification response, connection health, and billing lifecycle without allowing forbidden analytics payloads. **automated**

Step 10.1: Add failing tests for `processRelinkRequest()` in `apps/web/src/lib/handlers/relink.test.ts`. **automated**

Step 10.2: Add failing tests for `processDisconnectionRequest()` in `apps/web/src/lib/handlers/disconnection.test.ts`. **automated**

Step 10.3: Add failing tests for `processRelinkCallbackRequest()` in `apps/web/src/lib/handlers/relink-callback.test.ts`. **automated**

Step 10.4: Create `apps/web/src/lib/handlers/relink.ts` with `processRelinkRequest()` and request/result types. **automated**

Step 10.5: Create `apps/web/src/lib/handlers/disconnection.ts` with `processDisconnectionRequest()` and request/result types. **automated**

Step 10.6: Create `apps/web/src/lib/handlers/relink-callback.ts` with `processRelinkCallbackRequest()`. **automated**

Step 10.7: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 10.8: All request handlers validate inputs, delegate to service layer, and return structured side effects without touching HTTP or database directly. **automated**

Step 11.1: Add failing tests for `renderStaleConnection24hEmail()` in `packages/notifications/src/templates/stale-recovery.test.ts`. **automated**

Step 11.2: Add failing tests for `renderStaleConnection5dEmail()` in `packages/notifications/src/templates/stale-recovery.test.ts`. **automated**

Step 11.3: Add failing tests for `buildStaleNotificationDeliveryRequest()` in `packages/notifications/src/delivery/stale-recovery.test.ts`. **automated**

Step 11.4: Create `packages/notifications/src/templates/stale-recovery.ts` with `renderStaleConnection24hEmail()` and `renderStaleConnection5dEmail()`. **automated**

Step 11.5: Create `packages/notifications/src/delivery/stale-recovery.ts` with `buildStaleNotificationDeliveryRequest()`. **automated**

Step 11.6: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 11.7: Email templates render correct copy variants and delivery requests are structured for handoff to a future email provider adapter. **automated**

Step 16.1: Create provider-neutral runtime state contracts and fixtures. **automated**

Step 16.2: Build production public and authenticated shells. **automated**

Step 16.3: Implement production public landing and pricing routes. **automated**

Step 16.4: Implement production onboarding route states. **automated**

Step 16.5: Implement authenticated app home and exception detail routes. **automated**

Step 16.6: Implement subscriptions, settings, billing, and connections routes. **automated**

Step 16.7: Add focused route/component regression tests for production surfaces. **automated**

Step 16.8: Validate the production shell phase. **automated**

Step 2.1: Add failing tests for anonymous attribution capture and persistence in `apps/web/src/lib/instrumentation/attribution.test.ts`. **automated**

Step 2.2: Add failing tests for signup-time anonymous-to-user merge hooks in `packages/auth/src/instrumentation/identity-merge.test.ts`. **automated**

Step 2.3: Add failing tests for attribution storage and onboarding-correlation schema support in `packages/db/src/instrumentation/attribution.test.ts`. **automated**

Step 2.4: Implement anonymous session and attribution helpers in `apps/web/src/lib/instrumentation/attribution.ts`. **automated**

Step 2.5: Implement identity merge hooks and user trait translation in `packages/auth/src/instrumentation/identity-merge.ts`. **automated**

Step 2.6: Implement persisted attribution and onboarding-session schema support in `packages/db/src/instrumentation/attribution.ts` and related schema files. **automated**

Step 2.7: Run the attribution and identity-merge test suite and fix integration gaps until it passes. **automated**

Step 2.8: Verify first-touch and last-non-direct-touch attribution persist from anonymous landing through signup completion with a stable onboarding session ID. **automated**

Step 3.1: Add failing tests for onboarding and Plaid-link product events in `apps/web/src/lib/instrumentation/product-events.test.ts`. **automated**

Step 3.2: Add failing tests for detection, exception, and connection-health system events in `packages/ingestion/src/instrumentation/system-events.test.ts` and `packages/detection/src/instrumentation/system-events.test.ts`. **automated**

Step 3.3: Add failing tests for notification translation and billing lifecycle events in `packages/notifications/src/instrumentation/events.test.ts` and `apps/web/src/app/api/billing/webhooks/instrumentation.test.ts`. **automated**

Step 3.4: Implement onboarding, result-view, and exception-surface product events at the app boundary in `apps/web/src/lib/instrumentation/product-events.ts` and related route handlers. **automated**

Step 3.5: Implement backend-owned connection, scan, detection, exception, and notification lifecycle emitters in `packages/ingestion`, `packages/detection`, and `packages/notifications`. **automated**

Step 3.6: Implement Stripe-backed billing event translation in `apps/web/src/app/api/billing/webhooks/instrumentation.ts` and related billing workflow files. **automated**

Step 3.7: Run the phase-3 event emission tests and fix ownership-boundary regressions until they pass. **automated**

Step 3.8: Verify each phase-1 event is emitted exactly once from the boundary that owns the state transition. **automated**

Step 4.1: Add failing query tests for bank-link completion and time-to-first-results measurement in `packages/db/src/metrics/activation.test.ts`. **automated**

Step 4.2: Add failing query tests for MERR, urgent alert response, and noise guardrail measurement in `packages/db/src/metrics/engagement.test.ts`. **automated**

Step 4.3: Add failing query tests for monitored-user and connection-health measurement in `packages/db/src/metrics/retention.test.ts`. **automated**

Step 4.4: Implement backend metric query helpers and supporting views in `packages/db/src/metrics/activation.ts`, `packages/db/src/metrics/engagement.ts`, and `packages/db/src/metrics/retention.ts`. **automated**

Step 4.5: Add any required schema support for persisted measurement metadata in `packages/db/src/schema/*` and related migrations. **automated**

Step 4.6: Run the metric query test suite and fix query or schema issues until it passes. **automated**

Step 4.7: Verify the first core metrics are computable from backend truth with analytics used only for behavioral context. **automated**

Step 5.1: Add failing tests for `RelinkAttemptRow` schema in `packages/db/src/schema/relink-attempts.test.ts`. **automated**

Step 5.2: Add failing tests for `measureRelinkRecoveryRate` in `packages/db/src/metrics/recovery.test.ts`. **automated**

Step 5.3: Add failing test for disconnected exclusion in `packages/db/src/metrics/retention.test.ts`. **automated**

Step 5.4: Create `packages/db/src/schema/relink-attempts.ts` and re-export from `packages/db/src/schema/index.ts`. **automated**

Step 5.5: Create `packages/db/src/metrics/recovery.ts` with `measureRelinkRecoveryRate()`. **automated**

Step 5.6: Update `packages/db/src/metrics/retention.ts` to exclude disconnected connections. **automated**

Step 5.7: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 5.8: `RelinkAttemptRow` exported, recovery rate correct with trigger segmentation, disconnected excluded from health metrics. **automated**

Step 6.1: Add failing tests for stale-connection notification events in `packages/notifications/src/instrumentation/events.test.ts`. **automated**

Step 6.2: Add failing test for `product.relink_flow_opened` in `apps/web/src/lib/instrumentation/product-events.test.ts`. **automated**

Step 6.3: Add failing test for `system.connection_marked_disconnected` in `packages/ingestion/src/instrumentation/system-events.test.ts`. **automated**

Step 6.4: Add `createStaleConnectionNotificationQueuedEvent()` to `packages/notifications/src/instrumentation/events.ts`. **automated**

Step 6.5: Add `createRelinkFlowOpenedEvent()` to `apps/web/src/lib/instrumentation/product-events.ts`. **automated**

Step 6.6: Add `createConnectionMarkedDisconnectedEvent()` to `packages/ingestion/src/instrumentation/system-events.ts` and update event taxonomy. **automated**

Step 6.7: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 6.8: Stale notification events carry `connection_id`, relink flow carries trigger attribution, disconnected event exists in taxonomy. **automated**

Step 7.1: Add failing tests for notification scheduling in `packages/notifications/src/scheduling/stale-recovery.test.ts`. **automated**

Step 7.2: Add failing tests for connection state machine in `packages/db/src/logic/connection-state-machine.test.ts`. **automated**

Step 7.3: Add failing tests for catch-up sync planner in `packages/ingestion/src/scheduling/catch-up-sync.test.ts`. **automated**

Step 7.4: Create `packages/notifications/src/scheduling/stale-recovery.ts` with `evaluateStaleNotification()`. **automated**

Step 7.5: Create `packages/db/src/logic/connection-state-machine.ts` with `transitionConnectionState()`. **automated**

Step 7.6: Create `packages/ingestion/src/scheduling/catch-up-sync.ts` with `planCatchUpSync()`. **automated**

Step 7.7: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 7.8: Notification scheduler respects cadence and suppression, state machine covers all transitions, catch-up sync planner correct. **automated**

Step 8.1: Add failing tests for `handleConnectionBecameStale()` in `packages/ingestion/src/handlers/stale-detection.test.ts`. **automated**

Step 8.2: Add failing tests for `handleRelinkAttempt()` in `packages/ingestion/src/handlers/relink.test.ts`. **automated**

Step 8.3: Add failing tests for `handleDisconnection()` in `packages/ingestion/src/handlers/disconnection.test.ts`. **automated**

Step 8.4: Create `packages/ingestion/src/handlers/stale-detection.ts` with `handleConnectionBecameStale()`. **automated**

Step 8.5: Create `packages/ingestion/src/handlers/relink.ts` with `handleRelinkAttempt()`. **automated**

Step 8.6: Create `packages/ingestion/src/handlers/disconnection.ts` with `handleDisconnection()`. **automated**

Step 8.7: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 8.8: All three recovery handlers compose primitives correctly, return typed results, and handle invalid-state edge cases. **automated**

Step 9.1: Add failing tests for `processPlaidItemError()` in `packages/ingestion/src/webhooks/plaid-item-error.test.ts`. **automated**

Step 9.2: Add failing tests for `PlaidItemErrorPayload` schema validation in `packages/ingestion/src/webhooks/plaid-item-error.test.ts`. **automated**

Step 9.3: Create `packages/ingestion/src/webhooks/plaid-item-error.ts` with payload type and `processPlaidItemError()`. **automated**

Step 9.4: Run `pnpm test` — all tests pass, no regressions. **automated**

Step 9.5: Plaid webhook handler validates payloads, resolves connections, delegates to recovery service, and returns structured side effects. **automated**

The production app uses public and authenticated shells without prototype switchers, variant registries, review shortcuts, query-state review controls, or cockpit left-rail navigation.

The prototype switcher can move between variants and common states.

Variant differences are meaningful in layout, hierarchy, and copy, not just color.

Planned1

`$platform-strategy` - create `research/platform-strategy.md` because the enabled `business-ops` pack includes the missing platform expansion strategy artifact, and the completed implementation roadmap has no next phase queued.