Scaffold project skeleton with DESIGN.md and supporting docs

DECISIONS.md

@@ -0,0 +1,74 @@
+# Design Decisions
+
+This file records architectural choices and the alternatives considered.
+New entries are added when a design decision is resolved (not when options
+are brainstormed). Unresolved questions live in DESIGN.md §10.
+
+---
+
+## Why Mattermost Plugin vs Bot Account
+
+**Context:** AI assistants in Mattermost can be implemented as plugins
+(running inside the Mattermost server process) or as bot accounts
+(independent services using the REST API and WebSocket).
+
+**Alternatives considered:**
+1. **Plugin** — hooks into slash commands, message hooks, KV store, System
+   Console config UI, and the plugin lifecycle. No separate process to
+   manage. Deployment is a single `.tar.gz` upload.
+2. **Bot account** — separate service, more language freedom, but requires
+   managing OAuth tokens, WebSocket reconnection, a separate process with
+   its own lifecycle, and the bot account itself in Mattermost.
+
+**Outcome:** Plugin chosen for v0.1.0 because:
+- Single deployment artifact
+- Built-in config UI via System Console
+- No bot account to create and maintain
+- KV store for persistence without a database
+- Simpler for the target audience (self-hosted teams)
+
+**Trade-off:** Plugin runs inside the Mattermost process — bugs can affect
+server stability. Mitigated by standard isolation practices (panic recovery,
+goroutine lifecycle management).
+
+---
+
+## Why Ollama
+
+**Context:** Backend LLM provider for the plugin.
+
+**Alternatives considered:**
+1. **Ollama** — Single binary, simple REST API, streaming, model management,
+   self-hosted (data never leaves the infrastructure). Community Edition
+   friendly.
+2. **OpenAI / Anthropic API** — SaaS, API key required, data leaves the
+   network, ongoing API costs. Not aligned with self-hosted Mattermost
+   ethos.
+3. **Local inference (llama.cpp, etc.)** — More complex to set up and
+   manage. Ollama wraps this with a clean API.
+
+**Outcome:** Ollama. It matches the self-hosted, no-data-leaves paradigm of
+Mattermost Community Edition and provides the simplest API surface for a
+plugin to consume.
+
+---
+
+## Why Per-Channel Per-User Context (Proposed)
+
+**Context:** When a user sends `/ai <prompt>`, should the plugin remember
+previous exchanges?
+
+**Alternatives considered:**
+1. **Per-user global** — Context follows the user across channels. Simple
+   but confusing: context from a #general question leaks into #dev.
+2. **Per-channel per-user** — Each user gets separate context in each
+   channel. Natural mapping: different channels are different topics.
+3. **No context** — Stateless. Simplest but every prompt is isolated;
+   users can't have a conversation.
+
+**Outcome (proposed):** Per-channel per-user. Marked as D2 in DESIGN.md —
+not final until v0.1.0 implementation.
+
+---
+
+*This file follows the template from the `project-docs` skill.*