README: Konventionen bereinigen und Lücken schließen

- Stale K3S-01-Beispiel entfernt (hosts/k3s.md existiert seit 1c5e21c nicht mehr)
- Neuer Status "verworfen" fuer bewusst nicht umgesetzte Punkte, getrennt von
  "erledigt"
- Explizite Konvention: Gegenstuecke in anderen Host-Dateien beim Schliessen
  mitaktualisieren, nicht nur verlinkt stehen lassen
- Neuer Abschnitt "Verhaeltnis zu Gitea-Issues": Faustregel, wann etwas nur als
  Issue, nur hier, oder als Eintrag mit Issue-Verweis landet

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

README.md

@@ -33,9 +33,12 @@ auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört
 ## Konventionen
 
 **IDs** sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt:
-`CFGMON-01`, `GAME-01`, `MATRIX-01`, `K3S-01`, `ZONE-01`. IDs werden **nicht
-wiederverwendet** — ein erledigter Punkt behält seine Nummer, damit Querverweise und
-Commit-Messages dauerhaft stimmen.
+`CFGMON-01`, `GAME-01`, `MATRIX-01`, `ZONE-01` — ein Präfix pro Datei in `hosts/`
+bzw. `shared/`, keine Liste losgelöst vom tatsächlichen Datei-Bestand. IDs werden
+**nicht wiederverwendet** — ein erledigter Punkt behält seine Nummer, damit
+Querverweise und Commit-Messages dauerhaft stimmen. Auch wenn eine ganze Datei
+entfällt (siehe `hosts/k3s.md`, entfernt 2026-07-30), wird ihr Präfix nicht für
+etwas anderes wiederverwendet.
 
 Das Präfix für DNS-Themen ist bewusst `ZONE-` und nicht `DNS-`: `DNS-01` ist der
 Name eines ACME-Challenge-Typs und käme in genau diesen Backlogs ständig als
@@ -49,22 +52,46 @@ Fachbegriff vor.
 | `in Arbeit` | läuft gerade |
 | `wartet auf …` | blockiert, mit Angabe worauf |
 | `erledigt` | fertig, mit Datum — Eintrag bleibt stehen, siehe unten |
+| `verworfen` | bewusst **nicht** umgesetzt, mit Datum und Begründung — nicht dasselbe wie `erledigt`: es ist nichts passiert, sondern es wurde entschieden, es zu lassen |
 
-Erledigte Punkte werden **nicht gelöscht**, sondern auf `erledigt` gesetzt und nach
-unten in den Abschnitt „Erledigt" verschoben. Der Grund: bei mehreren Hosts ist die
-Frage „haben wir das damals eigentlich gemacht, und warum so?" häufiger als die
-Frage „was ist noch offen".
+Erledigte **und** verworfene Punkte werden **nicht gelöscht**, sondern nach unten
+in den Abschnitt „Erledigt" verschoben (verworfene Punkte darin klar als solche
+kennzeichnen). Der Grund: bei mehreren Hosts ist die Frage „haben wir das damals
+eigentlich gemacht, und warum so — oder haben wir es bewusst gelassen?" häufiger
+als die Frage „was ist noch offen".
 
 **Jeder Eintrag braucht** einen Status, eine Beschreibung des tatsächlichen
-Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht verifiziert
-ist, wird das dazugeschrieben — eine unbestätigte Vermutung, die wie ein Befund
-aussieht, kostet beim nächsten Mal mehr Zeit als sie spart.
+Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht direkt
+verifiziert ist (aus einer Konsole, einer Doku, einer Ableitung statt einer
+Messung von dem betroffenen System selbst), wird kurz dazugeschrieben, woher sie
+stammt — eine unbestätigte Vermutung, die wie ein Befund aussieht, kostet beim
+nächsten Mal mehr Zeit als sie spart.
 
 **Zeitkritisches** bekommt ein Datum in der Statuszeile, nicht nur „bald".
 
+**Gegenstücke in anderen Host-Dateien** (z. B. ein Punkt, der von zwei Seiten
+beschrieben wird, wie ein Push von `matrix` auf einen offenen Port bei `CFGMON`)
+werden beim Schließen einer Seite **auf der anderen Seite mitaktualisiert**, nicht
+nur verlinkt und stehen gelassen — sonst bleibt eine Seite unbemerkt veraltet.
+
 ## Verhältnis zu den Projekt-Repos
 
 Dieses Repo hält die offenen Punkte. Die **Konfiguration** liegt weiter in den
 jeweiligen Projekt-Repos, z. B. `sorb/threadnet-operating` für den
 Monitoring-Stack auf CFGMON. Damit nichts doppelt geführt wird, verweisen die
 Projekt-Repos hierher statt eigene Backlog-Dateien zu pflegen.
+
+## Verhältnis zu Gitea-Issues
+
+Manche Projekt-Repos (z. B. `sorb/axion1337.chat-gitops`) führen ihren eigenen
+Feature-/Fix-Backlog als Gitea-Issues — das bleibt dort, wird hier **nicht**
+dupliziert. Faustregel für die Abgrenzung:
+
+- **Reiner Projekt-Scope** (eine Funktion in einem Repo, ein Bug in einem Service):
+  Gitea-Issue im jeweiligen Projekt-Repo, kein Eintrag hier.
+- **Host-/Infrastruktur-Scope** (betrifft einen Host direkt, oder eine Entscheidung
+  über mehrere Hosts/Repos hinweg, z. B. wo ein CI-Runner laufen soll): Eintrag
+  hier, mit Verweis auf betroffene Issues statt deren Inhalt zu wiederholen.
+- **Beides zugleich** (ein Host-Thema hat ein konkretes Gegenstück als Issue, z. B.
+  ein fehlender Gitea-Runner blockiert CI in mehreren Repos): kurzer Eintrag hier
+  mit Link zum führenden Issue, statt den Issue-Inhalt hierher zu kopieren.