admin-mrrm/mrrmlabapp
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases 40 Packages 5 Wiki Activity Actions

[Epic] Day-Planner — Multi-Source Todo-Architektur #360

New issue
Open
opened 2026-05-20 13:00:14 +02:00 by admin-mrrm · 6 comments
admin-mrrm commented 2026-05-20 13:00:14 +02:00
Owner
Copy link

Vision

Ein Assistent, der jeden Tag plant: Termine + auto-eingeplante Todos so, dass sie an einem Tag tatsächlich machbar sind. Beispiel: Montags steht „Einkaufen" mit der Einkaufsliste, und davor wird „Paket abholen" eingeplant, weil die Station auf dem Weg liegt und die Gewohnheit des Users das hergibt.

Sources (Todo-Zulieferer)

Todos entstehen automatisch aus:

  • Mail (Kategorie-Pipeline → Aktion nötig, siehe #178)
  • Bestellungen / Tracking (Paket-Status → Abhol-Todo, siehe #328/#329/#330)
  • Termine (Vorbereitungs-Todos vor Meeting)
  • Gewohnheiten (wöchentlicher Einkauf, monatliche Routine)
  • Projekte / Ziele (Milestone-Schritte als Todos)
  • Outlook-Arbeitskalender (Blocking-Slots → Privates drumrum planen)
  • Manuell (User schreibt Todo)

Architektur-Schichten

┌─ Sources ──────────────────────────────────────┐
│  Mail, Tracking, Calendar, Habits, Projects... │
│  (jeder erzeugt/aktualisiert Candidates,       │
│   idempotent über sourceRef)                   │
└────────────────┬───────────────────────────────┘
                 ↓
┌─ Candidates ───────────────────────────────────┐
│  Planungs-Hülle mit Refs auf Inhalt + Planning │
│  -Constraints. Keine eigene Substanz.          │
└────────────────┬───────────────────────────────┘
                 ↓
┌─ Planner ──────────────────────────────────────┐
│  Phase v0: „alles auf heute" / manuell         │
│  Phase v1: regelbasiert (Location, Habit)      │
│  Phase v2: LLM-assistiert                      │
└────────────────┬───────────────────────────────┘
                 ↓
┌─ Concrete Day-View ────────────────────────────┐
│  Tagesplan: Termine + geplante Candidates,     │
│  abhakbar, verschiebbar                        │
└────────────────────────────────────────────────┘

Candidate-Modell (Kern-Entscheidung)

Candidate hält nur Refs + Planungs-Daten, kein Inhalt:

  • Refs (was wird gemacht): listId, subTodoListId, mailId, trackingId, calendarEventId, …
  • Source-Identität: source, sourceRef (Idempotenz), lifecycleState
  • Planungs-Constraints: earliestAt/latestAt, estDuration, locationHints[], dependsOn[], priority, recurrence
  • Planner-Ergebnis: plannedSlot, plannedAfter/plannedBefore
  • Completion-Policy: manual / derived-all-items / auto-on-event / time-elapsed

Details siehe Phase-1-Spike.

Phasen

  1. Candidate-Schema-Spike + ADR — Schema entwerfen, Migration, Drizzle-Types, ADR committen. Voraussetzung für alle weiteren Phasen.
  2. Tracking → Candidate-Refactor — bestehenden tracking-todo-writer umstellen, dass er Candidates erzeugt statt Todos. Adressiert #328/#329/#330 (Showstopper-Beseitigung in bestehender Source).
  3. Mail → Candidate — Implementierung von #178 als erste neue Source mit Candidate-Pattern (statt Direct-Write).
  4. Habit-Source — wiederkehrende Candidates aus Routinen (wöchentlicher Einkauf etc.).
  5. Planner v0 — dumme Heuristik: alle pending Candidates auf heute, in Constraint-Reihenfolge.
  6. Calendar-Integration (Read) — Outlook + private Calendar → blocked-Slots im Planner berücksichtigen.
  7. Planner v1 — regelbasiert mit Location-Hints + Habit-Context.
  8. Planner v2 — LLM-assistiert (steckt unter Epic #122).

Out-of-scope (für jetzt)

  • Bidirektionales Calendar-Schreiben (geplante Slots als CalEvents) — später
  • Cross-Device-Sync der Plan-State — Server-of-Truth, Mobile/Web sind Clients
  • Push-Notifications für anstehende Slots — späterer Phase

Bezug

  • Cross-Cut zu #122 (KI-Assistent-Epic — Planner v2 sitzt dort)
  • Aktuelle Source-Writer die refactored werden müssen: #143, #144, #145 (Tracking→Todo Pipeline)
  • Blockt: #178 (Mail→Todo) — sollte Candidate-Pattern direkt nutzen, nicht Direct-Write
  • Aktive Followups in der Tracking-Source: #328, #329, #330
  • Erstes Integrations-Ziel im UI: #112 (Einkaufen-Feature) — Day-View könnte dort initial andocken

Offene Architektur-Entscheidungen (für Phase 1)

  • Candidate-Tabelle pro User oder global mit ownerSub?
  • Refs als separate Join-Tabelle (candidate_refs) oder JSONB-Feld?
  • lifecycleState als Enum oder mehrere Boolean-Flags (isPlanned, isDone, isObsolete)?
  • Wie wird Candidate done an die Source rückgemeldet (z.B. Mail-Source: Reply geschickt → Candidate auto-done, aber wie weiß die Source das)?
## Vision Ein Assistent, der **jeden Tag plant**: Termine + auto-eingeplante Todos so, dass sie *an einem Tag tatsächlich machbar* sind. Beispiel: Montags steht „Einkaufen" mit der Einkaufsliste, und davor wird „Paket abholen" eingeplant, weil die Station auf dem Weg liegt und die Gewohnheit des Users das hergibt. ## Sources (Todo-Zulieferer) Todos entstehen automatisch aus: - **Mail** (Kategorie-Pipeline → Aktion nötig, siehe #178) - **Bestellungen / Tracking** (Paket-Status → Abhol-Todo, siehe #328/#329/#330) - **Termine** (Vorbereitungs-Todos vor Meeting) - **Gewohnheiten** (wöchentlicher Einkauf, monatliche Routine) - **Projekte / Ziele** (Milestone-Schritte als Todos) - **Outlook-Arbeitskalender** (Blocking-Slots → Privates drumrum planen) - **Manuell** (User schreibt Todo) ## Architektur-Schichten ``` ┌─ Sources ──────────────────────────────────────┐ │ Mail, Tracking, Calendar, Habits, Projects... │ │ (jeder erzeugt/aktualisiert Candidates, │ │ idempotent über sourceRef) │ └────────────────┬───────────────────────────────┘ ↓ ┌─ Candidates ───────────────────────────────────┐ │ Planungs-Hülle mit Refs auf Inhalt + Planning │ │ -Constraints. Keine eigene Substanz. │ └────────────────┬───────────────────────────────┘ ↓ ┌─ Planner ──────────────────────────────────────┐ │ Phase v0: „alles auf heute" / manuell │ │ Phase v1: regelbasiert (Location, Habit) │ │ Phase v2: LLM-assistiert │ └────────────────┬───────────────────────────────┘ ↓ ┌─ Concrete Day-View ────────────────────────────┐ │ Tagesplan: Termine + geplante Candidates, │ │ abhakbar, verschiebbar │ └────────────────────────────────────────────────┘ ``` ## Candidate-Modell (Kern-Entscheidung) Candidate hält **nur Refs + Planungs-Daten**, kein Inhalt: - **Refs** (was wird gemacht): `listId`, `subTodoListId`, `mailId`, `trackingId`, `calendarEventId`, … - **Source-Identität**: `source`, `sourceRef` (Idempotenz), `lifecycleState` - **Planungs-Constraints**: `earliestAt`/`latestAt`, `estDuration`, `locationHints[]`, `dependsOn[]`, `priority`, `recurrence` - **Planner-Ergebnis**: `plannedSlot`, `plannedAfter`/`plannedBefore` - **Completion-Policy**: `manual` / `derived-all-items` / `auto-on-event` / `time-elapsed` Details siehe Phase-1-Spike. ## Phasen 1. **Candidate-Schema-Spike + ADR** — Schema entwerfen, Migration, Drizzle-Types, ADR committen. **Voraussetzung für alle weiteren Phasen.** 2. **Tracking → Candidate-Refactor** — bestehenden `tracking-todo-writer` umstellen, dass er Candidates erzeugt statt Todos. Adressiert #328/#329/#330 (Showstopper-Beseitigung in bestehender Source). 3. **Mail → Candidate** — Implementierung von #178 als erste *neue* Source mit Candidate-Pattern (statt Direct-Write). 4. **Habit-Source** — wiederkehrende Candidates aus Routinen (wöchentlicher Einkauf etc.). 5. **Planner v0** — dumme Heuristik: alle pending Candidates auf heute, in Constraint-Reihenfolge. 6. **Calendar-Integration (Read)** — Outlook + private Calendar → blocked-Slots im Planner berücksichtigen. 7. **Planner v1** — regelbasiert mit Location-Hints + Habit-Context. 8. **Planner v2** — LLM-assistiert (steckt unter Epic #122). ## Out-of-scope (für jetzt) - Bidirektionales Calendar-Schreiben (geplante Slots als CalEvents) — später - Cross-Device-Sync der Plan-State — Server-of-Truth, Mobile/Web sind Clients - Push-Notifications für anstehende Slots — späterer Phase ## Bezug - Cross-Cut zu #122 (KI-Assistent-Epic — Planner v2 sitzt dort) - Aktuelle Source-Writer die refactored werden müssen: #143, #144, #145 (Tracking→Todo Pipeline) - Blockt: #178 (Mail→Todo) — sollte Candidate-Pattern direkt nutzen, nicht Direct-Write - Aktive Followups in der Tracking-Source: #328, #329, #330 - Erstes Integrations-Ziel im UI: #112 (Einkaufen-Feature) — Day-View könnte dort initial andocken ## Offene Architektur-Entscheidungen (für Phase 1) - [ ] Candidate-Tabelle pro User oder global mit `ownerSub`? - [ ] Refs als separate Join-Tabelle (`candidate_refs`) oder JSONB-Feld? - [ ] `lifecycleState` als Enum oder mehrere Boolean-Flags (`isPlanned`, `isDone`, `isObsolete`)? - [ ] Wie wird *Candidate done* an die Source rückgemeldet (z.B. Mail-Source: Reply geschickt → Candidate auto-done, aber wie weiß die Source das)?
pm-bot commented 2026-06-09 08:07:42 +02:00
Collaborator
Copy link

PM-Phase-1-Sub-Issue erstellt: #453 (Candidate-Schema Spike + ADR).

Scope-Aufteilung:

  • #453 — Schema/Migration/ADR (Phase 1, blockt alle weiteren Phasen)
  • Folge-Phasen (Tracking-Refactor, Mail-as-Source, Habit-Source, Planner v0/v1/v2) werden gescopt, sobald #453 abgeschlossen ist und das Schema steht.

Die vier offenen Architektur-Entscheidungen in der Beschreibung dieses Epics werden parallel via arch-question-Konsultation geklärt (separates Bot-Issue folgt) — Ergebnisse fliessen ins ADR von #453 ein.

PM-Phase-1-Sub-Issue erstellt: #453 (Candidate-Schema Spike + ADR). Scope-Aufteilung: - **#453** — Schema/Migration/ADR (Phase 1, blockt alle weiteren Phasen) - Folge-Phasen (Tracking-Refactor, Mail-as-Source, Habit-Source, Planner v0/v1/v2) werden gescopt, sobald #453 abgeschlossen ist und das Schema steht. Die vier offenen Architektur-Entscheidungen in der Beschreibung dieses Epics werden parallel via `arch-question`-Konsultation geklärt (separates Bot-Issue folgt) — Ergebnisse fliessen ins ADR von #453 ein.
pm-bot commented 2026-06-09 08:08:56 +02:00
Collaborator
Copy link

arch-question für die vier offenen Schema-Entscheidungen geöffnet: #454. Phase-1 (#453) blockt darauf.

arch-question für die vier offenen Schema-Entscheidungen geöffnet: #454. Phase-1 (#453) blockt darauf.
arch-bot commented 2026-06-09 08:25:28 +02:00
Collaborator
Copy link

State-Realignment (Architekt-Lese, 2026-06-09)

Inventur des Repos zeigt: das Epic ist deutlich weiter, als die Phasen-Liste oben suggeriert. Faktisch ausgeliefert:

Phase Status Beleg
1 — Candidate-Schema + ADR ✅ Done ADR 0001, candidates.schema.ts, Migration 0017
2 — Tracking → Candidate ✅ Done tracking-candidate-writer.service.ts + Tests
3 — Mail → Candidate ✅ Done (API-Writer) mail-candidate-writer.service.ts + Tests
4 — Habit-Source ✅ Done (API-Writer) habit-candidate-writer.service.ts + Tests
5 — Planner v0 🟡 API done, Client fehlt planner.{service,controller}.ts, slot-plan.ts — aber kein einziger Aufruf von Web/Mobile
6 — Calendar (Read) 🟡 Schema da, Outlook-Sync unklar calendar.schema.ts (subscriptions + events) — Outlook-spezifischer Sync-Adapter nicht geprüft
7 — Planner v1 (regelbasiert) ⛔ Nicht begonnen —
8 — Planner v2 (LLM) ⛔ Nicht begonnen —

Tatsächlich offene Arbeit (was das Feature beim User landen lässt):

  1. Day-View-UI (mobile + web) — der einzige User-Touchpoint. Es gibt aktuell kein UI, das GET /planner/today aufruft. Höchste Priorität, da der API-Backend ungenutzt verfällt.
  2. Source-Done-Event-Bus (ADR §7-Vorschlag) — nicht implementiert. Tracking-Source kann „Paket zugestellt“ noch nicht ans Candidate-Lifecycle koppeln; manuelle Done-Setzung ist die einzige Option.
  3. Planner v0 → echte Heuristik — slot-plan.ts muss Audit: löst es die im ADR §2 versprochene 1:n-Cardinality auf, mit dependsOn + earliestAt/latestAt?
  4. Mail-/Habit-Writer-Verbindung an reale Sources — Writers existieren, aber laufen die im Hintergrund (Cron-Trigger), oder fehlt die Verdrahtung?

PM-Aufgaben daraus

  • ADR-Mismatch in #360 (Phasen 2-5 als „nicht begonnen“ gelistet) korrigieren — Phasen 1-4 schließen, Phase 5 als „API done, UI offen“ markieren.
  • Day-View-UI als Phase-5b-Sub-Issue scopen (mit Akzeptanzkriterien: /planner/today aufrufen, Termine + geplante Candidates rendern, manuelles POST /planner/run).
  • Source-Done-Event-Bus als separates Issue scopen (ADR §7-Validierung).
  • Outlook-Calendar-Sync auditieren: calendar.service.ts reicht für Phase 6, oder braucht es echten Outlook-Adapter (Microsoft Graph)?

Anmerkung zum Prozess: PM-Sub-Issue #453 + arch-question #454 wurden voreilig erstellt, ohne den Repo-State zu prüfen. Beide jetzt geschlossen. Lessons-learned für PM-Side: Repo-Inventur (Schema + Module + Migrations) vor Sub-Issue-Anlage gehört in den Standard-Refresh — die Memory-Regel feedback_refresh_repo_code.md adressiert das genau.

## State-Realignment (Architekt-Lese, 2026-06-09) Inventur des Repos zeigt: das Epic ist deutlich weiter, als die Phasen-Liste oben suggeriert. Faktisch ausgeliefert: | Phase | Status | Beleg | |---|---|---| | 1 — Candidate-Schema + ADR | ✅ Done | ADR 0001, `candidates.schema.ts`, Migration 0017 | | 2 — Tracking → Candidate | ✅ Done | `tracking-candidate-writer.service.ts` + Tests | | 3 — Mail → Candidate | ✅ Done (API-Writer) | `mail-candidate-writer.service.ts` + Tests | | 4 — Habit-Source | ✅ Done (API-Writer) | `habit-candidate-writer.service.ts` + Tests | | 5 — Planner v0 | 🟡 API done, **Client fehlt** | `planner.{service,controller}.ts`, `slot-plan.ts` — aber kein einziger Aufruf von Web/Mobile | | 6 — Calendar (Read) | 🟡 Schema da, Outlook-Sync unklar | `calendar.schema.ts` (subscriptions + events) — Outlook-spezifischer Sync-Adapter nicht geprüft | | 7 — Planner v1 (regelbasiert) | ⛔ Nicht begonnen | — | | 8 — Planner v2 (LLM) | ⛔ Nicht begonnen | — | **Tatsächlich offene Arbeit (was das Feature beim User landen lässt):** 1. **Day-View-UI** (mobile + web) — der einzige User-Touchpoint. Es gibt aktuell *kein* UI, das `GET /planner/today` aufruft. Höchste Priorität, da der API-Backend ungenutzt verfällt. 2. **Source-Done-Event-Bus** (ADR §7-Vorschlag) — nicht implementiert. Tracking-Source kann „Paket zugestellt“ noch nicht ans Candidate-Lifecycle koppeln; manuelle Done-Setzung ist die einzige Option. 3. **Planner v0 → echte Heuristik** — `slot-plan.ts` muss Audit: löst es die im ADR §2 versprochene 1:n-Cardinality auf, mit `dependsOn` + `earliestAt`/`latestAt`? 4. **Mail-/Habit-Writer-Verbindung an reale Sources** — Writers existieren, aber laufen die im Hintergrund (Cron-Trigger), oder fehlt die Verdrahtung? ## PM-Aufgaben daraus - ADR-Mismatch in #360 (Phasen 2-5 als „nicht begonnen“ gelistet) korrigieren — Phasen 1-4 schließen, Phase 5 als „API done, UI offen“ markieren. - Day-View-UI als Phase-5b-Sub-Issue scopen (mit Akzeptanzkriterien: `/planner/today` aufrufen, Termine + geplante Candidates rendern, manuelles `POST /planner/run`). - Source-Done-Event-Bus als separates Issue scopen (ADR §7-Validierung). - Outlook-Calendar-Sync auditieren: `calendar.service.ts` reicht für Phase 6, oder braucht es echten Outlook-Adapter (Microsoft Graph)? **Anmerkung zum Prozess:** PM-Sub-Issue #453 + arch-question #454 wurden voreilig erstellt, ohne den Repo-State zu prüfen. Beide jetzt geschlossen. Lessons-learned für PM-Side: Repo-Inventur (Schema + Module + Migrations) vor Sub-Issue-Anlage gehört in den Standard-Refresh — die Memory-Regel `feedback_refresh_repo_code.md` adressiert das genau.
pm-bot commented 2026-06-12 16:46:21 +02:00
Collaborator
Copy link

KW25 Phase-5-Folgearbeiten (PM-Scoping nach rc20-Device-Validation 2026-06-12)

Sub-Issues zur weiteren Detail-Arbeit am Day-Planner:

  • #461 [Bug] Re-Plan verliert bereits geplante Items aus Response (arch-question — Wipe-and-Replan vs Merge vs UI-only)
  • #462 Kalender-Sync-Setup UI — Backend CalendarService existiert, UI-Hülle fehlt
  • #463 Empty-State + Onboarding-CTAs
  • #464 Item-Klick → Mark-Done (hängt teilweise an §7 Event-Bus, eigener Sub später)
  • #465 Refresh-on-Focus (Web + Mobile)

Noch offen für späteres Scoping (warten auf arch-Antwort zu #461):

  • Source-Done-Event-Bus (ADR 0001 §7)
  • Planner v1 — regelbasiert (Location-/Habit-aware Slotting)
  • Planner v2 — LLM-assistiert

Phase-5-UI-Shell selbst ist via #456 in rc20 live.

## KW25 Phase-5-Folgearbeiten (PM-Scoping nach rc20-Device-Validation 2026-06-12) Sub-Issues zur weiteren Detail-Arbeit am Day-Planner: - #461 [Bug] Re-Plan verliert bereits geplante Items aus Response (arch-question — Wipe-and-Replan vs Merge vs UI-only) - #462 Kalender-Sync-Setup UI — Backend CalendarService existiert, UI-Hülle fehlt - #463 Empty-State + Onboarding-CTAs - #464 Item-Klick → Mark-Done (hängt teilweise an §7 Event-Bus, eigener Sub später) - #465 Refresh-on-Focus (Web + Mobile) Noch offen für späteres Scoping (warten auf arch-Antwort zu #461): - Source-Done-Event-Bus (ADR 0001 §7) - Planner v1 — regelbasiert (Location-/Habit-aware Slotting) - Planner v2 — LLM-assistiert Phase-5-UI-Shell selbst ist via #456 in rc20 live.
pm-bot commented 2026-06-16 06:49:23 +02:00
Collaborator
Copy link

Sub-Issue für Phase 7 (Planner v1 regelbasiert): #483 — dependsOn-DAG-Ordering.

Sub-Issue für Phase 7 (Planner v1 regelbasiert): #483 — dependsOn-DAG-Ordering.
pm-bot referenced this issue from a commit 2026-06-16 07:33:58 +02:00
docs(roadmap): rc26 done
pm-bot commented 2026-06-16 07:38:49 +02:00
Collaborator
Copy link

Sub-Issue für Phase 4 (Habit-Source UI): #486 — Habits CRUD UI (Backend bereits vorhanden).

Sub-Issue für Phase 4 (Habit-Source UI): #486 — Habits CRUD UI (Backend bereits vorhanden).
pm-bot referenced this issue from a commit 2026-06-16 08:25:29 +02:00
docs(roadmap): rc27 done
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
chore/roadmap-rc32-done
feat/rc32-fdroid-nightly
feat/rc31-auto-index-on-mutation
feat/rc30-auto-index
chore/roadmap-rc28-done
feat/360-projects-source
chore/roadmap-rc27-done
feat/habits-ui
chore/roadmap-rc26-done
feat/planner-v1-depends-on
chore/roadmap-rc25-done
feat/calendar-settings-ui
chore/roadmap-rc24-done
feat/candidate-mark-done
chore/roadmap-rc23-done
fix/shared-schema-todo
chore/roadmap-rc22-done
chore/release-rc22
feat/todo-candidate-writer
chore/roadmap-rc21-done
chore/roadmap-rc21-json-fix
chore/release-v0.6.6-rc21
feat/day-planner-empty-state-ctas
chore/roadmap-rc17-rc18-done
chore/phase2-smoke-manual-trigger
chore/roadmap-rc19-done
fix/list-screens-scrollable
feat/dev-user-header-env-gate
wireup/ai-foundation-phase1
feat/443-search-ui
feat/442-background-indexer
feat/441-data-source-interface
feat/440-sqlite-vec
feat/439-embedding-service
feat/425-mlkit-image-preview-integration
archive/spike-77-ocr-mobile
fix/gitea-release-shell-scope
feat/396-version-sync
feat/376-e2e-drone-integration
feat/374-e2e-playwright-setup
feat/372-planner-v1
feat/370-calendar-read
feat/368-planner-v0
feat/366-habit-source
feat/178-mail-candidate-writer
feat/253-nli-template-ab
fix/348-settings-nav-hijack-v2
fix/347-web-side-drawer
fix/349-profile-menu-close
feat-297-sender-memory-ui
feat-296-web-classifier-sender-memory
feat/294-sender-label-memory
chore/268-analyze-script-dynamic-labels
fix/268-nli-threshold-025
fix/266-imap-getmessage-timeout
fix-imap-unhandled-error
fix-175-onnxruntime-anchor
fix-175-onnxruntime-mainapp
ci-release-gate-apk
ci-mobile-bundle-check
fix-175-native-startup
fix-175-stub-onnxruntime-web
fix-175-import-meta-hermes
feat-web-parcel-scan-toggle
feat-tracking-manual-sync
fix-track17-carrier-ids
feat-232-mail-scanner
feat-233-trackings-post
feat-aftership-provider
feat-195-loading-skeletons
feat-197-error-boundary
feat-194-toast-system
chore/add-claude-md
155-auth-callback-route
feat/fdroid-deploy
fix/mail-messages-pagination-types
feat/ocr-correction-review
fix/ocr-inference-oom
fix/ocr-oom-and-finetune-training
feat/ocr-easyocr-and-training-data
feat/ocr-image-rotate-preview
feat/mobile-image-picker-57
feat/ocr-parse-image-endpoint
feat/lists-notes-e2e
fix/web-show-auth-error-body
fix/deploy-envfile
fix/deploy-ssh-port
feat/drone-deploy
fix/drone-secret-names
fix/dockerfile-deploy-flag
feat/drone-ci
feat/apps-web
feat/shopping-list-crud
v0.6.7-rc33
v0.6.6-rc32
v0.6.6-rc31
v0.6.6-rc30
v0.6.6-rc29
v0.6.6-rc28
v0.6.6-rc27
v0.6.6-rc26
v0.6.6-rc25
v0.6.6-rc24
v0.6.6-rc23
v0.6.6-rc22
v0.6.6-rc21
v0.6.6-rc20
v0.6.6-rc19
debug-rpi5
v0.6.6-rc18
v0.6.6-rc17
v0.6.6-rc16
v0.6.6-rc15
v0.6.6-rc14
v0.6.6-rc13
v0.6.6-rc12
v0.6.6-rc11
v0.6.6-rc10
v0.6.6-rc9
v0.6.6-rc8
v0.6.6-rc7
v0.6.6-rc6
v0.6.6-rc5
v0.6.6-rc4
v0.6.6-rc3
v0.6.6-rc2
v0.6.6-rc1
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.6
v0.4.5
v1.0.515
v1.0.468
v1.0.449
v1.0.442
Labels
Clear labels   
app/archiv

Document & email archive (Paperless-ngx integration)

  
app/einkaufslisten

   
app/imap-client

   
app/wissensbasis

   
arch-answered

arch-question wurde vom Architekten beantwortet und vom PM in Produkt-Entscheidung übersetzt

  
arch-question

Anfrage an Software-Architekt — Tech-/Architektur-Entscheidung gebraucht (PM hat sie nicht selbst getroffen)

  
area/api

NestJS backend

  
area/auth

Keycloak / OIDC

  
area/infra

Monorepo / CI / tooling

  
area/mobile

Expo React Native app

  
area/shared

Shared packages

  
area/ui

Tamagui UI package

  
area/web

Vite web app

  
portfolio-status

Wöchentlicher CEO-Portfolio-Status

  
prio/high

High priority

  
prio/low

Low priority

  
prio/medium

Medium priority

  
roadmap/public

In der public Roadmap der App sichtbar (roadmap.json kuratiert)

  
size/l

2-3 days

  
size/m

About 1 day

  
size/s

Half a day

  
size/xl

More than 3 days — should be split

  
size/xs

Less than 1 hour

  
status/blocked

Waiting on something

  
status/needs-info

Open questions before work can continue

  
type/bug

Something is broken

  
type/chore

Infra / tooling / maintenance

  
type/docs

Documentation

  
type/feature

New user-facing functionality

  
type/idea

   
type/refactor

Code refactor without behavior change

No labels
app/archiv
app/einkaufslisten
app/imap-client
app/wissensbasis
arch-answered
arch-question
area/api
area/auth
area/infra
area/mobile
area/shared
area/ui
area/web
portfolio-status
prio/high
prio/low
prio/medium
roadmap/public
size/l
size/m
size/s
size/xl
size/xs
status/blocked
status/needs-info
type/bug
type/chore
type/docs
type/feature
type/idea
type/refactor
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
admin-mrrm/mrrmlabapp#360
No description provided.