milestones: M6 — Zuletzt, and M1 closes with it (ADR-0027)

M1 stood at one remaining entry, and that entry described nothing broken. The
dividing line from ADR-0010 offered M5 as the formal alternative, which is wrong
in substance: M5 collects protective building blocks, not legal questions. A
milestone that measures "what is silently broken" would have carried an item
saying nothing about the state of operations, and would never have closed.

M6 takes deliberately deferred work: neither broken nor missing protection, but
only due once the platform reaches a state it does not have — real users instead
of test accounts, publication, open federation. The one condition that keeps it
from becoming a dumping ground is written into the ADR and the roadmap: every
entry owes its trigger, or it belongs struck rather than deferred. #0072 already
carried its own — real users and open federation, neither of which is the case
while federation is closed.

The number in AGENTS.md moved from M1–M5 to M1–M6. That is a fact made false by
this decision rather than a rule change, but it is AGENTS.md, so it is called
out here rather than slipped in.

M1 — Betrieb absichern is closed: 21 done, 3 struck, 0 open.

AGENTS.md

@@ -165,7 +165,7 @@ Ohne Lab-Zugang: dieses Repo ist als Push-Mirror unter
 - `docs/issues/` ist kanonisch für den Management-Scope
   ([ADR-0012](docs/adr/0012-issues-im-repo-gitlab-als-spiegel.md));
   GitLab ist bespiegelte Ansicht. Jedes Issue trägt genau einen
