m/projax
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects Releases Wiki Activity

Sub-Project Support: Health → Mental (Alias: Psychologie) und das generelle Sub-Projekt-Modell #1

New Issue
Closed
opened 2026-05-15 17:02:04 +00:00 by mAi · 5 comments
mAi commented 2026-05-15 17:02:04 +00:00
Collaborator
Copy Link

Request

m (2026-05-15, PWA voice):

Wir brauchen ein Unterprojekt von Health in Projects, und zwar Mental. Ein Alias dafür wäre Psychologie. Wir sollten es mir ermöglichen, verschiedene Notizen zu meiner auffälligen Psychologie es zu halten und abzulegen.

(EN: "We need a sub-project of Health in projax, called Mental. Alias Psychologie. It should let m keep and file notes about his own psychology.")

Concretely: m wants a sub-project Mental (alias Psychologie) under the parent project Health in projax.

Implication for the projax data model

projax today (Phase 1) has a flat project list (mai.projects). Sub-projects are not modelled.

Required:

  1. Parent pointer in the project schema: parent_project_id foreign key (nullable) on mai.projects.id. Top-level projects have parent_project_id IS NULL; sub-projects point at their parent.
  2. Alias field: aliases TEXT[]. m's Mental with alias Psychologie is the first concrete use-case. Search + navigation must match aliases too.
  3. UI representation: list view shows a tree structure, with drilldown if helpful. Detail view shows a parent breadcrumb.
  4. Promote/demote mechanic: a sub-project can be promoted to top-level, a top-level project can be demoted to sub-project. See mBrian [[concept-promotion-demotion-projects]] — projax should be the natural carrier for these lifecycle transitions.

Concrete setup after the schema update

Once sub-project logic exists:

  1. Create Health as a top-level project (if not already present).
  2. Create Mental as a sub-project of Health, alias Psychologie.
  3. The mBrian topic topic-mental-health (created 2026-05-15) remains the knowledge backbone — projax links to it; we don't duplicate storage.
  4. Privacy: the Mental project should be markable visibility: private — m's psychology notes are not for other eyes.

Scope of this issue

  1. Schema migration: parent_project_id + aliases fields on mai.projects.
  2. Backend: API endpoints handle hierarchical project listing + alias-aware search.
  3. UI: minimal tree-render in the project list, drilldown detail view shows parent.
  4. mAi CLI: mai project list --tree option (or default behaviour).
  5. After merge: create Health and Mental (with alias Psychologie) in the DB.
  6. Privacy: visibility field per project (private/personal/public), filtered in UI + API.

A parallel sub-project use-case is Finanzplanung under Finances (also captured 2026-05-15, mBrian [[topic-finanzplanung]]) — same schema covers both.

Out of scope

  • Multi-level hierarchies (deeper than 2 levels) — for now Top and Sub is enough. If a sub-sub-project is needed later, that's a schema-extension issue.
  • UI drag-and-drop re-parenting (promote/demote is an API action, not a drag).
  • mBrian integration of the note surface — separate follow-up. Today m can already file in topic-mental-health and topic-finanzplanung in mBrian directly; projax links to them eventually.

Refs

  • mBrian: [[concept-promotion-demotion-projects]] — projax should natively support promote/demote.
  • mBrian: [[topic-mental-health]], [[topic-finanzplanung]] — the data backbones for the notes.
  • projax docs/design.md — source of truth for the data model; must be extended.

Role: researcher initial (schema design + migration plan + UI sketch), then coder.

