pdurlej/platform

Fork 0

Nest Platform: wizja, decyzje i plan federated shell MVP #736

New issue

Open

opened 2026-06-06 21:03:15 +02:00 by codex · 1 comment

codex commented

2026-06-06 21:03:15 +02:00

Collaborator

Kontekst

Nest Platform (NP) miało ewoluować w self-hosted, AI-first personal operating system inspirowany Lunatask, uruchamiany na RS 2000 i używany przez jednego operatora na macOS oraz iOS.

Główna wizja: nie budować od razu jednego monolitu, tylko stworzyć spójny federated shell: jedno UX, jeden kontrakt vault/markdown, jeden MCP/API surface, jeden model readiness/degraded/offline, ale z możliwością użycia lub lekkiej adaptacji najlepszych self-hosted providerów per domena.

Docelowe doświadczenie

NP ma dawać Lunatask-like daily driver experience:

Today jako centralny ekran dnia
Tasks do planowania, backlogu, wykonania i statusu
Habits do check-inów, streaków i rytmów
Journal jako długi dziennik w vaultcie plus szybkie capture
Notes jako Obsidian-compatible markdown vault
People jako personal relationship manager
Calendar jako orkiestracja CalDAV i time context
Review jako tygodniowe/miesięczne podsumowanie
Search i MCP jako warstwa AI-first nad całością

UX ma pozostać w NP. UI providerów może istnieć jako escape hatch, ale nie powinien być główną ścieżką użytkownika.

Kluczowe decyzje architektoniczne

1. NP jako federated shell

NP posiada:

główną nawigację i shell UX
search/index
MCP/API
audyt
degraded/offline behavior
vault/markdown contract
mechanizmy sync i external bindings

Providerzy są implementacyjnymi źródłami danych dla wybranych domen, ale użytkownik powinien pracować głównie w trasach NP.

2. Source-of-truth per domena v1

Ustalony kierunek dla v1:

Tasks: tududi jako operational source of truth; NP posiada shell, search/index, AI actions i mirrored projections. Długoterminowo możliwy natywny NP task core inspirowany tududi oraz TaskChampion/Taskwarrior.
Habits: OpenHabitTracker jako operational source of truth; NP pokazuje własny shell i mirroruje completions/streak summaries.
Journaling: długi dziennik pozostaje vault-first. Memos służy jako quick-capture/timeline provider. SilverBullet tylko jako editor nad tym samym Obsidian-compatible vaultem.
PRM: identity/contact data CardDAV-first, z Meerkat jako pierwszym provider candidate. Relationship metadata, reconnect cadence i interaction notes pozostają NP/vault-owned.
Notes: canonical source of truth to vault. SilverBullet jako preferowany UI/editor nad tym samym vaultem.
Calendar: Radicale jako canonical CalDAV layer. Zewnętrzne kalendarze są klonowane/mirrorowane read-only. NP pisze tylko do dedykowanego kalendarza NP.

3. Sync i identity contract

Potrzebny jest trwały model bindingów dla rekordów provider-backed:

domain
provider
externalId
npEntityId
syncState
lastPulledAt
lastPushedAt
lastError
externalRevision/etag

Tryby sync:

provider-first: tasks, habits
vault-first: notes, long-form journal
hybrid: PRM i journaling capture

Zasada konfliktów: user-authored vault content wygrywa nad mirrorami/provider projections, chyba że akcja jest jawnie provider-owned.

4. Calendar orchestration

Radicale jest canonical CalDAV layer.

imported external calendars pozostają read-only
NP writes tylko do dedykowanego kalendarza NP
CalendarMirror jest lokalną projekcją dla shell/search/AI
w v1 nie robimy write-back do zewnętrznych upstreamów

5. Offline/privacy posture

System pozostaje self-hosted only.

Krótki termin:

Obsidian-compatible vault jest offline editing surface
NP web ma degradować jawnie: cached read views, explicit degraded/offline banners, no silent data loss

