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

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

New Issue
Open
opened 2026-05-15 17:02:04 +00:00 by mAi · 2 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
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?