MVP Implementation Plan¶

1. Executive Summary¶

This document is the single authoritative implementation plan for Lablet Cloud Manager MVP. It is derived from the Codebase Discovery Audit.

Critical Insight: Foundation First¶

Worker Capacity → Resource Scheduling → Auto-Scaling → LDS → Frontend → Session Entity Model → Grading

Current State Analysis¶

MVP Scope¶

Deferred (Post-MVP)¶

Timeline Summary¶

Phase 0: Domain Prerequisites    ████████████████████  ✅ COMPLETE (2026-02-08)
Phase 1: Worker Foundation       ████████████████████  ✅ COMPLETE (2026-02-09)
Phase 2: Resource Scheduling     ████████████████████  ✅ COMPLETE (2026-02-10)
Phase 3: Auto-Scaling            ████████████████████  ✅ COMPLETE (2026-02-08)
Phase 4: LDS Integration         ████████████████████  ✅ COMPLETE (2026-02-10)
Phase 6: SSE & Frontend          █████████████████░░░  🔄 ~85% (G1+G3+G4+G5+F1+F2+F3+F8 done)
Phase 7: Session Entity Model    ████████████████████  ✅ COMPLETE (2026-02-20)
Phase 5: Grading Integration     ░░░░░░░░░░░░░░░░░░░░  ⬜ Blocked by Phase 7 → Ready to start
                                 ─────────────────────
                                 Execution order: 0→1→2→3→4→6→7→5
                                 Phase 7 COMPLETE — Phase 5 unblocked

2. Phase Dependencies¶

flowchart TD
    subgraph P0["Phase 0: Domain Prerequisites ✅"]
        P0A[Add READY state to LabletSessionStatus]
        P0B[Add form_qualified_name to LabletDefinition]
    end

    subgraph P1["Phase 1: Worker Foundation ✅"]
        P1A[Fix allocated_capacity updates]
        P1B[Add UpdateWorkerCapacityCommand]
        P1C[Verify metrics collection flow]
    end

    subgraph P2["Phase 2: Resource Scheduling ✅"]
        P2A[Complete PlacementEngine integration]
        P2B[Capacity validation in ScheduleCommand]
        P2C[Capacity allocation on schedule]
    end

    subgraph P3["Phase 3: Auto-Scaling ✅"]
        P3A[Implement worker provisioning]
        P3B[Scale-up trigger logic]
        P3C[Scale-down trigger logic]
    end

    subgraph P4["Phase 4: LDS Integration ✅"]
        P4A[LDS SPI Client]
        P4B[Session provisioning in LabletReconciler]
        P4C[MarkSessionReady + HandleSessionStarted]
    end

    subgraph P6["Phase 6: SSE & Frontend 🔄"]
        P6A[G1: Fix SSE pipeline ✅]
        P6B[F2: LDS Session Display ✅]
        P6C[F1: Reservation UI ✅]
        P6D[F3: Capacity Dashboard ✅]
        P6E[G4/G5: Test coverage ✅]
    end

    subgraph P7["Phase 7: Session Entity Model ✅"]
        P7A[LabletSession aggregate + LabletSessionStatus enum]
        P7B[UserSession / GradingSession / ScoreReport entities]
        P7C[CQRS commands + queries for child entities]
        P7D[MongoDB repos for 4 new collections]
        P7E[CloudEventIngestor in lablet-controller]
        P7F[GradingSPI adapter skeleton]
        P7G[Data migration + etcd key migration]
    end

    subgraph P5["Phase 5: Grading Integration ⬜"]
        P5A[Collection service]
        P5B[Grading SPI Client integration]
        P5C[CloudEvent handlers for grading.completed/failed]
    end

    P0 --> P1
    P1 --> P2
    P2 --> P3
    P2 --> P4
    P3 --> P4
    P4 --> P6
    P6 --> P7
    P7 --> P5

3. Phase 0: Domain Prerequisites¶

Status: ✅ COMPLETE (2026-02-08) Goal: Prepare domain models for LDS integration (required for Phase 4). Duration: ~1 week Requirements: FR-2.2.1, FR-2.2.5h, FR-2.1.6

3.1 Tasks¶

3.2 Specification: READY State¶

Current State Machine:

PENDING → SCHEDULED → INSTANTIATING → RUNNING → ...

Updated State Machine:

