scaffold: OpenScribe open-source self-hosted AI voice recorder

Bootstrap of the project (M0). Sets up the monorepo, design docs, hardware BOM,
the open API contract, component skeletons, licensing and CI, following the
Default Workflow SOP.

What changed:
- CLAUDE.md + docs/: copied the Default Workflow so sessions load the SOP.
- state/: PROJECT, ARCHITECTURE, DECISIONS, TODO, NOTES filled in for OpenScribe.
  ARCHITECTURE captures the four-part design (firmware, server, app, case) and the
  three sync paths; DECISIONS records the hardware, AI-stack, storage, app and
  licensing choices; TODO lays out milestones M1-M9.
- hardware/BOM.md: two build options (compact XIAO ESP32-S3 Sense; dev ESP32-S3 +
  I2S mic + SD), wiring/pinout, indicative cost.
- api/openapi.yaml: the completely open API (device + server surfaces), including
  recording list/download/delete and exports (wav/ogg/txt/srt/vtt/md/json).
- firmware/: PlatformIO ESP32-S3 project, two board profiles, pin map, boot scaffold
  with module seams for M1-M4.
- server/: FastAPI skeleton mirroring the OpenAPI, config for self-hosted MinIO,
  faster-whisper and Ollama; stub routes browsable at /docs.
- app/, case/: Flutter app plan; parametric OpenSCAD enclosure.
- Licensing: GPL-3.0 (code), CERN-OHL-S-2.0 (hardware), CC-BY-SA-4.0 (case/docs),
  REUSE-style LICENSES/ with SPDX headers; LICENSING.md explains the split.
- CI: Forgejo Actions workflow builds firmware (both profiles) and lints/imports server.

Why:
- Everything self-hosted and openly licensed per the user's requirements: an open
  API, three sync paths (BLE control, WiFi transfer, independent WiFi upload on
  charge to generic cloud storage), and a full self-hosted transcription+summary stack.

Notes:
- No custom PCB in v1; off-the-shelf modules. Physical verification waits on parts.
- Component code is stubs at M0; features land milestone by milestone, each as its
  own branch/PR per the workflow.

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

docs/documentation-policy.md

@@ -0,0 +1,54 @@
+# Documentation policy
+
+Two separate ideas, both about making the repo the single source of truth so that no
+session ever depends on another session's chat history.
+
+## A. State lives in committed markdown, not in the chat
+
+Do not use chat history, context, or cache as memory. They cost tokens to carry and
+vanish between sessions. Instead, everything a future session needs is written to the
+`state/` directory and committed:
+
+| File | Holds |
+|------|-------|
+| `PROJECT.md` | Objectives, scope, description, audience. The anchor. |
+| `ARCHITECTURE.md` | How the system is built and why it is built that way. |
+| `DECISIONS.md` | A dated log of decisions and their rationale. Append, never rewrite history. |
+| `TODO.md` | Done / in progress / pending. The current state of play. |
+| `NOTES.md` | Working notes, gotchas, environment quirks, dead ends to avoid. |
+
+Update these as part of the work, not as an afterthought. A change to how the system
+works is not finished until `ARCHITECTURE.md` or `DECISIONS.md` reflects it.
+
+Templates for all of these are in `templates/`.
+
+## B. Documentation is written in a separate session from the code
+
+The user facing documentation (README, guides, API docs, changelog) is **not** written
+in the same session that writes the code. This is deliberate:
+
+- It forces the building session to leave a complete trail. If the code cannot be
+  documented later from git history and comments alone, the trail was not good enough.
+- It keeps each session cheap and focused. A building session spends its budget
+  building; a documentation session spends its budget writing docs.
+- It gives the docs a cold, independent reader who documents what the code actually
+  says, not what the author remembers intending.
+
+### What the building session must leave behind
+
+So the later documentation session can work with no chat history:
+
+1. **Commit messages with full notes** - what changed, why, and any trade-offs. See
+   [Workflow](workflow.md).
+2. **A complete PR description** - feature, tools used, what was achieved, how it works.
+3. **Code comments that explain intent** - not what a line does (the code shows that)
+   but why it exists, what it assumes, and what would break it. Comment for a stranger
+   who was not in the room.
+4. **Current `state/` files** - especially `ARCHITECTURE.md` and `DECISIONS.md`.
+
+### What the documentation session does
+
+Starts cold. Reads `git log`, the PRs, the code and its comments, and the `state/`
+files. Writes the documentation from those alone. If something cannot be understood
+from the repo, that is a gap to flag, not a reason to guess or to reach for lost chat
+context.