Framework-Umbau: Backlogs wird management-Repo (ADR-0005, Kanban + Scrum-Elemente)
- decisions/: ADR-Verzeichnis mit Template + 0001-0005 (git.lab-Kanonik, Lab-Cutover, CVE-Meldeweg, Site-to-Site-VPN-Design, Framework-Wahl) - vision/: je eine Vision fuer Community/Tool/Plattform (Entwuerfe) - roadmap.md: Linien, Meilenstein-Kandidaten, Kadenz - hosts/+shared/: offene Punkte -> Issues #1-#12 im management-Projekt (IDs bleiben in den Titeln), Dateien halten Bestand + Historie - README: Framework, Board/status-Labels (WIP-Limit 2), Topologie Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
This commit is contained in:
Thore Cimbal
co-authored by
Claude Fable 5
Claude Fable 5
parent
0f3f155bc5
commit
fdf30d42e1
@@ -0,0 +1,30 @@
|
||||
# 0001 — git.lab ist kanonisch, Gitea wird per Push-Mirror beliefert
|
||||
|
||||
**Status:** akzeptiert · **Datum:** 2026-07-31 (rückwirkend dokumentiert 2026-08-01) · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Build-CI brauchte mehr Ressourcen als CFGMON hat (webpack ~4 GB Heap auf einem
|
||||
3,7-GiB-Host) und Gitea Actions zeigte mehrere echte Bugs. Das Homelab-GitLab
|
||||
(`git.lab`, nur im Lab/VPN auflösbar) hat die Kapazität; Produktion (Flux) darf
|
||||
aber nicht von der Lab-Verfügbarkeit abhängen.
|
||||
|
||||
## Entscheidung
|
||||
|
||||
`git.lab/axion1337.chat/*` ist die kanonische Heimat aller Repos; Gitea/rohana
|
||||
wird über Push-Mirrors beliefert und bleibt Flux-Source, Container-Registry,
|
||||
npm-Registry und Release-Download. **Direkte Pushes zu Gitea sind für gespiegelte
|
||||
Repos verboten** — der Mirror überschreibt divergenten Stand per Force.
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- Bei Lab-Ausfall läuft Prod weiter; nur neue Builds pausieren.
|
||||
- Commits, die doch auf Gitea landen (z. B. Cluster-CronJobs ohne Lab-Route),
|
||||
brauchen das Kanonisierungs-Verfahren (`verfahren/deploy-uebergabe.md`):
|
||||
`.patch` ziehen, `git am`, Push über git.lab. Zweimal live gebraucht.
|
||||
- Arbeiten an den Repos setzt Lab-Zugang voraus (vor Ort oder VPN).
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
- CFGMON-CI aufrüsten (Swap/Limits): strukturell zu klein, verworfen mit CFGMON-10.
|
||||
- git.lab öffentlich exponieren: Angriffsfläche fürs Lab, stattdessen VPN (→ 0004).
|
||||
@@ -0,0 +1,30 @@
|
||||
# 0002 — Issues und Management-Repo ziehen ins Lab („das Lab ist die Quelle der Wahrheit")
|
||||
|
||||
**Status:** akzeptiert · **Datum:** 2026-08-01 · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Nach dem Code-Umzug (ADR-0001) lagen Projektmetadaten (Issues, Backlogs-Repo)
|
||||
weiter auf Gitea — zwei Wahrheiten, driftgefährdet. Erreichbarkeits-Blocker
|
||||
LABNET-01 (WireGuard-Roadwarrior) wurde am 2026-08-01 gelöst.
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Alle Projekt-Issues leben auf git.lab (62 migriert, Gitea-Issues geschlossen mit
|
||||
Verweis); das Backlogs-Repo zieht als `axion1337.chat/management` ins Lab
|
||||
(Push-Mirror → `sorb/management` auf Gitea). Das Lab ist die Quelle der Wahrheit.
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- ⚠️ gitops-Issue-Nummern haben sich verschoben (Gitea zählte PRs mit); die
|
||||
verbindliche Zuordnung steht im Migrations-Fußtext jedes GitLab-Issues.
|
||||
- **Befristete Ausnahme:** Deploy-Übergabe-Issues laufen auf dem Gitea-Tracker
|
||||
von `sorb/management`, weil CFGMON git.lab (noch) nicht erreicht. Diese
|
||||
Ausnahme wird durch das Site-to-Site-VPN (ADR-0004) abgelöst — sie war der
|
||||
Auslöser für die ADR-Pflicht bei Ausnahmen (siehe `decisions/README.md`).
|
||||
- Releases bleiben auf Gitea (öffentlicher Download-Pfad), ebenso das gitops-Wiki.
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
- Issues auf Gitea belassen: dauerhafte Doppelführung, Roadmap/Boards unmöglich.
|
||||
- git.lab exponieren statt VPN: siehe ADR-0001/0004.
|
||||
@@ -0,0 +1,30 @@
|
||||
# 0003 — CVE-Meldeweg: aggregierte Alarme, eigener Security-Raum, gleicher Bot
|
||||
|
||||
**Status:** akzeptiert · **Datum:** 2026-08-01 · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Der erste CVE-Alarmweg (eine Matrix-Nachricht pro CVE) flutete den Raum mit 126
|
||||
Nachrichten und musste stummgeschaltet werden (gitops#51, AAR in `verfahren/aar/`).
|
||||
Gleichzeitig war entschieden (CFGMON-13), Release-/Security-Meldungen von
|
||||
Betriebsalarmen zu trennen.
|
||||
|
||||
## Entscheidung
|
||||
|
||||
CVE-Alarme werden **pro Scan-Ziel aggregiert** (`count by (target, target_type,
|
||||
host)`, CRITICAL sofort / HIGH nach 24 h) und in den **Security-Raum**
|
||||
(`!YRJvcEbVXtRlUIkNld`) geroutet; Details liegen im Grafana-CVE-Dashboard, die
|
||||
Nachricht verlinkt nur dorthin. Absender bleibt der bestehende `@alerts`-Bot
|
||||
(ein Bot, Trennung über Räume).
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- Raum bleibt lesbar; Einzel-CVE-Detail wandert in Dashboard/Metriken
|
||||
(`trivy_vuln_info{...}` mit CVE-ID, Severity, fixed_version, first_seen).
|
||||
- Pflichtfelder je Meldung: CVE-ID, Mitigation/Fix-Version, Zeitstrahl, Ort, Typ.
|
||||
- Follow-up-Idee (sorb): Grafana-Dashboard als Widget direkt im Matrix-Raum.
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
- Eine Nachricht pro CVE: real erlebter Flood, Raum unbrauchbar.
|
||||
- Eigener Bot je Meldungsklasse: mehr Betrieb ohne Erkenntnisgewinn, Räume trennen genügt.
|
||||
@@ -0,0 +1,40 @@
|
||||
# 0004 — Site-to-Site-VPN Hetzner-Projektnetz ↔ Lab, schaltbar über die UDM
|
||||
|
||||
**Status:** vorgeschlagen (Design abgestimmt, Umsetzung offen → [Issue #12](https://git.lab/axion1337.chat/management/-/issues/12)) · **Datum:** 2026-08-01 · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Das Lab ist die Quelle der Wahrheit (ADR-0002), aber die Hetzner-Hosts erreichen
|
||||
`git.lab` nicht — das erzwang beim Cutover die Übergabe-Issue-Ausnahme. Ein
|
||||
dauerhafter Zugang von exponierten Servern ins Heimnetz soll es trotzdem nicht sein.
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Ein **eigener WireGuard-Site-to-Site-Tunnel** (getrennt vom Roadwarrior) verbindet
|
||||
das Hetzner-Projektnetz `10.0.0.0/24` mit dem Lab — **die UDM initiiert**, der
|
||||
An/Aus-Schalter liegt in der UniFi-UI (Bedarfsfall-Prinzip, Kontrolle im Lab):
|
||||
|
||||
- Endpunkt = CFGMON (WG-Listener UDP 51821, ufw nur für `178.25.213.70/32`);
|
||||
keine neue Portfreigabe am Heimanschluss.
|
||||
- Transfernetz `10.58.75.0/24`; CFGMON ist Hetzner-seitiges Gateway
|
||||
(Forwarding + Hetzner-Cloud-Netzwerk-Route `10.58.73.0/24 → 10.0.0.3`).
|
||||
- Split-Tunnel strikt (AllowedIPs nur `10.58.73.0/24`), Split-DNS nur `~lab`
|
||||
→ `10.58.73.1` (kein `lab.de`, kein `axion1337.de`).
|
||||
- Eigene UDM-Firewall-Zone: nur → Overmind:443 + DNS `10.58.73.1:53`.
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- Übergabe-Issues können nach Umsetzung auf git.lab umziehen; die Ausnahme aus
|
||||
ADR-0002 entfällt.
|
||||
- Ein kompromittierter Hetzner-Host kann den Tunnel nicht öffnen (Initiative
|
||||
liegt bei der UDM) und sieht bei offenem Tunnel nur git.lab:443.
|
||||
- Der TURN-Rotations-CronJob trifft nur bei eingeschaltetem Tunnel auf git.lab —
|
||||
seine Gitea-PR-Ausnahme bleibt, bewusst.
|
||||
- game.axion1337.de profitiert erst nach Aufnahme in den vSwitch (GAME-01).
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
- Einzelne Roadwarrior-Profile pro Server: Schalter läge auf den exponierten
|
||||
Hosts, Key-Streuung, kein Site-Routing.
|
||||
- Tunnel dauerhaft an: widerspricht dem Bedarfsfall-Prinzip ohne echten Gewinn.
|
||||
- git.lab öffentlich exponieren: größte Angriffsfläche, klar verworfen.
|
||||
@@ -0,0 +1,44 @@
|
||||
# 0005 — Projektmanagement: Kanban-Rückgrat mit leichten Scrum-Elementen
|
||||
|
||||
**Status:** akzeptiert · **Datum:** 2026-08-01 · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Die Arbeit (Solo-Betrieb plus Claude-Sessions, unregelmäßige Abendblöcke,
|
||||
incident-getrieben) fasert ohne Struktur aus. Artefakte existierten verstreut
|
||||
(Markdown-Backlogs, Issues, AARs) ohne verbindenden Rahmen. sorb ist
|
||||
zertifizierter Scrum Master (ohne Praxis in der Rolle).
|
||||
|
||||
## Entscheidung
|
||||
|
||||
**Kanban als Betriebssystem**, ergänzt um die Scrum-Artefakte, die solo tragen:
|
||||
|
||||
| Element | Umsetzung |
|
||||
|---|---|
|
||||
| Board | GitLab-Gruppen-Board (Gruppe `axion1337.chat`), Spalten über `status:`-Labels |
|
||||
| Pull statt Commitment | `status:next` ist die einzige Zusage; gezogen wird nach Kapazität |
|
||||
| WIP-Limit | **max. 2 × `status:doing`** (Konvention — CE hat keine Board-Limits) |
|
||||
| Explizite Policies | ein `status:`-Label pro Issue; blockiert = `status:wartet` mit benanntem Grund |
|
||||
| Product Goal / Vision | `vision/` (eine Datei je Linie) |
|
||||
| Refinement | die etablierten Entscheidungsrunden (Vorlagen mit Optionen) |
|
||||
| Review/Retro | AARs (`verfahren/aar/`) nach Deploys/Incidents |
|
||||
| Definition of Done | Deploy-Übergabe-Verfahren (`verfahren/deploy-uebergabe.md`) |
|
||||
| Roadmap/Meilensteine | Gruppen-Milestones + `roadmap.md` (CE: keine Epics/Roadmap-View) |
|
||||
| Entscheidungen | ADRs in `decisions/` |
|
||||
| Experimente | Lean-Startup-Muster (Hypothese → kleinstes Experiment → messen) für Produktideen wie Raidplaner/Invite-Workflow |
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- Das Backlogs-Repo wird zum Management-Repo `axion1337.chat/management`;
|
||||
offene Punkte aus `hosts/`/`shared/` sind Issues mit `host:`-Labels,
|
||||
die Markdown-Dateien halten Bestand und Historie.
|
||||
- Ein Backlog-System statt zwei; das Gruppen-Board zeigt alles Offene.
|
||||
- Disziplin-Pflichten: Status-Labels pflegen, WIP-Limit respektieren,
|
||||
ADR bei Architekturentscheidungen und dauerhaften Ausnahmen.
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
- Scrum/Nexus: Sprints und Commitment brauchen planbare Team-Kapazität —
|
||||
bei Solo-Betrieb mit unregelmäßigen Blöcken Theater; Nexus ist Multi-Team.
|
||||
- Lean Startup / Design Thinking als Rahmen: Produktentdeckungs-Werkzeuge,
|
||||
kein Betriebs-Framework — bleiben als Werkzeug im Einsatz.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Architecture Decision Records (ADR)
|
||||
|
||||
Eine Datei pro Entscheidung, fortlaufend nummeriert, Format siehe
|
||||
[template.md](template.md) (MADR-light). ADRs werden **nie umgeschrieben** —
|
||||
eine revidierte Entscheidung bekommt ein neues ADR, das alte wird im Status
|
||||
auf `abgelöst durch NNNN` gesetzt.
|
||||
|
||||
**Wann ist ein ADR Pflicht:**
|
||||
|
||||
- Architektur- oder Prozessentscheidungen, die mehrere Repos/Hosts betreffen
|
||||
- **Jede dauerhafte Ausnahme von einer bestehenden Regel** — eine Ausnahme, die
|
||||
nur dokumentiert, aber nicht entschieden wurde, ist ein Fehler (gelernt beim
|
||||
git.lab-Cutover 2026-08-01: die „Übergabe-Issues bleiben auf Gitea"-Ausnahme
|
||||
hätte als Entscheidungsvorlage kommen müssen, nicht als Fußnote)
|
||||
- Verworfene Wege, deren erneute Prüfung Zeit kosten würde („warum haben wir
|
||||
das damals nicht gemacht?")
|
||||
|
||||
Kleine, repo-lokale Entscheidungen bleiben im jeweiligen Projekt (Commit-Message
|
||||
oder Issue) — nicht jede Abwägung braucht ein ADR.
|
||||
@@ -0,0 +1,19 @@
|
||||
# NNNN — Titel (Aussagesatz der Entscheidung)
|
||||
|
||||
**Status:** vorgeschlagen | akzeptiert | abgelöst durch NNNN · **Datum:** JJJJ-MM-TT · **Entscheider:** sorb
|
||||
|
||||
## Kontext
|
||||
|
||||
Was ist das Problem, was zwingt zur Entscheidung? (2–5 Sätze)
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Was wurde entschieden — als klare Aussage, umsetzbar ohne den Kontext zu lesen.
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
Was wird dadurch besser, was nehmen wir bewusst in Kauf, was ist jetzt Pflicht.
|
||||
|
||||
## Verworfene Alternativen
|
||||
|
||||
Je Alternative ein Satz, warum nicht.
|
||||
Reference in New Issue
Block a user