Thore CimbalandClaude Opus 4.8
51c05edb2d
Went through the seven imported waiting issues and replaced the generic 'reason is in the GitLab history' placeholder with the real blocker, which completes #0041. Three of the seven were not merely imprecise but wrong: - #0025: the deploy had long landed; screenshots confirm 24 aggregated messages in the security room (limit 29), summing to the known 126 CRITICALs. - #0014: the A/B/C decision exists as ADR-0008 (option A). Half its open question is now answered — MATRIX has no docker group at all, so the root-equivalence does not apply there. - #0027: the blocking Struktur-Workshop happened on 2026-08-06 and produced three ADRs, but W1 and W3 were spot-checked and are still unresolved. The remaining four wait on a named action by sorb. Measured from here: the GAME exporters are still filtered (and their silences expired on 2026-08-04, so TargetDown has been firing every 4h since), while CFGMON's 9090/3100 are already closed from the internet — so #0008 is about making that state deliberate rather than an acute exposure. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.9 KiB
type, id, status, created, milestone, priority, area, wartegrund, gitlab_iid, related
| type | id | status | created | milestone | priority | area | wartegrund | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|---|
| issue | 0021 | waiting | 2026-08-02 | M2 | medium | infrastructure | Wartet auf Go von sorb für Variante C (Fehlermeldung des CI-Jobs um den Hinweis 'Stack in Dokploy neu deployen' ergänzen); Variante A erst, wenn der Fall ein drittes Mal auftritt. | 21 |
OVERMIND-03: Windows-Build-VM verschwindet — CI kann sie nur starten, nicht anlegen
Import aus management#21 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).
Der CI-Job start_windows_vm macht ausschließlich docker start windows-runner. Existiert der Container nicht, scheitert er mit No such container: windows-runner — so geschehen am 2026-08-02 (Job 498), nachdem der Container zwischenzeitlich verschwunden war (vermutlich durch einen Dokploy-Redeploy oder den Host-Neustart; nicht verifiziert).
sorb hat ihn manuell neu gestartet, danach lief der Build. Der Fall wiederholt sich aber, sobald der Stack erneut angefasst wird.
Optionen:
- A — Job robuster machen: bei fehlendem Container den Dokploy-Stack
windows-runnerper API neu deployen statt nur zu starten. - B — Container über
restart: unless-stoppeddauerhaft halten. ⚠️ Widerspricht dem On-demand-Prinzip (die VM belegt 8 GB) und war eine bewusste Entscheidung. - C — so lassen, aber die Fehlermeldung im Job um den Hinweis „Stack in Dokploy neu deployen" ergänzen (billigste Variante).
Empfehlung: C jetzt, A wenn es ein drittes Mal passiert.
Präzisierung 2026-08-15
Kein technischer Blocker — das Issue enthält bereits die Empfehlung (C jetzt, A beim dritten Auftreten) und wartet nur auf das Go. C ist ein Einzeiler in der Job-Definition und macht den Fall selbsterklärend, statt die nächste Session wieder raten zu lassen. Bislang ist der Fall einmal aufgetreten (2026-08-02, Job 498).