PENDING → SCHEDULED → INSTANTIATING → READY → RUNNING → ...

Transition Table Update:

# domain/enums.py - LABLET_SESSION_VALID_TRANSITIONS
LabletSessionStatus.INSTANTIATING: [
    LabletSessionStatus.READY,       # NEW: LDS provisioned, awaiting user login
    LabletSessionStatus.TERMINATED,
],
LabletSessionStatus.READY: [         # NEW STATE
    LabletSessionStatus.RUNNING,     # User logged in (CloudEvent from LDS)
    LabletSessionStatus.TERMINATED,
],

READY State Semantics:

• CML lab is running on worker
• LDS LabSession is provisioned with device access info
• UserSession entity created with login_url (ADR-021)
• Awaiting user login via LDS portal

3.3 Acceptance Criteria¶

• [x] LabletSessionStatus.READY exists in enum
• [x] Transition INSTANTIATING → READY is valid
• [x] Transition READY → RUNNING is valid
• [x] LabletDefinition.form_qualified_name persists correctly
• [x] LDS session fields persist correctly (Phase 7 migrates to UserSession per ADR-021)
• [x] Domain events emit correctly
• [x] Read models reflect new attributes
• [x] All unit tests pass (210 tests, 21 new)

4. Phase 1: Worker Foundation¶

Status: ✅ COMPLETE (2026-02-09) Goal: Ensure worker capacity is accurately tracked so scheduling can make informed decisions. Duration: ~2 weeks Requirements: FR-2.4.1, FR-2.4.3 Bootstrap: PHASE_1_BOOTSTRAP.md

4.1 Problem Statement¶

The PlacementEngine in resource-scheduler uses declared_capacity and allocated_capacity to filter eligible workers. However:

1. allocated_capacity is never updated when sessions are scheduled
2. ScheduleLabletSessionCommand has a TODO: "Check worker status and capacity"
3. No command exists to update worker capacity when sessions start/stop

This means PlacementEngine sees stale data and may over-allocate workers.

4.2 Tasks¶

4.3 Specification: Capacity Allocation Flow¶

sequenceDiagram
    participant RS as resource-scheduler
    participant CPA as control-plane-api
    participant Worker as CMLWorker Aggregate
    participant etcd as etcd

    RS->>CPA: POST /api/internal/sessions/{id}/schedule (worker_id)
    CPA->>Worker: schedule(session_id, worker_id)
    Worker->>Worker: validate capacity available
    Worker->>Worker: allocate_capacity(requirements)
    Worker-->>CPA: LabletSessionScheduledDomainEvent
    Worker-->>CPA: WorkerCapacityAllocatedDomainEvent
    CPA->>etcd: PUT /workers/{id}/allocated_capacity
    CPA-->>RS: 200 OK {status: SCHEDULED}

AllocateCapacityCommand:

@dataclass
class AllocateCapacityCommand(Command[OperationResult[dict]]):
    """Allocate capacity on a worker for a lablet session."""
    worker_id: str
    session_id: str
    cpu_cores: int
    memory_gb: int
    storage_gb: int
    node_count: int

ReleaseCapacityCommand:

@dataclass
class ReleaseCapacityCommand(Command[OperationResult[dict]]):
    """Release capacity when session terminates."""
    worker_id: str
    session_id: str

4.4 Acceptance Criteria¶

• [x] AllocateCapacityCommand updates allocated_capacity on worker
• [x] ReleaseCapacityCommand decrements allocated_capacity on worker
• [x] ScheduleLabletSessionCommand validates capacity before scheduling
• [x] ScheduleLabletSessionCommand calls AllocateCapacityCommand on success
• [x] Session termination triggers ReleaseCapacityCommand
• [x] Worker capacity changes are published to etcd
• [x] PlacementEngine sees current capacity data (completed in Phase 2)
• [x] Integration tests verify full flow (completed in Phase 2)

5. Phase 2: Resource Scheduling¶

Status: ✅ Complete (2026-02-10) Goal: Resource-scheduler makes accurate placement decisions based on real-time capacity. Duration: ~1.5 weeks Requirements: FR-2.3.2a-e

5.1 Problem Statement¶

The PlacementEngine logic is mostly implemented but:

1. It uses stale capacity data (fixed in Phase 1)
2. The ScheduleLabletSessionCommand doesn't validate capacity
3. No feedback loop exists if scheduling fails

