what_to_wear/LEDGER.md

Fortschritts-Ledger — What to Wear (WTW)

Methode: AI-Dev-Method (BMAD + adversariale Reviewer-Linsen + KI-Zweitkritiker qwen/Cloud). Quelle der Methode: /root/.claude/method/DEV-METHOD.md (v1.1) bzw. Repo Kenearos/ai-dev-method. Dieses Ledger überlebt Kontext-Kompaktierung: erledigte Stories, offene Punkte, Gate-Ergebnisse (inkl. je Kritiker-Aufruf geschickter Dateien + Modell), Finding-Urteile.

Stand: 2026-07-13 · Phase: 4 LAUFEND — Epics & Stories (5 Epics, 23 Stories) nach Party-Mode reorganisiert; Readiness-Check läuft · Nächster Schritt: Phase 5 Sprint-Planung + Story-Loop

Benutzer-Entscheidungen E-1…E-4 (2026-07-11)

• E-1 Lizenz: Apache-2.0 (bewusst statt MIT-Vorschlag).
• E-2 Min-HA: ≥ 2025.3 (Subentries; Architekturphase verifiziert gegen reale APIs).
• E-3 Repo-Modell: Forgejo = Entwicklungs-Quelle, öffentliches GitHub = gepflegter Push-Mirror + Vertriebskanal (Releases/Issues auf GitHub — HACS-Pflicht). Kostet Release-Disziplin; vor Release einrichten.
• E-4 Foto-Feld: v1 gestrichen → v1.1 (LagerLens-Connector).

---

Umgebung (für spätere Sessions wichtig)

• Bash läuft als openclaw (uid 1000), kein passwortloses sudo. /root/Labor gehört root; Projektordner /root/Labor/what-to-wear wurde einmalig per sudo an openclaw übereignet.
• qwen-Kritiker nur über Tailscale erreichbar, wenn der Windows-Desktop (100.64.0.2) an ist (am 2026-07-11 erreichbar). Fällt er aus → Cloud-Eskalation openai/gpt-5.6-luna-pro via OpenRouter (QWEN_MAXTOK=16000 QWEN_REASONING=medium Pflicht). Tool: /root/.claude/tools/qwen.mjs.
• Repo: lokal (git master), noch kein Remote. Ziel-Remote später zu entscheiden (Forgejo vs. neues GitHub).

Phase 0 — Intent

Produkt: Quelloffene Home-Assistant-Integration (what_to_wear, HACS), die abends sagt, welche konkreten Kleidungsstücke aus dem Kleiderschrank man für morgen rauslegen soll — deterministisch aus der Wetterprognose, optional sprachlich schön formuliert, ausgespielt über Dashboard/Push/Ansage. Vertriebsprodukt (läuft in jeder Kunden-HA, nicht bei uns).

Design-Entscheidungen (Phase 0/Brainstorm, vom Benutzer freigegeben)

1. Form: Open-Source HACS-Custom-Integration what_to_wear, standalone in jeder Kunden-HA. Kein Vendor-Cloud.
2. Monetarisierung: kostenlos/Open-Source (Reichweite/Reputation, späterer Upsell via LagerLens).
3. Kleiderschrank: Inventar echter Stücke (nicht nur Kategorien), v1 nativ über HA-Sub-Entries.
4. LagerLens: Vision C — Standalone-Kern + optionaler LagerLens-Connector (v1.1), nicht Pflicht.
5. Logik: Hybrid — Regeln bestimmen was, optionaler LLM (Bring-your-own-Key, default AUS) den Ton.
6. Wetterquelle v1: HA-Wetter-Entität via weather.get_forecasts; Open-Meteo als Zweit-Provider v1.1.
7. Ausgabe: Sensor + Service/Event, read-only Lovelace-Karte, 2 Blueprints (Push, TTS) — alle 3 Kanäle.
8. Sprache: de + en.
9. Name: What to Wear (WTW), Domain what_to_wear.

Kritiker-Konsultationen

K1 — Wetterquelle (Design-Entscheidung), 2026-07-11