Średni termin:

self-hosted vault sync layer przyjazny iOS/macOS
Git/Forgejo jako audit/history, nie primary end-user sync UX

Acceptance dla degraded mode:

brak pustego dashboardu
brak błędnej daty lokalnej
brak ukrytego unsynced state
widoczny last-sync i pending-change indicators

Plan rollout / BMADX X4

Zakres został potraktowany jako X4/FUBAR: 6 providerów, rollout produkcyjny, migracje source-of-truth i E2E/canary.

Preferencje:

rollout w 3 falach
bezpośredni tailnet UI tylko dla Memos i SilverBullet
upstream kalendarzy/kontaktów jako mixed/manual
tasks/habits/contacts import jako osobne wątki

Wave 0: Foundation / preflight

Cele:

provider env, compose services, config katalogi, runbooki
scoped backup: np-federation-backup.sh i restore
config/np/federation-sources.yaml
provider health w readiness i smoke
stack providerów podniesiony disabled/not-wired bez naruszania prod NP

Stan rozmowy: Wave 0 zostało technicznie domknięte na RS 2000, włącznie z readiness, smoke i cert/DNS dla provider hostów.

Wave 1: Calendar / Journal / Notes

Providerzy:

Radicale dla CalDAV
Memos dla journal capture buffer
SilverBullet jako editor nad tym samym vaultem

Wykonane/ustalone:

DNS/TLS domknięty dla memos.pdurlej.com, silverbullet.pdurlej.com, radicale.pdurlej.com, meerkat.pdurlej.com
Playwright canary dla np, memos, silverbullet przeszedł
dodany importer .ics do CalendarMirror
testowy Google holidays ICS został podpięty jako source:
https://calendar.google.com/calendar/ical/en.polish%23holiday%40group.v.calendar.google.com/public/basic.ics
sync kalendarza na RS 2000 zaimportował 253 wydarzenia

Wave 2: Tasks / Habits

Planowane jako osobny wątek:

tududi operational source dla /api/tasks*
import tylko aktywnych i planowanych tasków z NP do tududi
DONE/ARCHIVED/CANCELLED zostają jako legacy/historyczny vault/index
OpenHabitTracker jako operational source dla /api/habits*
habits startują clean, bez migracji historycznej
cutover per domena, nie all-at-once

Wave 3: People / PRM

Planowane jako osobny wątek:

Meerkat jako CardDAV/API provider candidate
one-time/manual contact import
matching: normalized primary email, potem normalized phone, potem manual bind queue
Meerkat jako canonical CardDAV endpoint dla Apple Contacts po imporcie
NP people pozostaje hybrid: contact identity z Meerkat, reconnect metadata i notes w vault/NP

Ważne naprawy i odkrycia po drodze

Naprawiono runtime providerów w RS 2000: Memos DSN, Radicale permissions, OpenHabitTracker healthcheck.
Dodano /ready w NP i rozszerzono readiness/federation reporting.
Usunięto fałszywy blocker ZEROCLAW_*; ZeroClaw jest zarchiwizowany/wyłączony na RS 2000.
Naprawiono Playwright canary, żeby realnie failował przy browser errors.
Rozpoznano drift między lokalnym np i live /opt/np; część live source była starsza niż repo i wymagała wyrównania, aby provider sync działał realnie, nie tylko jako snapshot refresh.

Co chcieliśmy zrobić dalej

Domknąć Wave 1 dla journal/notes UX:
- Memos signup/admin/bootstrap
- Today/Journal same-day capture feed
- Promote capture into vault journal
- SilverBullet deep-linking do notatek/journal
Uruchomić osobny wątek Wave 2:
- migracja aktywnych tasków do tududi
- /api/tasks* provider-first
- OpenHabitTracker bootstrap
- /api/habits* provider-first
- shell-visible streak summaries
Uruchomić osobny wątek Wave 3:
- Meerkat/CardDAV setup
- contact import/matching
- Apple Contacts acceptance
- NP reconnect metadata i relationship notes
Cross-cutting polish:
- cached/degraded states per domain
- last-sync/pending indicators
- provider outage isolation
- scheduled sync jobs
- manual re-sync actions in shell
- broader Playwright canaries
- iOS/macOS manual acceptance

