mAi
b8d3418876
- 0001_init.sql: projax.items + projax.item_links tables with indices, partial-unique root slug, updated_at trigger, schema grants to the application role. - 0002_path_trigger.sql: BEFORE-write trigger maintains items.path via recursive parent walk; rejects cycles and structural-rule violations (areas at root, projects not at root). AFTER trigger rewrites descendant paths on slug rename or re-parent. - 0003_seed_areas.sql: dev, sports, home, work, health, finances, social. - db/migrate.go: embed.FS-backed sequential runner. - db/migrate_test.go: integration suite covering idempotency, nest, rename propagation, re-parent propagation, cycle rejection, and structural rules. Skips when no DB env var is set. Also ignores .m/events.log and .m/locks (per-worker scratch).
projax
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.projectstable - 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