5.2 Tasks¶

5.3 Specification: Enhanced PlacementEngine¶

Current _check_resource_capacity (partial):

def _check_resource_capacity(self, worker: dict, definition: dict) -> bool:
    # Uses declared_capacity - allocated_capacity
    # Problem: allocated_capacity is stale

Enhanced flow:

def schedule(self, instance: dict, definition: dict, workers: list) -> SchedulingDecision:
    # 1. Filter by status (RUNNING only)
    # 2. Filter by license affinity
    # 3. Filter by AMI requirements
    # 4. Filter by REAL-TIME capacity (from etcd or fresh API call)
    # 5. Filter by port availability
    # 6. Score by utilization (bin-packing)
    # 7. Select best or request scale-up

5.4 Acceptance Criteria¶

• [x] PlacementEngine uses real-time capacity data (etcd capacity preferred, API fallback)
• [x] Scheduling fails gracefully with clear error message (rejection_summary tracking)
• [x] Failed scheduling triggers requeue with backoff (base class backoff + max retry escalation at 5 failures → 300s)
• [x] Scale-up decision made when no eligible workers (granular rejection categories: status/license/capacity/ami/ports)
• [x] Scheduling metrics are emitted (OTel: decisions, latency, retries, etcd fetches, scale-ups)
• [x] Integration tests cover all decision paths (41 new tests: 17 PlacementEngine + 24 SchedulerHostedService)

6. Phase 3: Auto-Scaling¶

Status: ✅ COMPLETE (2026-02-08) Goal: Automatically provision/deprovision workers based on demand. Duration: ~2 weeks Requirements: FR-2.5.1a,c,d; FR-2.5.2a-b Bootstrap: PHASE_3_BOOTSTRAP.md (retrospective)

6.1 Problem Statement¶

Currently, worker provisioning is stubbed:

# worker_reconciler.py line ~290
async def _handle_pending(self, worker: CMLWorkerReadModel) -> ReconciliationResult:
    # ...
    # For now, requeue until template system is implemented
    return ReconciliationResult.requeue("Template provisioning not yet implemented")

No automatic scale-up or scale-down exists.

6.2 Tasks¶

6.3 Specification: Scale-Up Flow¶

sequenceDiagram
    participant RS as resource-scheduler
    participant CPA as control-plane-api
    participant WC as worker-controller
    participant EC2 as AWS EC2

    RS->>RS: No eligible workers for session
    RS->>CPA: POST /api/workers/scale-up {template, reason}
    CPA->>CPA: Create CMLWorker (status=PENDING)
    CPA-->>RS: 202 Accepted {worker_id}
    RS->>RS: Requeue session (await worker)

    Note over WC: Reconciliation loop
    WC->>CPA: GET /api/workers?status=PENDING
    WC->>EC2: RunInstances(template config)
    EC2-->>WC: ec2_instance_id, pending
    WC->>CPA: PATCH /api/workers/{id} {status=PROVISIONING, ec2_id}

    Note over WC: Next reconcile cycle
    WC->>EC2: DescribeInstances(ec2_instance_id)
    EC2-->>WC: running, ip_address
    WC->>CPA: PATCH /api/workers/{id} {status=RUNNING, ip}

    Note over RS: Next reconcile cycle
    RS->>CPA: GET /api/workers?status=RUNNING
    RS->>RS: Worker now eligible
    RS->>CPA: POST /api/internal/sessions/{id}/schedule

6.4 Specification: Scale-Down Flow¶

sequenceDiagram
    participant WC as worker-controller
    participant CPA as control-plane-api
    participant EC2 as AWS EC2

    Note over WC: Idle detection
    WC->>CPA: GET /api/workers/{id}
    WC->>WC: Check: no sessions, idle > threshold
    WC->>CPA: POST /api/workers/{id}/drain
    CPA->>CPA: Set status=DRAINING

    Note over WC: Wait for drain complete
    WC->>CPA: GET /api/workers/{id}/sessions
    CPA-->>WC: [] (empty)
    WC->>CPA: POST /api/workers/{id}/stop
    CPA->>CPA: Set desired_status=stopped

    Note over WC: Next reconcile
    WC->>EC2: StopInstances(ec2_instance_id)
    EC2-->>WC: stopping
    WC->>CPA: PATCH /api/workers/{id} {status=STOPPED}

