Reintegrate projax with mBrian as backend (data on mBrian, both frontends in parallel) #5

New Issue

Open

opened 2026-05-29 09:38:14 +00:00 by mAi · 1 comment

mAi commented 2026-05-29 09:38:14 +00:00

Collaborator

Copy Link

Premise (m's framing, 2026-05-29)

Use mBrian as projax's backend store so projax data lives in mBrian's graph and is automatically visible to both surfaces. mBrian's node+edge model + jsonb metadata accommodates the types projax needs. The graph stays canonical, no redundant data, both frontends keep working in parallel.

"Maybe we can try to 'reintegrate' projax into mBrian by at least using it as the backend?! That way our information is always available in both. The mBrian System allows all kinds of data and we could just add the types we have and put our data in json blobs?! The Graph is good to have and we don't have redundant data. As our frontend we keep both in parallel, that should be possible?! Of course we need to somehow keep this synced so coordination with mbrian wouldn't be so bad, I think."

Current state

• projax: own projax.items table (47 rows) + projax.item_links + projax.views (Phase 5j incoming) + bidirectional sync with mai.projects (Phase 1.5). Trigger-maintained paths text[] + slug-per-sibling uniqueness. Rich structured columns (status, pinned, tags, management, public_*, timeline_exclude). Aggregator (Phase 5a) over the projax store. Tiles dashboard (Phase 5h), calendar grid (Phase 5e), timeline (Phase 4a). MCP at /mcp/rpc.
• mBrian: topic-bounded knowledge graph in Postgres. Nodes (typed: topic, concept, idea, source, synthesis, question, log, schema). Edges (typed: child_of, related_to, derives_from, etc.). Per-node jsonb metadata. MCP at mcp__mbrian__*.

Mapping projax → mBrian

• projax.items row → mBrian node, type either a new [item] or [project] (or piggy-back on [topic] since hierarchy is the same shape).
• projax.item_links row → mBrian edge with ref_type as the edge relation + jsonb for ref_id / event_date / note.
• projax structured columns (status, pinned, tags, management, public_*, timeline_exclude, public_screenshots) → mBrian node metadata jsonb.
• DAG (paths[], parent_ids[]) → mBrian child_of edges. The paths array becomes a derived render-time concept, not a stored field.
• Slug uniqueness per sibling → enforced at the projax handler layer (or via mBrian schema convention), since mBrian doesn't have that constraint today.

Implementation shapes (4 options)

A. Full backend migration

projax loses its store. All reads/writes go through mBrian's MCP or direct DB. projax becomes a specialized view over the mBrian subset. End-state cleanest, cost highest. Touches: store/, aggregator/, every handler, every MCP tool, the mai.projects sync, every test. Multi-phase (likely a 5-7 sub-phase project on its own).

B. Bidirectional sync (mai.projects pattern from Phase 1.5)

Keep projax.items as projax's store. Add triggers: projax → mBrian on projax-side write; mBrian → projax on mBrian-side write. Both sides read their own. Mirrors the existing Phase 1.5 pattern. Lower cost than A. Risk: sync drift (already accepted for mai.projects, would be accepted again here). Both frontends "see" the data because each stores it.

C. One-way mirror (projax → mBrian)

projax remains source of truth. On every projax write, mirror to mBrian. mBrian gets the data for graph view + search but doesn't write back. Simpler than B, less symmetric — m can't edit a projax item from mBrian's UI.

D. MCP federation

No data duplication. mBrian's frontend queries projax via MCP for projax-shaped data. projax stays canonical. mBrian renders projax data inline where relevant (e.g. on a topic page that's associated with a projax item, mBrian fetches that item via mcp__projax__get_item). No schema changes anywhere. Lowest cost. End-state: federation, not integration.