Kryteria sukcesu

NP ma stać się daily-driver shell, w którym użytkownik pracuje w jednym spójnym interfejsie, a providery są wymienne i drugorzędne. Source-of-truth jest jawny per domena, sync/degraded behavior jest widoczne, a AI/MCP ma jednolity dostęp do tasków, habits, journal, notes, people i calendar bez ukrywania operacyjnych problemów providerów.

## Kontekst Nest Platform (`NP`) miało ewoluować w self-hosted, AI-first personal operating system inspirowany Lunatask, uruchamiany na RS 2000 i używany przez jednego operatora na macOS oraz iOS. Główna wizja: nie budować od razu jednego monolitu, tylko stworzyć spójny `federated shell`: jedno UX, jeden kontrakt vault/markdown, jeden MCP/API surface, jeden model readiness/degraded/offline, ale z możliwością użycia lub lekkiej adaptacji najlepszych self-hosted providerów per domena. ## Docelowe doświadczenie NP ma dawać Lunatask-like daily driver experience: - `Today` jako centralny ekran dnia - `Tasks` do planowania, backlogu, wykonania i statusu - `Habits` do check-inów, streaków i rytmów - `Journal` jako długi dziennik w vaultcie plus szybkie capture - `Notes` jako Obsidian-compatible markdown vault - `People` jako personal relationship manager - `Calendar` jako orkiestracja CalDAV i time context - `Review` jako tygodniowe/miesięczne podsumowanie - `Search` i MCP jako warstwa AI-first nad całością UX ma pozostać w NP. UI providerów może istnieć jako escape hatch, ale nie powinien być główną ścieżką użytkownika. ## Kluczowe decyzje architektoniczne ### 1. NP jako federated shell NP posiada: - główną nawigację i shell UX - search/index - MCP/API - audyt - degraded/offline behavior - vault/markdown contract - mechanizmy sync i external bindings Providerzy są implementacyjnymi źródłami danych dla wybranych domen, ale użytkownik powinien pracować głównie w trasach NP. ### 2. Source-of-truth per domena v1 Ustalony kierunek dla v1: - `Tasks`: `tududi` jako operational source of truth; NP posiada shell, search/index, AI actions i mirrored projections. Długoterminowo możliwy natywny NP task core inspirowany tududi oraz TaskChampion/Taskwarrior. - `Habits`: `OpenHabitTracker` jako operational source of truth; NP pokazuje własny shell i mirroruje completions/streak summaries. - `Journaling`: długi dziennik pozostaje vault-first. `Memos` służy jako quick-capture/timeline provider. `SilverBullet` tylko jako editor nad tym samym Obsidian-compatible vaultem. - `PRM`: identity/contact data CardDAV-first, z `Meerkat` jako pierwszym provider candidate. Relationship metadata, reconnect cadence i interaction notes pozostają NP/vault-owned. - `Notes`: canonical source of truth to vault. `SilverBullet` jako preferowany UI/editor nad tym samym vaultem. - `Calendar`: `Radicale` jako canonical CalDAV layer. Zewnętrzne kalendarze są klonowane/mirrorowane read-only. NP pisze tylko do dedykowanego kalendarza `NP`. ### 3. Sync i identity contract Potrzebny jest trwały model bindingów dla rekordów provider-backed: ```text domain provider externalId npEntityId syncState lastPulledAt lastPushedAt lastError externalRevision/etag ``` Tryby sync: - `provider-first`: tasks, habits - `vault-first`: notes, long-form journal - `hybrid`: PRM i journaling capture Zasada konfliktów: user-authored vault content wygrywa nad mirrorami/provider projections, chyba że akcja jest jawnie provider-owned. ### 4. Calendar orchestration Radicale jest canonical CalDAV layer. - imported external calendars pozostają read-only - NP writes tylko do dedykowanego kalendarza `NP` - `CalendarMirror` jest lokalną projekcją dla shell/search/AI - w v1 nie robimy write-back do zewnętrznych upstreamów ### 5. Offline/privacy posture System pozostaje self-hosted only. Krótki termin: - Obsidian-compatible vault jest offline editing surface - NP web ma degradować jawnie: cached read views, explicit degraded/offline banners, no silent data loss Średni termin: - self-hosted vault sync layer przyjazny iOS/macOS - Git/Forgejo jako audit/history, nie primary end-user sync UX Acceptance dla degraded mode: - brak pustego dashboardu - brak błędnej daty lokalnej - brak ukrytego unsynced state - widoczny last-sync i pending-change indicators ## Plan rollout / BMADX X4 Zakres został potraktowany jako `X4/FUBAR`: 6 providerów, rollout produkcyjny, migracje source-of-truth i E2E/canary. Preferencje: - rollout w 3 falach - bezpośredni tailnet UI tylko dla `Memos` i `SilverBullet` - upstream kalendarzy/kontaktów jako mixed/manual - tasks/habits/contacts import jako osobne wątki ### Wave 0: Foundation / preflight Cele: - provider env, compose services, config katalogi, runbooki - scoped backup: `np-federation-backup.sh` i restore - `config/np/federation-sources.yaml` - provider health w readiness i smoke - stack providerów podniesiony disabled/not-wired bez naruszania prod NP Stan rozmowy: Wave 0 zostało technicznie domknięte na RS 2000, włącznie z readiness, smoke i cert/DNS dla provider hostów. ### Wave 1: Calendar / Journal / Notes Providerzy: - `Radicale` dla CalDAV - `Memos` dla journal capture buffer - `SilverBullet` jako editor nad tym samym vaultem Wykonane/ustalone: - DNS/TLS domknięty dla `memos.pdurlej.com`, `silverbullet.pdurlej.com`, `radicale.pdurlej.com`, `meerkat.pdurlej.com` - Playwright canary dla `np`, `memos`, `silverbullet` przeszedł - dodany importer `.ics` do `CalendarMirror` - testowy Google holidays ICS został podpięty jako source: `https://calendar.google.com/calendar/ical/en.polish%23holiday%40group.v.calendar.google.com/public/basic.ics` - sync kalendarza na RS 2000 zaimportował 253 wydarzenia ### Wave 2: Tasks / Habits Planowane jako osobny wątek: - `tududi` operational source dla `/api/tasks*` - import tylko aktywnych i planowanych tasków z NP do tududi - DONE/ARCHIVED/CANCELLED zostają jako legacy/historyczny vault/index - `OpenHabitTracker` jako operational source dla `/api/habits*` - habits startują clean, bez migracji historycznej - cutover per domena, nie all-at-once ### Wave 3: People / PRM Planowane jako osobny wątek: - `Meerkat` jako CardDAV/API provider candidate - one-time/manual contact import - matching: normalized primary email, potem normalized phone, potem manual bind queue - Meerkat jako canonical CardDAV endpoint dla Apple Contacts po imporcie - NP `people` pozostaje hybrid: contact identity z Meerkat, reconnect metadata i notes w vault/NP ## Ważne naprawy i odkrycia po drodze - Naprawiono runtime providerów w RS 2000: Memos DSN, Radicale permissions, OpenHabitTracker healthcheck. - Dodano `/ready` w NP i rozszerzono readiness/federation reporting. - Usunięto fałszywy blocker `ZEROCLAW_*`; ZeroClaw jest zarchiwizowany/wyłączony na RS 2000. - Naprawiono Playwright canary, żeby realnie failował przy browser errors. - Rozpoznano drift między lokalnym `np` i live `/opt/np`; część live source była starsza niż repo i wymagała wyrównania, aby provider sync działał realnie, nie tylko jako snapshot refresh. ## Co chcieliśmy zrobić dalej 1. Domknąć Wave 1 dla journal/notes UX: - Memos signup/admin/bootstrap - Today/Journal same-day capture feed - Promote capture into vault journal - SilverBullet deep-linking do notatek/journal 2. Uruchomić osobny wątek Wave 2: - migracja aktywnych tasków do tududi - `/api/tasks*` provider-first - OpenHabitTracker bootstrap - `/api/habits*` provider-first - shell-visible streak summaries 3. Uruchomić osobny wątek Wave 3: - Meerkat/CardDAV setup - contact import/matching - Apple Contacts acceptance - NP reconnect metadata i relationship notes 4. Cross-cutting polish: - cached/degraded states per domain - last-sync/pending indicators - provider outage isolation - scheduled sync jobs - manual re-sync actions in shell - broader Playwright canaries - iOS/macOS manual acceptance ## Kryteria sukcesu NP ma stać się daily-driver shell, w którym użytkownik pracuje w jednym spójnym interfejsie, a providery są wymienne i drugorzędne. Source-of-truth jest jawny per domena, sync/degraded behavior jest widoczne, a AI/MCP ma jednolity dostęp do tasków, habits, journal, notes, people i calendar bez ukrywania operacyjnych problemów providerów.

