verify_claims.py gives all 813 claim rows a mechanical disposition;
the 28 flags were adjudicated by hand (REPORT.md appendix). Two survived
as genuine drift (F-017): a closed issue still described as open in
shared/lab-netzwerk.md, and a 'pending' decision block in hosts/cfgmon.md
whose premise the same file records as executed.
Also: narrow the vendored-path filter (it silently dropped 7 tracked
icon files and produced false path-miss flags), record the confirmed
canonical author identity in F-003, verify the Gitea#48->GitLab#46
numbering shift by title in F-005, and add the ADR-0010 draft under
analysis/drafts/ for the human to git-mv into decisions/.
Branch renamed to Neckbeard-v0.1.1-analyse-1 per the human.
| Analysis branch | `Neckbeard-v0.1.1-analyse-1`, branched from `main` at `2f012a6` (renamed from `analysis/neckbeard-fieldtest` at session close, per the human) |
@@ -77,6 +77,7 @@ The declaration and the application live in different places, and nothing compar
| [F-007](findings/F-007-mirror-scope-claims-contradict-each-other.md) | Mirror count stated as five and six on the same day; `game-operating` claimed mirrored, is not | Gap in the availability guarantee the two-host topology exists for |
| [F-005](findings/F-005-dead-gitea-tracker-still-referenced.md) | Live doc routes to the tracker three docs declare dead, under an ambiguous number | A high-priority open decision is reachable only through a retired system |
| [F-010](findings/F-010-stand-labels-lag-their-own-commits.md) | Hand-written "Stand" labels older than their own file's last commit | Trains readers to distrust current content; gives no signal when content really is stale |
| [F-017](findings/F-017-prose-asserts-states-already-resolved.md) | Prose asserts states the tracker already resolved: a closed issue called open, a "pending" decision whose premise was executed 60 lines earlier | Sentences a reader would act on; found only by the systematic claim sweep |
### Pattern C — Two backlogs, one rule
@@ -144,6 +145,27 @@ Listed only, not filed as issues in the neckbeard repo — that is a separate ac
---
## Appendix — the systematic claim verification
`analysis/scripts/verify_claims.py` gave every one of the 813 extracted claim rows a
| Analysis branch | `Neckbeard-v0.1.1-analyse-1`, branched from `main` (created as `analysis/neckbeard-fieldtest`, renamed at session close per the human) | `git checkout -b`, `git branch -m``[observed]` |
The reference standard for every "neckbeard mechanism" field in Phase 2
findings is neckbeard `v0.1.1` as pinned above (per ADR-0006).
.gitlab/issue_templates/Deploy-Übergabe.md 67 prose-or-runtime historical-wording Datensammlung und Zustellung getrennt scharf zu schalten ist fast immer
CLAUDE.md 4 prose-or-runtime Gruppe (axion1337.chat-Stack, ThreadNet-Repos, CFGMON/threadnet-operating,
CLAUDE.md 6 prose-or-runtime ESS-/Flux-Details in „ThreadNet Server Suite" = `axion1337.chat-gitops`) — bei
CLAUDE.md 10 informational runtime-path:https://rohana.axion1337.de/sorb/management > Push-Mirror unter `https://rohana.axion1337.de/sorb/management` von überall
CLAUDE.md 11 prose-or-runtime > **lesbar** — dort diese Datei und die ADRs nachschlagen. Nur pushen ist tabu.
CLAUDE.md 18 prose-or-runtime ## Projektrealitäten (Stand 2026-08-01)
CLAUDE.md 20 prose-or-runtime **Das Lab ist die Quelle der Wahrheit** ([ADR-0002](decisions/0002-issues-und-management-ins-lab.md)):
CLAUDE.md 22 informational runtime-path:git.lab/axion1337.chat/* - Kanonische Repos liegen auf `git.lab/axion1337.chat/*` (nur im Lab/VPN
CLAUDE.md 23 prose-or-runtime auflösbar). Gitea/rohana wird per **Push-Mirror** beliefert und bleibt
CLAUDE.md 24 prose-or-runtime Flux-Source, Container-/npm-Registry und Release-Download
CLAUDE.md 27 prose-or-runtime liegen die *Baupläne*, auf Gitea eine Kopie, die der Cluster **ohne verfügbares
CLAUDE.md 34 prose-or-runtime - **Nie direkt zu Gitea pushen** (gespiegelte Repos) — der Mirror überschreibt
CLAUDE.md 36 prose-or-runtime - **Gespiegelt wird nur die Gruppe `axion1337.chat`** (die fünf Produkt-Repos und
CLAUDE.md 37 prose-or-runtime `management`). Die Gruppe **`homelab`** (`docs`, `wiki`, `wiki-bookstack`) hat
CLAUDE.md 43 checked-ok path-ok:verfahren/aar/@management(dir) `verfahren/aar/` (dieses Repo ist gespiegelt), nicht nur in die READMEs der
CLAUDE.md 45 prose-or-runtime - Landet doch ein Commit auf Gitea (z. B. aus einer Host-Session ohne Lab-Route):
CLAUDE.md 48 prose-or-runtime von Gitea ziehen, `git am` (erhält Autorschaft), Push über git.lab.
CLAUDE.md 49 prose-or-runtime historical-wording - **Issues leben auf git.lab.** Die alten Gitea-Issues sind geschlossen und
CLAUDE.md 51 prose-or-runtime historical-wording (Gitea zählte PRs mit; z. B. Gitea#48 → GitLab#46) — alte „gitops#N"-Verweise
CLAUDE.md 52 prose-or-runtime meinen die Gitea-Nummer; verbindlich ist der Migrations-Fußtext im Issue.
CLAUDE.md 54 prose-or-runtime TURN-Rotations-CronJob schreibt weiter nach Gitea, weil er im Cluster läuft und
CLAUDE.md 56 prose-or-runtime **Die Rotation nicht von Hand nachziehen und den PR nie auf Gitea mergen** —
CLAUDE.md 57 prose-or-runtime das erledigt seit 2026-08-02 der geplante CI-Job `canonize_rotation` im
CLAUDE.md 58 prose-or-runtime gitops-Repo täglich von git.lab aus. Scheitert er, bleibt die Pipeline rot;
CLAUDE.md 62 prose-or-runtime Das gitops-Wiki liegt seit 2026-08-02 auf git.lab (*Wiki*-Reiter im Projekt);
CLAUDE.md 63 checked-ok path-ok:docs/@ThreadNet-Web(dir),axion1337.chat-gitops(dir),threadnet-call(dir) ⚠️ der `wiki`-**Branch** im gitops-Repo ist ein überholter Mai-Abzug von `docs/`
CLAUDE.md 72 prose-or-runtime - **Alles Offene ist ein Issue** — host-/infra-Scope hier im management-Projekt
CLAUDE.md 73 informational image-ref:host:;id-ok:CFGMON-01 historical-wording (`host:`-Labels, alte IDs wie `CFGMON-01` bleiben im Titel), Projekt-Scope im
README.md 13 informational runtime-path:git.lab;forge-repo:axion1337.chat/management **Kanonisch lebt dieses Repo auf `git.lab`** (`axion1337.chat/management`, nur im
README.md 37 checked-ok path-ok:verfahren/@management(dir) | `verfahren/` | Wie wir arbeiten: [Deploy-Übergabe/DoD](verfahren/deploy-uebergabe.md), [Refinement & Retro](verfahren/refinement.md), [AARs](verfahren/aar/), Werkzeuge |
README.md 38 checked-ok path-ok:hosts/@management(dir);path-ok:shared/@ThreadNet-Web(dir),management(dir) | `hosts/`, `shared/` | **Bestand + Historie** je Host/Thema — u. a. [Branding](shared/branding.md) (Marke, Paletten, wo welches Theme eingestellt ist); offene Punkte sind Issues |
README.md 43 informational forge-repo:homelab/wiki [`homelab/wiki`](https://git.lab/homelab/wiki)). **Geändert wird immer hier, nie dort.**
README.md 48 informational image-ref:host:;id-ok:CFGMON-01 historical-wording `host:`-Labels; die alten IDs wie `CFGMON-01` bleiben im Titel) bzw. in den
README.md 64 informational id-ok:CFGMON-01;id-ok:ZONE-01 **IDs** (`CFGMON-01`, `ZONE-01`, …) werden **nie wiederverwendet**; sie leben in
README.md 72 prose-or-runtime **Erledigtes und Verworfenes** bleibt sichtbar: Issues werden geschlossen (nicht
README.md 78 prose-or-runtime Konfiguration lebt in den Projekt-Repos (z. B. `threadnet-operating` für den
decisions/0001-gitlab-kanonisch-push-mirror.md 1 prose-or-runtime # 0001 — git.lab ist kanonisch, Gitea wird per Push-Mirror beliefert
decisions/0001-gitlab-kanonisch-push-mirror.md 8 prose-or-runtime 3,7-GiB-Host) und Gitea Actions zeigte mehrere echte Bugs. Das Homelab-GitLab
decisions/0001-gitlab-kanonisch-push-mirror.md 14 informational runtime-path:git.lab/axion1337.chat/* `git.lab/axion1337.chat/*` ist die kanonische Heimat aller Repos; Gitea/rohana
decisions/0001-gitlab-kanonisch-push-mirror.md 15 prose-or-runtime wird über Push-Mirrors beliefert und bleibt Flux-Source, Container-Registry,
decisions/0001-gitlab-kanonisch-push-mirror.md 16 prose-or-runtime npm-Registry und Release-Download. **Direkte Pushes zu Gitea sind für gespiegelte
decisions/0001-gitlab-kanonisch-push-mirror.md 17 prose-or-runtime Repos verboten** — der Mirror überschreibt divergenten Stand per Force.
decisions/0001-gitlab-kanonisch-push-mirror.md 22 prose-or-runtime - Commits, die doch auf Gitea landen (z. B. Cluster-CronJobs ohne Lab-Route),
decisions/0001-gitlab-kanonisch-push-mirror.md 23 checked-ok path-ok:verfahren/deploy-uebergabe.md@management brauchen das Kanonisierungs-Verfahren (`verfahren/deploy-uebergabe.md`):
decisions/0001-gitlab-kanonisch-push-mirror.md 24 prose-or-runtime `.patch` ziehen, `git am`, Push über git.lab. Zweimal live gebraucht.
decisions/0001-gitlab-kanonisch-push-mirror.md 29 informational id-no-issue:CFGMON-10 - CFGMON-CI aufrüsten (Swap/Limits): strukturell zu klein, verworfen mit CFGMON-10.
decisions/0002-issues-und-management-ins-lab.md 1 prose-or-runtime # 0002 — Issues und Management-Repo ziehen ins Lab („das Lab ist die Quelle der Wahrheit")
decisions/0002-issues-und-management-ins-lab.md 8 prose-or-runtime weiter auf Gitea — zwei Wahrheiten, driftgefährdet. Erreichbarkeits-Blocker
decisions/0002-issues-und-management-ins-lab.md 9 informational id-ok:LABNET-01 LABNET-01 (WireGuard-Roadwarrior) wurde am 2026-08-01 gelöst.
decisions/0002-issues-und-management-ins-lab.md 13 prose-or-runtime Alle Projekt-Issues leben auf git.lab (62 migriert, Gitea-Issues geschlossen mit
decisions/0002-issues-und-management-ins-lab.md 14 informational forge-repo:axion1337.chat/management Verweis); das Backlogs-Repo zieht als `axion1337.chat/management` ins Lab
decisions/0002-issues-und-management-ins-lab.md 15 informational forge-repo:sorb/management (Push-Mirror → `sorb/management` auf Gitea). Das Lab ist die Quelle der Wahrheit.
decisions/0002-issues-und-management-ins-lab.md 19 prose-or-runtime - ⚠️ gitops-Issue-Nummern haben sich verschoben (Gitea zählte PRs mit); die
decisions/0002-issues-und-management-ins-lab.md 21 prose-or-runtime - ~~**Befristete Ausnahme:** Deploy-Übergabe-Issues laufen auf dem Gitea-Tracker
decisions/0002-issues-und-management-ins-lab.md 22 informational forge-repo:sorb/management von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht.~~
decisions/0002-issues-und-management-ins-lab.md 23 checked-ok issue-ok:management#13(closed);id-ok:LABNET-03 ✅ **Zurückgebaut am 2026-08-02** (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):
decisions/0002-issues-und-management-ins-lab.md 25 checked-ok issue-ok:management#25(opened) sind nach git.lab gewandert ([#25](https://git.lab/axion1337.chat/management/-/issues/25),
decisions/0002-issues-und-management-ins-lab.md 26 checked-ok issue-ok:management#26(closed) [#26](https://git.lab/axion1337.chat/management/-/issues/26)), der Gitea-Tracker ist
decisions/0002-issues-und-management-ins-lab.md 27 checked-ok path-ok:.gitlab/issue_templates/@management(dir) leer, die Vorlage liegt als `.gitlab/issue_templates/`. **Damit gilt diese ADR
decisions/0002-issues-und-management-ins-lab.md 29 checked-ok path-ok:README.md@ThreadNet-Web,axion1337.chat-gitops,management historical-wording Ausnahmen (siehe `README.md`) — dass sie befristet war und die Frist gehalten hat,
decisions/0002-issues-und-management-ins-lab.md 31 prose-or-runtime - Releases bleiben auf Gitea (öffentlicher Download-Pfad), ebenso das gitops-Wiki.
decisions/0003-cve-meldeweg-aggregiert.md 8 checked-ok path-ok:verfahren/aar/@management(dir);issue-ok:axion1337.chat-gitops#51(opened) Nachrichten und musste stummgeschaltet werden (gitops#51, AAR in `verfahren/aar/`).
decisions/0003-cve-meldeweg-aggregiert.md 9 informational id-no-issue:CFGMON-13 historical-wording Gleichzeitig war entschieden (CFGMON-13), Release-/Security-Meldungen von
decisions/0004-site-to-site-vpn-hetzner-lab.md 3 checked-ok issue-ok:management#12(closed);issue-ok:management#12(closed) **Status:** akzeptiert (umgesetzt und abgenommen 2026-08-01, Testreihe 1–7 in [management#12](https://git.lab/axion1337.chat/management/-/issues/12)) · **Datum:** 2026-08-01 · **Entscheider:** sorb
decisions/0004-site-to-site-vpn-hetzner-lab.md 14 informational net-ref:10.0.0.0/24;net-ref:10.58.73.0/24 historical-wording Hetzner-Projektnetz `10.0.0.0/24` mit dem Lab-VLAN `10.58.73.0/24`. Der An/Aus-Schalter
decisions/0004-site-to-site-vpn-hetzner-lab.md 31 informational net-ref:10.0.0.0/8 | **Hetzner** | Netz-Range auf **`10.0.0.0/8`** erweitert, Route `10.58.73.0/24 → 10.0.0.3` — damit erreichen alle Server im Netz das Lab **ohne eigene Konfiguration** |
decisions/0004-site-to-site-vpn-hetzner-lab.md 32 informational net-ref:10.58.75.0/24;net-ref:10.0.0.0/24;image-ref:10.58.73.17:443;image-ref:10.58.73.1:53 | **UniFi-Firewall** | Trennung vom Roadwarrior über **Quell-/Ziel-IP** (`10.58.75.0/24` + `10.0.0.0/24`), nicht über eine eigene Zone: erlaubt sind nur `10.58.73.17:443` (git.lab/Registry) und `10.58
decisions/0004-site-to-site-vpn-hetzner-lab.md 39 checked-ok issue-ok:management#26(closed) [#26](https://git.lab/axion1337.chat/management/-/issues/26)), der Gitea-Tracker ist
decisions/0004-site-to-site-vpn-hetzner-lab.md 40 prose-or-runtime leer, die Vorlage liegt als GitLab-Issue-Template, und die Ausnahme aus ADR-0002 ist
decisions/0004-site-to-site-vpn-hetzner-lab.md 54 prose-or-runtime historical-wording Job läuft im Lab und erreicht Gitea öffentlich. Das war der eigentliche Grund für
decisions/0004-site-to-site-vpn-hetzner-lab.md 56 informational id-ok:GAME-01 - game.axion1337.de profitiert erst nach Aufnahme in den vSwitch (GAME-01).
decisions/0005-pm-framework-kanban.md 32 informational forge-repo:axion1337.chat/management - Das Backlogs-Repo wird zum Management-Repo `axion1337.chat/management`;
decisions/0005-pm-framework-kanban.md 33 checked-ok path-ok:hosts/@management(dir);path-ok:shared/@ThreadNet-Web(dir),management(dir);image-ref:host: offene Punkte aus `hosts/`/`shared/` sind Issues mit `host:`-Labels,
decisions/0006-wikis-konsolidieren-docusaurus.md 10 prose-or-runtime Vom Push-Mirror **nicht** erfasst: ein Wiki ist ein eigenes Repo, kein Branch.
decisions/0006-wikis-konsolidieren-docusaurus.md 11 prose-or-runtime 2. **`wiki`-Branch im gitops-Repo** — Stand 2026-05-14, mitgezogen, weil der Mirror
decisions/0006-wikis-konsolidieren-docusaurus.md 12 checked-ok path-ok:docs/@ThreadNet-Web(dir),axion1337.chat-gitops(dir),threadnet-call(dir) historical-wording alle Branches trägt. Inhalt: ein damaliger Abzug von `docs/`, kein gepflegtes Wiki.
decisions/0006-wikis-konsolidieren-docusaurus.md 13 checked-ok path-ok:docs/@ThreadNet-Web(dir),axion1337.chat-gitops(dir),threadnet-call(dir) 3. **`docs/` im main-Branch** — die eigentliche, laufend gepflegte Repo-Doku.
decisions/0006-wikis-konsolidieren-docusaurus.md 15 prose-or-runtime historical-wording Dazu waren die GitLab-Wikis aller Projekte **leer**, und die Wiki-Inhalte enthielten
decisions/0006-wikis-konsolidieren-docusaurus.md 23 prose-or-runtime „direkt-zu-Gitea"-Ausnahme aus [ADR-0001](0001-gitlab-kanonisch-push-mirror.md).
decisions/0006-wikis-konsolidieren-docusaurus.md 26 informational forge-repo:homelab/wiki [`homelab/wiki`](https://git.lab/homelab/wiki) baut mit Docusaurus eine Seite unter
decisions/0006-wikis-konsolidieren-docusaurus.md 28 informational forge-repo:homelab/docs historical-wording Homelab (`homelab/docs`), Arbeitsweise (`management`). Die Inhalte werden beim Bau
decisions/0006-wikis-konsolidieren-docusaurus.md 33 FLAG path-miss:content/ path-miss:content/ - **Änderungen gehören ins Quell-Repo**, nie ins Wiki-Repo — was dort in `content/`
decisions/0006-wikis-konsolidieren-docusaurus.md 43 prose-or-runtime `.md` wird als CommonMark statt MDX geparst.
decisions/0006-wikis-konsolidieren-docusaurus.md 44 prose-or-runtime - **Der `wiki`-Branch im gitops-Repo ist überholt.** Er bleibt vorerst als Historie
decisions/0006-wikis-konsolidieren-docusaurus.md 51 prose-or-runtime - **Alles in ein Repo verschmelzen:** Die Quellen haben unterschiedliche Leser und
decisions/0006-wikis-konsolidieren-docusaurus.md 53 prose-or-runtime - **Wiki auf Gitea belassen:** widerspricht ADR-0002 und hielt eine Ausnahme am
decisions/0007-wiki-oberflaeche-docusaurus-vs-bookstack.md 8 informational runtime-path:axionwiki.lab Docusaurus als Lesefläche gebaut — läuft seit 2026-08-02 unter `axionwiki.lab`.
decisions/0007-wiki-oberflaeche-docusaurus-vs-bookstack.md 42 prose-or-runtime Wahrheit neben git.lab — genau das, was [ADR-0002](0002-issues-und-management-ins-lab.md)
decisions/0007-wiki-oberflaeche-docusaurus-vs-bookstack.md 52 informational id-ok:CFGMON-09 Datenbank ohne Sicherung ist eine Zeitbombe (vgl. CFGMON-09, wo genau das seit
decisions/0007-wiki-oberflaeche-docusaurus-vs-bookstack.md 54 FLAG path-miss:import/ path-miss:import/ - **Ein Einweg-Import zum Befüllen, aber keine Synchronisation** (`import/` im
decisions/0007-wiki-oberflaeche-docusaurus-vs-bookstack.md 56 FLAG path-miss:provision.py path-miss:provision.py vergleichen, deshalb legt `provision.py` dieselben drei Bereiche an wie das
decisions/0008-agenten-sessions-root-aequivalent.md 9 informational id-ok:LABNET-02 LABNET-02-Nacht lief deshalb über die **docker-Gruppenmitgliedschaft** des Kontos
decisions/0008-agenten-sessions-root-aequivalent.md 46 informational id-ok:LABNET-02 ohne diese Entscheidung wäre LABNET-02 gar nicht durchführbar gewesen.
decisions/0008-agenten-sessions-root-aequivalent.md 50 prose-or-runtime AAR-Pflicht und „alles Offene wird ein Issue" auf diesem Host besonders zählen —
decisions/0008-agenten-sessions-root-aequivalent.md 55 prose-or-runtime Kommt einer dazu, wird diese ADR abgelöst.
decisions/0008-agenten-sessions-root-aequivalent.md 57 prose-or-runtime ## Offen, bewusst nicht vor der Entscheidung geklärt
decisions/0008-agenten-sessions-root-aequivalent.md 66 checked-ok issue-ok:management#14(opened) historical-wording nächsten Host-Session, festgehalten in #14.
decisions/0008-agenten-sessions-root-aequivalent.md 80 checked-ok path-ok:hosts/cfgmon.md@management und nicht bloß ein Absatz in `hosts/cfgmon.md`.
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 5 prose-or-runtime > Nachgetragen am 2026-08-09 in der [Retro](../verfahren/retro/2026-08-09.md). Die
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 13 prose-or-runtime öffentlichem Gitea-Spiegel heißt das: Jeder, der die Repos liest, kann ablesen, an
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 23 prose-or-runtime **Regel ab 2026-08-07**, gültig für alle Repos der Gruppe `axion1337.chat` und die
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 29 prose-or-runtime **Rückwirkend angewandt am 2026-08-09** auf **251 Commits** — alles aus dieser
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 34 prose-or-runtime | gitops | 117 von 264 | ab 2026-07-27 |
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 39 prose-or-runtime Dabei wurden 17 Tags mit umgezogen und die Autoren-Identitäten vereinheitlicht —
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 61 prose-or-runtime wieder aktiv.
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 66 prose-or-runtime liegen im selben GitLab und teilweise auf dem öffentlichen Spiegel — und sind
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 72 prose-or-runtime Das Force-Push der umgezogenen Tags hat in ThreadNet-Web **drei Release-Pipelines
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 74 informational tag-ok:v0.4.0 `v0.4.0` aus altem Quellcode gegen heutige Basis-Images neu gebaut und
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 77 checked-ok issue-ok:ThreadNet-Web#14(closed) ThreadNet-Web#14; die Sperre ist seit `3cb43f5` scharf.
decisions/0009-commit-konventionen-und-historien-anonymisierung.md 86 prose-or-runtime angefasst (`Scrublord@Mac.Bad`, 135 Commits aus der Zeit vor dieser
decisions/README.md 6 prose-or-runtime auf `abgelöst durch NNNN` gesetzt.
decisions/README.md 13 prose-or-runtime git.lab-Cutover 2026-08-01: die „Übergabe-Issues bleiben auf Gitea"-Ausnahme
hosts/cfgmon.md 11 informational net-ref:10.0.0.3;net-ref:10.0.0.2 | **Privat** | `10.0.0.3` (`enp7s0`, Hetzner-Netz — dort liegt auch k3s auf `10.0.0.2`) |
hosts/cfgmon.md 38 prose-or-runtime historical-wording [management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
hosts/cfgmon.md 42 checked-ok issue-ok:management#8(opened);id-ok:CFGMON-03 - [CFGMON-03 — Prometheus-Remote-Write/Loki öffentlich ohne Auth (Weg A, nachgelagerte Prüfung)](https://git.lab/axion1337.chat/management/-/issues/8)
hosts/cfgmon.md 43 checked-ok issue-ok:management#9(opened);id-ok:CFGMON-04 - [CFGMON-04 — Grafana-Admin-Credentials aus `.env` gelten nicht für die API](https://git.lab/axion1337.chat/management/-/issues/9)
hosts/cfgmon.md 46 informational id-no-issue:CFGMON-11 ## CFGMON-11 — Gitea-CI-Rückbau nach GitLab-Umzug
hosts/cfgmon.md 48 prose-or-runtime **Status:** erledigt (2026-07-31 spätabends) — bis auf einen kosmetischen Handgriff:
hosts/cfgmon.md 49 prose-or-runtime auf CFGMON `cd /opt/thread-net-git && git checkout main && git pull` (Checkout parkt
hosts/cfgmon.md 52 informational runtime-path:/opt/threadnet-operating **Dazu neu (2026-08-01 ~05:00):** Auch `/opt/threadnet-operating` braucht einmal
hosts/cfgmon.md 53 prose-or-runtime `git fetch && git reset --hard origin/main` — der State-Persistenz-Commit wurde
hosts/cfgmon.md 54 prose-or-runtime dort direkt nach Gitea gepusht (dfe04c4a), vom Mirror überschrieben, vom Mac aus
hosts/cfgmon.md 55 prose-or-runtime per Patch gerettet und kanonisch als `6ffab68` neu aufgelegt (inhaltsgleich,
hosts/cfgmon.md 87 informational runtime-path:~/.config/gitea-rohana/token `~/.config/gitea-rohana/token` auf dem Mac), `claude-push` (write:repository,
hosts/cfgmon.md 88 informational runtime-path:~/.config/gitea-rohana/push-token `~/.config/gitea-rohana/push-token`). Erster CI-Publish `0.19.2-threadnet.6`
hosts/cfgmon.md 94 informational runtime-path:git.lab/axion1337.chat (`git.lab/axion1337.chat`, Gruppe mit importierten Projekten angelegt; die Domain ist
hosts/cfgmon.md 97 prose-or-runtime pausieren). Der am 2026-07-30 auf Gitea-Seite aufgebaute CI-Unterbau wird damit teilweise
hosts/cfgmon.md 102 prose-or-runtime - **Actions-Toggle** `has_actions` bei `ThreadNet-Web` (am 2026-07-30 per API aktiviert)
hosts/cfgmon.md 103 prose-or-runtime wieder deaktivieren, ebenso bei `threadnet-call` (stoppt die fehlschlagende
hosts/cfgmon.md 105 checked-ok path-ok:.github/workflows/@threadnet-call(dir) - **`.github/workflows/` in `ThreadNet-Web`** (der kuratierte 6-Dateien-Satz) — wird durch
hosts/cfgmon.md 106 checked-ok path-ok:.gitlab-ci.yml@ThreadNet-Web,axion1337.chat-gitops,management `.gitlab-ci.yml` ersetzt. Die Erkenntnisse aus den Läufen vom 2026-07-30 mitnehmen:
hosts/cfgmon.md 110 prose-or-runtime - **Geerbte Upstream-Workflows in `threadnet-call`** (build/publish/test/translations/
hosts/cfgmon.md 113 FLAG path-miss:runner-data/.runner path-miss:runner-data/.runner der Gitea-Admin-UI deregistrieren und `runner-data/.runner` auf dem Host entfernen.
hosts/cfgmon.md 114 FLAG path-miss:embedded/web/.npmrc path-miss:embedded/web/.npmrc - **Token: npm-Token in `threadnet-call`s untracked `embedded/web/.npmrc`** (Klartext im
hosts/cfgmon.md 121 prose-or-runtime - **Runner-Service in `thread-net-git` ganz entfernen?** Hängt daran, ob das gitops-Repo
hosts/cfgmon.md 122 FLAG path-miss:deploy-on-push.yml path-miss:deploy-on-push.yml seinen leichten `deploy-on-push.yml` (YAML-Validierung/Notification, läuft sauber)
hosts/cfgmon.md 124 FLAG path-miss:runner/config.yaml path-miss:runner/config.yaml Revert-Commit in `thread-net-git`: Compose-Service `runner`, `runner/config.yaml`,
hosts/cfgmon.md 125 FLAG path-ok:.env.example@threadnet-call,threadnet-operating;path-miss:runner-data/ path-miss:runner-data/ `.env.example` (RUNNER_TOKEN), Cache-Port-Bindung 8088, `runner-data/`.
hosts/cfgmon.md 126 informational package-ref:@sorb/threadnet-call-embedded - **Registry-Ziel für `@sorb/threadnet-call-embedded`**: bleibt die Gitea-npm-Registry
hosts/cfgmon.md 128 prose-or-runtime GitLab-Package-Registry (dann läuft die Gitea-Package-Seite leer).
hosts/cfgmon.md 129 prose-or-runtime - **Container-Images bleiben in der rohana-Registry** (Flux/k8s pullt von dort — spricht
hosts/cfgmon.md 131 prose-or-runtime **neuen** Deploy-/Push-Token für die rohana-Registry (Neuanlage, kein Rückbau).
hosts/cfgmon.md 135 prose-or-runtime Gitea selbst, gitops-Repo als Flux-Source, Issues/Wiki/dieses Repo, der
hosts/cfgmon.md 136 informational id-ok:CFGMON-09 API-Token für Issue-Verwaltung, das Gitea-Backup-Script (CFGMON-09).
hosts/cfgmon.md 236 informational id-no-issue:CFGMON-02 ### CFGMON-02 — Traefik, Gitea, cAdvisor und Runner unter IaC gebracht · erledigt 2026-07-30
hosts/cfgmon.md 238 informational runtime-path:/data/compose/8 Liefen ursprünglich im Compose-Projekt `thread-net-git` aus `/data/compose/8`, einem von
hosts/cfgmon.md 239 informational forge-repo:sorb/thread-net-git;image-ref::latest Portainer verwalteten Stack ohne Repo dazu. Jetzt in `sorb/thread-net-git`: `:latest`-Tags
hosts/cfgmon.md 244 prose-or-runtime `ubuntu-latest`/`linux-build`/`win-wine` — die letzten beiden gezielt für Electron-Builds)
hosts/cfgmon.md 245 informational id-no-issue:CFGMON-08 — ursprünglich unter [CFGMON-08](#cfgmon-08) als offene Frage gelistet, siehe dort.
hosts/cfgmon.md 247 informational branch-ok:rework/stack Entstanden auf Branch `rework/stack`, zunächst nicht gemergt (produktiv aber schon aktiv).
hosts/cfgmon.md 248 informational branch-ok:origin/main;branch-ok:origin/rework/stack **2026-07-30 nach `main` gemergt** (`origin/main` == `origin/rework/stack` auf `02b3224`,
hosts/cfgmon.md 249 prose-or-runtime verifiziert) — damit spiegelt die Standardansicht des Repos jetzt den Live-Stand.
hosts/cfgmon.md 250 prose-or-runtime Verifiziert am 2026-07-30 über die Compose-Labels der laufenden Container
hosts/cfgmon.md 251 informational image-ref:working_dir: /opt/thread-net-git (`working_dir: /opt/thread-net-git`) und `docker compose ls`. `gitea-data` ist als
hosts/cfgmon.md 255 prose-or-runtime Zum Bootstrapping-Problem (Definition von Gitea liegt in Gitea): mitigiert,
hosts/cfgmon.md 256 prose-or-runtime weil das Deploy-Verzeichnis selbst der Checkout ist — fällt Gitea aus, liegt
hosts/cfgmon.md 263 informational runtime-path:/opt/monitoring;image-ref::latest Der Stack lief aus `/opt/monitoring` ohne Versionierung und mit `:latest`-Tags. Jetzt
hosts/cfgmon.md 264 checked-ok forge-repo:sorb/threadnet-operating;path-ok:monitoring/@axion1337.chat-gitops(dir),threadnet-operating(dir) in `sorb/threadnet-operating` unter `monitoring/`, Images gepinnt,
hosts/game.md 80 prose-or-runtime historical-wording [management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
hosts/game.md 83 checked-ok issue-ok:management#2(opened);id-ok:GAME-01 historical-wording - [GAME-01 — Host von CFGMON aus nicht erreichbar, 2 Targets down (⚠️ Silences bis 2026-08-04)](https://git.lab/axion1337.chat/management/-/issues/2)
hosts/game.md 84 checked-ok issue-ok:management#3(opened);id-ok:GAME-02 - [GAME-02 — `www.game.axion1337.de` ist überflüssig](https://git.lab/axion1337.chat/management/-/issues/3)
hosts/matrix.md 12 prose-or-runtime | **DNS** | `matrix.axion1337.de` **und** `matrix.axion1337.chat` zeigen auf dieselbe IP — ebenso `axion1337.chat` (Apex) und `account.axion1337.chat` (MAS). `axion1337.de` ist die ältere/Registrar-Do
hosts/matrix.md 31 prose-or-runtime historical-wording [management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
hosts/matrix.md 34 checked-ok issue-ok:management#1(opened);id-ok:MATRIX-03 - [MATRIX-03 — `www.matrix.axion1337.de` ist überflüssig](https://git.lab/axion1337.chat/management/-/issues/1)
hosts/matrix.md 36 informational id-no-issue:MATRIX-05 ## MATRIX-05 — node-exporter-DaemonSet in CrashLoopBackOff, Cluster-Scrape seit 2026-08-01 tot
hosts/matrix.md 38 prose-or-runtime **Status:** erledigt (2026-08-01 ~04:10, vom Mac aus mit kubectl/SSH)
hosts/matrix.md 41 informational image-ref:listen tcp 0.0.0.0:9100: bind: address already in use Teil 1 bestätigt per Pod-Log: `listen tcp 0.0.0.0:9100: bind: address already in use`;
hosts/matrix.md 43 informational image-ref:10.0.0.2:9100 via `10.0.0.2:9100` scrapt). Teil 2 erklärt: der Cluster-Service "funktionierte" nur in
hosts/matrix.md 49 checked-ok issue-ok:axion1337.chat-gitops#45(opened) historical-wording **Fix (gitops `228807f`, Weg A aus gitops#45):** HelmRelease + Alloy-Scrape entfernt,
hosts/matrix.md 152 informational package-ref:@matrix.axion1337.de;id-no-issue:MATRIX-01 ### MATRIX-01 — Klären, ob der Server Mail als `@matrix.axion1337.de` verschickt · erledigt 2026-07-30
hosts/matrix.md 154 prose-or-runtime Für `matrix.axion1337.de` existiert der komplette IONOS-Mail-Satz: `MX mx00/mx01`,
hosts/matrix.md 157 prose-or-runtime offen, weil Matrix-Homeserver typischerweise Mail für Registrierung/Passwort-Reset
hosts/matrix.md 160 prose-or-runtime **Antwort, verifiziert per Config** (nicht nur vermutet) — direkt im IaC-Repo
hosts/matrix.md 161 informational forge-repo:sorb/axion1337.chat-gitops `sorb/axion1337.chat-gitops`, dem tatsächlich hier deployten Stand geprüft:
hosts/matrix.md 163 checked-ok path-ok:apps/production/custom-configs/synapse-values.yaml@axion1337.chat-gitops;image-ref:email: - `apps/production/custom-configs/synapse-values.yaml` — kein `email:`/`smtp_host`/
hosts/matrix.md 165 checked-ok path-ok:apps/production/custom-configs/mas-secret.yaml@axion1337.chat-gitops - `apps/production/custom-configs/mas-secret.yaml` (SOPS-entschlüsselt geprüft) — kein
hosts/matrix.md 174 informational id-ok:ZONE-02 [ZONE-02](../shared/zone-axion1337.md) an dieser Stelle entblockt.
hosts/matrix.md 179 informational id-no-issue:MATRIX-04 MATRIX-04 unten. Nutzt die ohnehin am Apex laufende echte IONOS-Mail-Infrastruktur,
hosts/matrix.md 182 informational id-no-issue:MATRIX-02 ### MATRIX-02 — Pusht per Remote-Write auf einen offenen Prometheus · erledigt 2026-07-30
hosts/matrix.md 185 informational net-ref:10.0.0.3;net-ref:10.0.0.2 getrennten Absendern aus - "CFGMON (`10.0.0.3`) und der k3s-Host (`10.0.0.2`)" - als wären
hosts/matrix.md 187 informational net-ref:10.0.0.2 selbst die private IP `10.0.0.2` (verifiziert per `ip -4 addr show` auf dem Host).
hosts/matrix.md 189 checked-ok path-ok:apps/monitoring/alloy-config.yaml@axion1337.chat-gitops Verifiziert in `apps/monitoring/alloy-config.yaml` (diesem Cluster): Der Remote-Write-Push
hosts/matrix.md 190 informational runtime-path:http://10.0.0.3:9090/api/v1/write;runtime-path:http://10.0.0.3:3100/... geht bereits an `http://10.0.0.3:9090/api/v1/write` und Loki an `http://10.0.0.3:3100/...` -
hosts/matrix.md 191 informational image-ref:188.245.193.243:9090 **private IP, nicht die öffentliche** `188.245.193.243:9090`. Von dieser Seite aus ist hier
hosts/overmind.md 21 informational runtime-path:git.lab;image-ref:extra_hosts: git.lab:10.58.73.17;runtime-path:/etc/gitlab-runner/certs/git.lab.crt | gitlab-runner `lab-builder-1` (v18.7.0) | gleicher Stack, Service `gitlab-runner` | Docker-Executor + Socket, `concurrent = 1`. **Stolpersteine, live gefunden**: (1) Docker-interner DNS löst `git.la
hosts/overmind.md 23 FLAG runtime-path:registry.git.lab/axion1337.chat/vendor/windows:stable;runtime-path:git.lab/axion1337.chat/vendor/windows;image-ref:restart: "no";path-miss:docs/axion-runner.md path-miss:docs/axion-runner.md | Windows-Build-VM | Dokploy-Stack `windows-runner` (live seit 2026-07-31) | Image `registry.git.lab/axion1337.chat/vendor/windows:stable` (Eigenbau aus reviewtem Pin `7645a2b`, Vendor-Repo `git.lab/a
hosts/overmind.md 27 prose-or-runtime git.lab ist seit 2026-07-31 **kanonisch** für die gespiegelten Repos der Gruppe
hosts/overmind.md 28 prose-or-runtime `axion1337.chat` — Stand 2026-08-09 **sieben**: die sechs Produkt-Repos (ThreadNet-Web,
hosts/overmind.md 29 prose-or-runtime threadnet-call, thread-net-git, threadnet-operating, axion1337.chat-gitops, seit heute auch
hosts/overmind.md 30 prose-or-runtime `game-operating`) **und `management`, also dieses Repo**. Push-Mirrors nach rohana/Gitea,
hosts/overmind.md 31 prose-or-runtime direkte Gitea-Pushes tabu.
hosts/overmind.md 33 prose-or-runtime ⚠️ `gameserver` (achtes Projekt der Gruppe) hat **keinen** Mirror — offen in
hosts/overmind.md 34 checked-ok issue-ok:management#32(opened);issue-ok:management#32(opened) [management#32](https://git.lab/axion1337.chat/management/-/issues/32), dort liegt auf Gitea
hosts/overmind.md 38 prose-or-runtime **Issues nicht mehr** — die sind am 2026-08-01/02 nach git.lab gewandert
hosts/overmind.md 39 prose-or-runtime ([ADR-0002](../decisions/0002-issues-und-management-ins-lab.md)). Die letzte Ausnahme,
hosts/overmind.md 40 informational forge-repo:sorb/management die Deploy-Übergabe-Issues auf dem Gitea-Tracker `sorb/management`, ist am 2026-08-02
hosts/overmind.md 41 checked-ok issue-ok:management#25(opened);issue-ok:management#26(closed);id-ok:LABNET-03 mit LABNET-03 zurückgebaut: beide umgezogen (#25, #26), der Tracker ist leer.
hosts/overmind.md 44 prose-or-runtime historical-wording *(Bis 2026-08-01 stand hier „Backlogs (dieses Repo, ungespiegelt)" — das Repo heißt
hosts/overmind.md 45 prose-or-runtime seit der Umwidmung zum Management-Repo `management` und wird seither gespiegelt,
hosts/overmind.md 78 informational runtime-path:/etc/docker/certs.d/registry.git.lab/ca.crt `/etc/docker/certs.d/registry.git.lab/ca.crt` (Datei liegt schon als
hosts/overmind.md 79 informational runtime-path:/tmp/git.lab.crt `/tmp/git.lab.crt` vom Runner-Setup — kopieren reicht; kein Daemon-Restart nötig)
hosts/overmind.md 97 checked-ok issue-ok:management#4(opened) **Status:** Fix aktiv — die Beobachtung läuft als [Issue #4](https://git.lab/axion1337.chat/management/-/issues/4)
roadmap.md 52 prose-or-runtime 1. **Rebrand fortsetzen** — Desktop-Client heißt seit 2026-08-02 **ThreadNet** und
roadmap.md 53 checked-ok issue-ok:ThreadNet-Web#10(closed);issue-ok:ThreadNet-Web#10(closed) trägt die eigene Marke ([ThreadNet-Web#10](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/10),
shared/branding.md 43 checked-ok path-ok:apps/desktop/build/icon.ico@ThreadNet-Web | `apps/desktop/build/icon.ico` | Windows, 7 Größen von 16 bis 256 |
shared/branding.md 44 checked-ok path-ok:apps/desktop/build/icon.icns@ThreadNet-Web | `apps/desktop/build/icon.icns` | macOS, via `iconutil` aus einem `.iconset` |
shared/branding.md 47 checked-ok path-ok:vector-icons/1024.png@ThreadNet-Web Prüfen lässt sich die Gleichheit über die Prüfsumme von `vector-icons/1024.png`
shared/branding.md 48 checked-ok path-ok:build/icon.png@ThreadNet-Web gegen `build/icon.png` — weichen sie ab, ist eine Seite nachgezogen worden und die
shared/branding.md 103 prose-or-runtime ⚠️ **Ob ein Theme hell oder dunkel gemeint ist, steht nicht verlässlich in den
shared/branding.md 121 checked-ok path-ok:apps/desktop/axion1337/build.json@ThreadNet-Web;path-ok:apps/web/res/manifest.json@ThreadNet-Web | Betriebssystem, Startmenü, Installer, PWA | **ThreadNet** | `productName` in `apps/desktop/axion1337/build.json`, `name` in `apps/web/res/manifest.json` |
shared/branding.md 122 checked-ok path-ok:element-values.yaml@axion1337.chat-gitops;path-ok:apps/desktop/axion1337/config.json@ThreadNet-Web | in der Anwendung | **aXion1337.Chat** | `brand` in `element-values.yaml` (Prod) und `apps/desktop/axion1337/config.json` |
shared/branding.md 130 checked-ok path-ok:vision/threadnet.md@management Die Leitplanke dahinter steht in [`vision/threadnet.md`](../vision/threadnet.md):
shared/branding.md 138 informational tag-ok:v0.4.0 **Attribution:** „ThreadNet — powered by Element" steht seit `v0.4.0` in
shared/branding.md 150 checked-ok path-ok:apps/web/res/vector-icons/@ThreadNet-Web(dir);path-ok:apps/web/res/manifest.json@ThreadNet-Web | Web-Icons + PWA | `apps/web/res/vector-icons/`, `apps/web/res/manifest.json` (ThreadNet-Web) | `theme_color` = `#ed4f4c`, die Markenfarbe — nicht Elements `#76CFA6` |
shared/branding.md 151 checked-ok path-ok:apps/desktop/build/@ThreadNet-Web(dir) | Desktop-Icons | `apps/desktop/build/` (ThreadNet-Web) | `.png`, `.ico`, `.icns`, Layer-Asset — alle aus derselben Quelle |
shared/branding.md 152 checked-ok path-ok:apps/desktop/axion1337/config.json@ThreadNet-Web | ThreadNet Desktop | `apps/desktop/axion1337/config.json` (ThreadNet-Web) | eigene Kopie derselben Themes — beim Ändern beide mitziehen |
shared/branding.md 153 FLAG path-miss:theme/sorbs-palette.md path-miss:theme/sorbs-palette.md | BookStack | *Settings → Customization*, getrennt für hell und dunkel | liegt in der Datenbank, **nicht im Repo** — schriftlich hier und in `theme/sorbs-palette.md` |
shared/branding.md 154 prose-or-runtime | BookStack (Feinschliff) | `theme/*.css` im Wiki-BookStack-Repo | nur Flächen, Text, Ränder — die sieben Farben oben gehören in die Oberfläche |
shared/branding.md 155 FLAG path-miss:src/css/custom.css path-miss:src/css/custom.css | Docusaurus-Wiki | `src/css/custom.css` (homelab/wiki) | bislang nur Akzentfarbe |
shared/branding.md 156 checked-ok path-ok:apps/web/res/themes/element/img/backgrounds/alpenglow.jpg@ThreadNet-Web;path-ok:SdkConfig.ts@ThreadNet-Web | Titelbild Login | `apps/web/res/themes/element/img/backgrounds/alpenglow.jpg` (ThreadNet-Web), gesetzt in `SdkConfig.ts` | siehe unten — Bilddatei kommt nur über einen Build in den Container |
shared/branding.md 157 checked-ok path-ok:apps/authentik/authentik-blueprints.yaml@axion1337.chat-gitops;issue-ok:axion1337.chat-gitops#55(opened) | Anmeldeseite Authentik | Brand-Blueprint in `apps/authentik/authentik-blueprints.yaml` (gitops) | Favicon und Hintergrund werden **von axion1337.chat referenziert**, nicht hochgeladen. **Logo ist no
shared/branding.md 161 prose-or-runtime Seit 2026-08-06 zeigt die Login-Seite ein Alpenglühen über einer Bergkette statt
shared/branding.md 173 prose-or-runtime Fotografen namentlich. Nur `en`/`de` anzupassen hätte in 29 Sprachen eine **falsche
shared/branding.md 179 informational runtime-path:https://axion1337.chat/themes/element/img/backgrounds/alpenglow.jpg `https://axion1337.chat/themes/element/img/backgrounds/alpenglow.jpg`. Wer das Bild im
shared/branding.md 185 checked-ok path-ok:vector-icons/512.png@ThreadNet-Web Der erste Versuch setzte `branding_logo` auf `vector-icons/512.png`. Ergebnis: das
shared/branding.md 190 prose-or-runtime Zurückgesetzt am 2026-08-06 auf Authentiks eigenes Logo. Ein Ersatz braucht eine
shared/branding.md 192 FLAG path-miss:threadnet-logo-wortmarke.png path-miss:threadnet-logo-wortmarke.png auch `threadnet-logo-wortmarke.png` (Bildmarke *über* Schriftzug). Offen in
shared/branding.md 204 FLAG path-miss:theme/sorbs-palette.md path-miss:theme/sorbs-palette.md `theme/sorbs-palette.md` im BookStack-Repo ist die betriebsnahe Kopie mit den
shared/commit-zuordnung-2026-08-07.md 3 prose-or-runtime Am 2026-08-07 wurden die Zeitstempel aller Commits aus dieser Zusammenarbeit auf
shared/commit-zuordnung-2026-08-07.md 14 prose-or-runtime `backup-vor-rewrite`-Branches rekonstruiert und **paarweise verifiziert**: Für jedes
shared/commit-zuordnung-2026-08-07.md 26 prose-or-runtime Das Force-Push der umgezogenen Tags hat in ThreadNet-Web **drei Release-Pipelines
shared/commit-zuordnung-2026-08-07.md 27 informational tag-ok:v0.3.0;tag-ok:v0.4.0 neu gestartet** (`v0.3.0`, `v0.4.0`, `desktop-v1.12.17-clientscan`). Ein Tag ist
shared/commit-zuordnung-2026-08-07.md 33 informational image-ref:threadnet-web:v0.4.0;tag-ok:v0.4.0 Glück, keine Planung:** Mit stehender Tag-Protection wäre `threadnet-web:v0.4.0`
shared/lab-netzwerk.md 10 checked-ok issue-ok:management#12(closed) > (Testreihe 1–7 in [#12](https://git.lab/axion1337.chat/management/-/issues/12)).
shared/lab-netzwerk.md 11 checked-ok issue-ok:management#11(closed) > Es gibt dazu **keine offenen Issues mehr** — auch die Restpunkte #11
shared/lab-netzwerk.md 12 checked-ok issue-ok:management#16(closed);id-ok:LABNET-04 > (MacBook-Profil) und #16 (LABNET-04, Feinschliff an den UniFi-Regeln) sind
shared/lab-netzwerk.md 13 prose-or-runtime > geschlossen. Alles Folgende ist **Bestand und Historie**, keine offene Arbeit.
shared/lab-netzwerk.md 15 prose-or-runtime **Zwei WireGuard-Zugänge (Stand 2026-08-01, beide gelöst/abgenommen):**
shared/lab-netzwerk.md 85 prose-or-runtime **Diagnose-Plan von VOR der Lösung** — ⚠️ abgearbeitet und überholt, steht hier
shared/lab-netzwerk.md 102 checked-ok issue-ok:axion1337.chat-gitops#48(opened) **Verwandt:** gitops#48 (Cutover erst nach Lösung), perspektivisch ersetzt ein
shared/lab-netzwerk.md 105 prose-or-runtime ## Zugehörige Issues — alle geschlossen
shared/lab-netzwerk.md 108 prose-or-runtime historical-wording [management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
shared/lab-netzwerk.md 111 prose-or-runtime Zum Netz/VPN ist **nichts mehr offen** (Stand 2026-08-02):
shared/zone-axion1337.md 43 informational id-ok:ZONE-01 | `www.rohana`, `www.selendis`, `www.game`, `www.matrix` | wie ohne `www` | teils | überflüssig, siehe ZONE-01 |
shared/zone-axion1337.md 46 informational runtime-path:rohana `autodiscover`), auf `rohana` und `game` nicht.
shared/zone-axion1337.md 50 checked-ok issue-ok:management#5(opened);id-ok:ZONE-01 Damit die Rezepte in [ZONE-01](https://git.lab/axion1337.chat/management/-/issues/5)
shared/zone-axion1337.md 57 prose-or-runtime kann `rechnung@rohana.axion1337.de` in den Umschlag schreiben. Die folgenden
shared/zone-axion1337.md 72 informational runtime-path:rohana Genau die richtige Aussage für `rohana`, `selendis`, `matrix` — die verschicken keine
shared/zone-axion1337.md 73 informational id-no-issue:MATRIX-01 Mail (für `matrix` verifiziert in MATRIX-01: weder Synapse noch MAS senden).
shared/zone-axion1337.md 99 prose-or-runtime ⚠️ **DMARC wird vererbt.** Fehlt `_dmarc.rohana`, gilt die Policy des
shared/zone-axion1337.md 129 informational runtime-path:rohana historical-wording **Real eingetreten:** Bei `rohana` sind MX und SPF gelöscht, die Ersatz-Records
shared/zone-axion1337.md 137 prose-or-runtime historical-wording [management-Projekt](https://git.lab/axion1337.chat/management/-/issues); die IDs bleiben in den Issue-Titeln erhalten.
shared/zone-axion1337.md 140 checked-ok issue-ok:management#5(opened);id-ok:ZONE-01 - [ZONE-01 — IONOS-Default-Records bereinigen (Rezepte im Issue; rohana/selendis in Arbeit)](https://git.lab/axion1337.chat/management/-/issues/5)
shared/zone-axion1337.md 141 checked-ok issue-ok:management#6(opened);id-ok:ZONE-02 - [ZONE-02 — Apex-DMARC ist `p=none` und schützt nichts](https://git.lab/axion1337.chat/management/-/issues/6)
verfahren/README.md 12 checked-ok path-ok:textbloecke.md@management [`textbloecke.md`](textbloecke.md) hält kurze, kopierbare Blöcke, die man einer
verfahren/README.md 18 checked-ok path-ok:.gitlab/issue_templates/Deploy-Übergabe.md@management `.gitlab/issue_templates/Deploy-Übergabe.md` und erscheint beim Anlegen eines
verfahren/README.md 22 checked-ok path-ok:hosts/@management(dir);path-ok:shared/@ThreadNet-Web(dir),management(dir) historical-wording Abgrenzung zum Rest des Repos: `hosts/` und `shared/` halten **offene Punkte**,
verfahren/aar-vorlage.md 7 prose-or-runtime Was ist live und verifiziert. Was ist bewusst **nicht** live, und warum.
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 12 prose-or-runtime **Bewusst nicht live:** die Alarm-Zustellung nach Matrix. `room="security"` routet in
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 13 checked-ok path-ok:alertmanager.yml@threadnet-operating `alertmanager.yml` auf einen Null-Receiver (Commit `2b715ca` in
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 14 informational forge-repo:sorb/threadnet-operating `sorb/threadnet-operating`). Grund siehe Befund 1.
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 20 prose-or-runtime | 1 | Eine Matrix-Nachricht pro CVE. 126 CRITICAL landen in **einer** Alertmanager-Gruppe, nach 24 h kommen 1222 HIGH dazu. Dazu steht `save_state()` in `do_POST` hinter der Sende-Schleife: bricht ein
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 21 checked-ok issue-ok:axion1337.chat-gitops#52(opened) historical-wording | 2 | `docker compose up -d` aktiviert geänderte Configs nicht. Einzeldatei-Mounts hängen am Inode, `git pull` benennt um. Prometheus lief nach dem Deploy mit alten Regeln — `promtool` fand 9, Prometh
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 22 checked-ok issue-ok:axion1337.chat-gitops#51(opened) | 3 | `TrivyScanStale` kann ein nie erfolgreich gescanntes Image nicht melden — ohne ersten Report existiert keine Serie, an der `time() - trivy_last_scan_timestamp` hängen könnte | LOW | notiert in `
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 23 checked-ok image-ref:except: continue;issue-ok:axion1337.chat-gitops#51(opened) | 4 | Der Exporter prunt den First-Seen-State bei **jedem** Scrape. Ein transienter Lesefehler (`except: continue`) löscht die Erstfund-Zeitstempel des Targets dauerhaft | LOW | notiert in `gitops#51`
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 35 checked-ok path-ok:hosts/game.md@management | Zwei down-Targets könnten Folge des Deploys sein | `avg_over_time(up[3h])` | 0.00 — schon 3 h vorher tot, in `hosts/game.md` erfasst |
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 58 checked-ok issue-ok:axion1337.chat-gitops#51(opened) Richtungsentscheidung zu `gitops#51`, bevor die Alarme scharf gehen: entweder
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 59 checked-ok path-ok:matrix-alerts.py@threadnet-operating `matrix-alerts.py` auf eine Sammelnachricht pro Webhook-Batch umbauen (die fünf
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 65 informational image-ref:coturn/coturn:latest Nebenbefund ohne Handlungsbedarf von hier: `coturn/coturn:latest` ist das einzige
verfahren/aar/2026-08-01-cve-pipeline-gitops47.md 66 checked-ok issue-ok:axion1337.chat-gitops#47(opened) ungepinnte Image (bereits in `gitops#47` notiert).
verfahren/aar/2026-08-01-labnet02-cfgmon.md 10 informational net-ref:10.58.75.2/24 `enabled`. Interface `lab` steht mit `10.58.75.2/24`, Routen und Forward-Regeln aktiv,
verfahren/aar/2026-08-01-labnet02-cfgmon.md 28 prose-or-runtime historical-wording | 1 | `enp7s0` seit 18:11 DOWN, Privatnetz-Route weg. Auslöser war die Hetzner-Range-Umstellung /16 → /8: die private NIC wurde ab- und neu angehängt (`renamed from eth1`), danach wurde `hc-net-ifup@e
verfahren/aar/2026-08-01-labnet02-cfgmon.md 29 FLAG image-ref:Status: inactive;path-miss:lab.conf path-miss:lab.conf | 2 | ufw ist auf CFGMON **inaktiv** (`Status: inactive`, `ENABLED=no`). Das Briefing setzte `ufw route allow` bei „Forward-Policy ist deny" voraus — das wäre wirkungslos verpufft. Die DROP-Policy kom
verfahren/aar/2026-08-01-labnet02-cfgmon.md 30 prose-or-runtime | 3 | `sudo` ist aus einer Agenten-Session nicht bedienbar (kein TTY). Die Schritte liefen über die **docker-Gruppenmitgliedschaft** des Kontos (privilegierter Container + `nsenter`) — das ist root-äq
verfahren/aar/2026-08-01-labnet02-cfgmon.md 31 informational net-ref:10.58.73.0/24 historical-wording | 4 | Hetzner-Range war tatsächlich /16 — unabhängig aus der Routing-Tabelle verifiziert (`10.0.0.0/16 via 10.0.0.1 dev enp7s0`), `10.58.73.0/24` lag außerhalb | LOW | bestätigt, Umstellung durch sorb
verfahren/aar/2026-08-01-labnet02-cfgmon.md 38 prose-or-runtime | Split-Tunnel biegt den Default-Weg um | `ip route get 8.8.8.8` | unverändert über `eth0`; öffentliches DNS und HTTPS funktionieren |
verfahren/aar/2026-08-01-labnet02-cfgmon.md 42 prose-or-runtime **Nicht verifiziert:** ob der k3s-Host selbst läuft. Er ist unerreichbar, *weil* CFGMON
verfahren/aar/2026-08-01-labnet02-cfgmon.md 74 informational net-ref:10.0.0.3 1. `ip -brief addr show enp7s0` → UP mit `10.0.0.3`
verfahren/aar/2026-08-01-labnet02-cfgmon.md 75 informational net-ref:10.0.0.0/8;runtime-path:/16 2. `ip route | grep '^10\.'` → neue Route sollte `10.0.0.0/8` zeigen, nicht mehr `/16`
verfahren/aar/2026-08-01-labnet02-cfgmon.md 85 prose-or-runtime **Entscheidung offen:** ob der Root-Zugang über die docker-Gruppe so bleiben soll
verfahren/aar/2026-08-01-labnet02-cfgmon.md 93 checked-ok issue-ok:management#2(opened) AAR-Kommentar an `management#2` („Tunnel auf CFGMON ist active+enabled", daher komme
verfahren/aar/2026-08-01-labnet02-cfgmon.md 115 informational runtime-path:/etc/systemd/system/wg-quick@lab.service.d/10-after-docker.conf 1. Drop-in `/etc/systemd/system/wg-quick@lab.service.d/10-after-docker.conf` mit
verfahren/aar/2026-08-01-labnet02-cfgmon.md 123 prose-or-runtime historical-wording korrekt ab, keine Dubletten bei Neustarts). **Nicht verifiziert:** das Verhalten bei
verfahren/aar/2026-08-01-labnet02-cfgmon.md 143 checked-ok issue-ok:management#2(opened) (`oFRxWU…Z0o=`, Kommentar 399 in `management#2`) **gehört zu keinem Server auf der
verfahren/aar/2026-08-01-labnet02-cfgmon.md 145 informational id-ok:LABNET-02 historical-wording `wgsrv3 = sVuM0pgT…ZyM=` (LABNET-02, 51841). Jede Initiation von CFGMON war damit
verfahren/aar/2026-08-01-labnet02-cfgmon.md 158 informational runtime-path:~lab.de;runtime-path:~axion1337.de;runtime-path:~axionlabs.de;net-ref:10.58.73.1 `~lab.de`, `~axion1337.de`, `~axionlabs.de` über `10.58.73.1`; aXionLabs-Root-CA
verfahren/aar/2026-08-01-labnet02-cfgmon.md 159 prose-or-runtime im Truststore (verifiziert gegen die git.lab-Kette und per Fingerprint-Abgleich
verfahren/aar/2026-08-01-labnet02-cfgmon.md 160 prose-or-runtime gegen die step-ca, Port 666). Voller Dienst-Neustart aus der Datei verifiziert
verfahren/aar/2026-08-01-labnet02-cfgmon.md 170 prose-or-runtime **Offen nach diesem Nachtrag:** Testreihe 1–7 (inkl. Gateway-Rolle), Reboot-Beweis,
verfahren/aar/2026-08-01-labnet02-cfgmon.md 171 informational forge-repo:sorb/buffer Schlüsselrotation (Client-Private-Key lief beim Bootstrap über `sorb/buffer` auf
verfahren/aar/2026-08-01-labnet02-cfgmon.md 172 prose-or-runtime rohana; Repo wird laut sorb vernichtet, Rotation danach trotzdem empfohlen),
verfahren/aar/2026-08-01-labnet02-cfgmon.md 173 FLAG path-miss:lab.conf path-miss:lab.conf Repo-Zuhause für `lab.conf` + systemd-Drop-in (zurückgestellt bis nach der
verfahren/aar/2026-08-01-labnet02-cfgmon.md 181 informational runtime-path:git.lab Split-DNS-Zonen aktiv; `git.lab` auflösbar und pingbar. Damit sind der Bootfix
verfahren/aar/2026-08-01-labnet02-cfgmon.md 183 prose-or-runtime aus Nachtrag 2 im Ernstfall verifiziert. Aus der Offen-Liste von Nachtrag 2
verfahren/aar/2026-08-01-labnet02-lab.md 14 checked-ok issue-ok:management#12(closed) Testreihe 1–7 vollständig bestanden (Protokolle in `management#12`), zusätzlich der
verfahren/aar/2026-08-01-labnet02-lab.md 23 informational net-ref:10.0.0.0/24 UDM (Port 51841), **CFGMON als Client/Initiator**, `10.0.0.0/24` als Netz hinter dem
verfahren/aar/2026-08-01-labnet02-lab.md 34 informational net-ref:10.58.75.0/24;net-ref:10.0.0.0/24 | 1 | **„Server = WireGuard Server X" erfasst in der Policy Engine nur das Tunnel-Subnetz**, nicht die über „Networks Behind Client" angehängten Netze. Vier Korrekturrunden lang blieben die Regeln des
verfahren/aar/2026-08-01-labnet02-lab.md 38 informational net-ref:10.0.0.0/16;net-ref:10.58.73.0/24;net-ref:10.0.0.0/8 | 5 | Hetzner-Netz-Range `10.0.0.0/16` deckte das Routen-Ziel `10.58.73.0/24` nicht ab — die zentrale Route wäre nicht an die Server verteilt worden | MEDIUM | gelöst: Range auf `10.0.0.0/8` erweitert
verfahren/aar/2026-08-01-labnet02-lab.md 43 informational net-ref:10.58.75.2;net-ref:10.0.0.3 historical-wording `10.58.75.2` (Tunnel) *und* `10.0.0.3` (Hetzner-Netz) erreichbar. Vom Lab aus war die
verfahren/aar/2026-08-01-labnet02-lab.md 44 prose-or-runtime erste Adresse geblockt, die zweite offen — dieselbe Maschine, dieselben Dienste,
verfahren/aar/2026-08-01-labnet02-lab.md 75 prose-or-runtime - IoT- und Arbeit-Sperren sind **nicht verifiziert** — keine Gegenstelle in diesen
verfahren/aar/2026-08-01-labnet02-lab.md 77 informational id-ok:LABNET-02 - Regel-Beschreibungsfelder in UniFi sind leer; Verweis auf LABNET-02/ADR-0004 fehlt.
verfahren/aar/2026-08-01-labnet02-lab.md 80 prose-or-runtime Gitea-Ausnahme in ADR-0002/README/CLAUDE.md zurückbauen.
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 13 informational forge-repo:homelab/wiki-bookstack | BookStack als Gegenentwurf (`homelab/wiki-bookstack`) | ✅ live unter `bookstack.lab` |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 14 prose-or-runtime | 11 neue Themes (aXion1337 Light + 10 Paletten) | ✅ Web live, in allen Clients — ⚠️ **Paletten waren falsch**, korrigiert → [Nachtrag](#nachtrag-2026-08-02--die-paletten-waren-erfunden) |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 22 checked-ok path-ok:docs/@ThreadNet-Web(dir),axion1337.chat-gitops(dir),threadnet-call(dir);path-ok:docs/@ThreadNet-Web(dir),axion1337.chat-gitops(dir),threadnet-call(dir);issue-ok:management#19(opened) historical-wording | 1 | **Drei auseinandergelaufene Dokustände**: Gitea-Wiki-Repo (gepflegt, nicht gespiegelt), `wiki`-Branch im gitops-Repo (Mai-Abzug von `docs/`), `docs/` im main. Das Wiki enthielt sachlich Falsches
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 24 FLAG runtime-path:/favicon.ico;path-miss:text/html path-miss:text/html | 3 | **`/favicon.ico` lieferte HTTP 200 mit `text/html`** — die nginx-`try_files`-Kette gab die 404-Seite mit Erfolgsstatus aus. Safari hielt das Icon für vorhanden und zeigte den Buchstaben-Fallback
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 27 checked-ok path-ok:res/vector-icons/@ThreadNet-Web(dir);path-ok:manifest.json@ThreadNet-Web | 6 | **Nur macOS bekam neue Icons** — Windows (`.ico`) und Web (`res/vector-icons/`, `manifest.json`) blieben auf Element | MEDIUM | gelöst, `c51b681` |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 29 checked-ok issue-ok:management#21(opened) historical-wording | 8 | **Windows-Build-VM war weg** (`No such container`) — der CI-Job kann sie nur starten, nicht anlegen | MEDIUM | umgangen (manueller Neustart), Optionen in #21 |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 30 checked-ok issue-ok:management#22(opened) | 9 | **macOS-Build braucht Xcode** für das DMG (`actool`) und Rust für die nativen Module | MEDIUM | umgangen (electron-builder 25 fürs ZIP, `hdiutil` fürs DMG), dauerhaft offen in #22 |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 67 prose-or-runtime Release-Notes stand ein Link auf ein Issue, das ich nie angelegt hatte (fiel
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 79 informational runtime-path:/login | 3 | **Healthcheck auf `/login` schlug fehl → Container `unhealthy` → Traefik überspringt ihn komplett** | Default-Zertifikat + leeres 404, **identisch zum Bild eines fehlenden Netzes** |
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 86 prose-or-runtime im laufenden Container verifiziert wurde, ist damit kein Sicherheitsnetz, sondern
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 87 informational runtime-path:/status;runtime-path:/login ein Risiko. Ich hatte ihn zweimal ungeprüft geändert (`/status` → `/login`).
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 91 informational runtime-path:/opt `/opt`-Pfad — und die CI braucht `VARIANT_PATH`, sonst greift die Variante gar
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 98 prose-or-runtime Test, ein Issue-Verweis ohne Existenzprüfung, ein Icon-Skript ohne Blick aufs
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 104 checked-ok issue-ok:management#20(opened);id-ok:DOC-03 - **Entscheidung DOC-03 (#20)**: Docusaurus oder BookStack — beide laufen jetzt,
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 111 checked-ok issue-ok:ThreadNet-Web#6(opened) Signing (ThreadNet-Web#6) — ohne Signatur bleibt für Nutzer auf macOS der
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 118 prose-or-runtime historical-wording **Was war.** Die zehn Themes aus dem Rollout trugen nicht die Farben aus Anthropics
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 126 prose-or-runtime **Warum es nicht auffiel.** Erfundene Farben sehen nicht falsch aus. Ein Theme
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 131 prose-or-runtime **Falle für die nächste Runde.** Ob ein Theme hell oder dunkel gemeint ist, steht
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 135 checked-ok path-ok:shared/branding.md@management stehen in [`shared/branding.md`](../../shared/branding.md).
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 144 prose-or-runtime Sunset-Boulevard-Palette sind bis auf zwei Ziffern identisch (`#e76e51`/`#e76f51`,
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 150 FLAG path-miss:resources/webapp.asar path-miss:resources/webapp.asar stecken in `resources/webapp.asar`. Abgestimmt so belassen; der nächste reguläre
verfahren/aar/2026-08-02-wiki-und-desktop-clients.md 151 checked-ok image-ref:status:wartet;issue-ok:ThreadNet-Web#11(opened) historical-wording Build zieht die Korrektur mit (nachgehalten in ThreadNet-Web#11, `status:wartet`).
verfahren/aar/2026-08-09-refinement-und-betrieb.md 9 prose-or-runtime **Live und verifiziert:**
verfahren/aar/2026-08-09-refinement-und-betrieb.md 17 prose-or-runtime - 251 Commits über vier Repos auf 12:00-UTC-Zeitstempel umgeschrieben, Force-
verfahren/aar/2026-08-09-refinement-und-betrieb.md 18 prose-or-runtime gepusht, Mirrors und Flux verifiziert synchron
verfahren/aar/2026-08-09-refinement-und-betrieb.md 20 prose-or-runtime vorher unbekannte Repos ohne Push-Mirror
verfahren/aar/2026-08-09-refinement-und-betrieb.md 21 prose-or-runtime - `game-operating` gespiegelt und secret-frei verifiziert (Coolify-
verfahren/aar/2026-08-09-refinement-und-betrieb.md 26 prose-or-runtime **Bewusst nicht live:**
verfahren/aar/2026-08-09-refinement-und-betrieb.md 33 prose-or-runtime - `gameserver` weiterhin ohne Mirror — zwei Repos gleichen Namens mit
verfahren/aar/2026-08-09-refinement-und-betrieb.md 40 prose-or-runtime | 1 | `matrix-recovery-flow`-Blueprint scheiterte seit Tagen bei jedem Lauf, während Flux grün meldete | HIGH | behoben |
verfahren/aar/2026-08-09-refinement-und-betrieb.md 42 checked-ok path-ok:develop/config.json@ThreadNet-Web | 3 | Web-Client sendete Fehlerberichte an `rageshakes.element.io` — die Desktop-Bereinigung vom 2026-08-01 hatte den Web-Build nie erreicht, weil der beim Bauen Elements eigene `develop/config.json`
verfahren/aar/2026-08-09-refinement-und-betrieb.md 43 checked-ok issue-ok:management#32(opened) | 4 | `game-operating` und `gameserver` ohne Push-Mirror; bei `gameserver` liegt auf Gitea ein anderer Stand als auf git.lab | MEDIUM | `game-operating` behoben, `gameserver` offen (management#32) |
verfahren/aar/2026-08-09-refinement-und-betrieb.md 44 prose-or-runtime | 5 | Nach dem Privat-Stellen von `game-operating` auf Gitea übersprang die Stillstandsprüfung den Mirror-Abgleich klaglos, statt es als Befund zu werten | MEDIUM | behoben |
verfahren/aar/2026-08-09-refinement-und-betrieb.md 47 prose-or-runtime | 8 | threadnet-call-Doku beschrieb einen manuellen npm-Publish, der seit 2026-08-06 automatisiert läuft | LOW | behoben |
verfahren/aar/2026-08-09-refinement-und-betrieb.md 48 checked-ok path-ok:overmind.md@management | 9 | `overmind.md` nannte „sechs gespiegelte Repos" — nach dem Mirror für `game-operating` sind es sieben | LOW | behoben |
verfahren/aar/2026-08-09-refinement-und-betrieb.md 50 checked-ok issue-ok:ThreadNet-Web#14(closed);tag-ok:v0.4.0 historical-wording | 11 | Tag-Push (Force, für die Historien-Anonymisierung) löste in ThreadNet-Web drei Release-Pipelines neu aus; nur weil die geschützten Registry-Variablen im Zeitfenster fehlten, wurde `v0.4.0` nich
verfahren/aar/2026-08-09-refinement-und-betrieb.md 54 prose-or-runtime - **`game-operating` öffentlich auf Gitea** — Secret-Scan über alle fünf
verfahren/aar/2026-08-09-refinement-und-betrieb.md 60 FLAG issue-miss:management#60 issue-miss:management#60 - **Meine erste Diagnose zu #60** („Passwort-Wiederherstellung vermutlich tot")
verfahren/aar/2026-08-09-refinement-und-betrieb.md 68 checked-ok issue-ok:management#1(opened) Flux-Status.** Blueprint-Fehler #1/#2 waren nur so sichtbar — Flux, die
verfahren/aar/2026-08-09-refinement-und-betrieb.md 69 prose-or-runtime ConfigMap und der Cluster-Zustand insgesamt meldeten durchgehend grün.
verfahren/aar/2026-08-09-refinement-und-betrieb.md 71 checked-ok issue-ok:management#2(opened) verdeckten Fehler #2 erst zugänglich gemacht — der reguläre Weg (Worker-Log)
verfahren/aar/2026-08-09-refinement-und-betrieb.md 74 checked-ok issue-ok:management#3(opened) zu glauben** hat Befund #3 aufgedeckt — die Annahme im Issue betraf nur den
verfahren/aar/2026-08-09-refinement-und-betrieb.md 75 checked-ok path-ok:config.json@ThreadNet-Web Desktop-Client, `config.json` auf dem Web-Server sagte etwas anderes.
verfahren/aar/2026-08-09-refinement-und-betrieb.md 77 checked-ok issue-ok:management#4(opened) Befund #4 im ersten Lauf gefunden — eine dynamische Projektliste statt einer
verfahren/aar/2026-08-09-refinement-und-betrieb.md 78 prose-or-runtime im Code gepflegten hat zwei Repos zutage gebracht, die niemand auf dem
verfahren/aar/2026-08-09-refinement-und-betrieb.md 81 prose-or-runtime Fehlmessung beim `game-operating`-Check aufgedeckt, bevor sie als „sauber"
verfahren/aar/2026-08-09-refinement-und-betrieb.md 84 prose-or-runtime 251 Paaren über Tree *und* Commit-Nachricht verifiziert, keine Annahme.
verfahren/aar/2026-08-09-refinement-und-betrieb.md 100 checked-ok path-ok:decisions/@management(dir) Lehre aus der Retro, in `decisions/` dokumentiert
verfahren/deploy-uebergabe.md 6 checked-ok issue-ok:axion1337.chat-gitops#47(opened) Eingeführt am 2026-08-01 nach dem Deploy der CVE-Pipeline (`gitops#47`), siehe
verfahren/deploy-uebergabe.md 11 prose-or-runtime 1. Wer baut, öffnet **auf git.lab** ein Issue aus der Vorlage **Deploy-Übergabe**
verfahren/deploy-uebergabe.md 12 checked-ok path-ok:.gitlab/issue_templates/Deploy-Übergabe.md@management (`.gitlab/issue_templates/Deploy-Übergabe.md`, im Feld *Description template*).
verfahren/issue-migration/README.md 38 prose-or-runtime ⚠️ **gitops-Nummern sind NICHT deckungsgleich**: Gitea hatte Lücken (PRs zählen
verfahren/issue-migration/README.md 39 prose-or-runtime mit), GitLab vergibt lückenlos — z. B. Gitea#48 → GitLab#46, Gitea#51 → GitLab#49,
verfahren/issue-migration/README.md 40 prose-or-runtime Gitea#52 → GitLab#50. Die verbindliche Zuordnung steht im Migrations-Fußtext
verfahren/issue-migration/README.md 41 prose-or-runtime historical-wording jedes GitLab-Issues (`Migriert aus Gitea …#N`); alte Commit-/Doku-Verweise auf
verfahren/issue-migration/README.md 42 prose-or-runtime „gitops#N" meinen die **Gitea**-Nummer.
verfahren/refinement.md 51 checked-ok path-ok:retro/@management(dir) Ergebnisse werden unter [`retro/`](retro/) abgelegt, eine Datei je Termin. Die
verfahren/refinement.md 59 prose-or-runtime ermöglicht, welche Lehren, was bleibt offen. **Offene Punkte aus einem AAR werden
verfahren/refinement.md 61 checked-ok issue-ok:management#14(opened);issue-ok:management#16(closed) 2026-08-01, nachgezogen als #14–#16).
verfahren/refinement.md 88 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops,management - Die **kanonischen Arbeitskonventionen** stehen in [`CLAUDE.md`](../CLAUDE.md) und
verfahren/refinement.md 89 prose-or-runtime sind über den Gitea-Mirror von überall lesbar.
verfahren/retro/2026-08-09.md 13 prose-or-runtime **„Alles Offene wird ein Issue."** Das ist das Verfahren, das diesen Monat am
verfahren/retro/2026-08-09.md 15 prose-or-runtime vergessen, weil sie im Moment des Findens ein Issue bekamen — auch die, für die
verfahren/retro/2026-08-09.md 23 checked-ok issue-ok:management#15(opened);issue-ok:management#20(opened) historical-wording management#15 und #20 lagen drei Tage ohne Spalte — das ist der beabsichtigte
verfahren/retro/2026-08-09.md 31 informational image-ref:status:offen muss. Genau deshalb hat eine Session am 2026-08-06 ein `status:offen` erfunden und
verfahren/retro/2026-08-09.md 40 prose-or-runtime ## 2. Welche ADRs sind durch die Realität überholt?
verfahren/retro/2026-08-09.md 42 prose-or-runtime **Keine überholt — aber eine Lücke.**
verfahren/retro/2026-08-09.md 45 prose-or-runtime gebraucht.** Am 2026-08-07 wurde eine dauerhafte Prozessregel eingeführt (englische
verfahren/retro/2026-08-09.md 46 prose-or-runtime Conventional Commits, Zeitstempel auf 12:00 UTC) und am 2026-08-09 rückwirkend auf
verfahren/retro/2026-08-09.md 47 prose-or-runtime 251 Commits angewandt — eine **irreversible** Änderung an vier Repos, mit
verfahren/retro/2026-08-09.md 48 prose-or-runtime Force-Push durch einen Mirror, von dem Flux liest.
verfahren/retro/2026-08-09.md 51 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops,management ist das ein Lehrbuchfall. Stattdessen steht die Regel nur in der `CLAUDE.md` und
verfahren/retro/2026-08-09.md 55 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops,management erweitert (Titel ohne Priorität, Meilenstein-Pflicht) — beides in der `CLAUDE.md`,
verfahren/retro/2026-08-09.md 57 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops,management die `CLAUDE.md` die *Regel*. Es ist aber genau die Zwei-Orte-Konstruktion, die wir
verfahren/retro/2026-08-09.md 70 prose-or-runtime | `build_embedded` (threadnet-call) | grün, seit jeher | lud **nie** ein Artefakt hoch, falscher Pfad |
verfahren/retro/2026-08-09.md 72 prose-or-runtime | Blueprint `matrix-recovery-flow` | Flux grün, ConfigMap aktuell | seit Tagen bei **jedem** Lauf verworfen |
verfahren/retro/2026-08-09.md 73 prose-or-runtime | gitops-Arbeitskopie | „normal" | `main` trackte **Gitea** — ein `git push` wäre in die verbotene Richtung gegangen |
verfahren/retro/2026-08-09.md 74 prose-or-runtime | Leere Pipelines | rot | **nichts kaputt** — der umgekehrte Fall, Rauschen, das rot abtrainiert |
verfahren/retro/2026-08-09.md 75 informational tag-ok:v0.4.0 | Release-Pipeline auf `v0.4.0` | lief nach Tag-Push an | hätte ein veröffentlichtes Image überschrieben |
verfahren/retro/2026-08-09.md 87 checked-ok issue-ok:axion1337.chat-gitops#50(opened) Es gibt Issues für Einzelfälle — gitops#50 (Configs greifen nicht ohne Neustart),
verfahren/retro/2026-08-09.md 91 informational tag-ok:v0.4.0 ⚠️ **Der letzte Fall ist der unangenehmste.** Dass `v0.4.0` nicht überschrieben
verfahren/retro/2026-08-09.md 99 prose-or-runtime diesen Monat einzeln und mühsam gelernt haben — Blueprint-Status ≠ error, Mirror
verfahren/retro/2026-08-09.md 103 checked-ok issue-ok:management#28(opened) Das ist die Verallgemeinerung von management#28, das am 2026-08-06 bewusst nach
verfahren/retro/2026-08-09.md 112 checked-ok image-ref:status:next;issue-ok:management#15(opened);issue-ok:management#20(opened) - `status:next`: management#15 und #20 (fällig 31.08.) — Zusage von sorb
verfahren/retro/2026-08-09.md 113 checked-ok image-ref:status:wartet;issue-ok:threadnet-call#4(opened);issue-ok:ThreadNet-Web#11(opened) historical-wording - `status:wartet` entfernt bei threadnet-call#4 und ThreadNet-Web#11: der im Issue
verfahren/retro/2026-08-09.md 115 prose-or-runtime - **M5 — Härtung** angelegt, 14 Issues aus M1 verschoben. Trennlinie: *Ist etwas
verfahren/retro/2026-08-09.md 123 prose-or-runtime ## Offen aus dieser Retro
verfahren/stillstandspruefung.md 11 prose-or-runtime der bei jedem Lauf verworfen wurde, während Flux grün meldete.
verfahren/stillstandspruefung.md 23 prose-or-runtime | Repo ohne aktiven Push-Mirror | `game-operating` wurde angelegt und nie gespiegelt — auf Gitea existierte es nicht |
verfahren/stillstandspruefung.md 24 checked-ok issue-ok:management#28(opened);id-ok:MIRROR-01 | Mirror-Drift | MIRROR-01 (management#28): fällt der Mirror aus, liefert Flux still den letzten Stand weiter |
verfahren/stillstandspruefung.md 25 prose-or-runtime historical-wording | Pipeline mit null Jobs | ThreadNet-Web 203/204, threadnet-call 187 — rot, ohne dass etwas kaputt war |
verfahren/stillstandspruefung.md 26 prose-or-runtime | Erfolgreicher Job ohne Artefakt | `build_embedded` lief seit jeher grün und lud **nichts** hoch |
verfahren/stillstandspruefung.md 27 FLAG path-miss:dist/ path-miss:dist/ | npm-Paket zu klein | `0.19.2-threadnet.6`: 12,5 KB statt 12,8 MB, ohne `dist/` |
verfahren/stillstandspruefung.md 32 prose-or-runtime jahrelang durchrutscht. (Beim ersten Lauf kamen so zwei Projekte zum Vorschein,
verfahren/stillstandspruefung.md 37 prose-or-runtime Geplanter CI-Job im management-Repo, zusätzlich von Hand über *Run pipeline*
verfahren/stillstandspruefung.md 38 prose-or-runtime auslösbar. Befunde färben die Pipeline **rot** — das ist bei uns die Alarmanlage,
verfahren/stillstandspruefung.md 39 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops nicht ein zusätzlicher Meldeweg (siehe `gitops/CLAUDE.md` zur TURN-Rotation).
verfahren/stillstandspruefung.md 53 prose-or-runtime aufgefallen am 2026-08-09: `game-operating` wurde auf Gitea privat gestellt, und
verfahren/stillstandspruefung.md 54 prose-or-runtime die Prüfung übersprang den Mirror-Abgleich klaglos. Ein Repo, das gespiegelt wird,
verfahren/textbloecke.md 5 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops,management Die Konventionen stehen kanonisch in [`CLAUDE.md`](../CLAUDE.md) — aber eine
verfahren/textbloecke.md 13 checked-ok path-ok:CLAUDE.md@axion1337.chat-gitops passiert am 2026-08-02, als `gitops/CLAUDE.md` „keine Gitea-Ausnahme mehr" behauptete,
verfahren/textbloecke.md 14 checked-ok path-ok:CLAUDE.md@management während die `management/CLAUDE.md` zwei nannte.
verfahren/textbloecke.md 24 code-block historical-wording Lies zuerst CLAUDE.md im management-Repo auf git.lab und halte dich daran.
verfahren/textbloecke.md 25 code-block Kanonisch ist git.lab; nie direkt nach Gitea pushen.
verfahren/textbloecke.md 27 code-block Bevor du ein Issue schließt oder darüber urteilst: vollständig lesen, inklusive
verfahren/textbloecke.md 30 code-block Verifiziert und vermutet klar trennen; fremde Messungen als fremde kennzeichnen.
verfahren/textbloecke.md 35 informational forge-repo:sorb/Backlogs > dem Pfad `sorb/Backlogs` statt nach dem Namen `Backlogs`; und ein Issue, von dem
verfahren/textbloecke.md 43 code-block Konventionen: CLAUDE.md im management-Repo — von hier lesbar über den Gitea-Mirror
verfahren/textbloecke.md 44 code-block rohana.axion1337.de/sorb/management. Dort NUR lesen, niemals hinpushen.
verfahren/textbloecke.md 48 code-block Ping auf 10.58.73.17 schlägt IMMER fehl (nur 443 + DNS offen), das ist kein
verfahren/textbloecke.md 58 code-block Öffne auf git.lab ein Issue aus der Vorlage "Deploy-Übergabe"
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Thore Cimbal