Thore CimbalandClaude Fable 5
c23bb54a92
Gate 4, slice 4: 26 open management issues imported from live git.lab (read-only, descriptions included as authorized; GitLab iid = file id, labels/milestone/priority/due/host/area mapped into frontmatter, the import aborts instead of inventing a missing milestone or priority). Two new issues close the F-004 gap where work was really still open (0033 OVERMIND-01, 0034 CFGMON-11 incl. the plaintext npm-token rotation); CFGMON-12/13 already route to verified git.lab issues, MATRIX-05 is done and needs none (agreed with sorb). The three wiki task blocks now reference their issues, roadmap.md hands all counts to the generated STATUS.md and states M1-M5 per ADR-0010 (closing F-001 in the canonical prose), pruefe_prosa joins the CI validate job, and the import protocol under docs/sources/migration/ records every intervention into imported text. Verified: validate 0/0 over 29 issue files, gen_status --check current (distribution line M1 9 - M2 17 - M4 2 plus per-issue milestone and priority), pruefe_prosa 0 errors with clones and 0 errors/15 unchecked citations in offline CI mode, drift check green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.5 KiB
type, id, status, created, milestone, priority, area, gitlab_iid, related
| type | id | status | created | milestone | priority | area | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|
| issue | 0028 | open | 2026-08-02 | M2 | low | infrastructure | 28 |
MIRROR-01: Ein Ausfall der Push-Mirrors bleibt unbemerkt — Produktion friert still ein
Import aus management#28 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
Der Push-Mirror ist der einzige Weg von git.lab in die Produktion: Flux zieht ausschließlich aus Gitea (ADR-0001). Fällt er aus, passiert nichts Lautes — Flux reconciled weiter den zuletzt gespiegelten Stand. Die Produktion wirkt gesund und ist eingefroren.
Kein Alarm, keine rote Pipeline, kein Log, das jemand liest. Auffallen würde es erst, wenn sich jemand wundert, warum ein Deploy „nicht ankommt".
Warum das jetzt zählt
Aus #15: Welches Credential in den Mirrors hinterlegt ist, ist nicht rekonstruierbar — die API maskiert es, keine Session hat es dokumentiert. Wir wissen also nicht, ob es ein Ablaufdatum hat. Läuft es ab, tritt genau der stille Fall oben ein.
Stand 2026-08-02 laufen alle geprüften Mirrors fehlerfrei (update_status: finished, last_error: —) — das ist eine Momentaufnahme, keine Zusicherung.
Was zu tun ist
Ein Check auf den Mirror-Status der sechs gespiegelten Repos der Gruppe axion1337.chat:
curl -sS -H "PRIVATE-TOKEN: $TOKEN" \
"https://git.lab/api/v4/projects/<id>/remote_mirrors"
# relevant: .update_status != "finished" oder .last_error != null
Offen ist wo er läuft — beides ist vertretbar:
- Prometheus/Alertmanager auf CFGMON (
threadnet-operating) — passt zum vorhandenen Alarmweg, braucht aber ein git.lab-Token auf CFGMON und den Tunnel. - Scheduled CI-Job auf git.lab, wie
canonize_rotationim gitops-Repo — läuft im Lab, kein zusätzliches Credential nach außen, meldet sich über eine rote Pipeline. Dafür merkt er nichts, wenn das Lab selbst aus ist (was aber gerade der Fall ist, in dem die Mirrors ohnehin nicht laufen).
Abgrenzung
Nicht Teil dieses Issues: die Rotation der Tokens selbst (#15) und die Frage, welches Credential dort hinterlegt ist. Hier geht es allein darum, einen Ausfall zu bemerken.
Gefunden beim Session-Abschluss 2026-08-02, beim Nachgehen der Randbedingung aus #15.