Device Management — Roadmap Index

:::info Status Pointer page — docs/device-management-module-architecture.md is pure architecture (domain model, data model, lifecycle, authorization, threat model); it has no distinct phasing/roadmap section of its own. :::

The device-management architecture doc's own §2 "Current state" table (the original gap analysis) is what motivated the two roadmaps below — at the time it was written, stream authorization had no mount-level auth, push tokens were one-per-user, and there was no first-class inventory entity. Read Device Management module for the architecture those gaps were closed against.

The actual sequenced work lives in two places:

Roadmap	Covers	Status
Stream Player / User Device	The bulk of the gap-closing work: inventory, unified authorization, per-install push, playback entitlement, stream-player hardware	Backend/API implementation largely complete per the execution log; production enforcement flips (FANOUT_V2, STREAM_AUTHZ_ENFORCE) still staged — see below
Device Registry Unification	Folding the legacy transmitter provisioning path (mosque_devices.py) into the unified device_registry/device_claim path so transmitters and stream players share one authorization model	Done

For device sales billing specifically, see Device Sales Invoices.

Where "current status" actually lives

None of the roadmap/jira documents in this repository are living status trackers — they're plans and execution logs frozen at the point they were last edited. For the operational rollout state of the two flags this work introduced (FANOUT_V2 recipient fan-out, STREAM_AUTHZ_ENFORCE stream gate), see Backend Deployment — that page reflects DEPLOY.md, which is closer to current operational truth than the implementation-plan documents this roadmap section condenses.