Recommendation (head's read)

B or D, depending on whether m wants editing from both surfaces:

• If m wants to edit a projax item from inside mBrian's editor → B (bidirectional sync). The Phase 1.5 sync pattern proves the trigger shape works.
• If m only needs READ visibility from mBrian → D (MCP federation). Cheapest, least entangling, most reversible.

A is the architecturally ideal end-state but the implementation cost is large and would freeze projax development for the duration. Phase 5j (Views redesign) just started; landing A mid-5j is impractical.

C is a stepping stone toward A but rarely a stable end-state.

Open questions

1. Does m want to EDIT projax items from inside mBrian's UI, or only see them there?
2. mBrian's node schema: are there existing types that fit projax_item directly, or do we need a new type? ([project] exists? [item] exists?)
3. mBrian's edge model: does child_of carry slug semantics, or just parent-child relationship? Slug uniqueness per sibling — enforced where?
4. The mai.projects ↔ projax.items bidirectional sync: keep, drop, or chain through mBrian?
5. CalDAV / Gitea integrations are projax-specific. Do they stay attached to the projax handler layer (reading from whichever store wins), or do they migrate to mBrian-side edges?
6. Aggregator (Phase 5a fan-out + 5e calendar + 5h tiles) consumes projax store directly. With B or D, no change. With A or C, needs migration.
7. Cross-repo coordination: who's the mBrian head? Single inbox via otto/head, or direct head-to-head?
8. Phase 5j Views redesign currently in flight (kahn on Slice A). Coordinate the integration design with 5j so Views land on the eventual data model rather than today's projax.views table.

Constraints (don't relitigate)

• Single-user, Tailscale-only.
• No public exposure.
• Both projax and mBrian frontends keep working — no UI is being deprecated.
• mBrian is m's actual second brain; changes carry blast radius beyond projax. Any schema-touching work coordinates with mBrian's head.

Refs

• projax docs/design.md — current PRD
• mBrian concept-mbrian-conventions node — node/edge naming patterns
• Phase 1.5 mai.projects bidirectional sync (commit history in projax) — the trigger pattern that B would reuse
• Phase 5a-5j accumulated tooling that would need to consume the new backend (B/D: no change; A/C: rewrite)

Decision needed from m

Which shape (A/B/C/D), and if A or B, what's the sequencing relative to Phase 5j (Views redesign in flight)?

## Premise (m's framing, 2026-05-29) Use mBrian as projax's backend store so projax data lives in mBrian's graph and is automatically visible to both surfaces. mBrian's node+edge model + jsonb metadata accommodates the types projax needs. The graph stays canonical, no redundant data, both frontends keep working in parallel. > *"Maybe we can try to 'reintegrate' projax into mBrian by at least using it as the backend?! That way our information is always available in both. The mBrian System allows all kinds of data and we could just add the types we have and put our data in json blobs?! The Graph is good to have and we don't have redundant data. As our frontend we keep both in parallel, that should be possible?! Of course we need to somehow keep this synced so coordination with mbrian wouldn't be so bad, I think."* ## Current state - projax: own `projax.items` table (47 rows) + `projax.item_links` + `projax.views` (Phase 5j incoming) + bidirectional sync with `mai.projects` (Phase 1.5). Trigger-maintained `paths text[]` + slug-per-sibling uniqueness. Rich structured columns (status, pinned, tags, management, public_*, timeline_exclude). Aggregator (Phase 5a) over the projax store. Tiles dashboard (Phase 5h), calendar grid (Phase 5e), timeline (Phase 4a). MCP at `/mcp/rpc`. - mBrian: topic-bounded knowledge graph in Postgres. Nodes (typed: topic, concept, idea, source, synthesis, question, log, schema). Edges (typed: child_of, related_to, derives_from, etc.). Per-node jsonb metadata. MCP at `mcp__mbrian__*`. ## Mapping projax → mBrian - `projax.items` row → mBrian node, type either a new `[item]` or `[project]` (or piggy-back on `[topic]` since hierarchy is the same shape). - `projax.item_links` row → mBrian edge with `ref_type` as the edge relation + jsonb for ref_id / event_date / note. - projax structured columns (status, pinned, tags, management, public_*, timeline_exclude, public_screenshots) → mBrian node `metadata` jsonb. - DAG (paths[], parent_ids[]) → mBrian `child_of` edges. The paths array becomes a derived render-time concept, not a stored field. - Slug uniqueness per sibling → enforced at the projax handler layer (or via mBrian schema convention), since mBrian doesn't have that constraint today. ## Implementation shapes (4 options) ### A. Full backend migration projax loses its store. All reads/writes go through mBrian's MCP or direct DB. projax becomes a specialized view over the mBrian subset. End-state cleanest, cost highest. Touches: store/, aggregator/, every handler, every MCP tool, the mai.projects sync, every test. Multi-phase (likely a 5-7 sub-phase project on its own). ### B. Bidirectional sync (mai.projects pattern from Phase 1.5) Keep `projax.items` as projax's store. Add triggers: projax → mBrian on projax-side write; mBrian → projax on mBrian-side write. Both sides read their own. Mirrors the existing Phase 1.5 pattern. Lower cost than A. Risk: sync drift (already accepted for mai.projects, would be accepted again here). Both frontends "see" the data because each stores it. ### C. One-way mirror (projax → mBrian) projax remains source of truth. On every projax write, mirror to mBrian. mBrian gets the data for graph view + search but doesn't write back. Simpler than B, less symmetric — m can't edit a projax item from mBrian's UI. ### D. MCP federation No data duplication. mBrian's frontend queries projax via MCP for projax-shaped data. projax stays canonical. mBrian renders projax data inline where relevant (e.g. on a topic page that's associated with a projax item, mBrian fetches that item via `mcp__projax__get_item`). No schema changes anywhere. Lowest cost. End-state: federation, not integration. ## Recommendation (head's read) **B or D**, depending on whether m wants editing from both surfaces: - If m wants to edit a projax item from inside mBrian's editor → B (bidirectional sync). The Phase 1.5 sync pattern proves the trigger shape works. - If m only needs READ visibility from mBrian → D (MCP federation). Cheapest, least entangling, most reversible. A is the architecturally ideal end-state but the implementation cost is large and would freeze projax development for the duration. Phase 5j (Views redesign) just started; landing A mid-5j is impractical. C is a stepping stone toward A but rarely a stable end-state. ## Open questions 1. Does m want to EDIT projax items from inside mBrian's UI, or only see them there? 2. mBrian's node schema: are there existing types that fit `projax_item` directly, or do we need a new type? (`[project]` exists? `[item]` exists?) 3. mBrian's edge model: does `child_of` carry slug semantics, or just parent-child relationship? Slug uniqueness per sibling — enforced where? 4. The `mai.projects` ↔ `projax.items` bidirectional sync: keep, drop, or chain through mBrian? 5. CalDAV / Gitea integrations are projax-specific. Do they stay attached to the projax handler layer (reading from whichever store wins), or do they migrate to mBrian-side edges? 6. Aggregator (Phase 5a fan-out + 5e calendar + 5h tiles) consumes projax store directly. With B or D, no change. With A or C, needs migration. 7. Cross-repo coordination: who's the mBrian head? Single inbox via otto/head, or direct head-to-head? 8. Phase 5j Views redesign currently in flight (kahn on Slice A). Coordinate the integration design with 5j so Views land on the eventual data model rather than today's projax.views table. ## Constraints (don't relitigate) - Single-user, Tailscale-only. - No public exposure. - Both projax and mBrian frontends keep working — no UI is being deprecated. - mBrian is m's actual second brain; changes carry blast radius beyond projax. Any schema-touching work coordinates with mBrian's head. ## Refs - projax `docs/design.md` — current PRD - mBrian `concept-mbrian-conventions` node — node/edge naming patterns - Phase 1.5 mai.projects bidirectional sync (commit history in projax) — the trigger pattern that B would reuse - Phase 5a-5j accumulated tooling that would need to consume the new backend (B/D: no change; A/C: rewrite) ## Decision needed from m Which shape (A/B/C/D), and if A or B, what's the sequencing relative to Phase 5j (Views redesign in flight)?

mAi self-assigned this 2026-05-29 09:38:14 +00:00

mAi commented 2026-05-29 10:10:21 +00:00

Author

Collaborator

Copy Link

m's decision (2026-05-29 12:09)

Pick: A — Full backend migration

"I think that is what I want. The data itself is not too important yet. But I think we need the project-management element inside of mBrian for it to be the complete 2nd Brain experience."

m sees projax-as-project-management completing mBrian. Data loss-tolerance is high (47 items, hours-old structure). End-state: mBrian is canonical store; projax UI surfaces mBrian-sourced project data.

Sequencing (head proposal — needs m confirmation)

1. Let Phase 5j finish (kahn currently 5/7 slices through — A/B/C/E/G shipped; D editor + F 5i cleanup remain). The just-built /views routes, sidebar, system-view migration, icon registry are UI scaffolding that PRESERVES into Phase 6 — they just point at a different data source once the backend swaps. Estimated: D + F land in next 30-60 min at kahn's current cadence.

2. Start Phase 6 (mBrian backend migration) design as a separate inventor task. Phase 6 brief needs:

   • mBrian-side coordination (head-to-head: who owns mBrian's store, what types/edges need to be added)
   • Schema mapping spec: projax.items → mBrian node type X with metadata jsonb shape
   • Migration plan: hard-cut vs gradual (m said data loss-tolerant, so hard-cut is fine)
   • Read-path replacement: aggregator, dashboard tiles, calendar grid, timeline, search, MCP tools — all rewire to read from mBrian
   • Write-path replacement: edit handlers, /new, MCP create/update tools — all rewire
   • mai.projects bidirectional sync (Phase 1.5): drop, migrate, or chain through mBrian?
   • CalDAV + Gitea integrations: stay attached to projax handlers reading mBrian, or migrate to mBrian-side edges?

Outstanding open questions (still need m's input — from original issue body)

1. mBrian node/edge naming: existing [project] type or new [item]/[work-item] type?
2. mai.projects ↔ projax.items sync (Phase 1.5): keep, drop, or chain via mBrian?
3. CalDAV + Gitea integration ownership post-migration?
4. mBrian head: who is the contact, single inbox via otto/head or direct?
5. Cross-repo coordination protocol: delegation messages, shared design doc, or paired implementation?

Status: Phase 5j continues, Phase 6 design queued for after 5j ships

## m's decision (2026-05-29 12:09) **Pick: A — Full backend migration** > *"I think that is what I want. The data itself is not too important yet. But I think we need the project-management element inside of mBrian for it to be the complete 2nd Brain experience."* m sees projax-as-project-management completing mBrian. Data loss-tolerance is high (47 items, hours-old structure). End-state: mBrian is canonical store; projax UI surfaces mBrian-sourced project data. ## Sequencing (head proposal — needs m confirmation) 1. **Let Phase 5j finish** (kahn currently 5/7 slices through — A/B/C/E/G shipped; D editor + F 5i cleanup remain). The just-built /views routes, sidebar, system-view migration, icon registry are UI scaffolding that PRESERVES into Phase 6 — they just point at a different data source once the backend swaps. Estimated: D + F land in next 30-60 min at kahn's current cadence. 2. **Start Phase 6 (mBrian backend migration) design** as a separate inventor task. Phase 6 brief needs: - mBrian-side coordination (head-to-head: who owns mBrian's store, what types/edges need to be added) - Schema mapping spec: projax.items → mBrian node type X with metadata jsonb shape - Migration plan: hard-cut vs gradual (m said data loss-tolerant, so hard-cut is fine) - Read-path replacement: aggregator, dashboard tiles, calendar grid, timeline, search, MCP tools — all rewire to read from mBrian - Write-path replacement: edit handlers, /new, MCP create/update tools — all rewire - mai.projects bidirectional sync (Phase 1.5): drop, migrate, or chain through mBrian? - CalDAV + Gitea integrations: stay attached to projax handlers reading mBrian, or migrate to mBrian-side edges? ## Outstanding open questions (still need m's input — from original issue body) 1. mBrian node/edge naming: existing `[project]` type or new `[item]`/`[work-item]` type? 2. mai.projects ↔ projax.items sync (Phase 1.5): keep, drop, or chain via mBrian? 3. CalDAV + Gitea integration ownership post-migration? 4. mBrian head: who is the contact, single inbox via otto/head or direct? 5. Cross-repo coordination protocol: delegation messages, shared design doc, or paired implementation? ## Status: Phase 5j continues, Phase 6 design queued for after 5j ships

m referenced this issue from a commit 2026-05-29 10:49:50 +00:00

docs: Phase 6 mBrian-as-backend migration design plan

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

mai/kahn/phase-6-sliceB-prep

mai/kahn/phase-6a-mbrian-design

mai/kahn/phase-5j-views-redesign

mai/kahn/fix-views-edit-filters

mai/kahn/phase-5i-phase-a-design

mai/fuller/phase-5h-phase-a-design

No results found.

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

mAi m

No Assignees mAi

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: m/projax#5

No description provided.