docs(issues): open #0053 — carry eight non-canonical commits into the next history pass

Eight commits from the past two days carry the wrong author identity, made in an
agent session that set user.email by hand in fresh clones — an hour after that
same session wrote the canonical identity into AGENTS.md.

sorb's call is to fix them with the next history pass rather than force-pushing
two repos over eight commits. The issue exists anyway because gruppenpruefung
reports them on every run: without a recorded reason the next session starts
'repairing' them, or worse gets used to red findings, which is exactly what
happened with the TargetDown noise in #0002 the same morning.

Notes the structural prevention too — an includeIf block setting the identity for
group clones — since writing the rule down demonstrably did not prevent breaking it.

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

STATUS.md

@@ -2,9 +2,9 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (23 open, 23 closed)
+## Issues (24 open, 23 closed)
 
-Verteilung: M1 6 · M2 12 · M4 2 · M5 3
+Verteilung: M1 6 · M2 13 · M4 2 · M5 3
 
 | Issue | Status | Meilenstein | Priorität | Title |
 |---|---|---|---|---|
@@ -31,6 +31,7 @@ Verteilung: M1 6 · M2 12 · M4 2 · M5 3
 | [0044](docs/issues/0044-sops-secret-aenderung-startet-dienst-nicht-neu.md) | open | M5 | low | SOPS-Values-Secret-Änderung startet den konsumierenden Dienst nicht neu |
 | [0045](docs/issues/0045-report-event-kein-kontaktweg-fuer-melder.md) | open | M1 | low | Inhalts-Meldung führt ins Leere: kein Kontaktweg für Melder |
 | [0051](docs/issues/0051-cve-remediation-pass.md) | open | M5 | high | CVE-Remediation-Pass: Schwachstellen-Report abarbeiten |
+| [0053](docs/issues/0053-historien-durchgang-nicht-kanonische-commits.md) | open | M2 | low | Historien-Durchgang: acht nicht-kanonische Commits mitziehen |
 
 ## Active design docs (0)
 

docs/issues/0053-historien-durchgang-nicht-kanonische-commits.md

@@ -0,0 +1,53 @@
+---
+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 <sorb.business@gmail.com>` statt der kanonischen
+Identität `Thore Cimbal <cfx@riot.8shield.net>` (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.