Commit initial

This commit is contained in:
2026-04-15 17:57:12 +02:00
parent 005d8e797e
commit 55516ee10f
269 changed files with 26854 additions and 0 deletions
@@ -0,0 +1,81 @@
# 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*