## Request m (2026-05-15, PWA voice): > Wir brauchen ein Unterprojekt von Health in Projects, und zwar Mental. Ein Alias dafür wäre Psychologie. Wir sollten es mir ermöglichen, verschiedene Notizen zu meiner auffälligen Psychologie es zu halten und abzulegen. (EN: "We need a sub-project of Health in projax, called `Mental`. Alias `Psychologie`. It should let m keep and file notes about his own psychology.") Concretely: m wants a **sub-project** `Mental` (alias `Psychologie`) **under** the parent project `Health` in projax. ## Implication for the projax data model projax today (Phase 1) has a flat project list (`mai.projects`). Sub-projects are not modelled. Required: 1. **Parent pointer in the project schema**: `parent_project_id` foreign key (nullable) on `mai.projects.id`. Top-level projects have `parent_project_id IS NULL`; sub-projects point at their parent. 2. **Alias field**: `aliases TEXT[]`. m's `Mental` with alias `Psychologie` is the first concrete use-case. Search + navigation must match aliases too. 3. **UI representation**: list view shows a tree structure, with drilldown if helpful. Detail view shows a parent breadcrumb. 4. **Promote/demote mechanic**: a sub-project can be promoted to top-level, a top-level project can be demoted to sub-project. See mBrian `[[concept-promotion-demotion-projects]]` — projax should be the natural carrier for these lifecycle transitions. ## Concrete setup after the schema update Once sub-project logic exists: 1. Create `Health` as a top-level project (if not already present). 2. Create `Mental` as a sub-project of `Health`, alias `Psychologie`. 3. The mBrian topic `topic-mental-health` (created 2026-05-15) remains the knowledge backbone — projax links to it; we don't duplicate storage. 4. Privacy: the `Mental` project should be markable `visibility: private` — m's psychology notes are not for other eyes. ## Scope of this issue 1. Schema migration: `parent_project_id` + `aliases` fields on `mai.projects`. 2. Backend: API endpoints handle hierarchical project listing + alias-aware search. 3. UI: minimal tree-render in the project list, drilldown detail view shows parent. 4. mAi CLI: `mai project list --tree` option (or default behaviour). 5. After merge: create `Health` and `Mental` (with alias `Psychologie`) in the DB. 6. Privacy: `visibility` field per project (private/personal/public), filtered in UI + API. A parallel sub-project use-case is `Finanzplanung` under `Finances` (also captured 2026-05-15, mBrian `[[topic-finanzplanung]]`) — same schema covers both. ## Out of scope - Multi-level hierarchies (deeper than 2 levels) — for now `Top` and `Sub` is enough. If a sub-sub-project is needed later, that's a schema-extension issue. - UI drag-and-drop re-parenting (promote/demote is an API action, not a drag). - mBrian integration of the note surface — separate follow-up. Today m can already file in `topic-mental-health` and `topic-finanzplanung` in mBrian directly; projax links to them eventually. ## Refs - mBrian: `[[concept-promotion-demotion-projects]]` — projax should natively support promote/demote. - mBrian: `[[topic-mental-health]]`, `[[topic-finanzplanung]]` — the data backbones for the notes. - projax `docs/design.md` — source of truth for the data model; must be extended. Role: **researcher** initial (schema design + migration plan + UI sketch), then **coder**.
mAi commented 2026-05-16 13:19:53 +00:00
Author
Collaborator
Copy Link

Third sub-project use-case — NewHomeSpecs under mHome

Added 2026-05-16 (PWA chat): m wants a sub-project NewHomeSpecs under mHome for collecting specifications for his next home. Same schema requirement as Mental (under Health) and Finanzplanung (under Finances) — parent_project_id + alias + private visibility.

The mBrian backbone is already in place as [[topic-new-home-specs]] (private). Once the schema lands, the worker should create NewHomeSpecs as a sub-project of mHome and link to the mBrian topic.

If any of the three (Mental / Finanzplanung / NewHomeSpecs) suggests refinements to the schema (e.g. a fourth field, a different alias-resolution rule), it'd be the user-research signal for it.

No change to scope of this issue; just adding the third concrete consumer for the implementer's awareness.

