Files

T

Thore CimbalandClaude Fable 5 c23bb54a92 feat: slice 4 - the open management issues live in the repo

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>

2026-08-11 12:00:00 +00:00

1.5 KiB

Raw Blame History

type, id, status, created, milestone, priority, area, wartegrund, gitlab_iid, related

type

status

created

milestone

priority

area

wartegrund

gitlab_iid

issue

0021

waiting

2026-08-02

medium

infrastructure

Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren

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-runner per API neu deployen statt nur zu starten.
B — Container über restart: unless-stopped dauerhaft 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.

1.5 KiB Raw Blame History

OVERMIND-03: Windows-Build-VM verschwindet — CI kann sie nur starten, nicht anlegen

1.5 KiB

Raw Blame History