Add project documentation

Include design system guidelines, Phase 3 roadmap, code quality
review, proposed README, and authentication ADR.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

1 files changed, 35 insertions, 0 deletions

diff --git a/docs/adr/001-authentication-strategy.md b/docs/adr/001-authentication-strategy.md
new file mode 100644
index 0000000..e3610f3
--- /dev/null
+++ b/docs/adr/001-authentication-strategy.md
@@ -0,0 +1,35 @@
+# ADR 001: Authentication Strategy
+
+## Status
+Accepted
+
+## Context
+The application is being prepared for deployment to a public server. Currently, it has no authentication mechanism. We need to secure the application to prevent unauthorized access to personal task data (Todoist, Trello, etc.).
+
+## Decision
+We will implement **Session-Based Authentication** using server-side sessions stored in SQLite.
+
+### Technical Details:
+1.  **Session Management:** Use `alexedwards/scs` (v2) for session management.
+    *   It provides a robust, secure implementation of session cookies.
+    *   It supports SQLite as a backing store, simplifying infrastructure (no Redis needed).
+2.  **User Storage:** Create a `users` table in the existing SQLite database.
+    *   Columns: `id`, `username`, `password_hash`, `created_at`.
+3.  **Password Hashing:** Use `bcrypt` (via `golang.org/x/crypto/bcrypt`) for hashing passwords.
+4.  **Middleware:** Implement a middleware function to protect routes.
+    *   Public routes: `/login`, `/static/*`.
+    *   Protected routes: `/`, `/api/*`, etc.
+
+## Consequences
+*   **Pros:**
+    *   Simple architecture (keeps everything in SQLite).
+    *   Standard, well-understood security model.
+    *   `scs` handles cookie security (HttpOnly, Secure, SameSite) automatically.
+*   **Cons:**
+    *   Stateful (sessions in DB), but acceptable for this scale.
+    *   Requires managing a user table and password resets (though we will start with manual user creation).
+
+## Alternatives Considered
+*   **Basic Auth:** Too simple, poor UX (browser popup), hard to log out.
+*   **OAuth (Google/GitHub):** Overkill for a single-user/small-group app initially. Adds external dependencies and configuration complexity.
+*   **JWT (Stateless):** Adds complexity with token revocation and refresh tokens. Session-based is simpler for a server-rendered app.