tajniak81andClaude Opus 5
b4fb60a8ab
Scaffolds the server module and everything Phase 0 of PLAN.md calls for: a binary that boots, serves its discovery endpoints and nothing else yet. - config: one YAML file plus per-field WARP_* environment overrides, unknown fields rejected, validation that reports every problem at once - logging and metrics: slog, a Prometheus registry, per-route HTTP instrumentation labelled by pattern rather than path - httputil: the Matrix error envelope, error-returning handlers, CORS, request logging, panic recovery, and a router over http.ServeMux - endpoints: /_matrix/client/versions, /.well-known/matrix/client, /.well-known/matrix/server (gated), /healthz, /metrics, and M_UNRECOGNIZED for everything else - storage: driver registry, shared database/sql base, checksummed migration runner, sqlite and postgres drivers, pocketbase stub - settings: server_settings table behind a cached service, so the federation and registration switches change without a restart - federation: the gate that makes federation a runtime mode - cmd/warp: serve, migrate, generate-keys, version - Makefile, golangci-lint v2, GitHub Actions CI (Linux and Windows tests, race on Linux, storage tests against PostgreSQL, lint, boot smoke test), Dockerfile, example config and docs Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Clients
Nothing here yet. The client sub-projects start once the server can do something worth talking to:
| Directory | What | Starts after |
|---|---|---|
ui/ |
shared Vue 3 + Tailwind component library and Matrix store | server Phase 1 |
admin/ |
admin web panel, embedded into the warp binary |
server Phase 1 |
web/ |
web client (Vue SPA) + Go host | server M1 (Phase 4) |
desktop/ |
Wails v3 shell reusing the web frontend | once web has a timeline |
mobile/ |
Flutter app, Android first | server Phase 8 (push) |
See PLAN.md section 8 for the stack decisions behind each one.