## Third sub-project use-case — NewHomeSpecs under mHome Added 2026-05-16 (PWA chat): m wants a sub-project `NewHomeSpecs` under `mHome` for collecting specifications for his next home. Same schema requirement as Mental (under Health) and Finanzplanung (under Finances) — parent_project_id + alias + private visibility. The mBrian backbone is already in place as `[[topic-new-home-specs]]` (private). Once the schema lands, the worker should create `NewHomeSpecs` as a sub-project of `mHome` and link to the mBrian topic. If any of the three (Mental / Finanzplanung / NewHomeSpecs) suggests refinements to the schema (e.g. a fourth field, a different alias-resolution rule), it'd be the user-research signal for it. No change to scope of this issue; just adding the third concrete consumer for the implementer's awareness.
mAi commented 2026-05-16 13:22:35 +00:00
Author
Collaborator
Copy Link

This issue is obsolete — schema already exists

m corrected me on 2026-05-16: projax has been actively developed and the schema features I framed as "needed" are already in place:

  • aliases text[]: present since migration 0001_init.sql.
  • Multi-parent / sub-project relationships: present since migration 0010_multi_parent.sql.
  • items_unified model: present since 0004 + 0009 simplification.

The codebase is at Phase 3o (admin-index) — way past the Phase 1 framing in the original body. The schema portion of this issue is therefore done.

The three concrete consumers (Mental under Health, Finanzplanung under Finances, NewHomeSpecs under mHome) can be created via projax POST /new?parent=… or via the projax-mcp surface once m/projax#3 wires it up.

Marking status:done. m can close when ready.

## This issue is obsolete — schema already exists m corrected me on 2026-05-16: projax has been actively developed and the schema features I framed as "needed" are already in place: - **`aliases text[]`**: present since migration `0001_init.sql`. - **Multi-parent / sub-project relationships**: present since migration `0010_multi_parent.sql`. - **`items_unified` model**: present since `0004` + `0009` simplification. The codebase is at Phase 3o (admin-index) — way past the Phase 1 framing in the original body. The schema portion of this issue is therefore done. The three concrete consumers (Mental under Health, Finanzplanung under Finances, NewHomeSpecs under mHome) can be created via `projax POST /new?parent=…` or via the projax-mcp surface once `m/projax#3` wires it up. Marking `status:done`. m can close when ready.
mAi commented 2026-07-17 09:40:48 +00:00
Author
Collaborator
Copy Link

