projax

m's personal data backbone for self-management — areas of life, projects within them, and aggregated views over tasks that live elsewhere. Subsumes scattered state currently held in mai.projects, CalDAV task lists, Gitea issues, and mBrian topic hubs.

Spec: docs/design.md. Project conventions: CLAUDE.md.

Run locally

export PROJAX_DB_URL=postgres://postgres:<pw>@<msupabase-host>:6789/postgres?sslmode=disable
go run ./cmd/projax

Defaults:

• PROJAX_LISTEN_ADDR=:8080
• PROJAX_AUTO_MIGRATE=on (set to off to skip on-start migration apply)
• SUPABASE_URL + SUPABASE_ANON_KEY enable projax's own /login. Same Supabase backend as the rest of the m/* fleet, but every tool runs its own login page and scopes cookies per-host. Leave both unset for local dev — every request is anonymous.
• DAV_URL + DAV_USER + DAV_PASSWORD enable the CalDAV integration: /admin/caldav discovery, the Tasks section on item detail pages, and the "Create CalDAV list" action. Leave unset to disable (admin page shows a "not configured" notice).

Visit http://localhost:8080/. Routes:

Route	Purpose
GET /	Tree of areas + projects, plus orphan mai.projects
GET /i/{path}	Item detail; editable for projax, read-only for mai
POST /i/{path}	Save edits to a projax-native item
POST /i/{path}/promote	Promote a mai.projects orphan into a projax item
GET /new?parent={path}	Create a new item (area at root, project under parent)
POST /new	Submit
GET /admin/classify	Orphan list with inline HTMX promote
GET /login	Sign-in form (open)
POST /login	Sign-in submit (open)
POST /logout	Clear cookies, redirect to /login
GET /healthz	DB ping (open)
GET /static/style.css	Embedded CSS

Test

DB-backed integration tests are skipped automatically when no PROJAX_DB_URL / SUPABASE_DATABASE_URL is set:

SUPABASE_DATABASE_URL=postgres://... go test ./...

Covers: migration idempotency, path-trigger semantics (nest, rename, re-parent, cycle, structural rules), items_unified source split + promotion hiding, every HTTP handler, and a Promote round-trip.

Deploy (Dokploy on mlake)

0. Manual prerequisite — create the dedicated DB role (run once)

The binary connects as a dedicated projax_admin role so its blast radius is bounded to the projax schema (cannot reach mai.workers, otto.*, vault.*, etc.). The role lives outside the migrations because it carries credentials.

As a superuser on msupabase (e.g. via the Supabase SQL editor):

CREATE ROLE projax_admin WITH LOGIN PASSWORD '<choose-strong-pw>';

-- Cross-schema read of mai.projects (consumed by projax.items_unified):
GRANT USAGE  ON SCHEMA mai   TO projax_admin;
GRANT SELECT ON mai.projects TO projax_admin;

-- mai.projects has RLS enabled; standard SELECT grants aren't enough.
-- Add an explicit policy so projax_admin sees every row:
CREATE POLICY projax_read ON mai.projects FOR SELECT TO projax_admin USING (true);

Then store the credential in .env.age and surface it to Dokploy as the secret PROJAX_DB_URL:

PROJAX_DB_URL=postgres://projax_admin:<pw>@<msupabase-tailscale-host>:6789/postgres?sslmode=disable

After this, migration 0005_reown_to_projax_admin.sql will detect the role on the next deploy and transfer ownership of every projax-namespaced object. Migrations before/after that point are idempotent.

1. Dokploy app

deploy/dokploy.yaml is a reference manifest. Translate to the Dokploy UI:

1. Create an app projax with Dockerfile build context = repo root.
2. Set domain projax.msbls.de (public via Traefik + Let's Encrypt — auth gating is at the application layer, see Trust model).
3. Secret PROJAX_DB_URL from step 0.
4. Env SUPABASE_URL=https://supa.flexsiebels.de, secret SUPABASE_ANON_KEY (from .env.age).
5. Health check path /healthz.
6. Single replica.

The image is a distroless static container running as nonroot. Total image size is well under 20 MiB because everything (templates, CSS, migrations) is embed-bundled.

Trust model (v1)

Single-user. Public over HTTPS, gated by projax's own Supabase login. No anonymous routes except /healthz (Dokploy/Traefik probe), /login and /logout.

• Browser arrives without a session → 302 /login?redirectTo=<safe-path>.
• /login posts to <SUPABASE_URL>/auth/v1/token?grant_type=password with the m/* user account. On success projax sets access_token and refresh_token cookies (HttpOnly, Secure, SameSite=Lax, Path=/, Max-Age=1y, no Domain attribute so they are scoped to projax.msbls.de only).
• Every request after that validates the cookie against /auth/v1/user. On expiry, projax silently refreshes via /auth/v1/token?grant_type=refresh_token and rotates both cookies. The middleware also accepts Authorization: Bearer <token> for scripted clients.
• /logout clears both cookies and bounces to /login.
• redirectTo is path-only (/-prefixed, no //, no escape sequences). Cross-host bounces are rejected and fall back to /.
• Same Supabase backend as the rest of the m/* fleet (mBrian, flexsiebels, …); each tool keeps its own login + cookie scope.
• DB role is projax_admin — full rights on projax.*, read-only on mai.projects via an explicit RLS policy, blocked on every other schema (see deploy step 0).
• PROJAX_DB_URL + SUPABASE_ANON_KEY live in Dokploy secrets, never the repo.

If projax later needs auth (multi-device, shared with people, etc.), the natural fit is the same Supabase auth used by flexsiebels — defer until projax has actually outgrown the Tailscale fence.

Schema

projax.items        (id, kind[], title, slug, path, parent_id, content_md,
                     aliases[], metadata jsonb, status, pinned, archived,
                     start_time, end_time, created_at, updated_at, deleted_at)
projax.item_links   (item_id, ref_type, ref_id, rel, note, metadata, created_at)
projax.items_unified VIEW = projax.items UNION ALL adapter over mai.projects

A BEFORE trigger maintains items.path via parent walk and enforces structural rules (areas at root, projects not at root, no cycles). An AFTER trigger rewrites descendant paths on rename / re-parent.

A mai.projects row drops out of items_unified as soon as any projax.item_links row with ref_type='mai-project' points back at it — that's how the Promote flow makes the duplicate disappear without ever mutating mai.projects.

Migrations live in db/migrations/, are embedded into the binary, and applied lexicographically on boot.