• Modell: openai/gpt-5.6-luna-pro (Cloud-Eskalation; vom Benutzer ausdrücklich erlaubt, da nuancierte HA-Architekturfrage). Geschickte Datei: scratchpad/wetterquelle-briefing.md. Laufzeit 43 s, 10 Findings.
• Mein Urteil: alle 10 nach eigener Prüfung berechtigt (kein Fehlalarm; starkes Modell).
• Kern-Findings → übernommen ins Design:
  • [KRITISCH] HA hat nicht zwingend eine Wetter-Entität → Config-Flow-Auswahl + klarer Fehlerzustand.
  • [KRITISCH] weather.get_forecasts liefert kein einheitlich reiches Schema (return_response=True, HA-Mindestversion; UV/gefühlt/Böen/Regen-Wkt. oft fehlend) → bewusste Normalisierung, „fehlend ≠ 0".
  • [HOCH] Kein stiller Feld-Fallback zwischen Providern → Provider stabil pro Konfiguration.
  • [HOCH] Open-Meteo nicht pauschal „kostenlos/kommerziell frei" + Koordinaten an Dritte → Opt-in + Attribution + Coordinator/Timeout/Backoff (deshalb v1.1, nicht v1-Default).
  • [HOCH] „Morgen" = lokales Kalenderdatum in config.time_zone (DST 23/25 h), nie now+24h.
  • [HOCH] Einheiten mehr als °C/°F → festes SI-Internmodell, Werte nie aus Feldname/Größenordnung raten.
  • [MITTEL] Provider-Interface = ok; automatisch-fehlertoleranter Open-Meteo-Zweig = Over-Engineering für v1.
• Konsequenz: v1 = nur HA-Wetter-Entität hinter kleinem WeatherProvider-Interface; Open-Meteo v1.1.

K2 — Adversariale PRD-Validierung (4 Linsen, Multi-Agent-Workflow), 2026-07-11

• Aufbau: 4 parallele Reviewer-Linsen (rubrik / adversarial / edge-cases / sicherheit-recht, Claude-Subagenten) auf PRD Rev. 1 + Addendum + Spec; semantisches Dedup; je Finding ein Skeptiker-Agent mit Widerlegungsauftrag und Dokument-Evidenz. 36 Agenten, Detail-Reviews in docs/reviews/prd/review-*.md.
• Ergebnis: 45 Roh-Findings → 31 nach Dedup → 28 CONFIRMED / 3 REFUTED / 0 PLAUSIBLE.
• Urteil: Alle 28 bestätigten Findings in PRD Rev. 2 + Addendum Rev. 2 eingearbeitet (Kernpunkte: Outfit-Komposition/Schichtsumme; Requirement→Stück-Mapping inkl. Streichung profilsohle; Zieldatum-/Umschaltzeitpunkt-Logik statt Mitternachts-Kipp; Min-HA ≥ 2025.3 statt 2024.12 [faktisch falsch]; Karten-/Blueprint-Auslieferung HACS-konform; Degradations- tabelle mit met.no-Realität; Prioritäten je Requirement; Offset-Semantik; kanonische Entity-ID sensor.what_to_wear; Foto → v1.1 [E-4]; FR-6.5/6.6 Datenschutz + Injection; Metriken messbar gemacht inkl. S-4 Retention; NFR-9 Lizenz / NFR-10 Migration; single_config_entry; PRD als führend ggü. Spec deklariert).
• 3 Verwerfungen (mit Evidenz, wie von den Skeptikern belegt):
  1. „Wetter-Entität gelöscht/umbenannt undefiniert" — REFUTED: FR-3.4 + INV-1 decken den Fall (Entität liefert keine Prognose → erklärender Fehlzustand).
  2. „Markenrecht Home Assistant nicht adressiert" — REFUTED: NFR-5/S-3 schließen den brands-Eintrag mit eigenem Icon ein; brands-Review erzwingt das.
  3. „Blueprint-Sicherheitsleitplanken fehlen" — REFUTED: FR-7.4 (nur nutzergewählte Ziele) + NFR-1/INV-5 legen die Leitplanken bereits fest.

K3 — Architektur-API-Verifikation (4 Recherche-Agenten, 2026-07-11)

• Auftrag E-2/NFR-4: alle real genutzten HA-APIs gegen Core-Tag 2025.3.0 verifiziert (Subentries/ Config, weather.get_forecasts, Lovelace/HACS/Blueprints, Services/i18n/LLM/Testing) + Nachverifikation (Subentry-Update-Listener, Coordinator-Shutdown/Lock). Ergebnis: min-HA 2025.3 HALTBAR (Subentry- Reconfigure ab 2025.3 in nativer UI). Kernbefunde: get_forecasts liefert ANZEIGE-Einheiten; met.no nie apparent_temperature (§3a-Fallback = Normalfall); kein strings.json für Custom-Integrationen; SupportsResponse.OPTIONAL; API-Fallen 2025.3/2025.4/2025.8/2025.12/2026.2 dokumentiert. Belege: .memlog.md (Einträge 14–39) im Architektur-Workspace.

