Kairo-Jinkendo/docs/architecture/methods/SPEC_D_care_navigation_v0.1.md

SPEC-D — care_navigation

Steuerungsmethode — Spec-Tiefe D v0.1

Status: vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen Stand: 2026-07-26
Prozess: M1_Hybrid_Path_and_Depth_D_v0.1.md
Quellen: Decision-Lock Care, SPEC_Care_initiative_care_v0.1.md, Fit-Analyse
Ist-Code: Methode existiert noch nicht (neu) — P0
OM/UI: Archetyp-Vollspec Care

---

D1 Identität

Feld	Wert
method_key	care_navigation
Rolle	primary (Ausführung — Kernel §6)
Label (DE)	Fürsorge-Navigation
Zweck	Steuert das Wohlergehen einer Person im Fürsorgefokus (andere oder Self-Care). Vereinigt Prinzipien, Meilensteine, Rituale und reaktive Stränge unter einer Methode — ohne Archetyp-Mix A3+C1+A2.

---

D2 Geltung

Feld	Wert
Default für	initiative.care
kompatibel	initiative.care
nicht Default für	A1 (Können), A3 (Cadence ohne Fürsorge-Kern), C1 (Verfahren/Fall), B1 (Checklisten)

---

D3 Horizon

Schicht	Inhalt
CareFocus	welche Person (Selbst/Andere) ist der Fürsorgefokus
Checkpoint	optionaler Lebens-/Entwicklungs-Meilenstein („bis Schuleingang“, „Stabilität nach Krise“)
Jetzt	Schnitt aus: fälliges Ritual oder offene Reaktion oder nächster Checkpoint-Schritt

Horizon ist mehrschichtig — nicht nur ein Gate.

---

D4 Leading Work Item — polymorph (Kern)

Next Action zeigt auf genau eines der folgenden, je Ranking:

Typ	Wann typisch
CadenceInstance	fälliges/überfälliges Ritual (eine Instanz, kein Duplikat)
CareReaction	offener situativer Strang (Situation → Reaktion); oft Action oder Decision
HorizonStep	nächster Schritt am Care-Checkpoint (Action oder Kriterium)
PrincipleReminder	selten: Prinzip verletzt / Drift ohne konkrete Aufgabe — eher Attention als NA

Nicht Leading: flache Todo-Wand; fremde Rechtsfall-Logik (C1); Skill-Übung ohne Fürsorge-Framing (A1).

---

D5 Lifecycle-Pfad

Schritt	Status	Bedeutung Care
intake	active	Fokus-Person, Prinzipien, Ausgangslage
method_selection	active	Default care_navigation
structure_setup	active	Prinzipien (EFS/Config), optionale Checkpoints, Rituale, Reaktions-Eingang
planning	skip/light	keine Vollplanung; Checkpoints rollierend
action_selection	active	Ranking über Cadence / Reaction / HorizonStep
assignment	active	oft ein Primary Caregiver; Übernahme möglich (später)
waiting	active	auf Ritual-Erledigung, situatives Ereignis, Termin
result_intake	active	Ritual done, Reaktion abgeschlossen, Evidence
validation	optional	Checkpoint-Kriterien
review	optional	Lage der Fürsorge / Retrospektive
adaptation	active	Rituale/Prinzipien/Checkpoints anpassen
closure	skip/soft	Fürsorge oft dauerhaft; Closure nur wenn Fokus endet (z. B. Fall abgeschlossen)

---

D6 Next Action — Ranking (Ziel)

Priorität (Vorschlag):

1. Offene kritische Reaktion (akuter Bedarf, Frist, Sicherheit) → care_reaction_urgent
2. Überfälliges Ritual (verpasste Cadence, Eskalation) → care_ritual_overdue
3. Heute fälliges Ritual → care_ritual_due
4. Checkpoint-Schritt ready → care_checkpoint_ready
5. Sonst ruhige Lage → leerer NA-Kanal + Attention „stabil“ / Prinzip-Drift

Anti-Patterns:

• jedes verpasste Ritual erzeugt neuen Task-Duplikat (A3-Verbot gilt hier analog)
• alle Rituale + Reaktionen als gleichwertige Todo-Liste
• Self-Care als A1-Skill-Training umdeklarieren

Leerer Fall: erlaubt („gerade kein Schritt nötig“) — anders als A2, wo leerer Fall oft Planning Debt ist.

---

D7 Attention

Code	Wann
care_reaction_open	offene Reaktion ohne Fortschritt
care_ritual_overdue	Cadence verpasst
care_checkpoint_at_risk	Meilenstein gefährdet
care_principle_drift	wiederholte Abweichung von Prinzipien
care_caregiver_overload	zu viele offene Lasten auf einem Actor (später)

---

D8 Events

Event	Wirkung
Situatives Ereignis erfasst	öffnet/aktualisiert CareReaction
Ritual erledigt	CadenceInstance schließt; nächster Zyklus geplant (eine Instanz)
Checkpoint verify	Horizon wechselt
Prinzip geändert	Attention/Guidance, kein Auto-Commit von Arbeit
Externer Termin (Arzt, Schule)	kann Reaction oder Waiting speisen — nicht automatisch C1

---

D9 Nested

n/a typisch. Care kann Kind unter B2a sein (selten); dann gilt Child-NA = diese Methode, Parent = Impulse.

---

D10 OM-Voraussetzungen

Minimal	Optional
Initiative initiative.care	Checkpoints als RoadmapItems
CareFocus (EFS oder gleichwertig)	Evidence
≥1 Ritual (Recurring) oder Reaktions-Eingang	Decision bei schweren Abwägungen
Prinzipien (EFS/Text)	Mehrere Fokus-Personen — TBD

---

D11 Extension Points

Art	Ziel
next_action_strategy	care_navigation
steering_elements	next_action_primary, recurring_rhythm, neu care_focus, care_reactions
attention rules	siehe D7
hooks	on_next_action_requested, on_result_received, on_escalation_required, on_reassessment_required
structure builder	optionales Minimal-Kit: Fokus + 1 Ritual + 1 Prinzip

---

D12 Spannungen zum Kandidat-Kern · offene PO-Punkte

Anker	Bedarf
Work-Item-Polymorphie	zwingend (Cadence + Reaction + HorizonStep)
Event-Pfad	zwingend (Situation → Reaktion)
Loop / weiches Closure	zwingend
Horizon mehrschichtig	CareFocus + Checkpoint — Kern-Horizon muss mehr als „ein Gate“ können

PO ✓ (2026-07-25) — in Klartext:

1. Ein Vorhaben = eine Fokus-Person (oder „ich“ bei Self-Care). Mehrere Personen → mehrere Vorhaben / später Programm.
2. Reaktion = normales Arbeitspaket (ggf. kurz über Eingang); kein neues OM-Objekt „CareReaction“ — nur Spec-/Read-Model-Begriff.
3. Meilensteine/Checkpoints optional — Care nur mit Ritualen + Reaktionen ist gültig.

Nächste Methode

Degenerierter Pfad: checklist_flow.