--- type: issue id: "0053" status: open created: 2026-08-15 milestone: M2 priority: low area: infrastructure related: - "docs/adr/0009-commit-konventionen-und-historien-anonymisierung.md" --- # Historien-Durchgang: acht nicht-kanonische Commits mitziehen ## Problem / Motivation Acht Commits vom 14./15.08.2026 tragen `sorb ` statt der kanonischen Identität `Thore Cimbal ` (ADR-0009). Entstanden in einer Agenten-Session: in frisch geklonten Repos wurde `user.email` von Hand gesetzt — ausgerechnet kurz **nachdem** dieselbe Session die kanonische Identität in `AGENTS.md` ausgeschrieben hatte (#0027/W7). Die betroffenen Commits: | Repo | Commits | |---|---| | `threadnet-operating` | `1bbff5e7`, `4cb9bfb2`, `e0808bad`, `e9c13dcf` | | `notfallhandbuch` | `5e398e73`, `6ff291d0`, `a55e6ee2` | | `thread-net-git` | `8d089e23` | **Entscheidung sorb 2026-08-15:** *nicht* jetzt einzeln umschreiben, sondern **beim nächsten ohnehin anstehenden Historien-Durchgang mitziehen**. Ein Force-Push über zwei Repos für acht Commits steht in keinem Verhältnis — der Inhalt ist korrekt, nur das Namensschild ist falsch. ## Acceptance - Die acht Commits tragen die kanonische Identität (ADR-0009). - Die Auflage aus ADR-0009 ist erfüllt: **alt→neu-Zuordnung** dokumentiert, analog zu `docs/sources/migration/commit-zuordnung-2026-08-07.md`. - `gruppenpruefung.py` meldet keine `nicht-kanonische Identität` mehr. ## Notes **Warum dieses Issue existiert, obwohl die Sache vertagt ist:** `gruppenpruefung.py` meldet die acht Befunde bei *jedem* Lauf. Ohne einen dokumentierten Grund fängt die nächste Session an, sie zu „reparieren" — oder, schlimmer, gewöhnt sich an rote Befunde. Genau das ist am selben Tag beim `TargetDown`-Dauerfeuer aus #0002 passiert. Die Vertagung ist eine Entscheidung, kein Versehen, und gehört deshalb sichtbar abgelegt. **Vorbeugung (der eigentliche Punkt):** Die Ursache war ein `git config user.email` von Hand in einem frischen Klon. Dass die Regel eine Stunde vorher aufgeschrieben wurde, hat sie nicht verhindert — dieselbe Lehre wie beim Bindmount (#0027/W6-Klasse). Wirksam wäre etwas Strukturelles statt mehr Sorgfalt, z.B. ein `[includeIf]`-Block in der globalen `.gitconfig`, der die Identität für Klone der Gruppe automatisch setzt, sodass sie gar nicht erst von Hand gesetzt werden muss.