Head-Triage 2026-07-17: Modell längst da, Mental jetzt angelegt, ein echter Blocker bleibt (#7)

Beim Session-Start gegen den Live-Stand geprüft (main @ bcf3412). Das Issue ist von 2026-05-15 und beschreibt einen projax-Stand, den es so nicht mehr gibt — es redet noch von mai.projects als Store und einer flachen Projektliste. Seither sind Phase 1–8 gelaufen; Sub-Projekte sind seit Phase 6 kein offener Punkt mehr.

Scope-Punkt für Punkt

  1. Parent-Pointer / Sub-Projekt-Modell — ✅ fertig, und stärker als hier gefordert. Das Issue wollte einen parent_project_id-FK (also ein Elternteil). Live ist stattdessen ein DAG über child_of-Kanten in mBrian: beliebige Tiefe und Mehrfach-Eltern. Beweis aus dem Live-Baum: health.sports.manjin (drei Ebenen), und racetrack hängt real an zwei Eltern gleichzeitig.
  2. Aliases-Feld — ⚠️ Feld existiert, ist aber nicht beschreibbar. Siehe unten.
  3. UI-Tree + Breadcrumb — ✅ /views/tree rendert den Baum, Detail-Seite zeigt die Eltern.
  4. mai project list --tree — ❌ nicht gebaut, und absichtlich nicht: projax CLAUDE.md führt "CLI surface" unter Out of scope ("m has explicitly opted out"). Der Punkt ist durch eine spätere Entscheidung von dir überholt, nicht vergessen worden. Sag Bescheid, falls du das anders willst.
  5. Health + Mental anlegen — ✅ heute erledigt. health gab es schon (Root-Area). Mental neu: health.mental, id 4bbe78f7-520c-47e2-bb00-9b0fe1425ea5. Verlinkt im content_md auf den mBrian-Topic topic-mental-health statt die Inhalte zu duplizieren — wie im Issue gefordert.
  6. Privacy — ✅ erfüllt, per Default. Es gibt kein visibility-Enum (private/personal/public), sondern ein public-Boolean, das auf false steht, solange du nichts anderes sagst. Dazu ist die ganze App Tailscale-only. health.mental ist damit privat — es gibt schlicht keine Oberfläche, auf der es auftauchen könnte. Wenn du ein echtes dreistufiges visibility willst, ist das ein eigenes Issue.

Der eine echte Blocker: der Alias geht nicht

Psychologie konnte ich nicht setzen — und das ist kein Vertipper, sondern ein Loch, das mir hier aufgefallen ist: aliases hat drei Read-Pfade und keinen einzigen Write-Pfad. Alle 88 Items live haben aliases:[]. Die Suche rankt explizit nach Alias, der Tree-Filter matcht darauf, das MCP gibt das Feld zurück — nur setzen kann es niemand: kein Formularfeld, kein MCP-Parameter, und der Writer schickt das Feld nie, obwohl die mBrian-API es auf POST und PATCH längst akzeptiert.

Als #7 gefilet und in Arbeit. Sobald das durch ist, bekommt health.mental den Alias Psychologie und dieses Issue ist auch in Punkt 2 erfüllt.

Status

Offen bleibt an #1 real nur der Alias (→ #7). Punkt 4 ist durch deinen CLI-Opt-out erledigt. Ich schließe nicht selbst — sobald #7 durch ist, melde ich mich hier nochmal.

## Head-Triage 2026-07-17: Modell längst da, `Mental` jetzt angelegt, ein echter Blocker bleibt (#7) Beim Session-Start gegen den Live-Stand geprüft (`main` @ bcf3412). Das Issue ist von 2026-05-15 und beschreibt einen projax-Stand, den es so nicht mehr gibt — es redet noch von `mai.projects` als Store und einer flachen Projektliste. Seither sind Phase 1–8 gelaufen; **Sub-Projekte sind seit Phase 6 kein offener Punkt mehr.** ### Scope-Punkt für Punkt 1. **Parent-Pointer / Sub-Projekt-Modell** — ✅ **fertig, und stärker als hier gefordert.** Das Issue wollte einen `parent_project_id`-FK (also *ein* Elternteil). Live ist stattdessen ein **DAG über `child_of`-Kanten in mBrian**: beliebige Tiefe *und* Mehrfach-Eltern. Beweis aus dem Live-Baum: `health.sports.manjin` (drei Ebenen), und `racetrack` hängt real an zwei Eltern gleichzeitig. 2. **Aliases-Feld** — ⚠️ **Feld existiert, ist aber nicht beschreibbar.** Siehe unten. 3. **UI-Tree + Breadcrumb** — ✅ `/views/tree` rendert den Baum, Detail-Seite zeigt die Eltern. 4. **`mai project list --tree`** — ❌ nicht gebaut, und **absichtlich nicht**: projax CLAUDE.md führt "CLI surface" unter *Out of scope* ("m has explicitly opted out"). Der Punkt ist durch eine spätere Entscheidung von dir überholt, nicht vergessen worden. Sag Bescheid, falls du das anders willst. 5. **`Health` + `Mental` anlegen** — ✅ **heute erledigt.** `health` gab es schon (Root-Area). `Mental` neu: `health.mental`, id `4bbe78f7-520c-47e2-bb00-9b0fe1425ea5`. Verlinkt im content_md auf den mBrian-Topic `topic-mental-health` statt die Inhalte zu duplizieren — wie im Issue gefordert. 6. **Privacy** — ✅ **erfüllt, per Default.** Es gibt kein `visibility`-Enum (private/personal/public), sondern ein `public`-Boolean, das auf `false` steht, solange du nichts anderes sagst. Dazu ist die ganze App Tailscale-only. `health.mental` ist damit privat — es gibt schlicht keine Oberfläche, auf der es auftauchen könnte. Wenn du ein echtes dreistufiges `visibility` willst, ist das ein eigenes Issue. ### Der eine echte Blocker: der Alias geht nicht `Psychologie` konnte ich **nicht** setzen — und das ist kein Vertipper, sondern ein Loch, das mir hier aufgefallen ist: **`aliases` hat drei Read-Pfade und keinen einzigen Write-Pfad.** Alle 88 Items live haben `aliases:[]`. Die Suche rankt explizit nach Alias, der Tree-Filter matcht darauf, das MCP gibt das Feld zurück — nur setzen kann es niemand: kein Formularfeld, kein MCP-Parameter, und der Writer schickt das Feld nie, obwohl die mBrian-API es auf POST *und* PATCH längst akzeptiert. Als **#7** gefilet und in Arbeit. Sobald das durch ist, bekommt `health.mental` den Alias `Psychologie` und dieses Issue ist auch in Punkt 2 erfüllt. ### Status Offen bleibt an #1 real nur der Alias (→ #7). Punkt 4 ist durch deinen CLI-Opt-out erledigt. Ich schließe nicht selbst — sobald #7 durch ist, melde ich mich hier nochmal.
mAi commented 2026-07-17 09:53:31 +00:00
Author
Collaborator
Copy Link

Alias-Anforderung erfüllt — Mental hat jetzt den Alias Psychologie

Die letzte offene Anforderung aus diesem Issue ist erledigt. Live-Stand von health.mental (id 4bbe78f7-520c-47e2-bb00-9b0fe1425ea5):

{"title": "Mental", "slug": "mental", "paths": ["health.mental"], "aliases": ["Psychologie"]}

Großschreibung erhalten — Psychologie, nicht psychologie.

Warum das bis jetzt nicht ging

aliases war ein totes Feld: drei Read-Pfade, kein einziger Write-Pfad (#7). Das Projekt war angelegt, der Alias schlicht nicht setzbar — als Workaround stand „Alias: Psychologie" nur als Prosa im content_md. Der Write-Pfad ist mit #7 gebaut (Writer-Payload + Web-Edit-Form + MCP-Parameter), dann der Alias gesetzt.

Commit: e859a98cd0
Details + Verify-Protokoll: #7

Nachweis, dass der Alias auch wirkt

Die Suche findet Mental über den Alias — verifiziert mit einem Token, das ausschließlich in aliases steht (die Suche nach Psychologie allein wäre kein Beweis, das Wort steht auch im Content). Der Tree-Filter matcht Aliases case-insensitiv, psychologie findet es also genauso.

Der Alias ist jetzt schon live wirksam — er liegt in den Daten, nicht im Binary; die Read-Seite war fertig und läuft ab dem Moment, wo Daten da sind.

Offen

Der Prosa-Satz „Alias: Psychologie" im content_md ist jetzt redundant. Ich habe ihn bewusst nicht angefasst — das ist dein Text, und Content-Edits waren nicht Teil des Auftrags. Sag Bescheid, wenn er raus soll.

Beide Issues (#1, #7) lasse ich offen — Schließen ist deine Sache.

## Alias-Anforderung erfüllt — `Mental` hat jetzt den Alias `Psychologie` Die letzte offene Anforderung aus diesem Issue ist erledigt. Live-Stand von `health.mental` (id `4bbe78f7-520c-47e2-bb00-9b0fe1425ea5`): ```json {"title": "Mental", "slug": "mental", "paths": ["health.mental"], "aliases": ["Psychologie"]} ``` Großschreibung erhalten — `Psychologie`, nicht `psychologie`. ### Warum das bis jetzt nicht ging `aliases` war ein totes Feld: drei Read-Pfade, kein einziger Write-Pfad (#7). Das Projekt war angelegt, der Alias schlicht nicht setzbar — als Workaround stand „Alias: Psychologie" nur als Prosa im `content_md`. Der Write-Pfad ist mit #7 gebaut (Writer-Payload + Web-Edit-Form + MCP-Parameter), dann der Alias gesetzt. Commit: https://mgit.msbls.de/m/projax/commit/e859a98cd0dc50c9a11ac0f3ecbb8c5cf1b39d80 Details + Verify-Protokoll: #7 ### Nachweis, dass der Alias auch wirkt Die Suche findet `Mental` über den Alias — verifiziert mit einem Token, das ausschließlich in `aliases` steht (die Suche nach `Psychologie` allein wäre kein Beweis, das Wort steht auch im Content). Der Tree-Filter matcht Aliases case-insensitiv, `psychologie` findet es also genauso. Der Alias ist **jetzt schon** live wirksam — er liegt in den Daten, nicht im Binary; die Read-Seite war fertig und läuft ab dem Moment, wo Daten da sind. ### Offen Der Prosa-Satz „Alias: Psychologie" im `content_md` ist jetzt redundant. Ich habe ihn bewusst **nicht** angefasst — das ist dein Text, und Content-Edits waren nicht Teil des Auftrags. Sag Bescheid, wenn er raus soll. Beide Issues (#1, #7) lasse ich offen — Schließen ist deine Sache.
m closed this issue 2026-07-17 10:05:15 +00:00
mAi added the
status:done
 label 2026-07-17 10:18:51 +00:00
mAi commented 2026-07-17 10:18:51 +00:00
Author
Collaborator
Copy Link

Alle Anforderungen erfüllt (2026-07-17) — bereit zum Schließen

Nachtrag zu meinem Triage-Kommentar von heute früh: der Alias ist jetzt da.

  • health.mental existiert, Elternteil health, privat (public: false).
  • Alias Psychologie ist live — live verifiziert nach Deploy 70b0e04 (healthz == HEAD): aliases: ["Psychologie"].

Der Blocker war #7 (aliases hatten drei Read-Pfade und keinen Write-Pfad — alle 88 Items standen auf aliases:[]). Ist gemerged und deployed.

Ein ehrlicher Vorbehalt: die Suche findet Mental über den Alias, aber ungerankt. Der Bucket-Vertrag, der einen Alias-Treffer über einen Fließtext-Treffer stellt, existiert nur im Legacy-Backend; Produktion fährt PROJAX_BACKEND=mbrian, dessen Suche flach ist. Das ist #10 und wartet auf deine Entscheidung — es ändert nichts an der Erfüllung dieses Issues, aber "Alias funktioniert" heißt hier "wird gefunden", nicht "wird bevorzugt".

Punkt 4 des ursprünglichen Scopes (mai project list --tree) bleibt bewusst offen — CLI ist per projax CLAUDE.md out of scope, deine Entscheidung von damals.

Ich schließe nicht selbst.

## Alle Anforderungen erfüllt (2026-07-17) — bereit zum Schließen Nachtrag zu meinem Triage-Kommentar von heute früh: der Alias ist jetzt da. - `health.mental` existiert, Elternteil `health`, privat (`public: false`). - **Alias `Psychologie` ist live** — live verifiziert nach Deploy `70b0e04` (healthz == HEAD): `aliases: ["Psychologie"]`. Der Blocker war #7 (aliases hatten drei Read-Pfade und keinen Write-Pfad — alle 88 Items standen auf `aliases:[]`). Ist gemerged und deployed. **Ein ehrlicher Vorbehalt:** die Suche findet `Mental` über den Alias, aber **ungerankt**. Der Bucket-Vertrag, der einen Alias-Treffer über einen Fließtext-Treffer stellt, existiert nur im Legacy-Backend; Produktion fährt `PROJAX_BACKEND=mbrian`, dessen Suche flach ist. Das ist **#10** und wartet auf deine Entscheidung — es ändert nichts an der Erfüllung dieses Issues, aber "Alias funktioniert" heißt hier "wird gefunden", nicht "wird bevorzugt". Punkt 4 des ursprünglichen Scopes (`mai project list --tree`) bleibt bewusst offen — CLI ist per projax CLAUDE.md out of scope, deine Entscheidung von damals. Ich schließe nicht selbst.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
status:done
Completed successfully — m closes
status:failed
Could not complete — needs human intervention
status:in-progress
Currently being worked on by an agent
status:needs-review
Done but m should verify
status:partial
Some progress made but blocked
No Label
status:done
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/projax#1
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?