6.5 Acceptance Criteria¶

• [x] Worker provisioning creates real EC2 instances
• [x] Worker template configuration is applied correctly
• [x] Scale-up triggered when no eligible workers for pending session
• [x] Scale-down triggered when worker has no sessions and is idle
• [x] Draining prevents new session scheduling
• [x] Scaling constraints (min/max) are respected
• [x] Scaling decisions are audit-logged (OTel metrics + structured logging)
• [x] Integration tests verify scale-up scenarios (14 tests); scale-down unit-tested (13 tests)

7. Phase 4: LDS Integration¶

Status: ✅ COMPLETE (2026-02-10) Goal: Provision LDS LabSessions for lablet sessions and handle user login events. Duration: ~2 weeks Requirements: FR-2.2.5, FR-2.2.6 Bootstrap: PHASE_4_BOOTSTRAP.md

7.1 Tasks¶

7.2 Specification: LDS Client Interface¶

# lablet-controller/integration/services/lds_spi.py

class LdsSpiClient:
    """LDS (Lab Delivery System) SPI client."""

    async def create_session_with_part(
        self,
        username: str,
        timeslot_start: datetime,
        timeslot_end: datetime,
        form_qualified_name: str,
    ) -> LdsSessionInfo:
        """Create LabSession with a LabSessionPart for the content."""
        ...

    async def set_devices(
        self,
        session_id: str,
        devices: list[DeviceAccessInfo],
    ) -> None:
        """Set device access information for the session."""
        ...

    async def get_session_info(self, session_id: str) -> LdsSessionInfo:
        """Get session details including login_url."""
        ...

    async def archive_session(self, session_id: str) -> None:
        """Archive session (called on TERMINATED)."""
        ...

@dataclass
class DeviceAccessInfo:
    name: str           # Device label from content.xml
    protocol: str       # "ssh", "telnet", "vnc", "web"
    host: str           # Worker IP address
    port: int           # Allocated port
    uri: str            # Connection URI
    username: str       # Device credentials
    password: str       # Device credentials

@dataclass
class LdsSessionInfo:
    session_id: str
    login_url: str
    status: str

7.3 Specification: CloudEvent Ingestion (ADR-022)¶

Per ADR-022, all external CloudEvents are routed to lablet-controller, not control-plane-api. The lablet-controller uses Neuroglia's CloudEventIngestor with @dispatch handlers:

# lablet-controller/application/events/cloud_event_ingestor.py

class LabletCloudEventIngestor(CloudEventIngestor):
    """Receives and dispatches CloudEvents from LDS and GradingEngine."""

    def __init__(self, service_provider, control_plane_client: ControlPlaneApiClient):
        super().__init__(service_provider)
        self._cpa = control_plane_client

    @dispatch(LdsSessionStartedEvent)
    async def on_lds_session_started(self, event: LdsSessionStartedEvent) -> None:
        """Handle LDS session.started — transition READY → RUNNING."""
        await self._cpa.update_user_session_status(event.lablet_session_id, UserSessionStatus.ACTIVE)
        await self._cpa.transition_session(event.lablet_session_id, LabletSessionStatus.RUNNING)

    @dispatch(LdsSessionEndedEvent)
    async def on_lds_session_ended(self, event: LdsSessionEndedEvent) -> None:
        """Handle LDS session.ended — transition RUNNING → COLLECTING, initiate grading."""
        await self._cpa.update_user_session_status(event.lablet_session_id, UserSessionStatus.ENDED)
        await self._cpa.transition_session(event.lablet_session_id, LabletSessionStatus.COLLECTING)
        # Initiate grading via GradingSPI (Phase 7)

    @dispatch(GradingSessionCompletedEvent)
    async def on_grading_completed(self, event: GradingSessionCompletedEvent) -> None:
        """Handle grading.session.completed — create ScoreReport, transition to STOPPING."""
        await self._cpa.create_score_report(event.lablet_session_id, event.score_data)
        await self._cpa.update_grading_session_status(event.lablet_session_id, GradingStatus.SUBMITTED)
        await self._cpa.transition_session(event.lablet_session_id, LabletSessionStatus.STOPPING)

    @dispatch(GradingSessionFailedEvent)
    async def on_grading_failed(self, event: GradingSessionFailedEvent) -> None:
        """Handle grading.session.failed — mark FAULTED."""
        await self._cpa.update_grading_session_status(
            event.lablet_session_id, GradingStatus.FAULTED, error=event.error_message
        )

