Index and status tracker for the things we own, organized by product (matching the overhaul plan taxonomy and diagram). Use this to see at a glance what is properly specced and what still needs speccing.
Keep the status column in sync with each doc's own **Status:** line as work
lands.
- Implemented: specced and built in v2 (may still be under doc review).
- Specced: spec and design exist and are review-ready; buildable.
- Spiked: research/spike only, surfaces open questions; needs a real spec.
- Draft: an early draft exists, not yet reviewed.
- Stub: placeholder folder only; not started.
- Blocked: waiting on an open decision (see "Open decisions").
| Issue / service | Status | What exists / what is left |
|---|---|---|
| 001-cloud-core | proprietary cloud product | |
| auth | Mixed | the auth system, in 5 docs: concepts (primer), spec + design (Specced), oem-auth (Implemented). See rows below |
| auth / spec + design | Specced | spec.md (endpoints + tokens) and design.md (e2e code changes + the identity model, migration bridge, and miniapp auto-auth + injection): exchange, refresh, miniapp-token mint, JWKS. Open: API-key role |
| auth / oem-auth | Implemented | the OEM-JWT exchange mechanics, built in v2, e2e verified with test-oem. Left: finalize doc review |
| oem-service | Stub | needs spec |
| miniapp-service | Draft | placeholder plus preinstalled-local-miniapps.md, superseded/expanded by 011-miniapp-registry |
| dev-console-service | Stub | needs spec |
| storage-service | Stub | needs spec (wrapper around swappable blob providers; used by miniapp-service, dev-console-service) |
| 002-cloud-runtime | self-hostable runtime product | |
| architecture + design | Written | architecture.md: the big picture (scaling rules, session lifecycle, e2e trace). design.md: the @mentra/cloud-runtime package build map + signatures + current state |
| protocol (transport) | Locked | contract locked (/api paths, envelope with timestamp, REST subscriptions 2a with sessionId+version, UDP encryption); zod types written in @mentra/cloud-runtime/protocol |
| audio | Specced / partial | spec + design (proposal, under review); pipeline partially built (UDP + Redis + Soniox, phone WS). Subscription transport decided (2a: REST + stream entry); UDP encryption documented |
| camera (managed photo + stream) | Specced | spec.md: presigned-upload photo (cloud out of the byte path, storage-event completion, photo.ready push) + client-controlled managed stream |
| 003-cloud-proxy | Stub | needs spike (non-blocking; cloud-client is proxy-aware via endpoint config) |
| 004-cloud-client | Specced / partial | architecture.md: the big picture (how a miniapp reaches the cloud, what the cloud-client is and why, auth for Mentra + OEMs, decisions). spec.md: the public API. design.md: how it's built (transports, connection lifecycle, token refresh). udp-liveness-fallback: partially implemented reversible UDP/WS audio transport selection; phone harness and cross-pod probe ack routing remain |
| 005-websites | web frontends | |
| console | Draft | see 013-console2 |
| miniapp-store | Stub | needs spec |
| oem-portal | Draft | spike exists; current proposal is 014-enterprise-portal |
| 006-dev-toolkit | developer toolkit | |
| local-sdk | Spiked | findings + open questions, not yet a proposal. Left: spec + design |
| cli | Draft | see 012-mentra-cli-v2 |
| 007-runtime-auth-independence | Draft | runtime auth split issue: make Runtime Services able to accept trusted runtime tokens without live Core dependency; define optional Core endpoint/client behavior |
| 008-subscription-seed-overlap | Draft | subscription replay/seed overlap issue: prevent duplicated seed and live transcript events when a miniapp subscribes during an active stream |
| 009-miniapp-auto-auth | Draft | miniapp backend auth: host-minted audience-scoped miniapp tokens exposed through session.auth, without leaking Core/runtime credentials |
| 010-dev-miniapp-auth-audience | Draft | dev-slot versus real-package auth audience issue: keep com.dev routing while minting backend tokens only for trusted dev registration package names |
| 011-miniapp-registry | Draft | package, bundle, release channel, submission, and preinstalled registry data model plus device auto-update contract |
| 012-mentra-cli-v2 | Draft | new @mentra/cli shape, short commands, CLI login, developer signing key, dev attestation, publish flow |
| 013-console2 | Draft | new developer console product boundary, WorkOS direction, screens, Console2 data ownership and CLI authorization |
| 014-enterprise-portal | Draft | separate enterprise/OEM portal with EnterpriseOrg, EnterpriseMembership, and standards-aligned TrustedIssuer model |
| 015-internal-admin | Draft | internal admin site and admin CLI for reviews, incidents, preinstalled registry, admin audit logs |
| 016-miniapp-signing-and-dev-attestation | In progress | PRD and implementation issue for @mentra/cli developer signing keys, signed release metadata, and signed dev attestations for miniapp auto-auth |
| 019-incident-reporting-migration | Implemented / partial | initial Cloud V2 core + cloud-client + engine filing path is built. Left: durable attachment storage service, admin retrieval, runtime/cloud-log enrichment, and v1 mobile cleanup |
| 020-glasses-status-boundary | Implemented | removed host access to raw glasses/gallery runtime stores and replaced it with typed engine read models, events, and commands |
| 022-support-profiles | Implemented | authenticated mobile support snapshots, admin lookup, and best-effort low-volume PostHog transition capture |
- Runtime auth split: should runtime-only cloud-client construction omit
cloud.core, expose a disabled module, or use a separate RuntimeClient? Recently decided: audio subscription transport (Option 2a, REST + stream control entry, see002-cloud-runtime/audio/wire.md);mentraUserId=users._id; the Mentra-as-OEM core-token migration bridge.
- Review and lock
002-cloud-runtime/protocol.md(now includes REST subscriptions, UDP encryption, the corrected frame), then add the shared zod types in@mentra/cloud-runtime/protocol. - Spec the
004-cloud-clientruntime module (the client end of the protocol). - Review and split the new cross-product drafts (
011through015) into build tasks: storage-service, miniapp-service, CLI, Console2, Portal, Admin. - Promote
local-sdkfrom spike to spec.