Zum Hauptinhalt springen
Technische Referenz

Bausteine
Alle Repos, ein System

OCC ist kein Monolith, sondern 7 unabhängige, öffentliche Git-Repositories, die sich zu einem Gesamtsystem zusammensetzen. Diese Seite ist die kuratierte Alternative zur rohen GitLab-Gruppenansicht — mit Zweck, Lizenz, Abhängigkeiten und aktuellem Lifecycle-Status.

Die 7 Repositories

iio-governance-framework — Kern OSS-Vorbereitung

259 Governance-Layer, 546 auditierbare Flows, HITL-Gate-Pattern, Projection-Engine, Flow-Schema v2.0 — plus 6 offene Standards (AHIP, AGS, VAC, IOSC, IOP, CPP) unter standards/.

Lizenz: Apache-2.0 (Code) / CC-BY-4.0 (Docs)

Repo folgt nach OSS-Vorbereitung.

iio-governance-python — Aufbauend auf Kern OSS-Vorbereitung

Python-Paket, das den Framework-Kern als installierbare Bibliothek verpackt (pip install iio-governance).

Lizenz: Apache-2.0

Repo folgt nach OSS-Vorbereitung.

infrastructure-skills — Aufbauend auf Kern OSS-Vorbereitung

Wiederverwendbare Infrastruktur-Skills (Deploy, DNS, Monitoring, Server-Ops) für Organisationen, die das Framework selbst betreiben.

Lizenz: Apache-2.0

Repo folgt nach OSS-Vorbereitung.

governed-robotics-tony — Showcase — nutzt Kern Contribution offen

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)

Contributions willkommen — 3 good first issues ↗

Repo auf GitLab ↗ · Technische Details →

Blobclash IT-Defense — Showcase — nutzt Kern Contribution offen

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)

Contributions willkommen — 3 good first issues ↗

Repo auf GitLab ↗ · Technische Details →

catalog — Verzeichnis OSS-Vorbereitung

Ö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

Repo folgt nach OSS-Vorbereitung.

iio-language-culture-kit — Aufbauend auf Kern Intern

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

Technische Details →

occ.gitlab.io — Identität — kein Code-Abhängiger OSS-Vorbereitung

Diese Website selbst (Foundation-Auftritt). Governance-Identität nach außen, keine funktionale Abhängigkeit zu den anderen Repos.

Lizenz: CC-BY-4.0

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.

Intern Nur im privaten Monorepo — noch kein öffentliches Repo
OSS-Vorbereitung OSS-Vorbereitung läuft: Secrets-Scan, Lizenz-Audit, Kuration
Öffentlich (Read-Only) Öffentlich lesbar und klonbar — Contribution-Prozess noch nicht live
Contribution offen Externe Beiträge aktiv eingeladen und bearbeitet
Archiviert Deprecated oder abgelöst

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:

Abhängigkeits-Struktur
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.

Weiterlesen