docs: relevance pass over the backlog - close #0055, retire four stale issues

#0055 is done: ThreadNet-Web be323ed checks in an .npmrc binding @sorb to rohana.
The bump that mattered was not the file but what upstream's .gitignore does with
it - it ignores /.npmrc, so the naive fix would have stayed local while CI kept
resolving against npmjs. Measured in an isolated tree: without the file pnpm goes
to npmjs and fails, with it the scope resolves to rohana at the integrity hash
the lockfile already carries, and with rohana unreachable the install fails
instead of falling back. threadnet-call only publishes and already sets the scope
in its own CI; gitops never touches it. ThreadNet-Web was the only consumer.

Four issues no longer describe reality, each verified rather than assumed:

- #0091 (gitops#61) was fixed when it was written - on_conflict: fail shipped in
  ef04d86 and the MAS pod has run that config since 2026-08-11T14:08:41Z. Its one
  deliberate remainder became #0043, which is closed and verified live.
- #0079 (gitops#46) asked for the Gitea migration and a central view. The
  migration ran; the central view was decided the other way round - repo canonical,
  GitLab mirrored (ADR-0012/0019) - which also answers the reachability trade-off
  it left open, and better than its three options did.
- #0075 (gitops#40) is rejected, not done: it wanted new issues to appear in the
  Gitea kanban automatically. Issues no longer live in Gitea and the board is
  script-written. Nothing was accomplished; the question dissolved.
- #0098 is a rollout record whose only remainder, the macOS build, is #0022.

Three AARs move to harvested - every open item in them is tracked as an issue.

