Metarepo

Versionierte Quelle für Fleet-Mitgliedschaft, gemeinsame Contracts, Templates und wiederverwendbare CI-Workflows.

Rolle und Wahrheitsgrenzen

Der normative Rollenvertrag liegt in system/metarepo-role.v1.json.

Metarepo besitzt ausschließlich folgende Wahrheitsbereiche:

• Fleet-Mitgliedschaft in fleet/repos.yml
• gemeinsame Contracts unter contracts/
• kuratierte Templates unter templates/
• wiederverwendbare CI-Workflows unter .github/workflows/

Metarepo ist keine Control Plane und keine Quelle der gesamten Systemarchitektur. Die Zuständigkeiten sind getrennt:

Information	Zuständige Quelle
Systemzwecke, Beziehungen und Einstiegspunkte	systemkatalog
Aufgaben, Queue, Verifikation und Abschluss	bureau
Rechnerzugriff, Leases, Audit und operative Ausführung	grabowski
Laufzeitgesundheit	jeweiliger Dienst und seine Beobachtungsfläche
zeitliche Ereignis- und Änderungsgeschichte	chronik

Die Mitgliedschaft in der Metarepo-Fleet ist nicht gleichbedeutend mit der Zugehörigkeit zum vollständigen Operator-Ökosystem.

Aktive Lieferflächen

Fleet

fleet/repos.yml ist die einzige normative Quelle der Fleet-Mitgliedschaft. Operative Zusatzdaten wie Branch, Domain, Abhängigkeiten und Tooling-Overrides liegen getrennt in fleet/repo-metadata.yml.

Das Top-Level-repos.yml ist eine generierte, nicht normative Kompatibilitätsprojektion für bestehendes WGX-, Graph- und Template-Tooling. Sie wird ausschließlich mit just fleet-projection aus den beiden kanonischen Fleet-Dateien erzeugt. just fleet-projection-check und just validate blockieren manuelle Änderungen oder vergessene Regeneration.

Die gerenderte Fleet-Übersicht wird aus der Mitgliedschaftsquelle erzeugt: docs/_generated/fleet.md.

Contracts

Unter contracts/ liegen versionierte Daten- und Workflowverträge. Änderungen benötigen:

1. einen nachweisbaren Producer- oder Consumerbedarf;
2. Kompatibilitätsbewertung und Versionsentscheidung;
3. grüne Contract- und Consumer-Tests;
4. einen dokumentierten Ablösepfad bei Breaking Changes.

Templates und wiederverwendbare Workflows

• templates/ enthält kuratierte, repoübergreifend bestimmte Vorlagen.
• .github/workflows/reusable-*.yml und weitere workflow_call-Workflows werden von mehreren Repositories eingebunden.
• Aktive Consumer müssen vor Umbenennung oder Entfernung organisationsweit inventarisiert werden.

Legacy- und Kompatibilitätsflächen

Diese Flächen sind weiterhin vorhanden, aber nicht Teil der normativen Metarepo-Rolle:

• repos.yml – deterministisch generierte Kompatibilitätsprojektion; nicht manuell bearbeiten
• wgx/ – vendierter Altstand; kanonischer Eigentümer ist das Repository wgx
• servers/local-mcp/ – lokale Legacy-Brücke; Nutzung und Ablösung werden geprüft
• .github/workflows/heimgewebe-command-dispatch.yml – aktive Kompatibilitätsfläche mit organisationsweiten Callern

Sie dürfen erst entfernt werden, wenn ihre tatsächlichen Consumer und ein grüner Migrations-Readback belegt sind.

Historische Architekturdokumente

Die Dokumente zum früheren „Heimgewebe-Organismus“ sind seit dem 15. Juli 2026 hashgebunden unter docs/archive/heimgewebe-organismus-v0.2/ archiviert. Ihre bisherigen Pfade bleiben als ausdrücklich historische Kompatibilitätseinstiege erhalten. Für die gegenwärtige Systemtopologie ist der Systemkatalog zuständig.

Schnellstart

# Abhängigkeiten installieren
just deps

# repos.yml aus den kanonischen Fleet-Quellen erzeugen
just fleet-projection

# lokale Validierung einschließlich Projektionsdrift, Tests und Workflow-Linting
just validate

# Contract-Prüfungen
just contracts-validate

# Fleet-Übersicht
just list

Typische Änderungen

Contract ändern

1. Producer und Consumer bestimmen.
2. Schemaänderung und Kompatibilität prüfen.
3. Fixtures und Consumer-Tests aktualisieren.
4. Versionierung oder Migrationsfenster festlegen.

Template ändern

1. Ziel- und Consumer-Repositories bestimmen.
2. lokale Abweichung nicht blind überschreiben.
3. Verbesserung kuratieren und im Metarepo testen.
4. Rollout über PRs mit Drift- und Consumerbeleg durchführen.

Beispiele für bestehendes Tooling:

./scripts/sync-templates.sh --pull-from <repo> --pattern "<glob>"
./scripts/sync-templates.sh --push-to <repo> --pattern "<glob>"
./scripts/wgx-doctor --repo <repo> --patterns "<glob1>,<glob2>"

Dokumentation

• Rollenvertrag
• Agentenleitfaden
• Contracts
• Fleet-Management
• Reusable CI
• ADRs
• Runbooks
• Vollständiger Dokumentationsindex

Projektstruktur

metarepo/
├── system/              # Maschinenlesbare Rollen- und Wahrheitsverträge
├── fleet/               # Mitgliedschaft und getrennte operative Fleet-Metadaten
├── contracts/           # Gemeinsame versionierte Contracts
├── templates/           # Kuratierte Shared Templates
├── .github/workflows/   # Reusable Workflows und Repo-CI
├── scripts/             # Sync-, Prüf- und Migrationswerkzeuge
├── docs/                # Metarepo-Dokumentation und Legacy-Material
├── reports/             # Nicht normative Befunde und Drift-Reports
├── repos.yml            # Generierte Kompatibilitätsprojektion; nicht normativ
└── Justfile

Beitragen

Änderungen laufen über Pull Requests. Vor einem Merge müssen Diff, Validierung, Consumer-Auswirkung und Wahrheitsgrenzen geprüft sein. Weitere Details stehen in CONTRIBUTING.md.

Lizenz

Dieses Projekt steht unter der CC0 1.0 Universal Public Domain Dedication. Die mitgelieferte actionlint-Dokumentation stammt vom actionlint-Projekt und steht unter der MIT-Lizenz; siehe LICENSE.txt.