CloudEvent endpoint registered at POST /api/events on lablet-controller. State mutations are proxied to control-plane-api via internal REST calls (ADR-001).

7.4 Acceptance Criteria¶

• [x] LDS client creates sessions with device access info (636-line LdsSpiClient with multi-region support)
• [x] LabletReconciler provisions LDS session during INSTANTIATING (7-step _provision_lds_session() flow)
• [x] Session transitions to READY after LDS provisioning (atomic MarkSessionReadyCommand via AD-P4-01)
• [x] LDS session info stored on UserSession entity (Phase 7 migration — currently on LabletSession via mark_ready() domain method)
• [x] CloudEvent session.started triggers READY→RUNNING transition (Phase 7 migrates handler to lablet-controller CloudEventIngestor per ADR-022)
• [x] LDS session archived when session reaches TERMINATED (_archive_lds_session() with graceful error handling)
• [x] Integration tests verify flow with mock LDS (57 tests: 44 LDS SPI + 5 mark-ready + 8 session-started)
• [x] Staging validation with live LDS deployment (G3: 12/12 checks passed, bug fix: archive_session() json=None→json={}, Docker config added)

8. Phase 5: Grading Integration¶

Status: ⬜ Blocked by Phase 7 Goal: Collect device configurations and submit for grading via GradingEngine. Duration: ~1.5 weeks Requirements: FR-2.6.1, FR-2.6.2 Dependencies: Phase 7 (Session Entity Model) must be complete first

8.1 Tasks¶

8.2 Specification: Collection Service¶

# lablet-controller/application/services/collection_service.py

class CollectionService:
    """Collects device configurations from CML lab nodes."""

    async def collect_configs(
        self,
        worker_ip: str,
        lab_id: str,
        commands: list[str] | None = None,
    ) -> CollectionResult:
        """Collect running-config from all nodes in the lab."""
        commands = commands or ["show running-config"]

        nodes = await self._cml.get_lab_nodes(worker_ip, lab_id)

        results = []
        for node in nodes:
            node_outputs = []
            for command in commands:
                output = await self._cml.execute_console_command(
                    worker_ip, lab_id, node.id, command
                )
                node_outputs.append(CommandOutput(command=command, output=output))

            results.append(DeviceCollection(name=node.label, outputs=node_outputs))

        return CollectionResult(devices=results, collected_at=datetime.now(UTC))

8.3 Specification: State Flow¶

stateDiagram-v2
    [*] --> RUNNING: User logged in
    RUNNING --> COLLECTING: StartCollectionCommand
    COLLECTING --> GRADING: Collection complete
    GRADING --> STOPPING: Grading complete
    STOPPING --> STOPPED: Resources released
    STOPPED --> TERMINATED: Cleanup complete
    TERMINATED --> [*]

8.4 Acceptance Criteria¶

• [ ] Collection service gathers show running-config from all nodes
• [ ] RUNNING→COLLECTING transition works via command
• [ ] Collection results stored/forwarded to grading engine
• [ ] COLLECTING→GRADING transition after collection complete
• [ ] Grading engine submission works
• [ ] CloudEvent grading.completed triggers score storage
• [ ] GRADING→STOPPING transition after grading complete
• [ ] Integration tests verify full flow

9. Phase 6: SSE, Frontend & Integration Readiness¶

Status: 🔄 In Progress Goal: Fix SSE event pipeline, fill integration gaps, and build the frontend UI to MVP readiness. Duration: ~3–4 weeks Requirements: FR-2.1 (UI), FR-2.2 (lifecycle visibility), FR-2.4 (capacity dashboard), FR-2.6 (grading display)

9.1 Sub-Phase A: SSE & Backend Readiness¶

These tasks address broken or missing backend infrastructure required before frontend work.

9.2 Sub-Phase B: Frontend Implementation¶

These tasks address UI gaps identified in the control-plane-api frontend. The CPA frontend is the primary user interface; worker-controller, lablet-controller, and resource-scheduler UIs remain empty scaffolds.

Existing UI Pages (CPA)¶

Frontend Gap Tasks¶

9.3 Recommended Implementation Order¶

