---
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"
gitlab_iid: "38"
---
# 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.

## Nachtrag 2026-08-18: Echtzeit-Stempel gehören in denselben Durchgang

`gruppenpruefung.py` meldet zusätzlich neun Commits mit **Echtzeit-Zeitstempeln** statt der
normalisierten Stempel — dieselbe Klasse „Namensschild/Stempel falsch, Inhalt korrekt", also
derselbe Beschluss: **beim nächsten Historien-Durchgang mitziehen**, nicht einzeln umschreiben.

| Repo | Commits | Anmerkung |
|---|---|---|
| `management` | `d47c2c4e`, `2daadb8b`, `6b8869f1`, `bff1ca44`, `0cce6f64` | Author-Datum normalisiert, Committer-Datum real (Rebase vom 11.08.) |
| `axion1337.chat-gitops` | `27a5395e`, `e110918d` | wie oben (12.08.) |
| `axion1337.chat-gitops` | `065b1308`, `ea01c0bc` | beide Stempel real (12.08.) |

Acceptance ergänzt: `gruppenpruefung.py` meldet auch keine `Echtzeit-Stempel` mehr.