docs(16): capture phase context

.planning/phases/16-multi-user-data-model/16-DISCUSSION-LOG.md

@@ -0,0 +1,85 @@
+# Phase 16: Multi-User Data Model - Discussion Log
+
+> **Audit trail only.** Do not use as input to planning, research, or execution agents.
+> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
+
+**Date:** 2026-04-05
+**Phase:** 16-multi-user-data-model
+**Areas discussed:** User ID Representation, Existing Data Migration, Category Uniqueness, Settings Scope, API Key Ownership
+**Mode:** --auto --batch (all decisions auto-selected)
+
+---
+
+## User ID Representation
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| Local users table with integer ID | Thin table mapping Logto sub to auto-increment integer, all FKs use integer | ✓ |
+| Logto sub string directly | Store Logto sub (string UUID) as FK on every entity table | |
+| Mapping table without FK | Store logtoSub on entities, join manually | |
+
+**User's choice:** Local users table with integer ID (auto-selected)
+**Notes:** Integer FKs are more efficient for joins. Thin table auto-creates on first OIDC login.
+
+---
+
+## Existing Data Migration
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| Migration assigns all rows to user ID 1 | Add userId column, set all existing data to first user | ✓ |
+| Prompt for Logto sub during migration | Interactive script asks for the Logto user ID | |
+| Leave data unassigned until claimed | Nullable userId, user claims data on first login | |
+
+**User's choice:** Migration assigns all rows to user ID 1 (auto-selected)
+**Notes:** Single existing user, simplest approach.
+
+---
+
+## Category Uniqueness
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| Composite unique (userId, name) | Each user has independent category namespace | ✓ |
+| Global unique (current) | All users share one category namespace | |
+
+**User's choice:** Composite unique (userId, name) (auto-selected)
+**Notes:** Required by MULTI-03.
+
+---
+
+## Settings Scope
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| Composite PK (userId, key) | Each user has own settings | ✓ |
+| Separate user_settings table | New table for per-user settings | |
+
+**User's choice:** Composite PK (userId, key) (auto-selected)
+**Notes:** Required by MULTI-06. Minimal schema change.
+
+---
+
+## API Key Ownership
+
+| Option | Description | Selected |
+|--------|-------------|----------|
+| userId column on apiKeys | API keys belong to creating user, middleware resolves user scope | ✓ |
+| Shared API keys (no user scope) | API keys grant access to all data | |
+
+**User's choice:** userId column on apiKeys (auto-selected)
+**Notes:** Required by MULTI-05 for MCP tool scoping.
+
+---
+
+## Claude's Discretion
+
+- Migration SQL approach
+- userId scoping helper vs inline where clauses
+- Default category creation strategy
+- Thread resolution cross-user checks
+- Service change ordering
+
+## Deferred Ideas
+
+None — discussion stayed within phase scope