ImpTune/.planning/phases/01-foundation/01-CONTEXT.md

Phase 1: Foundation - Context

Gathered: 2026-04-10 Status: Ready for planning

## Phase Boundary

A running Docker container with the app scaffold, SQLite data schema, and a validated .intunewin generation capability. This phase delivers the infrastructure skeleton that all subsequent phases build on. No user-facing features beyond the app shell.

## Implementation Decisions

App shell & navigation

• Persistent left sidebar with flat, equal-weight sections: Dashboard, Drivers, Printers, Clients, Packages
• Dashboard is the landing page: quick action buttons at top ("New Printer", "Upload Driver", "Export Package") plus recent printers/packages list below
• System/auto theme — follow OS dark/light preference (two color schemes)

CSS & offline access

• Air-gapped deployment — no CDN access from the server, all assets must be bundled in the Docker image
• Use a lightweight pre-built CSS framework (e.g., Pico CSS) instead of Tailwind — no build step, just a static CSS file
• HTMX and Alpine.js downloaded during Docker image build (ADD/curl), baked into the image as static files
• All JS/CSS served from the container's static files directory — zero external requests at runtime

Database schema

• Full schema created upfront in Phase 1 — all tables for phases 2-5 (drivers, printers, clients, icons)
• Peewee ORM for all database operations — matches SQLite single-writer model
• Schema auto-created on first run via Peewee's create_tables()

Driver storage

• SHA256 content-addressed storage for driver files on the Docker volume
• Deduplication: same file uploaded twice results in one copy on disk
• SQLite stores the hash reference + original filename + metadata; filesystem stores the actual files

Claude's Discretion

• Specific lightweight CSS framework selection (Pico CSS, Simple.css, or similar)
• Dashboard layout details and empty state design
• Exact color scheme for light and dark themes
• Project directory structure (guided by ARCHITECTURE.md research)
• .intunewin spike implementation details

## Specific Ideas

• Sidebar sections ordered as flat equals, not by workflow hierarchy — Dashboard is just another section, not a special landing
• Dashboard should get technicians moving immediately — quick actions are the primary UI element, recent activity is secondary
• The app runs on private MSP networks that may have no internet access at all — everything must work fully offline after the Docker image is built

<code_context>

Existing Code Insights

Reusable Assets

• None — greenfield project, no existing code

Established Patterns

• None yet — Phase 1 establishes all patterns

Integration Points

• ARCHITECTURE.md proposes the project structure: api/, services/, generators/, templates/, db/, storage/
• STACK.md defines all dependencies and version constraints
• .intunewin format documented in STACK.md (inner ZIP + AES-256-CBC encryption + Detection.xml + outer ZIP)

</code_context>

## Deferred Ideas

None — discussion stayed within phase scope

---

Phase: 01-foundation Context gathered: 2026-04-10