K4 — Adversariale Architektur-Validierung (6 Linsen, 2026-07-11)

• Aufbau: 5 Reviewer-Linsen (Rubrik / Web-Verifikation / Inkompatibilitäts-Angriff / Edge-Cases / Sicherheit-Recht) + Input-Abgleich (122 Punkte), parallel als Claude-Subagenten auf Spine Rev. 1. Detail-Reviews: _bmad-output/planning-artifacts/architecture/architecture-what-to-wear-2026-07-11/reviews/.
• Ergebnis: Web-Verify 0 Sachfehler; Inkompat 17 Löcher (5 KRITISCH), Edge-Cases 16 Findings (1 KRITISCH), Rubrik 10, Sicherheit 7, Abgleich 7 FEHLT/12 teilweise. Alle Findings selbst geprüft: sämtlich berechtigt → Spine Rev. 2: neue AD-19…AD-24 (kanonischer Payload, Textmodell, Requirement-Registry, Item-Schema, Options-Schema, Parsing-Besitz) + Schärfungen AD-1…AD-18.

Gate 2 — Architektur (2026-07-11)

• Modell: openai/gpt-5.6-luna-pro via OpenRouter — Ersatz für qwen (qwen offline: Desktop pingt, Port 8088 zu; gleiche Lage wie Gate 1, dortige Benutzer-Freigabe »weiter mit luna-pro«). Laufzeit 69 s. Geschickte Datei: ARCHITECTURE-SPINE.md (Rev. 2) — ein Aufruf.
• NICHT-melden-Liste (wörtlich): »E-1 Lizenz Apache-2.0; E-2 minimale HA-Version 2025.3; E-3 Forgejo-Entwicklungsquelle + öffentlicher GitHub-Push-Mirror als Vertriebskanal; E-4 kein Foto-Feld in v1; PRD-Non-Goals v1 (Open-Meteo, LagerLens-Connector, CRUD-Karte, Mehrpersonen-Profile, Rotation, Export/Import, Aktivitätskontext, Wäschestatus, Telemetrie); die im Dokument als [PRÄZISIERUNG] markierten, im Ledger dokumentierten PRD-Abweichungen.«
• Ergebnis: 9 Findings (3 KRITISCH / 5 HOCH / 1 MITTEL). Urteile (Evidenz im Memlog E42):
  1. Zeitbudget 10+25>30 s ✔ übernommen (LLM-Timeout 18 s + Budget-Arithmetik in AD-6)
  2. Service-Frische-Race ✔ teilweise — Serialisierung in den Coordinator verlegt (asyncio.Lock um _async_update_data); Verifikation zeigte: async_refresh startet eigenen Lauf, Risiko war Überschreiben durch parallelen Alt-Lauf, nicht Warten
  3. coordinator.data is None beim Erstfehler ✔ übernommen (Fehler-Contract in AD-7)
  4. Event-/Response-Limits ✔ übernommen (strukturelle Begrenztheit + to_event-Assert, AD-19)
  5. Semantische LLM-Manipulation ✖ verworfen als Architekturänderung (Evidenz: FR-6.6 final definiert die objektiven Kriterien; semantische Validierung nicht objektiv entscheidbar) — als dokumentiertes Rest-Risiko in AD-16 + README aufgenommen
  6. LLM-Response-Body ungedeckelt ✔ übernommen (64-KB-Cap, AD-6)
  7. AD-10↔AD-12-Widerspruch ✖ verworfen (Evidenz: AD-10 verbietet dict-ITEM-Zugriff hass.data["lovelace"]["…"], AD-12 nutzt Attribut-Zugriff .mode/.resources); Stabilitätsrisiko-Teil ✔ teilweise (Ressourcen-Test im latest-CI-Job, AD-18)
  8. Private Subentry-Helper ✖ verworfen als Blocker (Evidenz: offizielles Dev-Doku-Muster + Kompat-Kaskade AD-9 + CI-Matrix fängt Drift); Migrations-Robustheit ✔ übernommen (AD-8)
  9. Naive datetimes ✔ übernommen (verwerfen statt Zeitzone raten, AD-24)
• Status: Gate 2 BESTANDEN (nach Einarbeitung; Spine status: final).

