Skip to content

Commit ea595b1

Browse files
gregor-samosirclaude
gregor-samosir
and
claude
committed
Feste Ergebnis-Zeile in allen Vorhaben-/Auftrag-/Arbeitsplan-Dateien
Nebenbefund aus Vorhaben-Doku-Konsistenz.md, auf Owner-Auftrag umgesetzt. Jede der elf Dateien traegt jetzt **Ergebnis: ...** in den ersten 15 Zeilen; zwei davon (Arbeitsplan-KNX-Vorderhaus.md, Vorhaben-Nur-ESP32-Pfad.md) hatten einen veralteten oder fehlenden Kopf und sind inhaltlich richtiggestellt. repo_konsistenz_test.py prueft die Zeile ab jetzt mechanisch (nur Praesenz, nicht Korrektheit) - mit echter Gegenprobe: vor der Aenderung 9 von 11 Dateien ROT, danach alle GRUEN. Ob der Inhalt stimmt, prueft /abschluss Schritt 3, dessen Wortlaut entsprechend geschaerft ist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 parent 0911f19 commit ea595b1

14 files changed

Lines changed: 88 additions & 27 deletions

‎.claude/skills/abschluss/SKILL.md‎

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -73,11 +73,14 @@ auf einem Arbeits-Branch.
7373
} | sort -u
7474
```
7575

76-
Für jede betroffene Datei: Steht oben das **aktuelle** Ergebnis, oder
77-
widerspricht es dem, was weiter unten in derselben Datei steht (Lehrstück:
78-
`Arbeitsplan-KNX-Vorderhaus.md` und `Vorhaben-Nur-ESP32-Pfad.md`, beide am
79-
2026-09-18 mit veraltetem Kopf gefunden)? Abweichung melden und, wenn es
80-
reine Doku ist, mit dieser Session gleich richtigstellen.
76+
Jede solche Datei trägt seit 2026-09-18 eine `**Ergebnis: ...**`-Zeile in den
77+
ersten 15 Zeilen — `repo_konsistenz_test.py` prüft nur, dass sie **da ist**,
78+
nicht ob sie **stimmt**. Für jede betroffene Datei deshalb lesen: Ist die
79+
Zeile noch aktuell, oder widerspricht sie dem, was weiter unten in derselben
80+
Datei steht (Lehrstück: `Arbeitsplan-KNX-Vorderhaus.md` und
81+
`Vorhaben-Nur-ESP32-Pfad.md`, beide am 2026-09-18 mit veraltetem Kopf
82+
gefunden)? Abweichung melden und, wenn es reine Doku ist, mit dieser Session
83+
gleich richtigstellen.
8184

8285
## 4. Abschlussmeldung
8386

‎Arbeitsplan-KNX-Vorderhaus.md‎

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,15 @@
11
# Arbeitsplan: KNX-Schritt „Vorderhaus“ in der Firmware
22

3+
> **Ergebnis: erledigt (2026-09-14) — ausgerollt als 3.22.0 auf allen vier
4+
> Boards.** Der Schritt läuft an beiden Stufen, fällig nur bei Heizbetrieb;
5+
> `knx_schnittstelle` ist an allen vieren Pflicht. Offen bleibt nur
6+
> außerhalb dieses Repos: die Mischer-Anleitung (Owner), danach die
7+
> Arbeitsanweisung für den KNX-Re-Assert in `nodered-flows` (Claude).
8+
>
39
> **Übergabe für eine neue Session — Stand 2026-09-12 abends.**
410
> Recherche, Vorabtest, Entwurf und Rückleseregel sind abgeschlossen und
511
> vom Owner entschieden. Die Firmware steht unverändert auf 3.20.0. Offen ist
612
> die Umsetzung; dieser Plan führt vom ersten Befehl bis zum Rollout.
7-
> **Ergebnis: offen.**
813
>
914
> **2026-09-13:** E1–E4 und drei Folgepunkte entschieden (Abschnitt
1015
> „Entschieden am 2026-09-13“), dazu die Farbe des Vorderhausfalls neu:

‎Arbeitsplan-Notbetrieb-NodeRED.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Arbeitsplan: Node-RED-Seite des Notbetriebs
22

3-
> **Erledigt am 2026-08-20.** Umgesetzt im Projekt `nodered-flows`:
3+
> **Ergebnis: erledigt (2026-08-20).** Umgesetzt im Projekt `nodered-flows`:
44
> *Notbetriebswerte-Sender V1.0* (Teil 1) und *Hauptmodus-Verteiler V6.5*,
55
> Ausgang 15 (Teil 2); `NOTBETRIEB.md` dort ist nachgezogen (Teil 3), die vier
66
> Abnahmepunkte sind durch. Von hier aus gegengeprüft: Alle fünf Werte liegen im

‎Arbeitsplan-Robustheit-3.20.0.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,10 @@
11
# Arbeitsplan 3.20.0: Robustheit und Langzeitstabilität
22

3+
> **Ergebnis: erledigt (2026-09-02) — als 3.20.0 ausgerollt.** M1–M4
4+
> umgesetzt, am Prüfstand abgenommen (P1–P4 bestanden) und auf allen vier
5+
> Boards ausgerollt. Vollständiger Befund in
6+
> `Massnahmenplan-Codedurchsicht-2026-09-02.md`.
7+
38
Umsetzung von M1–M4 aus `Massnahmenplan-Codedurchsicht-2026-09-02.md`.
49
Ausgangsstand: 3.19.0, Commit `4a2da3a` auf `main`, alle vier Boards laufen
510
3.19.0.

‎Auftrag-Heizstab-Notbetrieb.md‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
# Auftrag: Der Notbetrieb muss `SET39 ForceHeater` zurücknehmen
22

3-
> **Beantwortet am 2026-08-30 — angenommen, gebaut und ausgeliefert in 3.18.0.**
3+
> **Ergebnis: erledigt (2026-08-30) — angenommen, gebaut und ausgeliefert in
4+
> 3.18.0.**
45
> Der Befund stimmt in allen Punkten: `SET39` kam in keiner der beiden
56
> Schrittfolgen vor, und niemand hätte den Zustand zurückgenommen. Beide Folgen
67
> haben jetzt an **Position 2** den Schritt `ForceHeater = 0` — genau dort, wo

‎Auftrag-Wartungsschalter-NodeRED.md‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
# Auftrag: Die Wartung muss den Re-Assert wirklich stilllegen — und von außen sichtbar sein
22

3-
> **Beantwortet am 2026-08-20 — und zwar anders, als dieser Auftrag annimmt.**
3+
> **Ergebnis: erledigt (2026-08-20) — beantwortet, und zwar anders, als
4+
> dieser Auftrag annimmt.**
45
> Die Sperre war nicht defekt. **Sie war nie eingeschaltet.**
56
>
67
> Zwei Spuren, die eine Wartungsflanke zwingend hinterlässt, fehlten beide:

‎Vorhaben-Byte28-Betriebsart.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Vorhaben: Betriebsart Kurve ↔ Direkt als Set-Kommando (Byte 28)
22

3-
> ## ✅ VOLLSTÄNDIG ERLEDIGT am 2026-08-19 mit Firmware 3.11.0
3+
> **Ergebnis: erledigt (2026-08-19) — ✅ vollständig, Firmware 3.11.0.**
44
>
55
> **Die Wärmepumpe nimmt Byte 28 an.** Das war die einzige echte Unbekannte
66
> (Abschnitt 3), und sie ist beantwortet. SET35 `HeatingMode` und SET36

‎Vorhaben-Doku-Konsistenz.md‎

Lines changed: 14 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -148,20 +148,22 @@ lesen, prüfen und melden; pushen nur auf Auftrag. Eintrag in `CLAUDE.md` unter
148148
Einmal am Ende der Session laufen lassen, die Teil 3 abschließt; dabei gefundene
149149
Abweichungen berichtigen.
150150

151-
## Nebenbefund: das Ergebnis im Kopf der Vorhaben
151+
## Nebenbefund: das Ergebnis im Kopf der Vorhaben — umgesetzt (2026-09-18)
152152

153153
`CLAUDE.md` sagt über die Vorhaben- und Auftragsdateien: „Ergebnis steht jeweils
154-
im Kopf“. Zwei weichen ab:
155-
156-
* [`Arbeitsplan-KNX-Vorderhaus.md`](Arbeitsplan-KNX-Vorderhaus.md) führt oben noch
157-
„Ergebnis: offen“; das tatsächliche Ergebnis („ausgerollt“) steht drei Absätze
158-
tiefer.
159-
* [`Vorhaben-Nur-ESP32-Pfad.md`](Vorhaben-Nur-ESP32-Pfad.md) nennt im Kopf nur den
160-
Planungsstand vom 2026-08-25, obwohl 3.16.0 umgesetzt und ausgerollt ist.
161-
162-
**Vorschlag für den Owner:** eine feste Zeile `**Ergebnis:** …` direkt unter der
163-
Überschrift jeder solchen Datei. Dann kann `repo_konsistenz_test.py` prüfen, dass
164-
sie vorhanden ist — ob sie stimmt, prüft der Abschluss-Skill (Teil 4, Schritt 3).
154+
im Kopf”. Zwei wichen ab: [`Arbeitsplan-KNX-Vorderhaus.md`](Arbeitsplan-KNX-Vorderhaus.md)
155+
führte oben noch „Ergebnis: offen”, während das tatsächliche Ergebnis
156+
(„ausgerollt”) drei Absätze tiefer stand; [`Vorhaben-Nur-ESP32-Pfad.md`](Vorhaben-Nur-ESP32-Pfad.md)
157+
nannte im Kopf nur den Planungsstand vom 2026-08-25, obwohl 3.16.0 umgesetzt
158+
und ausgerollt war.
159+
160+
**Auf Owner-Auftrag umgesetzt:** Jede `Vorhaben-*.md`/`Auftrag-*.md`/
161+
`Arbeitsplan-*.md` trägt jetzt eine Zeile `**Ergebnis: …**` in den ersten 15
162+
Zeilen (elf Dateien, die zwei genannten korrigiert). `repo_konsistenz_test.py`
163+
prüft mechanisch, dass sie **da ist** — mit echter Gegenprobe: vor dem
164+
Ergänzen 9 von 11 Dateien ROT, danach alle GRÜN. Ob sie **stimmt**, prüft der
165+
Skill `/abschluss`, Schritt 3 (Teil 4) — das bleibt Sache des Lesens, nicht
166+
mechanisch prüfbar.
165167

166168
## Regeln für die Session
167169

‎Vorhaben-HeaterSet.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
# Vorhaben: Heizstab freigeben (Byte 9) und ForceHeater (Byte 5)
22

3+
> **Ergebnis: erledigt, bis auf das Winterexperiment (frühestens Winter
4+
> 2026/27).** SET37–39 seit 3.17.0 im Einsatz, die Notbetrieb-Rücknahme seit
5+
> 3.18.0.
6+
37
Ziel ist, den internen Heizstab über MQTT ansprechbar zu machen — bis 3.16.0
48
ging das nur am Bedienterminal.
59

‎Vorhaben-Hydraulik-Notbetrieb.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,8 @@
11
# Vorhaben: Die Hydraulik beim Notbetrieb auf 1-stufig schalten
22

3+
> **Ergebnis: erledigt (2026-08-27) — umgesetzt als 3.15.0, an der Anlage
4+
> abgenommen (P1–P4, P6, P7).**
5+
36
Der Notbetrieb setzt hydraulisch **1-stufigen** Betrieb voraus. Bisher stellt
47
das niemand sicher — im Normalbetrieb schaltet die Kaskadensteuerung einen
58
Tasmota-Switch, und genau die ist im Notbetriebsfall weg. Dieses Vorhaben legt

0 commit comments

Comments
 (0)