-  Meilenstein (M1–M5) und genau eine Priorität — das Schema erzwingt
+  Meilenstein (M1–M6) und genau eine Priorität — das Schema erzwingt
   beides. Zeitkritisches trägt ein `due`-Datum, nicht „bald".
 - **WIP-Limit 2** (Validator-Regel). Die Zusage-Status `next` und
   `in-progress` vergibt **nur sorb**; Sessions bilden ab (`waiting` mit

STATUS.md

@@ -4,16 +4,10 @@
 
 ## Issues (48 open, 53 closed)
 
-Verteilung: M1 1 · M2 16 · M3 4 · M4 11 · M5 16
+Verteilung: M2 16 · M3 4 · M4 11 · M5 16 · M6 1
 
 Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
 
-### M1 (1)
-
-| Issue | Priorität | Status | Title |
-|---|---|---|---|
-| [0072](docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md) | low | open | DSGVO/Datenschutz-Compliance konkretisieren |
-
 ### M2 (16)
 
 | Issue | Priorität | Status | Title |
@@ -81,12 +75,18 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
 | [0089](docs/issues/0089-gitops-58-eigene-images-sind-unsigniert-beim-deploy-pru.md) | low | open | Eigene Images sind unsigniert — beim Deploy prüft nichts die Herkunft |
 | [0090](docs/issues/0090-gitops-59-kein-kubernetes-audit-log-zugriffe-an-der-api.md) | low | open | Kein Kubernetes-Audit-Log — Zugriffe an der API werden nicht protokolliert |
 
+### M6 (1)
+
+| Issue | Priorität | Status | Title |
+|---|---|---|---|
+| [0072](docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md) | low | open | DSGVO/Datenschutz-Compliance konkretisieren |
+
 
 ## Active design docs (0)
 
 _none active_
 
-## ADRs (26)
+## ADRs (27)
 
 | ADR | Status | Title |
 |---|---|---|
@@ -116,6 +116,7 @@ _none active_
 | [0024](docs/adr/0024-drei-framework-dateien-erklaert-erweitert.md) | accepted | ADR-0024: Drei Framework-Dateien sind erklärt erweitert — Diff-Referenz statt Byte-Vergleich |
 | [0025](docs/adr/0025-egress-ausnahmen-als-cidr-ausser-hinter-cdn.md) | accepted | ADR-0025: Egress-Ausnahmen werden als CIDR gepinnt — außer hinter einem CDN |
 | [0026](docs/adr/0026-pruefziele-werden-abgeleitet-nicht-gepflegt.md) | accepted | ADR-0026: Prüfziele werden abgeleitet, nicht gepflegt — und das Ausbleiben der Herleitung alarmiert |
+| [0027](docs/adr/0027-zuletzt-eigener-meilenstein.md) | accepted | ADR-0027: „Zuletzt" wird ein eigener Meilenstein (M6) |
 
 ## Open AARs (8)
 

docs/adr/0027-zuletzt-eigener-meilenstein.md

@@ -0,0 +1,86 @@
+---
+type: adr
+id: "0027"
+status: accepted
+date: 2026-08-21
+supersedes: null
+superseded_by: null
+related:
+  - "docs/adr/0010-haertung-eigener-meilenstein.md"
+  - "docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md"
+---
+
+# ADR-0027: „Zuletzt" wird ein eigener Meilenstein (M6)
+
+## Kontext
+
+Am 2026-08-21 war **M1 — Betrieb absichern** bis auf einen einzigen Eintrag
+abgearbeitet: 21 erledigt, 3 gestrichen, **1 offen** — `#0072`
+(DSGVO/Datenschutz-Compliance).
+
+`#0072` gehört dort inhaltlich nicht hin. **ADR-0010** hat die Trennlinie
+zwischen M1 und M5 gezogen: *„Ist etwas Vorhandenes kaputt (M1) oder fehlt
+etwas, das wir noch nie hatten (M5)?"* Datenschutz-Compliance ist nichts
+Kaputtes. Sie ist aber auch kein Schutzbaustein im Sinne von M5 — sie ist
+schlicht **noch nicht fällig**: Das Issue nennt selbst als Auslöser „sobald
+echte Nutzer (nicht nur Testaccounts) und offene Föderation im Spiel sind", und
+beides ist heute nicht der Fall.
+
+Damit hätte ein Meilenstein, der misst „was ist kaputt", auf unbestimmte Zeit
+einen Eintrag getragen, der nichts über den Betriebszustand aussagt — und wäre
+nie geschlossen worden. Ein Meilenstein, der aus einem einzelnen nicht fälligen
+Vorhaben heraus offen bleibt, misst nicht mehr, was er zu messen vorgibt.
+
+## Optionen
+
+**A: `#0072` in M1 belassen.** Ehrlich in dem Sinn, dass nichts verschoben
+wird — aber M1 bliebe unbegrenzt offen, und sein Zahlenstand wäre als Aussage
+über den Betrieb wertlos.
+
+**B: `#0072` streichen.** Schließt M1 heute. Verliert aber ein Vorhaben, das
+später zwingend wiederkommt, und dann ohne Vorarbeit.
+
+**C: Nach M5 verschieben.** Formal nach ADR-0010 vertretbar („nie gehabt"),
+inhaltlich falsch: M5 sammelt **Schutzbausteine**, keine Rechtsfragen. Es
+verwässert die einzige klare Trennlinie, die wir haben.
+
+**D: Einen Meilenstein für ausdrücklich Vertagtes anlegen.**
+
+## Entscheidung
+
+**Option D. M6 — „Zuletzt"** wird angelegt (Entscheidung sorb, 2026-08-21:
+*„verschiebe diesen nach M6 bzw. erstelle diesen Meilenstein, wir kümmern uns am
+Ende darum, nicht jetzt"*). `#0072` zieht dorthin.
+
+**Trennlinie zu den übrigen:**
+
+> Ein Vorhaben gehört nach M6, wenn es **weder kaputt** (M1) **noch ein
+> fehlender Schutz** (M5) ist, sondern **erst durch einen Zustand fällig wird,
+> den die Plattform noch nicht erreicht hat** — echte Nutzer statt Testkonten,
+> Veröffentlichung, offene Föderation.
+
+⚠️ **M6 ist keine Ablage für Unliebsames.** Der Unterschied zu „gestrichen" ist,
+dass der Eintrag **wiederkommt**, und zwar an einem benennbaren Auslöser. Wer
+etwas nach M6 schiebt, schuldet diesen Auslöser im Issue — sonst gehört es
+gestrichen, nicht vertagt.
+
+## Konsequenzen
+
+*Einfacher.* M1 kann geschlossen werden und sagt damit wieder etwas: „nichts
+Bekanntes ist still kaputt". Die Trennlinie aus ADR-0010 bleibt scharf, weil
+Rechtsfragen nicht mehr in den Härtungs-Meilenstein ausweichen müssen.
+
+*Schwerer.* Es gibt einen Meilenstein mehr, und der Reiz, Unbequemes dorthin zu
+schieben, ist real. Die Auflage oben — **benennbarer Auslöser oder streichen** —
+ist die einzige Bremse dagegen, und sie hängt an der Aufmerksamkeit dessen, der
+verschiebt. Kein Werkzeug erzwingt sie.
+
+*Mitzuziehen war:* `schema.yaml` (Enum und Kopfkommentar), `roadmap.md`
+(Übersicht und Meilenstein-Tabelle) und `AGENTS.md` (die Zeile „Meilenstein
+(M1–M5)" im Projektabschnitt, die durch diese Entscheidung faktisch falsch
+wurde).
+
+⚠️ *Was diese Entscheidung nicht leistet.* Sie sagt nichts darüber, **wann** M6
+angefasst wird. „Am Ende" ist kein Datum. Solange kein Auslöser eintritt, ist
+der Meilenstein eine Liste, die niemand liest — das ist hinnehmbar, solange
+jeder Eintrag seinen Auslöser trägt, und wertlos, sobald einer es nicht tut.

docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md

@@ -3,11 +3,12 @@ type: issue
 id: "0072"
 status: open
 created: 2026-07-28
-milestone: M1
+milestone: M6
 priority: low
 projekt: gitops
 gitlab_iid: "34"
-related: []
+related:
+  - "docs/adr/0027-zuletzt-eigener-meilenstein.md"
 ---
 # DSGVO/Datenschutz-Compliance konkretisieren
 
@@ -18,3 +19,23 @@ Bisher nur als vages "M7: Enterprise-Ready - Future"-Ziel in der alten Milestone
 ---
 *Migriert aus Gitea `sorb/axion1337.chat-gitops#34` — dort erstellt am 2026-07-28 von sorb.*
 <!-- gitea-migration: sorb/axion1337.chat-gitops#34 -->
+
+## Vertagt nach M6 — 2026-08-21
+
+**Entscheidung sorb:** verschieben nach M6, den Meilenstein dafür neu anlegen —
+*wir kümmern uns am Ende darum, nicht jetzt.*
+
+Das Issue stand in **M1 — Betrieb absichern**, beschreibt aber nichts Kaputtes.
+Nach ADR-0010 (kaputt oder nie gehabt) wäre M5 die formale Alternative gewesen —
+inhaltlich falsch, weil M5 Schutzbausteine sammelt und keine Rechtsfragen.
+Deshalb der neue Meilenstein **M6 — Zuletzt**
+([ADR-0027](../adr/0027-zuletzt-eigener-meilenstein.md)).
+
+**Den Auslöser, den M6 für jeden Eintrag verlangt**, trägt dieses Issue bereits
+im Text oben: sobald echte Nutzer statt Testkonten und offene Föderation im
+Spiel sind. Solange die Föderation geschlossen ist (ADR-0021, #0060) und nur
+Testkonten laufen, ist die Sache nicht fällig.
+
+⚠️ **Vertagt ist nicht erledigt.** Tritt der Auslöser ein, kommt das Thema ohne
+jede Vorarbeit zurück — seit dem 2026-07-28 steht hier kein einziger konkreter
+Punkt.

roadmap.md

@@ -5,7 +5,7 @@
 > GitLab-Board — hier steht bewusst keine Zählung mehr (Lehre F-001/
 > F-010: handgepflegte Stände veralten und widersprechen dem Werkzeug).
 >
-> Die Gruppen-Milestones sind **M1–M5**; seit 2026-08-06 hängt jedes
+> Die Gruppen-Milestones sind **M1–M6**; seit 2026-08-06 hängt jedes
 > offene Issue an genau einem (Regel in [AGENTS.md](AGENTS.md), erzwungen
 > durch `schema.yaml`). M5 — Härtung wurde am 2026-08-09 entschieden:
 > Trennlinie „kaputt (M1) oder nie gehabt (M5)", siehe
@@ -25,6 +25,7 @@ die Liste zum Bestand passt. Hier steht deshalb bewusst nur die Bedeutung.
 | **M3 — Community-Funktionen** | Was die Community spürt: Invite-Workflow, Raidplaner, alles über Chat hinaus. Setzt die Vision „kontrolliert wachsend" um. |
 | **M4 — Produktreife ThreadNet** | Fork-Politur bis zur Vorzeigbarkeit: Rebranding zu Ende, Signing, Feedback-Weg. **Voraussetzung für eine Veröffentlichung.** |
 | **M5 — Härtung** | Schutzbausteine, die es heute **nicht** gibt. Trennlinie zu M1: „kaputt (M1) oder nie gehabt (M5)" — [ADR-0010](docs/adr/0010-haertung-eigener-meilenstein.md). |
+| **M6 — Zuletzt** | Ausdrücklich Vertagtes: weder kaputt noch fehlender Schutz, sondern **erst fällig, wenn die Plattform einen Zustand erreicht, den sie heute nicht hat** (echte Nutzer statt Testkonten, Veröffentlichung, offene Föderation). ⚠️ Jeder Eintrag schuldet seinen **Auslöser** — sonst gehört er gestrichen, nicht vertagt. [ADR-0027](docs/adr/0027-zuletzt-eigener-meilenstein.md). |
 
 ## Linien und nächste Meilenstein-Kandidaten
 

schema.yaml

@@ -6,7 +6,7 @@
 # PROJEKTERWEITERUNGEN gegenüber neckbeard v0.3.1 (Original:
 # docs/sources/upstream/neckbeard-v0.3.1/schema.yaml; Design:
 # docs/design/done/2026-08-11-neckbeard-migration.md, ADR-0012/0013):
-#   * issue: Pflichtfelder milestone (M1–M5) + priority; Status-Enum um
+#   * issue: Pflichtfelder milestone (M1–M6) + priority; Status-Enum um
 #     next/waiting erweitert; due/host/area/wartegrund/gitlab_iid;
 #     Regel waiting_requires_reason; globale Regel wip_limit (max. 2
 #     in-progress) in validate.py.
@@ -118,7 +118,7 @@ types:
       id: { pattern: "^\\d{4}$" }
       status: { enum: [open, next, in-progress, waiting, done, rejected] }
       created: { kind: date }
-      milestone: { enum: [M1, M2, M3, M4, M5] }
+      milestone: { enum: [M1, M2, M3, M4, M5, M6] }
       priority: { enum: [high, medium, low] }
       due: { kind: date, nullable: true }
       host: { enum: [cfgmon, overmind, matrix, game], nullable: true }