Phase 4 — Epics & Stories + Party-Mode (2026-07-13)

• Artefakt: _bmad-output/planning-artifacts/epics.md — 5 Epics, 23 Stories, alle mit Given/When/Then + FR-/AD-Referenzen. Reihenfolge vorwärts-abhängigkeitsfrei; »15-Min-Wow« (S-2/JTBD-3) landet Ende Epic 2.
• Party-Mode (Pflicht, 4 Linsen parallel: Architekt/Dev/PM/UX): Draft (5 Epics/19 Stories) → reorganisiert (5 Epics/23 Stories). Alle Findings selbst geprüft, sämtlich berechtigt:
  • PM [KRITISCH]: Golden-Path über 3 Epics verstreut → Epic 2 = »15-Minuten-Wow« (Kleiderschrank+Karte+Service+Push zusammengezogen).
  • Architekt [HOCH]: Story 1.6/1.7 zu groß → gesplittet (1.6 ha_entity+Provider-Port / 1.7 Coordinator / 1.8 Config-Flow+Lebenszyklus / 1.9 Sensor+Stale); changed/Store-Owner → Coordinator (1.7); AD-23-Options-Schema einmalig in 1.1/const.py; CI-grün von Mirror entkoppelt.
  • Dev [HOCH]: RawForecast/NormForecast ins Modell (1.1); WeatherProvider-Protocol-AC (1.6); __init__-Unload-Lebenszyklus (1.8); NFR-7-Timing-Assert (1.7).
  • UX [KRITISCH]: stale-Feld nutzersichtbar (Payload 1.5 + Sensor-Owner 1.9 + Karten-Render 2.3); Erklärbarkeit im Volltext (1.5); Doku-Links in Config-Flow-Fehlern (1.8); Ton-Indikator auf Karte (2.3).
  • LLM-Phraser (rein) von LLM-Client (Adapter) getrennt (4.2/4.3).
• Readiness-Check (adversarial): READY-MIT-AUFLAGEN → alle 34 FRs / 10 NFRs / 24 ADs in ≥ 1 Story-AC; alle 10 Party-Mode-Fixes bestätigt. 3 Auflagen eingearbeitet: (1) 1.8/1.9- Plattform-Naht (1.8 testet mit PLATFORMS=[], 1.9 schaltet Forwarding scharf → keine Forward-Dependency); (2) NFR-1 expliziter Netz-Abstinenz-Assert im 5.3-E2E; (3) 1.4-Matcher emittiert sprachneutrale Grund-Keys, 1.5 lokalisiert (AD-13). epics.md status: final.
• Test-Umgebung provisioniert: .venv (Python 3.13.11) + pytest-homeassistant-custom-component ==0.13.225 (HA 2025.3.4 = Min-Ziel) + pytest 8.3.4. aiohttp==3.11.13 ist yanked → expliziter Pin nötig (für CI-Requirements merken). Bereit für den Story-Loop.

Dokumentierte PRD-/Addendum-Präzisierungen (Architekturphase, FR-4.1-konform)

1. FR-7.1 »LLM-Text in State/Karte« → State trägt max 255 Zeichen ⇒ llm_text nur in Event + Service-Response; Karte v1 = Kurztext + Strukturdaten (AD-20).
2. Addendum §5 »Morgenfenster vollständig abdecken« → ≥ 1 hourly-Eintrag im Fenster (AD-17).
3. Addendum §5 Tagesaggregate »aus daily« → bei fehlendem daily deterministisch aus hourly (AD-17).
4. Addendum §8 »englische Namen via Translations« → logic/texts.py (hassfest-Schema, AD-13).
5. FR-2.1-UI-Kategorien → englisches Enum + Selector-Translations (AD-22).
6. Statusmenge: effektiv leerer Schrank ist kein Fehlerstatus, sondern Empfehlungsinhalt (AD-2).

Gate 1 — PRD (2026-07-11)