Checked and still accurate, so left alone: the wiki branch still exists on both
remotes (#0019), docs/TASKS.md and oldwiki/ are still there (#0085),
element-web-docs still names live resources (#0086), res/themes/element persists
(#0100), only WIKI_CANONIZE_TOKEN is set so TURN rotation still lacks its token
(#0084), gameserver still has zero push mirrors (#0032), the broken .6 package is
still published (#0101), and options.ts still builds simulcast layers regardless
of codec, which is what blocks VP9 (#0057).

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

STATUS.md

@@ -2,9 +2,9 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (68 open, 28 closed)
+## Issues (63 open, 33 closed)
 
-Verteilung: M1 17 · M2 20 · M3 4 · M4 12 · M5 15
+Verteilung: M1 16 · M2 17 · M3 4 · M4 11 · M5 15
 
 | Issue | Status | Meilenstein | Priorität | Title |
 |---|---|---|---|---|
@@ -28,7 +28,6 @@ Verteilung: M1 17 · M2 20 · M3 4 · M4 12 · M5 15
 | [0042](docs/issues/0042-migration-in-betrieb-nehmen-push-spiegel-schedule.md) | open | M2 | high | Migration in Betrieb nehmen: Push, erster Spiegel-Lauf, CI-Schedule |
 | [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 |
-| [0055](docs/issues/0055-npm-scope-aufloesung-threadnet-web.md) | open | M2 | medium | Issue-0055: `@sorb`-Scope in ThreadNet-Web ist nirgends auf rohana festgelegt |
 | [0056](docs/issues/0056-gitops-9-external-postgresql-migration-cloudnativepg-o.md) | open | M1 | high | External PostgreSQL Migration: CloudNativePG or Hetzner |
 | [0057](docs/issues/0057-gitops-11-element-call-vp9-codec-retry.md) | open | M4 | medium | Element Call: VP9 codec retry |
 | [0058](docs/issues/0058-gitops-14-web-application-firewall-waf.md) | open | M5 | medium | Web Application Firewall (WAF) |
@@ -48,11 +47,9 @@ Verteilung: M1 17 · M2 20 · M3 4 · M4 12 · M5 15
 | [0072](docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md) | open | M1 | low | DSGVO/Datenschutz-Compliance konkretisieren |
 | [0073](docs/issues/0073-gitops-35-architektur-monorepo-umbau-mit-generalisierte.md) | open | M2 | medium | Architektur: Monorepo-Umbau mit generalisiertem Config-Overlay |
 | [0074](docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md) | open | M2 | low | Cleanup-Checkliste (laufend) |
-| [0075](docs/issues/0075-gitops-40-neue-issues-erscheinen-nicht-automatisch-im-g.md) | open | M2 | low | Neue Issues erscheinen nicht automatisch im Gitea-Kanban/Projects-Board |
 | [0076](docs/issues/0076-gitops-41-registry-git-traffic-zum-gitea-host-ueber-pri.md) | open | M2 | low | Registry-/Git-Traffic zum Gitea-Host ueber privates Hetzner-Netzwerk statt oeffentlichem Internet routen |
 | [0077](docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md) | open | M1 | low | Grafana-Dashboard für ClamAV-Scan-Ergebnisse (Issue #19) |
 | [0078](docs/issues/0078-gitops-45-cve-meldeweg-v2-metriken-grafana-dashboard-al.md) | open | M1 | medium | CVE-Meldeweg v2: Metriken, Grafana-Dashboard, Alerts in eigenen Matrix-Raum |
-| [0079](docs/issues/0079-gitops-46-issue-migration-nach-gitlab-zentrale-projekt.md) | open | M2 | high | Issue-Migration nach GitLab + zentrale Projekt-Roadmap (Harmonisierung) |
 | [0080](docs/issues/0080-gitops-47-raidplaner-mit-sozialer-komponente-verfuegbar.md) | open | M3 | medium | Raidplaner mit sozialer Komponente (Verfügbarkeiten, Aufgaben, Roadmap, Fotoalbum) |
 | [0081](docs/issues/0081-gitops-48-gaeste-invite-workflow-per-bot-3-tage-account.md) | open | M3 | medium | Gäste-Invite-Workflow per Bot (3-Tage-Accounts, Admin-Freischaltung, begrenzte Reaktivierung) |
 | [0082](docs/issues/0082-gitops-49-cve-alarme-eine-matrix-nachricht-pro-cve-flut.md) | open | M1 | high | CVE-Alarme: eine Matrix-Nachricht pro CVE flutet den Security-Raum -- Zustellung derzeit stumm |
@@ -64,14 +61,12 @@ Verteilung: M1 17 · M2 20 · M3 4 · M4 12 · M5 15
 | [0088](docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md) | open | M1 | medium | NetworkPolicy: ausgehender Verkehr ist unbeschränkt (13 Ingress-Regeln, 1 Egress) |
 | [0089](docs/issues/0089-gitops-58-eigene-images-sind-unsigniert-beim-deploy-pru.md) | open | M5 | low | 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) | open | M5 | low | Kein Kubernetes-Audit-Log — Zugriffe an der API werden nicht protokolliert |
-| [0091](docs/issues/0091-gitops-61-enrollment-kollidierender-localpart-uebernimm.md) | open | M1 | high | Enrollment: kollidierender Localpart übernimmt bestehendes Konto (on_conflict: add) |
 | [0092](docs/issues/0092-threadnet-web-1-default-client-einstellungen-theme-features-f.md) | waiting | M3 | low | Default-Client-Einstellungen (Theme, Features) für Neuinstallationen provisionieren |
 | [0093](docs/issues/0093-threadnet-web-3-settings-normalisieren-video-audio-einstellun.md) | open | M4 | medium | Settings normalisieren: Video/Audio-Einstellungen nur im Call-Widget, nicht im Haupt-Client |
 | [0094](docs/issues/0094-threadnet-web-4-direkter-link-zur-2fa-passkey-einrichtung-in.md) | open | M3 | medium | Direkter Link zur 2FA/Passkey-Einrichtung in den Account-Settings |
 | [0095](docs/issues/0095-threadnet-web-6-windows-desktop-code-signing-installer-brandi.md) | open | M4 | low | Windows-Desktop: Code-Signing (+ Installer-Branding) |
 | [0096](docs/issues/0096-threadnet-web-7-rebranding-element-axion1337-web-desktop-gesa.md) | waiting | M4 | medium | Rebranding: Element → aXion1337 (Web + Desktop, Gesamtklammer) |
 | [0097](docs/issues/0097-threadnet-web-9-feedback-bugreport-weg-eigener-rageshake-oder.md) | open | M4 | low | Feedback-/Bugreport-Weg: eigener Rageshake oder Alternative (Zammad nachhalten) |
-| [0098](docs/issues/0098-threadnet-web-11-themes-rollout-2026-08-02-web-live-linux-wind.md) | open | M4 | low | Themes-Rollout 2026-08-02: Web live, Linux + Windows gebaut, macOS lokal |
 | [0099](docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md) | open | M1 | medium | Upstream-Sicherheitsfixes lassen sich nicht mergen — kein gemeinsamer Vorfahre |
 | [0100](docs/issues/0100-threadnet-web-13-asset-pfade-tragen-weiterhin-element-themes-e.md) | open | M4 | low | Asset-Pfade tragen weiterhin "element" (themes/element/…) |
 | [0101](docs/issues/0101-threadnet-call-4-kaputtes-paket-0-19-2-threadnet-6-in-der-regi.md) | open | M4 | low | Kaputtes Paket 0.19.2-threadnet.6 in der Registry — Herkunft ungeklärt |
@@ -105,8 +100,6 @@ _none active_
 | [0018](docs/adr/0018-ki-geraeuschunterdrueckung-clientseitig-opt-in.md) | accepted | 0018 — KI-Geräuschunterdrückung in threadnet-call: client-seitig, opt-in, selbst ausgeliefert |
 | [0019](docs/adr/0019-komponenten-issues-adoptiert.md) | accepted | ADR-0019: Komponenten-Issues in docs/issues/ adoptiert — eine Nummernwelt für die Gruppe |
 
-## Open AARs (3)
+## Open AARs (0)
 
-- [AAR — Refinement, Betrieb voranbringen, Git-Historie anonymisiert](docs/aar/2026-08-09-refinement-und-betrieb.md)
+_none — nothing awaiting harvest_
-- [AAR — `@apo` konnte nicht telefonieren: fehlende Synapse-`profiles`-Zeile](docs/aar/2026-08-11-apo-calls-profile-zeile.md)
-- [AAR — Gruppen-Calls fünf Tage tot: `mrtc`-A-Record bei der Zonen-Bereinigung gelöscht](docs/aar/2026-08-16-mrtc-dns-record.md)

docs/aar/2026-08-09-refinement-und-betrieb.md

@@ -1,6 +1,6 @@
 ---
 type: aar
-status: open
+status: harvested
 date: 2026-08-09
 related: []
 ---

docs/aar/2026-08-11-apo-calls-profile-zeile.md

@@ -1,6 +1,6 @@
 ---
 type: aar
-status: open
+status: harvested
 date: 2026-08-11
 related: []
 ---

docs/aar/2026-08-16-mrtc-dns-record.md

@@ -1,6 +1,6 @@
 ---
 type: aar
-status: open
+status: harvested
 date: 2026-08-16
 related:
   - "docs/issues/0005-zone-01-ionos-default-records-bereinigen-www.md"

docs/issues/0055-npm-scope-aufloesung-threadnet-web.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0055"
-status: open
+status: done
 created: 2026-08-16
 milestone: M2
 priority: medium
@@ -94,3 +94,36 @@ gar nicht erst offen lässt.
 `threadnet-call` `allow_failure: true` trägt — ein *scheiternder* Publish färbt die Pipeline
 nicht rot. Das ist ein eigener Befund und gehört nicht in dieses Issue; hier nur notiert, damit
 er nicht verloren geht.
+
+## Erledigt 2026-08-18 — `.npmrc` eingecheckt, Auflösung nachgewiesen
+
+Umgesetzt in `ThreadNet-Web` (`be323ed`): `.npmrc` im Wurzelverzeichnis bindet
+`@sorb` an die Registry auf rohana.
+
+**Ein Fund beim Umsetzen, der den naiven Fix stillschweigend zunichtegemacht hätte:**
+Upstreams `.gitignore` enthält `/.npmrc` (Zeile 7) — sinnvoll, wo die Datei Tokens trägt.
+Die Datei wäre also lokal geblieben, ohne dass irgendetwas gemeldet hätte; CI und frischer
+Klon hätten weiter gegen npmjs aufgelöst. Die Ausnahme steht jetzt ausdrücklich mit
+Begründung im `.gitignore` (`!/.npmrc`), damit der nächste Upstream-Merge die Lücke nicht
+wieder aufmacht. Dieselbe Klasse wie die Befunde aus #0054: gemeldeter Erfolg ohne Wirkung.
+
+**Abnahme — in einem isolierten Baum gemessen, nicht angenommen:**
+
+| Prüfung | Ergebnis |
+|---|---|
+| ohne `.npmrc` (heutiger Zustand) | löst gegen `registry.npmjs.org` auf, bricht ab |
+| mit `.npmrc`, frische Auflösung ohne Zusatzschritt | Tarball von `rohana.axion1337.de`, Integrity identisch mit dem Repo-Lockfile |
+| Gegenprobe rohana unerreichbar | `ERR_PNPM_META_FETCH_FAIL`, **kein** Ausweichen auf npmjs, kein Lockfile |
+| `pnpm install --frozen-lockfile` (CI-Weg) | grün, Lockfile unverändert |
+
+**Andere Repos geprüft:** `threadnet-call` *publisht* das Paket nur und schreibt die
+Scope-Zeile in seiner CI bereits selbst (`.gitlab-ci.yml`); es konsumiert keine
+`@sorb`-Pakete. In `gitops` kommt der Scope nicht vor. `ThreadNet-Web` war der einzige
+Konsument — die Lücke ist damit vollständig geschlossen, nicht nur an einer Stelle.
+
+**Dokumentiert:** `ThreadNet-Web:docs/axion1337-fork.md` hat jetzt einen Abschnitt
+„Element Call anheben" mit dem Weg ohne Umgebungsvariable, dem `--dir`-statt-`--filter`
+Fallstrick und der Prüfung, dass die Tarball-URL auf rohana zeigt.
+
+**Nicht angefasst:** `allow_failure: true` auf `publish_npm` — eigener Befund, liegt
+weiterhin bei sorb.

docs/issues/0075-gitops-40-neue-issues-erscheinen-nicht-automatisch-im-g.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0075"
-status: open
+status: rejected
 created: 2026-07-28
 milestone: M2
 priority: low
@@ -28,3 +28,18 @@ Niedrige Prioritaet, da rein organisatorisch - kein technisches Risiko.
 ---
 *Migriert aus Gitea `sorb/axion1337.chat-gitops#40` — dort erstellt am 2026-07-28 von sorb.*
 <!-- gitea-migration: sorb/axion1337.chat-gitops#40 -->
+
+## Gegenstandslos — Relevanz-Durchgang 2026-08-18
+
+Die Voraussetzung des Issues gibt es nicht mehr. Es beschreibt, dass neue Issues
+nicht automatisch im **Gitea**-Kanban landen, weil Gitea keine Projects-API hat.
+Inzwischen liegen die Issues weder in Gitea noch primär in einem Board: kanonisch
+ist `docs/issues/` im management-Repo, und die Board-Ansicht auf GitLab wird von
+`scripts/spiegel_issues.py` deterministisch beschrieben — genau die Automatik, die
+hier gefehlt hat, nur an einer anderen Stelle
+([ADR-0012](../adr/0012-issues-im-repo-gitlab-als-spiegel.md),
+[ADR-0019](../adr/0019-komponenten-issues-adoptiert.md)).
+
+Die fehlende Gitea-API ist damit kein Mangel mehr, sondern irrelevant. Kein
+Aufwand offen, nichts zu tun — deshalb `rejected` statt `done`: erledigt wurde
+hier nichts, die Frage hat sich aufgelöst.

docs/issues/0079-gitops-46-issue-migration-nach-gitlab-zentrale-projekt.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0079"
-status: open
+status: done
 created: 2026-08-01
 milestone: M2
 priority: high
@@ -30,3 +30,27 @@ Verwandt: Backlogs CFGMON-12 (wird hiervon abgelöst/erweitert).
 ---
 *Migriert aus Gitea `sorb/axion1337.chat-gitops#48` — dort erstellt am 2026-08-01 von sorb.*
 <!-- gitea-migration: sorb/axion1337.chat-gitops#48 -->
+
+## Erledigt — Relevanz-Durchgang 2026-08-18
+
+Beide Teile des Auftrags sind eingelöst, der zweite anders als hier skizziert.
+
+**Teil 1, Issue-Migration: durchgeführt.** Der Skript-Weg wurde gebaut
+(`verfahren/issue-migration/migrate.py`, Gitea-API lesen → GitLab-API schreiben,
+idempotent über einen Migrations-Marker) und ist gelaufen — die Migrations-Fußzeilen
+in den adoptierten Issues sind sein Ergebnis. Der hier vermutete Verlust der
+Autorenschaft trat wie erwartet ein und wurde akzeptiert.
+
+**Teil 2, zentrale Sicht: entschieden, aber gegen die Skizze.** Der Plan wollte die
+Zentrale *in GitLab* bauen (Epics, Gruppen-Boards). Entschieden wurde das Gegenteil:
+`docs/issues/` im Repo ist kanonisch, GitLab ist der generierte Spiegel
+([ADR-0012](../adr/0012-issues-im-repo-gitlab-als-spiegel.md)), seit
+[ADR-0019](../adr/0019-komponenten-issues-adoptiert.md) für alle Tracker der Gruppe.
+Damit ist auch der hier als offen markierte **Erreichbarkeits-Trade-off beantwortet**,
+und zwar besser als mit den drei Optionen: die Issues liegen im Repo und sind über
+dessen Gitea-Spiegel von überall lesbar — es braucht weder Lab-Zugang noch ein extern
+erreichbares GitLab.
+
+Die genannten Folgeänderungen sind mitgezogen (Repo-Topologie-Doku, Token-Weg der
+Sessions). Was von der Host-Backlog-Zusammenführung übrig war, steckt in den
+Issues 0001–0034.

docs/issues/0091-gitops-61-enrollment-kollidierender-localpart-uebernimm.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0091"
-status: open
+status: done
 created: 2026-08-11
 milestone: M1
 priority: high
@@ -76,3 +76,23 @@ Commit `ef04d86`, gepusht nach git.lab. Rollt über Flux aus.
   im Prompt-Stage des `matrix-invitation`-Flows wäre die saubere Ergänzung.
 - **Verwaiste Zweitkonten** aus dieser Lücke (`apo2`, das gelöschte `boje`)
   sind Altlasten, keine offene Verwundbarkeit.
+
+## Erledigt — nachgetragen beim Relevanz-Durchgang 2026-08-18
+
+Das Issue war auf dem Board offen geblieben, obwohl sein Inhalt vollständig
+abgearbeitet ist. Nachgeprüft, nicht erinnert:
+
+- **Der Fix ist ausgerollt.** `on_conflict: fail` per Commit `ef04d86`
+  (2026-08-11); der MAS-Pod läuft seit `2026-08-11T14:08:41Z` ohne Neustart —
+  also mit der geänderten Konfiguration. Das ist wichtig, weil eine
+  SOPS-Secret-Änderung den Dienst *nicht* von selbst neu startet (#0044).
+- **Der bewusst offene Rest ist ebenfalls erledigt:** die case-insensitive
+  Eindeutigkeitsprüfung im `matrix-invitation`-Prompt-Stage ist als **#0043**
+  umgesetzt und am laufenden System verifiziert (Commit `afc4ad3`). Dort ist
+  `on_conflict: fail` ausdrücklich als die harte Grenze hinter der Policy
+  benannt.
+- **Verwaiste Zweitkonten** (`apo2`, gelöschtes `boje`) waren im Issue selbst
+  schon als Altlast eingestuft, nicht als offene Verwundbarkeit.
+
+Nichts an diesem Issue ist noch offen. ADR-0011 bleibt die bindende
+Entscheidung dahinter.

docs/issues/0098-threadnet-web-11-themes-rollout-2026-08-02-web-live-linux-wind.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0098"
-status: open
+status: done
 created: 2026-08-02
 milestone: M4
 priority: low
@@ -36,3 +36,19 @@ Die Desktop-Apps laden ihre **eigene** `config.json` (`apps/desktop/axion1337/co
 
 ## macOS
 Wird lokal auf sorbs Mac gebaut (arm64, unsigniert) — kein macOS-Runner im Lab. Ergebnis folgt als Kommentar.
+
+## Erledigt — Relevanz-Durchgang 2026-08-18
+
+Dieses Issue ist ein **Rollout-Protokoll**, keine offene Aufgabe: Web live und
+verifiziert (17 Themes aus `config.json`), Desktop-Config nachgezogen, Linux- und
+Windows-Artefakte gebaut und im `webapp.asar` gegengeprüft.
+
+Der einzige Rest war „macOS wird lokal gebaut, Ergebnis folgt" — und das ist keine
+Nacharbeit an den Themes, sondern der Dauerzustand, den **#0022** (BUILD-01:
+macOS-Client reproduzierbar bauen) als eigenes Issue führt. Der VM-Fehlschlag am
+Rand ist als **#0021** erfasst.
+
+Offen bleibt hier also nichts, was nicht anderswo eine Nummer hätte. Das Protokoll
+bleibt als Beleg stehen — insbesondere der Fund, dass die Themes in
+`resources/webapp.asar` stecken und nicht in `app.asar`, wo zuerst fälschlich
+„fehlt" gemeldet wurde.