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-11 · Phase: 2 abgeschlossen (Gate 1 bestanden; PRD final nach Benutzerfreigabe E-1…E-4)

---

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.

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	qwen/luna	—	offen
Gate 3	Code (Security)	qwen/luna	—	offen

Stories

• (noch keine — folgen nach PRD + Architektur + Epics/Stories)

Offene Punkte / nächste Schritte

• Benutzer-Review des Specs (docs/superpowers/specs/2026-07-11-what-to-wear-design.md).
• Danach DEV-METHOD-Kanal: BMAD-Installation (npx bmad-method install … --directory /root/Labor/what-to-wear, legt Verzeichnisse an → Benutzer-OK), dann PRD → adversariale Linsen → qwen-Gate 1.
• Kleinentscheidungen offen: Lizenz (Vorschlag MIT), Min-HA-Version (Vorschlag 2024.12+).