remove preact and create setup wizard

.project/adrs/adr-001-tech-stack.md

@@ -1,53 +1,54 @@
-# ADR-001: Go Backend with Preact Frontend
+# ADR-001: Go Server with Embedded Web Assets
 
 ## Status
 Accepted
 
 ## Context
-We need to choose a backend language/framework and frontend technology for a documentation platform with these requirements:
-- Ultra-fast performance
-- Minimal external dependencies
-- No vendor lock-in
-- Battle-tested security
-- Server-side rendering for non-interactive pages
-- Offline-capable web client
+We need a documentation platform with fast page delivery, minimal external
+dependencies, secure server-side rendering, and a straightforward deployment
+artifact.
 
 ## Decision
-**Backend**: Go 1.22+ with standard library plus minimal, well-audited packages  
-**Frontend**: Preact 10 with TypeScript, Vite build system
+Use Go 1.24+ with the standard library plus minimal, audited packages. The Go
+binary serves HTML templates and embeds its CSS, images, and small browser
+scripts. There is no separate SPA, Node dependency tree, or frontend build
+pipeline.
+
+Browser scripts progressively add editing, offline caching, WebSocket updates,
+comments, and authentication interactions to server-rendered pages.
 
 ## Consequences
 
 ### Positive
-- Go's standard library is comprehensive and security-audited
-- Single static binary deployment — no runtime dependencies
-- Preact is 10KB (vs 40KB+ React) with identical API
-- Go's `html/template` provides safe SSR with auto-escaping
-- TypeScript gives type safety without runtime overhead
-- Both ecosystems have excellent supply-chain security (Go modules with checksums, npm audit)
+- One application binary and one build toolchain
+- Go `html/template` provides auto-escaped server rendering
+- Embedded assets deploy with the server binary
+- Fewer supply-chain dependencies and fewer moving parts in CI
+- Pages remain readable before browser scripts execute
 
 ### Negative
-- Go template syntax is less expressive than JSX
-- WebSocket sync logic must be implemented manually (no framework like Socket.io)
-- Preact ecosystem smaller than React (mitigated by using mostly native APIs)
+- Template syntax is less expressive than JSX
+- Browser behavior uses small framework-free modules
+- WebSocket and offline behavior must be maintained directly
 
 ## Alternatives Considered
 
+### Separate Preact SPA
+- **Pros**: Component model, client-side routing, TypeScript ecosystem
+- **Cons**: Adds Node tooling, package dependencies, a second build pipeline,
+  and duplicate UI surfaces
+- **Rejected**: The Go-served UI already covers the application surface
+
 ### Rust + Axum
 - **Pros**: Memory safety guarantees, excellent performance
-- **Cons**: Longer compile times, smaller talent pool, steeper learning curve for team
-- **Rejected**: Go's pragmatic balance of safety and velocity better fits project timeline
-
-### Deno Fresh
-- **Pros**: Island architecture, native TypeScript, no build step
-- **Cons**: Newer ecosystem, fewer audited libraries, Deno runtime less battle-tested than Go
-- **Rejected**: Go's maturity and deployment simplicity preferred
+- **Cons**: Longer compile times and steeper learning curve
+- **Rejected**: Go better fits the project deployment model
 
 ### Next.js / React Server Components
 - **Pros**: Mature ecosystem, built-in SSR
-- **Cons**: Heavy bundle size, complex build system, RSC lock-in, many dependencies
-- **Rejected**: Violates "minimal dependencies" and "no vendor lock-in" principles
+- **Cons**: Heavy build system and more runtime complexity
+- **Rejected**: Violates the minimal dependency goal
 
 ## References
 - Go Security Policy: https://go.dev/security
-- Preact Size Comparison: https://bundlephobia.com/package/preact@10.19.3
+- Go `html/template`: https://pkg.go.dev/html/template