# Roadmap: ImpTune

## Overview

ImpTune ships in five phases ordered by risk and dependency. The foundation phase validates the highest-risk unknown (.intunewin format) before anything else is built. Driver management comes next because the printer form's driver dropdown depends on parsed INF data. Printer configuration and persistence follow. Script generation builds the PowerShell output that both export formats wrap. Finally, package export assembles all prior work into downloadable deployment artifacts.

## Phases

**Phase Numbering:**
- Integer phases (1, 2, 3): Planned milestone work
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)

Decimal phases appear between their surrounding integers in numeric order.

- [x] **Phase 1: Foundation** - Docker container scaffold, SQLite schema, and .intunewin format spike (completed 2026-04-10)
- [ ] **Phase 2: Driver Management** - Driver ZIP upload, INF parsing, DriverDesc dropdown, volume persistence
- [ ] **Phase 3: Printer Configuration** - Full printer config form, client/tenant labels, SQLite persistence
- [ ] **Phase 4: Script Generation** - PowerShell install/uninstall/detection scripts with all correctness guards
- [ ] **Phase 5: Package Export** - .intunewin and NinjaRMM ZIP export, icon upload, command preview

## Phase Details

### Phase 1: Foundation
**Goal**: A running Docker container with the app scaffold, data schema, and a validated .intunewin generation capability
**Depends on**: Nothing (first phase)
**Requirements**: INFRA-01, INFRA-02
**Success Criteria** (what must be TRUE):
  1. Running `docker compose up` starts the app and serves a response on localhost
  2. The container has no Node.js dependency and starts from a single image
  3. A Python-generated .intunewin file uploads successfully to a real Intune tenant without format errors
  4. SQLite database initializes automatically on first run with the correct schema
**Plans**: 3 plans

Plans:
- [x] 01-01: Docker container scaffold (Dockerfile, python:3.12-slim-bookworm, volume, healthcheck)
- [ ] 01-02: SQLite schema and data models (peewee ORM, driver + printer + client tables)
- [ ] 01-03: .intunewin format spike (AES-256-CBC encrypted ZIP-in-ZIP with detection.xml, validated against real Intune)

### Phase 2: Driver Management
**Goal**: Technicians can upload driver packages and select driver names from parsed INF data — no free-text entry
**Depends on**: Phase 1
**Requirements**: DRV-01, DRV-02, DRV-03, DRV-04, DRV-05
**Success Criteria** (what must be TRUE):
  1. User can upload a ZIP file containing INF + supporting files via the browser
  2. After upload, user sees a dropdown of driver names extracted from the INF (DriverDesc values), not a text field
  3. Uploaded driver packages survive container restarts (persisted to Docker volume)
  4. System flags files in the driver package that are not referenced by the INF, with a count or list
**Plans**: 2 plans

Plans:
- [ ] 02-01-PLAN.md — INF parser with TDD (encoding detection, token resolution, multi-model, unused files)
- [ ] 02-02-PLAN.md — Driver upload endpoint, persistence, drivers page UI with HTMX

### Phase 3: Printer Configuration
**Goal**: Technicians can configure all printer parameters, assign printers to clients, and retrieve saved configs without re-uploading drivers
**Depends on**: Phase 2
**Requirements**: PRNT-01, PRNT-02, PRNT-03, PRNT-04, PRNT-05, PRNT-06, PRNT-07, PRNT-08, PRNT-09, PRNT-10
**Success Criteria** (what must be TRUE):
  1. User can fill in a printer form (name, IP, port, duplex, color/BW, paper size, collate) and save it
  2. Saved printer appears under its client/tenant label after page refresh
  3. System auto-populates the port name field from the entered IP address (user can edit it)
  4. User can open a saved printer config and regenerate its package without uploading the driver again
**Plans**: TBD

Plans:
- [ ] 03-01: Printer config form and CRUD API (all fields, validation, SQLite persistence)
- [ ] 03-02: Client/tenant organization (label assignment, printer list grouped by client)
- [ ] 03-03: Saved config retrieval and regeneration flow

### Phase 4: Script Generation
**Goal**: The system produces correct, production-ready PowerShell scripts that handle all Intune and RMM execution contexts
**Depends on**: Phase 3
**Requirements**: SCRPT-01, SCRPT-02, SCRPT-03, SCRPT-04, SCRPT-05
**Success Criteria** (what must be TRUE):
  1. Generated install script runs successfully on a clean Windows endpoint via Intune (pnputil staging + port + driver + printer + settings)
  2. Generated install script self-elevates via UAC when run interactively by a standard user
  3. Generated install script relaunches in 64-bit PowerShell when Intune's 32-bit process triggers it (WOW64 guard)
  4. Generated uninstall script removes printer, driver, and port cleanly
  5. Generated detection script returns exit 0 when the printer is installed and exit 1 when it is not
**Plans**: TBD

Plans:
- [ ] 04-01: Jinja2 PS install script template (pnputil two-step, SYSTEM vs user detection, WOW64 guard, idempotency)
- [ ] 04-02: Uninstall and detection script templates
- [ ] 04-03: Script generation API endpoint (accepts printer config, returns script content)

### Phase 5: Package Export
**Goal**: Technicians can download a complete, ready-to-deploy package for either Intune or NinjaRMM in one click
**Depends on**: Phase 4
**Requirements**: PKG-01, PKG-02, PKG-03, PKG-04, PKG-05
**Success Criteria** (what must be TRUE):
  1. User can download a .intunewin file that Intune accepts as a Win32 app without errors
  2. User can download a NinjaRMM ZIP containing the install script and driver folder
  3. User can upload a custom PNG icon (256x256, max 750KB) and it is embedded in the .intunewin package
  4. User can preview and copy the Intune install command string and uninstall command string before exporting
**Plans**: TBD

Plans:
- [ ] 05-01: NinjaRMM ZIP builder (script + driver folder, StreamingResponse download)
- [ ] 05-02: .intunewin builder (reuse Phase 1 spike, wire to printer config + drivers + detection script)
- [ ] 05-03: Icon upload and Intune command preview UI

## Progress

**Execution Order:**
Phases execute in numeric order: 1 → 2 → 3 → 4 → 5

| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 1. Foundation | 3/3 | Complete   | 2026-04-10 |
| 2. Driver Management | 1/2 | In Progress|  |
| 3. Printer Configuration | 0/3 | Not started | - |
| 4. Script Generation | 0/3 | Not started | - |
| 5. Package Export | 0/3 | Not started | - |