Blobclash IT-Defense
Ein Spiel, das kämpft, was es lehrt
Blobclash ist ein spielbares 2D-Tower-Defense-Lehrspiel — der Spieler verteidigt IT-Infrastruktur gegen einfallende Bedrohungen (Bugs, Hacker, Hardware-Fehler, sogar einen KI-Boss). Entstanden als Vibe-Coding-Prototyp der Intelego GmbH, dann durch denselben IIO-Governance-Apparat transformiert, den das Spiel selbst vermittelt: Audit-Findings, HITL-Gates, ein vollständiger OSS-Repo-Lifecycle.
Direkt spielen
Kein Login, kein Download, kein Paywall — Browser öffnen und verteidigen:
Die Rekursion
Blobclash ist kein gewöhnliches Spiel — es ist ein selbst-beweisendes Artefakt. Drei Ebenen fallen zusammen:
- Das Spiel lehrt — IT-Defense, Zero-Trust, Defense-in-Depth, Incident Response.
- Das Spiel wurde gebaut — via Vibe-Coding → AI-Assistenz → IIO-Governance, denselben Methoden, die es vermittelt.
- IIO governed das Spiel — mit denselben Prinzipien: HITL-Gates, Audit-Findings → Tickets, Geschichte wird sichtbar.
Der schwierigste Gegner im Spiel heißt LLM-Leviathan — ein neuronales-Netz-Boss, der drei Sprachen spricht. Ein Spiel über AI-Bedrohungen, gebaut von einer AI, bekam einen AI-Boss. Das ist keine Design-Entscheidung — das ist Rekursion.
Von Vibe-Coding zu Governance
45 Commits im Zeitraum März–Mai 2026, ohne Projektplan,
ohne Architektur-Entscheidung, ohne Ticket-System — reines Vibe-Coding.
Am 24. Mai 2026 übernahm IIO: ein bestehendes AUDIT_FINDINGS.md
mit 6 dokumentierten Findings wurde durch den regulären Governance-Prozess
geschleust.
| Finding | Severity | Ergebnis |
|---|---|---|
BLC-001 — _finalizeHof elapsed-time | MEDIUM | bereits im Code gefixt |
| BLC-002 — Response-Error-Handling | LOW | fixed |
| BLC-003 — State-Reset-Lücken | LOW | fixed |
| BLC-004 — Path-Traversal | LOW (Security) | bereits geschützt |
| BLC-005 — Body-Size-Limit | LOW (Security) | bereits implementiert (64 KB) |
| BLC-006 — CORS-Konfiguration | LOW (Security) | bereits konfigurierbar |
4 von 6 Findings waren bereits vor dem Audit im Code behoben — das Spiel hatte sich zwischen Erstellung und Governance-Übernahme selbst verbessert. Keine der drei sicherheitsrelevanten Findings (BLC-004/005/006) war offen, als das Repo öffentlich wurde.
OSS-Repo-Lifecycle in drei Gates
Der Übergang von privatem Monorepo-Code zu einem eigenständigen,
contribution-offenen OSS-Repo lief über occ-repo-publish-flow
— jede Stufe ein eigenes, per-Repo parametrisiertes HITL-Gate:
- cleanup — Secrets-Scan, SBOM + License-/CVE-Audit, CONTRIBUTING/Code-of-Conduct/Security-Policy angelegt.
- public-readonly — Repo-Move nach
gitlab.occ.iio.space/occ/blobclash, öffentlich lesbar/klonbar. - contribution-open — 3 good-first-issues live, externe Beiträge aktiv eingeladen.
Open Source
Lizenz: Apache-2.0 (Code), CC-BY-4.0 (Docs/Narrative)
Repository: gitlab.occ.iio.space/occ/blobclash
Contribution: DCO-basiert (git commit -s), kein CLA nötig für Apache-2.0 — gleiches Muster wie governed-robotics-tony.
Good First Issues: 3 offene Einstiegsaufgaben ↗