patch76/ha-betriebshandbuch

HA-Betriebshandbuch für Claude-Instanzen

Dieses Handbuch enthält nur instanzunabhängiges Wissen: API-Syntax, YAML-Regeln, Storage-Schemata, bekannte Fallen. Instanz-spezifische Daten (Entity-IDs, IPs, Tokens, Automationslisten) gehören in die jeweilige claude.md.

---

0. Arbeitsweise (Pflichtregeln)

• Verifikationspflicht: Kein Wissen ungeprüft übernehmen — weder aus Doku noch aus einer anderen Claude-Instanz. Vor Eintrag in claude.md live testen oder per API verifizieren.

• Skill-Referenzen: immer vollständig qualifizieren (PFLICHT): Jede Referenz auf einen Skill oder Skill-Abschnitt muss Repo + Pfad enthalten. Verboten: → Skill §X, SKILL.md §X oder im Skill ohne Repo-Angabe. Korrekte Formate:

  • Patch76/ha-betriebshandbuch SKILL.md §X — ha-betriebshandbuch Hauptdatei
  • Patch76/ha-betriebshandbuch references/<datei>.md — Referenz-Dateien
  • homeassistant-ai/skills home-assistant-best-practices/SKILL.md — best-practices Skill

• EISENGESETZ: KEIN write_file auf kritische Dateien ohne vorherige Backup-Rotation (→ §2.7). DATEI.bak → DATEI.bak.prev · DATEI → DATEI.bak · erst dann write_file. Gilt für: claude.md, alle manuell gepflegten /config/*.yaml (configuration.yaml, automations.yaml, template.yaml, scripts.yaml, scenes.yaml, sensor.yaml und gleichartige — ausgenommen secrets.yaml und von Add-ons/Integrationen automatisch generierte YAML-Dateien), alle .storage/-Dateien. secrets.yaml: write_file grundsätzlich verboten — Credentials dürfen nie per Agent überschrieben werden. Keine Ausnahme. Keine Ausnahme: nicht für kleine Änderungen, nicht wenn Datei frisch geladen, nicht im Notfall. Den Geist zu befolgen bedeutet den Buchstaben zu befolgen.

• EISENGESETZ: Kein str.replace() ohne frischen repr()-Check des Ankers (→ §2.7 R2). Gilt besonders bei §!-Writes auf claude.md: Datei unmittelbar vor jedem Replace lesen, Anker 1:1 aus repr()-Output ableiten — nie aus Session-Gedächtnis rekonstruieren. Vorige Schreibvorgänge können Zusätze enthalten, die den gemerkten Anker ungültig machen.

• API-Antworten in Python verarbeiten: Immer urllib.request (→ §2.7) oder -o /tmp/datei.json + Heredoc. NIEMALS curl ... | python3 - << 'HEREDOC' — stdin-Konflikt, curl-Daten gehen verloren (→ §2.6). Symptom: JSONDecodeError: Expecting value: line 1 column 1 — täuschend, weil stdin leer, nicht fehlerhaft.

• Bei unbekanntem Fehler zuerst web_search — nicht mehr als 3 gescheiterte Versuche ohne neue Information.

• Gate-Versagen (allgemein): Schlägt ein Gate fehl (Check nicht bestanden, Bedingung nicht erfüllt), gilt: sofort stoppen — Befund benennen, nicht improvisieren, auf Anweisung warten. Gilt für alle Gates (G1–G9). Ausnahme G6 (Backup-Gate): bei fehlendem .bak-Slot überspringen und write_file trotzdem ausführen — das ist kein Versagen, sondern Erstlauf. Ausnahme G9 (GB-Precheck): bei Fund → Fix lokal, dann erneut prüfen, kein Commit vor grünem Check.

• Freigabe-Prinzip (kanonisch):

  1. Grundregel: Explizites „ja“/„ok“ vor jeder angekündigten Aktion — nie ankündigen + fragen + sofort ausführen.
  2. Scope: Eine Freigabe gilt für die vollständig angekündigte Aktionskette. Commit + PR + Merge zusammen angekündigt → Merge eingeschlossen, kein zweites „ja“ nötig. Nur Commit angekündigt → Merge braucht separate Freigabe. Claude benennt die vollständige Kette vorab — nie kürzer ankündigen als sie ist.
  3. §Sicht ≠ Freigabe: §Sicht-OK ist keine Handlungserlaubnis. Nach §Sicht: Plan vorlegen, auf „ja“ warten.
  4. Timeout: Bleibt „ja“ dauerhaft aus → §! ausführen, Session beenden.

• Öffentliche Doku-URLs: web_fetch nur mit URLs die im Kontext bekannt sind: vom Nutzer angegeben, aus web_search-Ergebnissen oder früheren web_fetch-Calls. Keine selbst konstruierten URLs. Browser (computer-Tool) nur für HA-UI (Auth-geschützt) oder interaktive Seiten — nicht für Doku. Muster: web_search("HA integration xyz site:developers.home-assistant.io") → dann web_fetch(url).

• Verifikation vor destruktiver Aktion: Befunde, die eine destruktive Aktion begründen (Löschen, Entfernen, PR), immer einzeln und isoliert verifizieren — nie aus Schleifenergebnissen ableiten. Netzwerkfehler in Schleifen erzeugen Falsch-Negative.

• Neustart nur mit expliziter Benutzerbestätigung.

• AW-Lesbarkeit (Umgebungsunterschied): In der claude.ai-Umgebung ist die AW (Projektanweisung) direkt im Context-Window — kein curl, kein bash_tool, kein Dateipfad nötig. Memory analog (userMemories-Tag). In Claude Code dagegen existieren Dateipfade (CLAUDE.md, ~/.claude/).

• Pflichtsequenz-Gate (PFLICHT nach Schritt 4): Nach Abschluss aller 5 Schritte (0–4) Gate-Signal ausgeben: PFLICHTSEQUENZ-GATE: PASSED — S0:[Dateiname/skip], S1:[Zeilenzahl claude.md], S2a:[Zeilenzahl SKILL.md], S3:[Kanal-Status], S4:[github.md Zeilenzahl] Bei Fehler: PFLICHTSEQUENZ-GATE: FAILED — S2a:[FEHLER: curl 404] (Slot mit Fehlerbeschreibung). Jeder Slot muss einen konkreten, aus der tatsächlichen Ausführung stammenden Wert enthalten — kein Weiterfahren ohne vollständiges Signal.

• Kein Zeilenlimit auf Pflichtdateien: Kein head/tail und keine nachgelagerte Kürzung (sed, awk, cut, Python-slice) auf SKILL.md, claude.md, references/*.md, session_handoff.md, Kanal-Dateien. Vollständiger curl ohne Pipe-Limit — Pflicht.

• Vor HA-Updates: ha_get_updates(entity_id="update.home_assistant_core_update", include_release_notes=True) ausführen (Impact-Review). Prüft Breaking Changes und Hinweise vor dem Update — Pflicht bevor homeassistant/restart nach einem Update ausgeführt wird.

• GitHub-PRs immer als Draft anlegen (via bash_tool + GitHub REST API). "draft": true im POST-Body an POST /repos/Patch76/<repo>/pulls. Manuell auf „Ready" setzen.

• Live abrufen statt fragen: Ist ein Zustand per API prüfbar (Entity-State, last_triggered, Attribut), immer live abrufen — nie den Nutzer fragen. Fragen nur wenn der Kontext wirklich nicht abrufbar ist.

• Status-Verifikation vor Nutzer-Anweisung: Bevor Claude dem Nutzer sagt „poste X", „klicke Y" oder „führe Z aus", muss der aktuelle Zustand des betreffenden Objekts (Comment-Liste, PR-Status, Branch-Stand) unmittelbar vor der Anweisung live abgerufen worden sein — nie aus dem Gedächtnis.

• claude.md-Schreibschutz (Drift-Prävention): Inhalte, die vollständig in SKILL.md, AW oder references/.md dokumentiert sind, gehören nicht in claude.md — auch nicht als Kurzfassung, Reminder oder Zusammenfassung. Erlaubt: instanzspezifisches Betriebswissen das nicht live abrufbar ist (Connector-Name, bekannte Hardware-Eigenheiten, Verifikationsdatum) und Kurzverweise der Form → Patch76/ha-betriebshandbuch SKILL.md §X (ha-betriebshandbuch) oder → homeassistant-ai/skills home-assistant-best-practices/SKILL.md (best-practices). Nicht erlaubt: Entity-IDs, States und Hardware-Konfiguration — diese sind via ha-mcp oder REST jederzeit live abrufbar und veralten in claude.md lautlos. Betriebswissen und bekannte Eigenheiten (z.B. Hardware-Interaktionen die Automationen beeinflussen) sind davon ausgenommen — sie sind Erfahrungswissen, kein abrufbarer State. Zweifelsregel: Steht der Inhalt bereits in SKILL.md, AW oder references/.md → claude.md-Eintrag ablehnen oder löschen. (→ references/meta.md §22.4)

• Skill-Pflege (KRITISCH): Beim Aktualisieren des Skills gilt:

  • Veraltetes Wissen streichen oder als ⚠️ VERALTET kennzeichnen — nie still ergänzen.
  • Neues Wissen ersetzt altes: beide Stellen anpassen (nicht nur neue Sektion anfügen).
  • Querverweise prüfen: Verweist §X auf §Y? → §Y-Änderung erfordert §X-Check.
  • Nur live getestetes oder per API/Doku verifiziertes Wissen eintragen.
  • Neue Regel aus Postmortem: Rationalisierung verbatim dokumentieren ("Agent hat X gemacht weil...") — das ist die RED-Phase. Erst dann Regel schreiben.
  • Formulierungsregel für neue Instruktionen (ECC-Prinzip): Jede neue zeitliche Bedingung ("vor X", "nach Y", "bei Z") prüfen: Ist das Ereignis für den Agenten observierbar? Wenn nein → als Phasen-Trigger formulieren + Gate-Signal definieren (→ references/signals.md Abschnitt "Designprinzip: Explicit Checkpoint Confirmation"). Entscheidungsregel: Kritischer Übergang / Multi-Step / irreversible Aktion → ECC. Atomare Aktion / Low-criticality / innerhalb einer Phase → temporale Formulierung reicht.
  • Instanzübergreifende Wissensänderungen (API-Verhalten, neue §§, Templates): Kanal-Abstimmung (lb-rbo-channel) vor PR Pflicht — nicht die Anwendung, nur die Änderung gemeinsamen Wissens triggert Abstimmung.
  • Instanzübergreifende Behauptungen im Kanal: mit [UNVERIFIZIERT-LB] / [UNVERIFIZIERT-RBO] kennzeichnen, wenn nicht live getestet.
  • Body-Limit (upstream CONTRIBUTING.md): Skill-Body unter 500 Zeilen halten. Bei Annäherung an das Limit: Inhalt in references/ auslagern (→ §2.10 als Vorlage). Aktuell: ~382 Zeilen (Stand 13.04.2026).

• Kanal-Verifikationspflicht beim Einlesen (KRITISCH): Behauptungen aus lb_to_rbo.md / rbo_to_lb.md nie blind übernehmen — immer live gegen die eigene Instanz gegenchecken, bevor eine Änderung umgesetzt wird.

  | Behauptungstyp | Verifikation | |---|---| | CLAUDE.md wurde geändert | read_file /config/CLAUDE.md → Stichprobe der behaupteten Stelle | | API-Verhalten (z.B. Pfad-Regel) | Testaufruf mit bekanntem Ergebnis durchführen | | MCP-Tool verfügbar | ha_list_services oder Tool direkt aufrufen | | Nicht testbar | Als [UNVERIFIZIERT] kennzeichnen — nie stillschweigend als wahr annehmen |

  Ergebnis der Verifikation in der eigenen Antwort-Nachricht (rbo_to_lb.md / lb_to_rbo.md) kurz dokumentieren: ✓ verifiziert / ✗ abweichend (mit Befund).

Kanalschreib-Pflicht (KRITISCH — gilt für jede sendende Instanz)

Kanaldateien (lb_to_rbo.md / rbo_to_lb.md) sind kumulative Dokumente. Ein PUT ohne vorherigen Lesevorgang überschreibt den gesamten Kanalinhalt — ältere Nachrichten sind unwiederbringlich verloren.

Pflichtablauf vor jedem Kanalschreiben:

1. Datei vollständig lesen (GET contents/lb_to_rbo.md) → Inhalt + SHA sichern
2. Neuen Block an bestehenden Inhalt anhängen
3. Gesamtinhalt (alt + neu) als content (base64) mit aktuellem sha per PUT zurückschreiben

TOCTOU-Pflicht: SHA und Content in einem einzigen JSON-Call holen — nicht zwei separate Requests (raw-Accept + JSON für SHA). Zwischen zwei Calls kann ein anderer PUT dazwischenkommen → veralteter SHA → 409 Conflict oder stille Überschreibung. existing = base64.b64decode(GET_json(lb_to_rbo.md)['content']).decode('utf-8')

Anti-Pattern:

# FALSCH — überschreibt alle bisherigen Nachrichten:
payload = {"message": "...", "content": base64(nur_neue_nachricht), "sha": sha}

Korrekt:

# RICHTIG — lesen, anhängen, zurückschreiben:
existing = base64.b64decode(GET(lb_to_rbo.md)['content']).decode('utf-8')
full_content = existing + neue_nachricht
payload = {"message": "...", "content": base64(full_content), "sha": sha}

Kanal-Semantik: Zweck und Trigger-Schwelle

Der Kanal ist ein Drift-Abstimmungs-Instrument — kein Archiv, kein Sync-Tool für Skills.

Senden wenn (DRIFT-SYNC): Änderung an claude.md oder AW-Struktur, die die andere Instanz ohne eigene Anpassung strukturell anders verhalten ließe — und die Mirko nicht im Chat bereits explizit als „gilt für beide Instanzen" oder „bereits auf [Instanz] umgesetzt" markiert hat.

Nicht senden:

• Instanzspezifisches (Entity-IDs, Hardware, Connector-Stand)
• SKILL.md-Änderungen — werden bei Sessionstart automatisch geladen
• Trivia oder reine Informationen ohne Handlungsbedarf für die andere Instanz

Kategorie: Nur DRIFT-SYNC. Frühere Kategorien (FAKT-SYNC, STRUKTUR-SYNC, PATTERN-SYNC) entfallen — sie führten zu Trivial-Nachrichten ohne Drift-Relevanz.

Empfänger-Pflicht (verbindlich)

Jede Kanalnachricht erzeugt auf Empfängerseite eine Pflichtreaktion. Schweigen und beiläufiges BESTÄTIGT ohne Inhalt sind keine gültigen Antworten.

Genau eine der drei Reaktionen ist zu dokumentieren:

| Reaktion | Bedeutung | |---|---| | → UMSETZUNG | Ausarbeitung der Änderung + Mirko-Freigabe auf Empfängerseite einholen | | → ABLEHNUNG | Begründete Ablehnung (z.B. nicht zutreffend auf dieser Instanz) | | → BEREITS UMGESETZT | Mirko hat im Chat explizit bestätigt dass Änderung gilt oder umgesetzt ist |

Nur explizite Formulierungen zählen als „bereits umgesetzt" — thematische Bestätigung im Gesprächskontext genügt nicht.

Kanal-Purge

Block ist löschreif sobald Empfänger eine der drei Reaktionen dokumentiert hat und Mirko-Freigabe vorliegt. Kein beidseitiges BESTÄTIGT-Ritual nötig.

Durchführung (expliziter Schritt, nicht bei §! automatisch):

1. Löschreife Blöcke identifizieren (Empfänger-Reaktion dokumentiert)
2. Mirko-Freigabe einholen
3. Bereinigte Version als neuer PUT — Commit-Message: Kanal-Purge: Sessions X–Y
4. GitHub-History als Backup — kein Datenverlust möglich

Anonymisierung und Identitätswahrung (KRITISCH)

Kanalnachrichten dürfen keine Credentials, Tokens, IPs oder instanzspezifischen Zugangsdaten enthalten. Vor jeder Übernahme zwingend gegen eigene Instanz prüfen.

Antwortpflicht

Jede Kanalnachricht trägt einen Status-Header:

• ## Status: OFFEN — Empfänger-Reaktion ausstehend
• ## Status: ERLEDIGT — Reaktion dokumentiert, löschreif nach Mirko-Freigabe

Beim Einlesen des Kanals (→ Schritt 3 Pflichtsequenz): Alle OFFEN-Blöcke identifizieren — in der laufenden Session reagieren. Schweigen ist keine gültige Antwort.

Pflicht-Warnblock (Kopf jeder Kanalnachricht — zwingend)

⚠️ IDENTITÄTSPFLICHT — Absender: [Instanz]. Alle Inhalte sind Erkenntnisse dieser Instanz.
VOR jeder Übernahme zwingend gegen eigene Instanz prüfen:
Token · Credentials · PAT · Entity-IDs · Helper-Namen · IPs · Pfade · BSSIDs · Zonen
Nicht verifiziert = nicht umsetzen. (→ §0 Kanal-Verifikationspflicht)

---

PR-Review-Sequenz für upstream PRs

Scope: Diese Sequenz gilt für Dokumentations-PRs auf homeassistant-ai/skills (YAML). Für Code-PRs auf homeassistant-ai/ha-mcp gilt §PR-Gate (→ references/github.md) als maßgebende Struktur — die Schritte dieser Sequenz sind dort integriert.

• Verhältnis zu §PR-Gate: Diese Sequenz ist eine ha-skills-spezifische Konkretisierung von §PR-Gate Ebene 2 (Rebase + Gemini + §Sicht). Sie ersetzt §PR-Gate nicht, sondern ergänzt es mit Docs-Repo-spezifischen Checks (YAML-Syntax, Stil-Modell, Key-notes).
• GitHub-Gate (→ references/github.md §Git): einmalig beim Eintritt — läuft zusätzlich.
• §Sicht standalone (AW §⑤): on-demand — erfüllt Schritt 3 dieser Sequenz nicht.

Sequentiell, nicht optional. Für ha-skills-PRs.

Begründung: Claude (Stufe 2) ist 10–30× teurer als Gemini/Llama (Stufe 1). Stufe 1 ist kein Gatekeeper — er lenkt die Aufmerksamkeit von Stufe 2. Claude reviewt immer, aber mit unterschiedlicher Tiefe.

1. Rebase-Gate        kostenlos    GET /repos/homeassistant-ai/skills/commits?path=<datei>
                                   → Stale Branch = dirty diff = unbeabsichtigte Reverts
                                   → Bei Staleness: erst rebasen, dann weiter
                                   → Nach Rebase: `git diff upstream/main..HEAD --stat` auf
                                     Gesamt-Diff — jede unerwartete Datei = Stopp-Signal.
                                     Kein Push bevor jede Zeile im Diff erklärt ist.

2. Gemini-Check       ~$0.003      PR-Diff → Gemini 2.5 Flash via OpenRouter (anonymisiert!)
                                   → Befunde: Claude prüft Claim-Taxonomie (A_Output) + alle 4 Filter: A_Output, B_Output, C_Output, D_Output_Docs
                                   → Keine Befunde: Claude prüft kompakt: A_Output, B_Output, D_Output_Docs

3. §Sicht             teuer        Vierfach-Review — immer, Tiefe nach Gemini-Output

Stufentrennung (was gehört wohin):

| Stufe 1 — Gemini (kontextfrei) | Stufe 2 — Claude (kontextabhängig) | |---|---| | CONTRIBUTING.md-Compliance | Falsch-Positiv-Bewertung (live verifizieren) | | Undokumentierte API-Referenzen | PR-Formulierungen und Antworten | | Interne Klassen-Namen in Tabellen | Entscheidungen mit Systembruch-Risiko | | AVOID/CORRECT-Block-Vollständigkeit | Strukturelle Urteile (Shared-Repo vs. Betriebshandbuch) |

Compact-Review-Filter (Schritt 3 ohne Auxiliary-Befunde): A_Output, B_Output, D_Output_Docs (→ Filter-Registry mit vollständigen Definitionen: references/sicht.md)

• A_Output Veritas: nie weglassen — schützt gegen Auxiliary-False-Negatives
• B_Output Adversarial: kein context-freies Modell kann den Gegenfall für spezifischen Projektkontext formulieren
• D_Output_Docs Integrität: Compliance + Systembruch-Nebenwirkungen
• C_Output Scope entfällt: Auxiliary-Modelle können strukturelle Einordnung übernehmen; am stärksten kontextabhängig

Grenzen: Nicht jede Aufgabe fällt eindeutig in eine Stufe. CONTRIBUTING.md-Compliance kann Kontext brauchen (Warum ist dieser Tool-Name verboten?). Im Zweifel: Gemini-Befund als Hinweis werten, Claude entscheidet. Policy-Dokumente upstream (z.B. AGENTS.md), die Gemini als Gegenargument zitiert: Entstehung der Regel live prüfen — fabricated citations in Maintainer-Disputes sind möglich und verifiziert vorgekommen. Nie aus Session-Memory zitieren — immer frisch lesen.

Session-Ökonomie: Lange Sessions schleppen gesamten Kontext mit. §! bei natürlichen Meilensteinen — frische Session = sauberer Kontext. Referenz-Dateien bedarfsgesteuert nachladen (→ §? und AW Schritt 2b). §! / §R / §? / §Sicht / §Fakten / §Git / Weiter: → references/signals.md nachladen. Kein Signal ausführen ohne signals.md geladen.

• Pre-Action Phase-Checkpoint: Vor destruktiven/mehrstufigen Aktionen (write_file kritisch, PR-Merge, HA-Neustart, Automation-Änderung) im Output: Phase: [X] · Aktion: [Y] · Letzter Stand: [Z] Zweck: Bei Session-Interrupt enthält Output-History genug für §R-Recovery.

Pre-Action Rule-Summary (Fading-Schutz): Bei write_file-kritisch, PR-Merge, HA-Neustart vor der Aktion drei kritischste Regeln explizit rekapitulieren:

1. Freigabe + Scope: „ja“ erhalten? Kette vollständig angekündigt? (→ §0 Freigabe-Prinzip Punkte 1+2)
2. Backup: Slot-Rotation ausgeführt? → kein Write ohne Backup.
3. Merge: In Kette eingeschlossen oder separate Freigabe nötig? (→ §0 Freigabe-Prinzip Punkt 2) Zweck: Proaktiver Fading-Schutz in langen Sessions — nicht von Agent-Selbsterkenntnis abhängig.

---

28. §Fakten — Forensischer Verifikations-Modus

→ references/signals.md nachladen (bei §Fakten-Signal).

---

1. REST API — Endpunkte & Syntax

→ references/rest-api.md nachladen (bei API-Calls, Endpunkt-Fragen, Template-/History-/Logbook-API).

2. shell_command — JSON-Parse-Pfad (KRITISCH)

→ references/shell-commands.md nachladen (bei write_file, read_file, delete_file, run_python, atomarem Zyklus).

20. Bekannte Anti-Patterns (Schnellreferenz)

→ references/anti-patterns.md nachladen (vor write_file / run_python / GitHub-Aktionen).

23. Verifikation nach Änderungen

24. Fehlerdiagnose — Rückwärtstracing

→ references/meta.md (nachladen bei aktivem Debugging / unbekanntem Fehlerzustand). Kernprinzip: Nie am Symptom fixen — Quelle finden. Symptom → Immediate Cause → Quelle → Fix.

25. §R Interrupt-Recovery-Protokoll

→ references/meta.md (nachladen bei Signal §R / Kontextverlust). EISENGESETZ: Kein Improvisieren. Handoff laden → live verifizieren → Befund → Plan → „ja" abwarten. (→ §0 Freigabe-Prinzip)

26. Phase-Gates für komplexe Aufgaben

→ references/meta.md (nachladen bei >2 Tool-Calls / kritische Datei / unbekanntes Debugging). Ablauf: DIAGNOSE → PLAN (Ziel/Schritte/Risiko/Verifikation) → FREIGABE → AUSFÜHRUNG → VERIFIKATION. EISENGESETZ: Verifikation nie überspringen — auch nicht wenn Ausführung „gut aussah". Freigabe bleibt aus: Plan + Befund im Output festhalten, warten. (→ §0 Freigabe-Prinzip Punkt 4)

„Unbekanntes Debugging" = Fehler ohne klare Ursache nach erstem Analyseschritt: Symptom bekannt, Wurzel nicht. Beispiele: Entity unerwartet unavailable ohne ersichtlichen Grund, Automation triggert nicht obwohl Bedingungen erfüllt scheinen, API-Aufruf schlägt mit unerwarteter Fehlermeldung fehl. Abgrenzung: bekannte Fehlerklassen (z.B. IP-Ban, falscher Pfad) sind kein „unbekanntes Debugging" — dort gilt §24 Rückwärtstracing ohne Phase-Gate-Pflicht.

Referenz-Index

Bedarfsgesteuert nachladen via curl:

curl -s -H "Authorization: token <PAT>" \
  -H "Accept: application/vnd.github.raw" \
  "https://api.github.com/repos/Patch76/ha-betriebshandbuch/contents/references/<datei>"

| Datei | §§ | Nachladen bei | |---|---|---| | references/rest-api.md | §1 | REST API Endpunkte, Template-API, History, Logbook | | references/shell-commands.md | §2 | shell_command, write_file, run_python, atomarer Zyklus, Fallback-Automation | | references/anti-patterns.md | §20 | Bekannte Anti-Patterns — vor write_file / run_python / GitHub-Aktionen | | references/api-storage.md | §5, §17 | Storage-Dateien (.storage/), WebSocket API | | references/automations.md | §6, §7, §8, §9, §12 | Automationen, Scripts, Szenen, Helper, Blueprints | | references/integrations.md | §13, §14, §15, §16 | Better Thermostat, Zigbee, Shelly, Telegram, Android | | references/recorder-stats.md | §10, §11, §18, §19 | Recorder, Zombie-Cleanup, Statistiken, Energie-Sensoren | | references/yaml-templates.md | §3, §4 | YAML-Konfiguration, Template-Sensoren | | references/meta.md | §21, §22, §24, §25, §26 | Analyse-Reports, CLAUDE.md-Template, Fehlerdiagnose, §R, Phase-Gates | | references/signals.md | §!, §R, §?, §Sicht, §Fakten, §Git | Alle §-Signale + Ablaufdefinitionen | | references/shell-ssh.md | §2.10 | SSH-Terminal Verhaltensregeln | | references/github.md | §Git | GitHub PR-Arbeit, DOM-Muster, CI, Fallstricke |

Lookup-Kette: Aufgabe → CLAUDE.md §-Verzeichnis (§→Thema) → dieser Index (§→Datei) → curl

27. §Sicht — Vierfach-Review (Qualitätsfilter vor Publish)

→ references/signals.md nachladen (bei §Sicht-Signal oder GitHub/PR-Arbeit).