> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hashgrid.net/llms.txt
> Use this file to discover all available pages before exploring further.

# ROADMAP

# UniFi MCP Server — Roadmap

This roadmap is synchronized with `DEVELOPMENT_PLAN.md` and reflects the current architectural evolution plan.

## Posture

* Phase 3: Protect API integration
* Phase 4: testing, polish, minor gaps, and developer experience (in progress — includes API-spec alignment to Network v10.6.106 / Protect v7.3.68)
* Phase 5: enterprise scale and operational excellence
* Phase 5a: Protect v7 expansion (39 new operations: arm profiles/alarm control, sirens, speakers, fobs, relays, bridges, link stations, alarm hubs, users, POS ingestion)
* Phase 6: new API domains — Mobility v1.0.0, InnerSpace v1.3.23, Carrier Fabric v1.0.0
* Phase 7: deployment automation (done) — Ansible playbook for Docker hosts (single or clustered), Helm chart for Kubernetes, and agent setup prompts for server-only, single-server fleet and clustered installs
* Phase 8 (active, revision basis `311fce7`, reconciled 2026-11-08): Network 11 live-controller N1–N4 and endpoint discovery remain open. `DEVELOPMENT_PLAN.md` §4.9 adds the eight PDF/dashboard gap categories without renumbering the existing phases; SD-WAN config/status reads already exist and are undergoing official-path/model repair, while policy parity remains open. Classic standalone target support is not established by the rival's claimed direct mode.
* Phase 5+ follow-on: Access expansion — **blocked** (no official Access spec published as of 2026-10-27)

## How to use this roadmap

### Objective

Keep planning, implementation, and documentation synchronized so phase claims stay tied to the actual repository state.

### Prerequisites

* You have read `SPEC.md` and `DEVELOPMENT_PLAN.md`.
* You know whether you are planning new work, verifying progress, or reconciling drift.

### Procedure

1. Start with the current phase and read its exit criteria.
2. Check the corresponding runbook or support doc before making a change.
3. Use the deliverables list to determine whether a change belongs in code, docs, tests, or release workflow.
4. If a phase is complete, update the version roadmap and any adjacent references together.
5. If a phase is not complete, keep the language explicitly aspirational.

### Verification

* Phase labels match the live repo state.
* Deliverables and exit criteria are consistent with the detailed plan.
* No doc describes future work as shipped work.

### Rollback

* If roadmap text drifts from reality, revert the text first, then re-baseline against the code.

### Common failure modes

* Updating the roadmap in isolation while the development plan still disagrees.
* Promoting a deliverable to complete before the implementation and tests exist.
* Leaving phase labels ambiguous enough that operators cannot tell what is actually ready.

## Phase 3: Protect API integration

Goal: deliver native Protect coverage on top of the existing Network and Site Manager foundations.

### Deliverables

* `src/api/protect_client.py`
* Protect models under `src/models/protect_*.py`
* Tool modules for cameras, devices, NVR, views, and events
* Protect MCP resources for cameras and events
* Integration tests with mocked NVR responses
* Protect documentation updates in `API.md` and `docs/UNIFI_API.md`

### Exit criteria

* Protect tools match the documented endpoint surface
* Tests cover the new models and response shapes
* Docs distinguish implemented Protect support from future Access work

***

## Phase 4: Testing, polish, minor gaps, and developer experience

Goal: harden the server, close the remaining small gaps, and add AI-friendly operational assets.

### Deliverables

* Dynamic DNS full CRUD
* Tagged MAC management
* Device migration tools
* `NETWORK_PLAYBOOK.md`
* `skills/` domain knowledge packs
* `Makefile`, `docker-compose.yml`, and `HARBOR_SETUP.md`
* release and documentation synchronization

### Exit criteria

* Coverage target reached and stable
* Developer workflow is standardized
* Docs reflect the implemented feature set

***

## Phase 5: Enterprise scale and operational excellence

Goal: turn the server into a multi-site, multi-team operating platform with strong safety and observability controls.

### Deliverables

* Multi-controller / multi-site orchestration
* Dry-run / change-safe mode
* Tool-level RBAC via API key scopes
* Append-only audit log
* Prometheus metrics endpoint
* A2A agent card and manifest
* Webhook event bus with Redis pub/sub
* Tool exposure profiles for network, protect, access, talk, drive, and read-only sessions — partial (read-only and protect done)
* Protect v7 expansion — open (queued as Phase 5a per 2026-09-26 spec audit; 39 new operations)
* Access API implementation — open (blocked: no official spec exists as of 2026-09-26)

### Exit criteria

* Multi-controller routing is isolated and testable
* Write operations are previewable, auditable, and scoped
* Server observability is first-class
* Named tool exposure modes keep per-session tool lists small and task-relevant
* Access domain is mapped and scheduled into implementation

***

## Version roadmap

| Version | Scope | Notes |
| - | - | - |
| v0.2.5 | Earlier release | Baseline release artifact |
| v0.3.0 | Phases 0–2 completion | Docs sync, Network refs, connector foundation |
| v0.4.0 | Phase 3 | Protect API integration (folded into v0.5.0 — never tagged) |
| v0.5.0 | Phases 3+4+5a+6 | Tagged 2026-09-28, never published (its contents ship in v0.6.0): 343 tools/60 modules, spec alignment v10.6.106/v7.3.68, Protect v7 expansion, Mobility/InnerSpace/Carrier Fabric, transport auth hardening |
| v0.6.0 | Fleet Phases 0–5 + Phase 7 | Released 2026-10-12: multi-controller fleet stack, SIEM export and audit retention, Ansible playbook, Helm chart and `-fleet` images, agent setup prompts (the release page has no assets; see v0.6.1) |
| v0.6.1 | Patch | Released 2026-10-14: release assets (wheel, sdist, SBOM) and the Supermemory v5 client |
| v0.7.0 | Phase 8 code/doc halves + ops increments | Released 2026-10-29: N3 `statistics_note` in the stats tool output (breaking return-shape change on three list tools), N1 doc steering plus the 10.6.109 live baseline and early N1 answer (`.analysis-reports/live-controller-10.6-baseline-2026-10-29/`), N6 USG gating in `fleet_health`, native MCP prompts, live A2A capabilities, Redis webhook event bus, `UNIFI_MIXED_MODE`, local-build deployment paths, playbook converge test |
| v1.0.0 | Phase 5 | Enterprise scale and operational excellence |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.