Iskra commented

2026-06-14 03:04:00 +02:00

Collaborator

Iskra judgment

Field	Value
Target	`pdurlej/platform#issue#736`
Priority	p1
Action	operator_needed
Scores	reach 5 / impact 5 / confidence 5
Piotr fit	high
Effort	large
Labels	`judge/p1`, `judge/operator-needed`
Judge	`iskra` via `openclaw`

Rationale: This is P1 operator-needed product architecture work because the federated shell MVP needs explicit scope cuts before it becomes an unbounded personal-OS rebuild.

Caveat: Do not start building broad modules until the MVP contract, provider boundaries, offline/degraded behavior, and first daily-driver slice are chosen.

Structured openclaw.judge.v0 payload

<!-- openclaw.judge.v0 -->
{
  "confidence": 5,
  "effort_hint": "large",
  "escalation": {
    "kind": "operator",
    "reason": "Nest Platform federated shell is a strategic product architecture choice spanning personal OS scope, provider selection, vault contracts, and MVP boundaries."
  },
  "evidence_refs": [
    {
      "note": "Issue captures Nest Platform vision as a self-hosted AI-first personal operating system inspired by Lunatask.",
      "type": "forgejo",
      "value": "issue-title-body-labels-and-target-snapshot"
    },
    {
      "note": "Body proposes a federated shell rather than an immediate monolith, with shared UX, vault contract, MCP/API surface, and readiness model.",
      "type": "forgejo",
      "value": "issue-body-context-and-architecture"
    },
    {
      "note": "Body defines a broad daily-driver target across Today, Tasks, Habits, Journal, Notes, People, Calendar, Review, Search, and MCP layers.",
      "type": "forgejo",
      "value": "issue-body-target-experience"
    }
  ],
  "impact": 5,
  "judge_actor": {
    "name": "iskra",
    "runtime": "openclaw"
  },
  "judged_at": "2026-06-14T01:03:00Z",
  "labels_to_apply": [
    "judge/p1",
    "judge/operator-needed"
  ],
  "piotr_fit": "high",
  "priority": "p1",
  "rationale_summary": "This is P1 operator-needed product architecture work because the federated shell MVP needs explicit scope cuts before it becomes an unbounded personal-OS rebuild.",
  "reach": 5,
  "recommended_next_action": "operator_needed",
  "rerun_reason": "no_prior_judgment",
  "schema": "openclaw.judge.v0",
  "target": {
    "kind": "issue",
    "number": 736,
    "repo": "pdurlej/platform"
  },
  "target_snapshot": {
    "body_hash": "sha256:a065ccee24edd9c25a92f6e9561e0583073c42501aba0eed252aa3b7ed324fec",
    "commit_count": null,
    "evidence_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "head_sha": null,
    "labels": [],
    "labels_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "state": "open",
    "title_hash": "sha256:732e359ab1fcfba5704f8388614bbd067bf3ee9ef02ca26c9af0e54b1b12e661",
    "updated_at": "2026-06-06T21:03:15+02:00"
  },
  "top_caveat": "Do not start building broad modules until the MVP contract, provider boundaries, offline/degraded behavior, and first daily-driver slice are chosen."
}
<!-- /openclaw.judge.v0 -->