• Modell: openai/gpt-5.6-luna-pro via OpenRouter — Ersatz für qwen (qwen offline: Desktop pingt, Port 8088 zu; Benutzer-Freigabe »weiter mit luna-pro«). Laufzeit 58 s.
• Geschickte Dateien: _bmad-output/planning-artifacts/prd.md (Rev. 2) + _bmad-output/planning-artifacts/prd-addendum.md (Rev. 2) — ein Aufruf.
• NICHT-melden-Liste (wörtlich, wie an den Kritiker gesendet): »kostenlos/Open-Source ohne Telemetrie; Kleiderschrank als Inventar echter Stücke; LLM-Ton optional per Bring-your-own-Key (default aus); Wetterquelle v1 ausschließlich HA-Wetter-Entität; LagerLens-Connector, Open-Meteo, CRUD-Karte, Mehrpersonen-Profile, Foto-Feld, Rotation, Export/Import erst v1.1; Zielplattform Home Assistant; Sprachen de+en.«
• Ergebnis: 12 Findings (3 KRITISCH / 5 HOCH / 4 MITTEL). Eigenes Urteil: alle 12 übernommen (2 davon teilweise, s. u.). Fixes in PRD Rev. 3 + Addendum Rev. 3:
  1. Umschaltzeitpunkt-Recompute exakt (FR-7.5) ✔ übernommen
  2. Forecast-Zeitzuordnung/TZ + prognose_stand (Addendum §5, FR-7.1) ✔ teilweise — der Teil »frisch berechnet, aber Provider-Forecast veraltet« ist über prognose_stand-Attribut sichtbar gemacht, ein hartes Alters-Limit der Provider-Prognose bewusst nicht definiert (Evidenz: HA liefert kein verlässliches Prognose-Erzeugungsdatum über get_forecasts; Erkennbarkeit statt Blockade).
  3. FR-6.6 objektive Abnahmekriterien + Injection-Testkatalog ✔ übernommen
  4. Service-Response statt Event-Race (FR-7.2) ✔ übernommen
  5. Test-Abruf: Timeout + 4. temporärer Fehlerfall (FR-1.2) ✔ übernommen
  6. Subentry-Annahme ✔ teilweise — CI-Test gegen Minimalversion ergänzt (NFR-4); Migration/Löschen bereits durch NFR-10/FR-2.4 abgedeckt (Evidenz: Zitate ebd.).
  7. Zusammengesetzte Wärmebedarf-Lücke + Konfliktvorrang (Addendum §4.6) ✔ übernommen
  8. Lovelace-Registrierung präzisiert: idempotent, ?v=, YAML-Erkennung, Deregistrierung ✔
  9. Options-Struktur + Offset-Scope (nur °C-Schwellen) (FR-1.4/4.2) ✔ übernommen
  10. Attribut-/Event-Größengrenzen (FR-7.1) ✔ übernommen
  11. Sprachbindung dynamisch vs. registriert (FR-1.3) ✔ übernommen
  12. Beispiel-Set normativ (Addendum §8 + Abnahmetest) ✔ übernommen
• Status: Gate 1 BESTANDEN (nach Einarbeitung; PRD final nach Benutzerfreigabe E-1…E-4).

Gates (Status)

Gate	Gegenstand	Modell	Datei(en)	Status
—	Wetterquelle (Design)	luna-pro	wetterquelle-briefing.md	✅ verifiziert
—	PRD adversarial (4 Linsen)	Claude-Workflow	prd.md, prd-addendum.md, Spec	✅ 28/31 übernommen
Gate 1	PRD Rev. 2→3	luna-pro (qwen-Ersatz)	prd.md + prd-addendum.md	✅ bestanden, 12/12 übernommen
Gate 2	Architektur Rev. 2	luna-pro (qwen-Ersatz)	ARCHITECTURE-SPINE.md	✅ bestanden, 9 Findings (6 übernommen, 3 verworfen mit Evidenz)
Gate 3	Code (Security)	qwen/luna	—	offen

Architektur-Artefakt: _bmad-output/planning-artifacts/architecture/architecture-what-to-wear-2026-07-11/ (ARCHITECTURE-SPINE.md final, 24 ADs; .memlog.md 43 Einträge; reviews/ 6 Linsen). Paradigma: Pipes-and-Filters-Kern (logic/, hass-frei) in Ports-and-Adapters-Schale.

Stories

• (noch keine — folgen aus Phase 4 Epics/Stories)

Offene Punkte / nächste Schritte

• Phase 4: Epics & Stories aus dem Spine + Party-Mode + Readiness-Check.
• Autonomer Durchlauf (Goal-Hook, Benutzer abwesend): qwen offline → Gates mit luna-pro (dokumentiert).
• Bei Phase 7: irreversible/identitätskritische Schritte (GitHub-Mirror-Setup E-3, brands-PR, HACS-Default-Antrag, Version-Tag/Release) dem Benutzer vorlegen, nicht selbst ausführen.