docs: DEVLOG-Eintrag für M4

Ziel, Erledigtes, die Entscheidungen mit Begründung, die Probleme samt
Lösung und die offenen Punkte — allen voran, dass auch der Schreibweg
nicht gegen die echten APIs geprüft werden konnte.

Dauer laut zeiten.csv: 167 Minuten. Gesamt bislang 413 Minuten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

devlog/DEVLOG.md

@@ -10,7 +10,84 @@ die Übersicht aus `scripts/zeit.sh summe`.
 | M1          | claude | 161     | 2,68     |
 | M2          | claude | 44      | 0,73     |
 | M3          | claude | 41      | 0,68     |
-| **Gesamt**  |        | **246** | **4,10** |
+| M4          | claude | 167     | 2,78     |
+| **Gesamt**  |        | **413** | **6,88** |
+
+---
+
+## 2026-09-10 – M4: Wochenplanung und Zeitblöcke
+
+**Dauer:** 167 Minuten (20:42–23:29), Art `claude`.
+
+**Ziel der Sitzung:** Die Kernidee des Projekts — Aufgaben per Ziehen und
+Ablegen in echte Kalendertermine verwandeln, mit Rückweg.
+
+### Erledigt
+
+- `Zeitblock` samt Migration und Schleifenschutz (30 Tests)
+- Schreibweg zu Graph und Google mit `If-Match`, Rückweg im Abgleich
+- Rasterlogik für die Wochenansicht (21 Tests)
+- Wochenansicht mit `@dnd-kit/core`: einplanen, verschieben, ausplanen
+- Kapazität und Belegung je Wochentag
+- 3 neue E2E-Tests, Handbuchseite
+
+### Entscheidungen mit Begründung
+
+**Der Fingerabdruck geht nur über Beginn und Ende.** Titel und Beschreibung
+ändern sich auch aus harmlosen Gründen — etwa weil der Aufgabentitel
+bearbeitet wurde. Für die Planung zählt allein, wann der Block liegt; alles
+andere in den Fingerabdruck zu nehmen hieße, den Anbieter grundlos zu
+behelligen.
+
+**Der Kalender gewinnt, ausnahmslos.** Wer im Kalender etwas verschiebt,
+meint es so. Säße der Planer am längeren Hebel, zöge er dem Benutzer den
+Termin wieder weg — und der wüsste nicht, warum. Bei HTTP 412 verwirft der
+Planer sogar seinen eigenen Fingerabdruck, damit der nächste Abgleich die
+fremde Änderung sicher als solche erkennt.
+
+**Scheitert das Schreiben, überlebt die Planung.** Der Zeitblock bleibt mit
+vermerktem Fehler stehen. Ihn zu verwerfen hieße, die Planung des Benutzers
+wegen eines Netzproblems zu vergessen; das nächste Verschieben trägt ihn
+nach. Beim Löschen ist es umgekehrt: Da verschwindet der Zeitblock auch bei
+unerreichbarem Kalender, sonst wäre die Planung blockiert.
+
+**Die Dauer kommt aus dem geschätzten Aufwand.** Wer schätzt, bekommt die
+passende Blockgröße geschenkt. Das belohnt genau die Gewohnheit, die die
+Planung überhaupt erst tragfähig macht.
+
+**Ziehen beginnt erst nach acht Pixeln.** Ohne diese Schwelle löst jeder
+Klick einen Zug aus und die Knöpfe im Block wären nicht mehr bedienbar.
+
+**Überbuchte Tage werden rot, aber nicht gesperrt.** Der Planer ist ein
+Werkzeug, kein Aufpasser. Manchmal muss ein Tag überbucht sein.
+
+### Probleme und Lösungen
+
+| Problem                                                                                                               | Lösung                                                                                                       |
+| --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| Ein Zeitblock steht auch im Terminspiegel und erschien doppelt — einmal als eigene Planung, einmal als fremder Termin | Die Wochenabfrage filtert Termine heraus, deren `extId` zu einem Zeitblock gehört.                           |
+| Ein Build lief 32 Minuten statt Sekunden                                                                              | Systemlast durch einen gleichzeitigen Docker-Bau. Ein sauberer Neubau danach: 46 Sekunden. Kein Codeproblem. |
+| Sich überschneidende Termine lagen unsichtbar übereinander                                                            | `spurenVerteilen` legt sie nebeneinander und gibt eine Spur wieder frei, sobald sie zu Ende ist.             |
+
+### Offene Punkte
+
+- **Der Schreibweg ist nicht gegen die echten APIs geprüft.** Wie in M3
+  fehlen die Zugangsdaten. Die Logik ist getestet, der erste echte Schreib-
+  und Rückweg ist Florians.
+- Die Dauer lässt sich nicht am Balken ziehen; wer eine andere will, ändert
+  den Aufwand der Aufgabe.
+- Ein Zeitblock landet immer im ersten verbundenen Kalender. Das
+  Standard-Kalenderkonto je Bereich ist im Datenmodell vorbereitet, aber
+  noch nicht in der Oberfläche.
+
+### Commits
+
+- 5791047 feat(zeitbloecke): Datenmodell und Schleifenschutz
+- 9c1c916 feat(zeitbloecke): Schreibweg in den Kalender und Rückweg zurück
+- bcb4b8e feat(woche): Rasterlogik für die Wochenansicht
+- fada445 feat(woche): Wochenansicht mit Ziehen und Ablegen
+- 5b1e998 test: Wochenansicht und Ausplanen absichern
+- 0974695 docs: Handbuchseite zur Wochenplanung
 
 ---
 

devlog/zeiten.csv

@@ -2,3 +2,4 @@ datum;start;ende;minuten;meilenstein;art;notiz
 2026-09-10;12:06;14:47;161;M1;claude;M1 Fundament fertiggestellt
 2026-09-10;15:57;16:41;44;M2;claude;M2 Aufgaben und Projekte fertig
 2026-09-10;17:48;18:29;41;M3;claude;M3 Kalender lesen fertig
+2026-09-10;20:42;23:29;167;M4;claude;M4 Wochenplanung fertig