# Phase 1: Foundation - Context

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

<domain>
## 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.

</domain>

<decisions>
## 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

</decisions>

<specifics>
## 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

</specifics>

<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>
## Deferred Ideas

None — discussion stayed within phase scope

</deferred>

---

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