Umsetzung

GitHub: Issues, Milestones und Kanban (Execution)

Die operative Steuerung laeuft im privaten Repo davidverholen/redc: Issues sind die Arbeitspakete, Milestones buendeln die Gates (Phase 0: P0–P4, Phase A: G0–G4), Labels markieren Art (phase-0, phase-a, gate, …) und Issue-Dependencies die Reihenfolge (blocked by).

Rollen (nicht vermischen)

Mechanismus	Zweck
Status (im Project, nicht auf der Issue selbst)	Kanban: Backlog / In Progress / Done — wo du gerade arbeitest
Milestone	Zu welchem Gate/Zielpaket die Issue gehoert (Filter, Fortschritt, optionale Frist)
Labels phase-0 / phase-a	Phase zuordnen; Filter fuer Board-Views
Dependencies	Echte Blocker: „erst X, dann Y“

Empfehlung: ein GitHub Project (z. B. REDC Execution), verknuepft mit dem Repo — nicht Milestones als Spalten nachbauen; Milestones bleiben wie von GitHub gedacht.

Kanban: Spalten = Status

1. GitHub → Projects → neues Project anlegen (oder gh; siehe unten).
2. Projekt mit Repo davidverholen/redc verknuepfen (Link a repository).
3. View → Board (oder Table fuer Listenansicht).
4. Spalten ueber das Feld Status (Standard: Todo, In Progress, Done — oder eigene Werte). Issues per Drag & Drop verschieben.

Mehrere Uebersichten: Views statt mehrerer Projekte

Statt mehrerer getrennter Projekte fuer jede Phase: mehrere gespeicherte Views in einem Project:

View	Sinn
Execution (alle)	Board nach Status; alle Execution-Issues (label:phase-0 OR label:phase-a)
Phase 0	Gleiches Board, Filter label:phase-0
Phase A	Gleiches Board, Filter label:phase-a
Nach Gate (optional)	Table-View, Group by: Milestone — Milestone-Blöcke wie „Zeilen“

So bleibt ein Kanban-Modell; Phasen trennst du per Filter, nicht per doppelte Issue-Listen.

CLI: Project anlegen und Issues einhaengen

gh braucht die Scopes project und read:project (einmalig im Terminal, ggf. Geraetelogin):

gh auth refresh -h github.com -s project,read:project

Projekt anlegen, mit Repo verknuepfen, alle offenen Issues mit phase-0 oder phase-a hinzufuegen:

OWNER="@me"
REPO="davidverholen/redc"
TITLE="REDC Execution"
NUM="$(gh project create --owner "$OWNER" --title "$TITLE" --format json --jq .number)"
gh project link "$NUM" --owner "$OWNER" -R "$REPO"
for n in $(
  { gh issue list -R "$REPO" -l phase-0 --state open --json number -q '.[].number'
    gh issue list -R "$REPO" -l phase-a --state open --json number -q '.[].number'
  } | sort -un
); do
  gh project item-add "$NUM" --owner "$OWNER" --url "https://github.com/$REPO/issues/$n"
done
gh project view "$NUM" --owner "$OWNER" --web

Hinweis: Doppeltes item-add fuer dieselbe Issue kann doppelte Karten erzeugen — Skript nur einmal ausfuehren oder Duplikate im UI entfernen.

Nach dem Anlegen im Browser: Board-View, Status-Spalten pruefen, oben beschriebene gefilterte Views fuer Phase 0 und Phase A speichern.

Das gleiche automatisiert (Repo-Link + alle passenden Issues): tooling/gh_setup_execution_project.sh — nach gh auth refresh mit Project-Scopes ausfuehren.

Roadmap-View: Start- und Zieldatum

Im GitHub Project „REDC Execution“ sind die Felder Start date und Target date angelegt. In der Roadmap-View oben rechts Date fields zuweisen (Start = Start date, Ziel = Target date).

Die erste Version der Termine ist eine grobe Nebenjob-Planung (Schwerpunkt Wochenende, unter der Woche ca. bis 10 h fuer Calls/Koordination), abgestimmt mit den Gates und der UG-Timeline (~4–6 Wochen in phase-a/01-ug-gruenden.md) sowie G4 = Kalendertage ab nominales Go-Live (Tag 30 / 60 / 90). Ankerstart: 7. Apr. 2026 — bei Bedarf im Skript verschieben.

Aktualisieren (nach Anpassung der Tabelle im Skript):

python3 tooling/gh_project_set_roadmap_dates.py

Skript: tooling/gh_project_set_roadmap_dates.py (SCHEDULE und ggf. ITEM_ID bei neuen Issues).

Issue-Beschreibungen (Kontext + Checklisten aus dem Plan, Links auf GitHub-Markdown): tooling/gh_update_execution_issue_bodies.py — bei Plan-Aenderungen anpassen und erneut ausfuehren.

---

Phase 0 — Pre-Validierung

Hier starten: phase-0/README.md

#	Dokument	Was
0	00-these-kill-tests.md	These, Constraints und fruehe Kill-Tests
1	01-markt-sku-validierung.md	Markt, SKU und Erloesspur vorvalidieren
2	02-lieferanten-colo-finanzierung-precheck.md	unverbindlicher Startpfad fuer Hardware, Colo, Finanzierung
3	03-kapital-downside-entscheidung.md	Kapitalaktivierung und persoenliche Downside pruefen
4	04-go-zu-phase-a.md	Go / Pause / No-Go zu Phase A

Phase A — Erster Server live

Hier starten: phase-a/README.md

#	Dokument	Was
0	00-eigenkapital.md	Eigenes Geld sicherstellen (~20k)
1	01-ug-gruenden.md	UG gruenden (parallel zu Schritt 2)
2	02-angebote.md	GPU + Colo + Finanzierung anfragen
3	03-go-no-go.md	Mit echten Zahlen rechnen, Go/No-Go
4	04-live-gehen.md	Bestellen, aufbauen, Vast-Listing

Business Plan: ../BUSINESS-PLAN.md (Phase A = §9.0, §10)