9.3.1  G1: Fix SSE pipeline                          ✅ DONE
9.3.2  F2: LDS Session Display                      ✅ DONE
9.3.3  G3: Phase 4 staging validation (validates F2 + LDS flow)  ✅ DONE
9.3.4  F1: Reservation Management UI                ✅ DONE
9.3.5  F3: Capacity Dashboard                       ✅ DONE
9.3.6  F8: Resource Scheduler UI                     ✅ DONE
9.3.7  G4: Worker Controller tests (+53)             ✅ DONE
9.3.8  G5: Lablet Controller tests (+59)             ✅ DONE
9.3.9  F5–F7, F9: Post-MVP polish (deferred)
9.3.10 F4: Grading Results Display (blocked by Phase 7)

9.4 Acceptance Criteria¶

• [x] SSE events flow end-to-end for all aggregates (workers, lablet sessions, lablet definitions, worker templates)
• [x] SSE initial snapshots sent on connect (workers, lablet sessions, lablet definitions)
• [x] LDS session URL displayed on lablet session cards with "Open Lab" button
• [x] DTO mappers include LDS session info in API responses (migrating to UserSession per ADR-021)
• [ ] Reservation filtering available on LabletsPage
• [ ] Fleet-level capacity overview visible on OverviewPage or dedicated dashboard
• [ ] Worker Controller test coverage ≥80%
• [ ] Lablet Controller test coverage ≥80%
• [x] UI builds successfully (make build-ui exits 0). StateStore registerSlice + reducer-aware dispatch added to lcm_ui core (AD-9). Parcel cache gotcha documented.

10. Phase 7: Session Entity Model Migration¶

Status: ✅ Complete (2026-02-20) Goal: Implement the LabletSession entity model (ADR-020), child entities (ADR-021), CloudEvent ingestion (ADR-022), and GradingSPI skeleton. Duration: ~3–4 weeks Requirements: FR-2.2.1, FR-2.2.2, FR-2.6.1, FR-2.6.2 Dependencies: Phase 6 (frontend stabilization) substantially complete ADRs: ADR-020, ADR-021, ADR-022 📋 Detailed Plan: phase-7-session-migration.md (codebase audit + 12 sub-phases)

Migration Strategy Decisions¶

Sub-Phase Overview¶

Acceptance Criteria (Summary)¶

• [x] Zero LabletInstance / lablet_instance / lablet_lab_binding / lablet_record_run references in Python source (docstring exceptions only)
• [x] MongoDB: lablet_sessions, user_sessions, grading_sessions, score_reports operational
• [x] MongoDB: lablet_instances, lablet_lab_bindings, lablet_record_runs, tasks dropped
• [ ] CloudEvent webhook handles 4 event types via CPA proxy — DEFERRED (AD-P7-06)
• [x] make lint + make test pass for all services (pre-existing failures only)
• [x] make build-ui passes
• [x] All services start and communicate

Full task breakdown, entity schemas, API mappings, and verification checklist: → phase-7-session-migration.md

11. Post-Implementation: Status Document Update¶

Goal: Update IMPLEMENTATION_STATUS.md to reflect actual implementation state. Duration: ~2 days Trigger: After Phase 7 completion

11.1 Tasks¶

12. Mandatory: Documentation Maintenance Per Phase¶

Per-Phase Documentation Checklist¶

Every phase completion MUST include:

Bootstrap Prompt Requirement¶

Every PHASE_N_BOOTSTRAP.md document MUST include a final task:

### P{N}-FINAL: Update Implementation Documentation
- Update `docs/implementation/mvp-implementation-plan.md`:
  - Mark Phase {N} as ✅ COMPLETE with date
  - Check all acceptance criteria
  - Add completion notes (key artifacts, test count, breaking changes)
- Update `docs/implementation/IMPLEMENTATION_STATUS.md`:
  - Update all affected FR rows to reflect actual state
  - Update progress bars
  - Bump document version
- Store completion knowledge via Knowledge Manager
- Create `PHASE_{N+1}_BOOTSTRAP.md` for next phase

13. Risk Register¶

14. Success Metrics¶

Phase Completion Criteria¶

MVP Readiness Checklist¶

• [ ] All phases complete
• [ ] Integration tests pass
• [ ] Staging environment validated
• [ ] IMPLEMENTATION_STATUS.md updated
• [ ] Runbooks created for operations
• [ ] Monitoring dashboards configured
• [ ] Documentation current

15. Revision History¶