mAi
9f905de461
cmd/projax/main.go boots a pgxpool against PROJAX_DB_URL (falls back to
SUPABASE_DATABASE_URL), auto-applies embedded migrations on start
(disable with PROJAX_AUTO_MIGRATE=off), and serves on PROJAX_LISTEN_ADDR
(default :8080).
store package wraps the unified view + projax.items writes. Item has
helper methods for templates: IsArea, Editable, SourceRefDeref. The
Promote() flow runs the insert + item_links link inside a single
transaction so the source row drops out of items_unified atomically.
web package: per-page html/template instances parsed against a shared
layout.tmpl, embedded static/style.css, HTMX from CDN. Pages:
GET / tree of items_unified
GET /i/{path} detail (editable for projax, read-only +
promote form for mai.projects)
POST /i/{path} update projax-native item
POST /i/{path}/promote one-page promote (HTMX-aware fragment for
inline classify)
GET /new?parent={path} create form
POST /new create projax-native item
GET /admin/classify orphan list with inline HTMX promote
GET /healthz DB ping
GET /static/* embedded assets
Auth is intentionally out of scope for v1 — service binds to whatever
PROJAX_LISTEN_ADDR points at, deploy guidance pins it to the Tailscale
interface (covered in 1d README).
Tests (skip when DB env is unset):
TestTreeRenders, TestHealthz,
TestDetailProjaxNativeEditable, TestDetailMaiProjectsReadOnly,
TestClassifyListsOrphans, TestPromoteRoundTrip.
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