Bausteine
Alle Repos, ein System
OCC ist kein Monolith, sondern 8 unabhängige Git-Repositories, die sich zu einem Gesamtsystem zusammensetzen — aktuell 2 davon öffentlich zugänglich, die übrigen in OSS-Vorbereitung oder intern (Status unten, ehrlich gestaffelt). Diese Seite ist die kuratierte Alternative zur rohen GitLab-Gruppenansicht — mit Zweck, Lizenz, Abhängigkeiten, aktuellem Lifecycle-Status und Sync-Alter.
Die 8 Repositories (2 öffentlich)
Governance-Layer, auditierbare Flows, HITL-Gate-Pattern, Projection-Engine, Flow-Schema v2.0 — plus 6 offene Standards (AHIP, AGS, VAC, IOSC, IOP, CPP) unter standards/. Bausteine stammen aus dem IIO-Framework (betrieben von Intelego GmbH, iio.space) — OCC trägt den freigegebenen Teil.
Lizenz: Apache-2.0 (Code) / CC-BY-4.0 (Docs)
Letzter Sync: 2026-05-20 (85 Tage — überfällig, Ziel: max. 30 Tage)
Repo folgt nach OSS-Vorbereitung.
Python-Paket, das den Framework-Kern als installierbare Bibliothek verpackt (pip install iio-governance).
Lizenz: Apache-2.0
Letzter Sync: 2026-05-16 (89 Tage — überfällig, Ziel: max. 30 Tage)
Repo folgt nach OSS-Vorbereitung.
Wiederverwendbare Infrastruktur-Skills (Deploy, DNS, Monitoring, Server-Ops) für Organisationen, die das Framework selbst betreiben.
Lizenz: Apache-2.0
Letzter Sync: 2026-05-20 (85 Tage — überfällig, Ziel: max. 30 Tage)
Repo folgt nach OSS-Vorbereitung.
Referenzimplementierung: HITL-Gate-Pattern angewendet auf einen physischen Roboter (TonyPi Pro). Zeigt dieselbe PDP-Logik (AUTO/HITL/BLOCK) wie der Framework-Kern, nur auf Servo-Bewegungen statt API-Calls.
Lizenz: Apache-2.0 (Code) / CC-BY-4.0 (Docs)
Sync: nativ im öffentlichen Repo entwickelt, kein Monorepo-Sync nötig
Contributions willkommen — 3 good first issues ↗
Spielbares 2D-Tower-Defense-Lehrspiel (IT-Security/Zero-Trust-Konzepte), Beitrag der Intelego GmbH. Zeigt denselben Vibe-Coding→AI-Assistenz→IIO-Governance-Prozess wie der Framework-Kern, angewendet auf ein Spiel statt Infrastruktur-Code. Live auf play.iio.space.
Lizenz: Apache-2.0 (Code) / CC-BY-4.0 (Docs/Narrative)
Letzter Sync: 2026-08-03 (10 Tage)
Contributions willkommen — 3 good first issues ↗
Öffentlicher Index aller OCC-Solutions und Showcases (inkl. Tony) — Metadaten, Lizenz, Status (staged/live). Referenziert die anderen Repos, enthält selbst keinen Solution-Code.
Lizenz: CC-BY-4.0
Letzter Sync: 2026-06-01 (73 Tage — überfällig, Ziel: max. 30 Tage)
Repo folgt nach OSS-Vorbereitung.
Language-Culture-Publishing Kit (LCPK): 12 Kulturprofile für echte kulturelle Sprachadaptation (nicht nur Übersetzung), Language Resolver, Prompt-as-Source Page-Briefs. Treibt bereits die i18n-Schicht dieser Website und die IIO-Cockpit-Sprachumschaltung an.
Lizenz: Apache-2.0
Sync: noch kein GitLab-Repo
Diese Website selbst (Foundation-Auftritt). Governance-Identität nach außen, keine funktionale Abhängigkeit zu den anderen Repos.
Lizenz: CC-BY-4.0
Letzter Sync: 2026-05-20 (85 Tage — überfällig, Ziel: max. 30 Tage)
Repo folgt nach OSS-Vorbereitung.
Lifecycle-Status
Jedes Repo durchläuft einen definierten Publish-Prozess (occ-repo-publish-flow). Stufenübergänge erfordern ein HITL-Gate — kein Repo wird öffentlich ohne Operator-Freigabe.
Wie sich das zusammensetzt
iio-governance-framework ist der Kern — alles andere baut darauf auf oder referenziert ihn. Kein Repo braucht ein anderes, um zu funktionieren, außer diesem einen:
iio-governance-framework (Kern: Layer + Flows + HITL + 6 Standards)
│
├── iio-governance-python (pip-Wrapper um den Kern)
├── infrastructure-skills (Ops-Skills für Kern-Betreiber)
├── governed-robotics-tony (Showcase: Kern-Pattern auf Hardware angewendet)
└── catalog (Index, referenziert Kern + Showcases)
occ.gitlab.io (diese Website — Identität, keine Code-Abhängigkeit)Warum getrennte Repos statt einem Monorepo? Jeder Baustein hat eigene Reifegrad-Geschwindigkeit — der Kern ändert sich selten (Governance-Stabilität), die Showcases (Tony) und der Katalog ändern sich häufig (neue Demos, neue Solutions). Getrennte Repos = getrennte Release-Zyklen, ohne dass ein Showcase-Fix eine Framework-Version erzwingt.