### Iskra judgment | Field | Value | | --- | --- | | Target | `pdurlej/platform#issue#736` | | Priority | p1 | | Action | operator_needed | | Scores | reach 5 / impact 5 / confidence 5 | | Piotr fit | high | | Effort | large | | Labels | `judge/p1`, `judge/operator-needed` | | Judge | `iskra` via `openclaw` | **Rationale:** This is P1 operator-needed product architecture work because the federated shell MVP needs explicit scope cuts before it becomes an unbounded personal-OS rebuild. **Caveat:** Do not start building broad modules until the MVP contract, provider boundaries, offline/degraded behavior, and first daily-driver slice are chosen. <details> <summary>Structured openclaw.judge.v0 payload</summary> ```json  { "confidence": 5, "effort_hint": "large", "escalation": { "kind": "operator", "reason": "Nest Platform federated shell is a strategic product architecture choice spanning personal OS scope, provider selection, vault contracts, and MVP boundaries." }, "evidence_refs": [ { "note": "Issue captures Nest Platform vision as a self-hosted AI-first personal operating system inspired by Lunatask.", "type": "forgejo", "value": "issue-title-body-labels-and-target-snapshot" }, { "note": "Body proposes a federated shell rather than an immediate monolith, with shared UX, vault contract, MCP/API surface, and readiness model.", "type": "forgejo", "value": "issue-body-context-and-architecture" }, { "note": "Body defines a broad daily-driver target across Today, Tasks, Habits, Journal, Notes, People, Calendar, Review, Search, and MCP layers.", "type": "forgejo", "value": "issue-body-target-experience" } ], "impact": 5, "judge_actor": { "name": "iskra", "runtime": "openclaw" }, "judged_at": "2026-06-14T01:03:00Z", "labels_to_apply": [ "judge/p1", "judge/operator-needed" ], "piotr_fit": "high", "priority": "p1", "rationale_summary": "This is P1 operator-needed product architecture work because the federated shell MVP needs explicit scope cuts before it becomes an unbounded personal-OS rebuild.", "reach": 5, "recommended_next_action": "operator_needed", "rerun_reason": "no_prior_judgment", "schema": "openclaw.judge.v0", "target": { "kind": "issue", "number": 736, "repo": "pdurlej/platform" }, "target_snapshot": { "body_hash": "sha256:a065ccee24edd9c25a92f6e9561e0583073c42501aba0eed252aa3b7ed324fec", "commit_count": null, "evidence_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "head_sha": null, "labels": [], "labels_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "state": "open", "title_hash": "sha256:732e359ab1fcfba5704f8388614bbd067bf3ee9ef02ca26c9af0e54b1b12e661", "updated_at": "2026-06-06T21:03:15+02:00" }, "top_caveat": "Do not start building broad modules until the MVP contract, provider boundaries, offline/degraded behavior, and first daily-driver slice are chosen." }  ``` </details>

Iskra added the

judge/operator-needed

judge/p1

labels

2026-06-14 03:04:01 +02:00