bootstrap: README + CLAUDE.md (data backbone for personal self-management)

Multiple interfaces, project codes, first-class non-code projects, Otto as consumer not owner. Inventor pass next.

CLAUDE.md

@@ -0,0 +1,73 @@
+# projax — Project Instructions
+
+## Purpose
+
+Data backbone for m's complete self-management — projects (digital + physical + strategic + life themes), tasks, lifecycle, milestones. Multiple interfaces consume it. No interface is canonical; each is a view.
+
+**Memory group_id:** `projax`
+
+## Architecture principles
+
+1. **Model first, interfaces second.** The data model is the asset; UIs are replaceable.
+2. **Project Code is the lingua franca.** Every project gets a concise, human-readable code (TBD format) and that code surfaces in every interface, every notification, every task title.
+3. **First-class non-code projects.** Greenhouse construction, household chores, career positioning, sport goals — same model as code projects.
+4. **No CLI required.** m has explicitly opted out of CLI-first. Interfaces are visual / API / Otto-mediated.
+5. **Subsumes existing scattered state.** mai.projects, Gitea issues, CalDAV tasks, mBrian topics, Dokploy services. Migration not greenfield isolation.
+6. **Otto is a consumer, not an owner.** Otto-PWA renders projax data; otto coordinates work *based on* projax; otto does not *define* projax.
+
+## Open design questions (Phase 1)
+
+The inventor's first deliverable. Don't pre-decide:
+
+- **Storage**: own Postgres schema? SQLite? msupabase `projax` schema? Reuse mai schema?
+- **Project Code generation**: shortcode pattern (3-5 char?), collision strategy, retroactive assignment to 30+ existing projects
+- **Schema**: project, task, milestone, owner, stakeholder, lifecycle-state, type (code/physical/strategic/life), parent/child for sub-projects, tags, links
+- **Lifecycle states**: idea → spec → active → paused → done → archived. Plus blocked-by, waiting-for-input, on-hold.
+- **API shape**: REST? GraphQL? Direct DB? mai-MCP-style?
+- **Interface integrations**:
+  - Otto-PWA (read + edit)
+  - Browser UI (full editor)
+  - Excalidraw view (visual roadmap, dependencies graph)
+  - CalDAV tasks (bidirectional sync? one-way mirror? read-only ingest?)
+  - Gitea issues (sync via webhook? read-only ingest?)
+  - mBrian topic-hubs (link/back-link integration)
+- **Migration**: 28 active mai.projects + ~15 test rows + 4 archived/sleeping
+- **Project Tracking gaps surfaced by otto inventory** (2026-05-15):
+  - mai.projects is verschmutzt with test rows
+  - projects.yaml symlink is dead
+  - no cross-project status view exists
+  - mBrian topic-hubs cover only ~8/30 projects
+
+## Tech stack
+
+TBD by inventor. Constraints:
+- m's preferred: Go for backends, single-binary deploys, SQLite or Postgres on msupabase, no build-step for frontends if avoidable
+- Must work with existing m's infra (Tailscale-only network, Dokploy for hosting if web-side, mai/CLAUDE.md conventions)
+
+## Branch strategy
+
+- `main` = production-deployable
+- `feat/*` / `fix/*` — short-lived
+- No `dev` branch initially (small project)
+- `--no-ff` merges to main
+
+## Worker preferences
+
+- **First shift = inventor** (design pass): produce `docs/design.md` answering the open questions, propose Project Code format, sketch schema + lifecycle + interface contracts, plan migration from `mai.projects` + sibling sources.
+- **Second shift = coder** (after m's go): bootstrap repo skeleton, schema migrations, minimal API + first interface (probably the simplest one — Otto-PWA read-view or browser CRUD).
+- **Gated transitions**: inventor reports design-ready, m approves, head flips to coder. No auto-flip.
+- Model: Sonnet for both shifts — structure-heavy work.
+
+## Out of scope
+
+- Multi-user
+- Mobile-first / responsive (desktop browser + Otto-PWA cover)
+- Public exposure
+- Generic SaaS-product instincts
+
+## Refs
+
+- otto session 2026-05-15 — inventory of where project data lives today, justifying this project's existence
+- `mai.projects` schema (msupabase) — primary current state
+- mBrian conventions (topic-hub pattern) — relevant for non-code project tracking
+- `~/.claude/CLAUDE.md` § Git Strategy, Channel Routing, Memory Protocol

README.md

@@ -1,3 +1,41 @@
 # projax
 
-m's personal project + self-management system. Data backbone with multiple interfaces (Otto-PWA, web UI, Excalidraw views, CalDAV tasks).
+m's personal project + self-management system. The data backbone for everything m tracks — code projects, physical projects, strategic threads, life themes, daily ops. Multiple interfaces consume the same model. Otto is one of them, not the owner.
+
+## Status
+
+Bootstrap. Inventor designs schema + lifecycle + interface contracts before any code lands.
+
+## Vision
+
+- **Single source of truth** for what m is doing, has done, will do, is sitting on, is procrastinating about.
+- **Multiple interfaces** (none is canonical): Otto-PWA, browser UI, Excalidraw views, CalDAV task lists, CLI is *not* a requirement (m explicitly opted out).
+- **Project Code** as the lingua franca — concise, human-readable, ambiguity-free across all interfaces.
+- **Subsumes today's scattered state**: `mai.projects`, Gitea issues, CalDAV tasks, mBrian topic-hubs, Dokploy services, ~/dev/CLAUDE.md files. Migration over time.
+- **Goes beyond code**: physical projects (mGreen greenhouse, household), strategic threads (career positioning), life themes (sport goals, learning) — all first-class.
+
+## Out of scope (for now)
+
+- Replacing mai.projects-the-table. projax will likely *own* it instead, or sync, or supersede gradually — design pass decides.
+- Multi-user. m only.
+- Public exposure / sharing. Local-first, runs on m's infra.
+- Becoming a generic project-management product. Built for m's stack and tone.
+
+## Architecture (TBD by inventor)
+
+Open questions for the first design pass:
+
+- Schema shape: relational (Postgres? SQLite?) vs graph (mBrian-style) vs hybrid
+- Project Code generation: shortcode pattern, collision rules, retro-fitting to existing 30+ projects
+- Lifecycle states + transitions (idea → active → paused → done → archived?)
+- How interfaces share the model — REST API? GraphQL? direct DB read?
+- Where the data lives: msupabase schema? Own DB? mBrian sub-graph?
+- Integration shape with: mai.* (tasks, workers, sessions), Gitea, CalDAV, mBrian, Otto-PWA, Excalidraw
+- Migration: 28 active mai.projects + ~15 test rows + 4 archived — how to clean up and import
+
+## Refs
+
+- mai.projects current state: msupabase `mai.projects` table
+- otto's project inventory walk-through (head session 2026-05-15)
+- mBrian topic-hubs (paliad, hlckm, tech-msbls, ai, professional-positioning, schadensberechnung-lizenzanalogie, flexsiebels-brand)
+- CalDAV calendars on `dav.msbls.de`: work, plan, privat, mhome, mcalendar, logm, people