Der Systemkatalog beschreibt die stabilen Bestandteile des Heimgewebe-Ökosystems: vorhandene Systeme, ihren Zweck, ihren langfristigen Lebenszyklus, ihre Grenzen, Wahrheitszuständigkeiten, dauerhafte Beziehungen und Einstiegspunkte.
Er ist kein Steuerungs- oder Statussystem. Aufgaben, Prioritäten, Laufzustände, Pull Requests, Prüfungen und Ausführung bleiben bei den dafür zuständigen Primärsystemen.
- Erzeugte Leseansicht
- Veröffentlichtes Kartenmanifest
- Katalogpolicy
- Systeme
- Stabile Beziehungen
- Stabile Resilienzsemantik
- Wahrheitszuständigkeiten
- Agenteneinstieg
- Architektur
- Audit der früheren Cabinet-Räume
- Resilienz-Gap-Matrix v1
- Welche stabilen Systeme sind katalogisiert, und welche Metarepo-Fleet-Repositories sind abgedeckt?
- Welchem Zweck dient jedes System?
- Ist seine stabile Katalogrolle aktiv, im Übergang, eine Referenz, archiviert oder außer Betrieb?
- Wofür ist es ausdrücklich nicht zuständig?
- Wem gehört welche Wahrheit?
- Welche stabilen Beziehungen bestehen?
- Welche stabile Kritikalität, Ausfalldomänen, Kopplungsarten und zulässigen Recoverypfade sind geprüft?
- Wo liegen die verlässlichen Einstiegspunkte?
- Welche Aufgabe als Nächstes bearbeitet werden soll.
- Ob ein Dienst gerade gesund ist.
- Ob ein Pull Request mergebar ist.
- Ob Tests oder Reviews ausreichend sind.
- Ob eine Ausführung erlaubt ist.
- Ob ein historischer Claim heute noch gilt.
- Ob ein Recoverypfad aktuell bereit, getestet oder ausführbar ist.
Dafür gelten die Primärquellen:
| Bereich | Primärquelle |
|---|---|
| Aufgaben, Queue, Claims, Receipts | Bureau |
| Lokale und repositorybezogene Ausführung | Grabowski |
| Repositories, Branches, PRs, Issues, Reviews | GitHub |
| Technische Prüfergebnisse | CI und Review-Gates |
| Laufende Dienste | Runtime, systemd, Healthchecks und Logs |
| Verifizierbarer, zitierfähiger Codebase-Kontext | RepoGround |
| Allgemeine Live-Anzeige | Leitstand |
RepoGround ist die einzige aktive Produkt-, Repository-, Befehls- und Runtimeidentität. Frühere Namen bleiben ausschließlich in unveränderlichen historischen Belegen oder versionierten Datenkennungen erhalten und sind keine aktiven Kompatibilitätseinstiege.
catalog/ Schema und nichtkanonisches Beispiel
policy/ Rollen- und Projektionsgrenzen
registry/ecosystem/ Kanonische Systeme, Fleet-Abdeckung, Beziehungen, Resilienz, Claims und Zuständigkeiten
rendered/ Deterministisch erzeugte Leseansicht und Karte
scripts/ Validatoren, Renderer und Artefaktmanifest-Werkzeug
Die frühere Cabinet-Raumstruktur liegt ausschließlich unter docs/archive/cabinet-era/. Sie ist historisches Material, keine aktive Navigation, kein zweiter Katalog und keine Wahrheitsquelle.
Die Fleet-Mitgliedschaft selbst gehört Metarepo (fleet/repos.yml). Der Systemkatalog gleicht diese Quelle ab, übernimmt daraus aber weder Zweck noch Architektursemantik. Jedes Fleet-Repository muss katalogisiert sein; Quellausschlüsse wie fleet: false müssen ausdrücklich dokumentiert bleiben.
Der vollständige Organisationsumfang steht separat in registry/ecosystem/organization-scope.v1.json. Dort ist jedes nicht geforkte Heimgewebe-Repository einschließlich archivierter Repositories entweder als Katalogsystem, archivierte Referenz oder begründeter Ausschluss klassifiziert. Die Datei enthält die vollständige aktuelle Klassifikation. CI mintet dafür kurzlebig ein ausschließlich lesendes Heimgewebe-App-Token und gleicht den Umfang einschließlich privater Repository-Metadaten live gegen GitHub ab. Die konkreten Anzahlen werden aus den kanonischen Daten berechnet statt in dieser Dokumentation doppelt gepflegt. Private Commit- und Inhaltsmetadaten werden nicht in den öffentlichen Quellenbindungen veröffentlicht.
Konkrete Coding-Agenten sind keine stabilen Katalogsysteme. Die dauerhafte Zuständigkeit für Agent-Auswahl und Rollenrouting liegt bei Grabowski und wird als Authority-Domäne agent_routing referenziert.
Für Agenten und lokale Werkzeuge gibt es eine statusfreie Leseoberfläche über die versionierten JSON-Dateien:
python3 scripts/systemkatalog_query.py system grabowski
python3 scripts/systemkatalog_query.py repository weltgewebe
python3 scripts/systemkatalog_query.py truth-owner agent_routing
python3 scripts/systemkatalog_query.py relations bureau
python3 scripts/systemkatalog_query.py entrypoints leitstand
python3 scripts/systemkatalog_query.py failure-domain host:heim-pc
python3 scripts/systemkatalog_query.py recovery-mode grabowski-release-rollbackJede Ausgabe nennt den gelesenen Katalogcommit, die Quellpfade und – soweit öffentlich zulässig – die zugehörige Quellenbindung. Die CLI besitzt keine Datenbank, keine Schreibschnittstelle und keine Runtime-Autorität.
Jeder Knoten trägt eine reviewte Katalogklassifikation active, transition, reference, archived oder retired. Sie beschreibt die langfristige Rolle im Ökosystem und nennt Prüfdatum sowie Evidenzreferenzen. Sie behauptet weder, dass ein Prozess läuft, noch dass ein GitHub-Repository archiviert werden darf oder eine Bureau-Aufgabe abgeschlossen ist.
Die Mermaidkarte macht diese Klassen sichtbar, ohne die getrennte Kantenstabilität stable, bounded oder related umzudeuten. Eine stabile Beziehung zu einem historischen Knoten bleibt eine stabile historische Beziehung und wird nicht zu einer aktiven Betriebsabhängigkeit.
registry/ecosystem/source-bindings.v1.json bindet jedes System und jede stabile Beziehung an einen geprüften Quellstand, einen Locator, eine Prüfmethode, ein Prüfdatum und eine Unsicherheit. Öffentliche Repositoryquellen werden an Commit und Inhalts-SHA-256 gebunden. Kataloginterne Quellcommits, die kein Vorfahr von origin/main sind, benötigen zusätzlich den deterministischen Git-Tag systemkatalog-provenance-v1/<vollständiger Commit-SHA>. Der Tag muss exakt auf den benannten Commit zeigen und hält ihn nach Squash-Merge und Branch-Löschung in frischen Clones erreichbar. Inhaltsdigest, Locator und bei Squash-Äquivalenz die aktuellen Dateibytes werden weiterhin unabhängig geprüft. Bei privaten Repositories bleiben Commit und Inhalt redigiert; veröffentlicht wird nur ein Digest nichtvertraulicher Klassifikationsmetadaten.
policy/freshness-slo.v1.json definiert Erkennungs- und Reviewziele. GitHub- und Fleet-Abweichungen sowie Änderungen gebundener Primärdokumente erzeugen einen maschinenlesbaren Driftbericht. Der Folgeschritt bleibt ausdrücklich proposal-only: Er darf einen deduplizierten Bureau-Kandidaten und einen Änderungsvorschlag erzeugen, aber keine neue Semantik automatisch mergen.
python3 scripts/read_github_catalog_observations.py --output /tmp/systemkatalog-observations.json
python3 scripts/system_catalog_drift.py \
--github-observations /tmp/systemkatalog-observations.json \
--fleet-file /pfad/zu/metarepo/fleet/repos.yml \
--checkDer Systemkatalog bleibt damit statisch. Laufzustand und Alarmanzeige gehören weiterhin in Bureau, Leitstand, CI und die lokale Operatorumgebung.
Der Systemkatalog wird ausschließlich als versionierte, statische Repositoryartefakte bereitgestellt:
rendered/system-catalog.mdals lesbare Katalogansicht;rendered/ecosystem-registry-map.mmdals Mermaidkarte;registry/ecosystem/*.jsonundclaims.jsonlals kanonische Daten, einschließlich statusfreier Resilienzsemantik;rendered/ecosystem-map-artifact-manifest.jsonals veröffentlichter, commit- und hashgebundener Übergabevertrag für Verbraucher wie Leitstand und Schauwerk.
Eine eigene HTTP-Runtime, Datenbank, Queue oder Schreibschnittstelle gehört nicht zum Produkt. Aktuelle Betriebszustände werden weiterhin an ihren jeweiligen Runtime-Primärquellen geprüft.
Cabinet- und Agentenlaufzeitpfade werden absichtlich nicht durch .gitignore verborgen. Falls solche Pfade erneut entstehen, bleiben sie im Working Tree sichtbar; der Repository-Vertrag verhindert zusätzlich, dass sie außerhalb von docs/archive/cabinet-era/ versioniert werden.
Das Manifest wird absichtlich in einem zweiten Commit veröffentlicht: Der erste Commit enthält die Katalogdaten und Projektionen. Danach bindet das Manifest exakt diesen Artefakt-Commit und die SHA-256-Prüfsummen der sechs ausgelieferten Dateien. So entsteht keine unmögliche Selbstreferenz auf den Commit, der das Manifest selbst enthält.
# 1. Katalogdaten und Projektionen committen
python3 scripts/render_system_catalog.py
python3 scripts/render_ecosystem_registry_map.py
git commit
# 2. Den Artefakt-Commit dauerhaft adressierbar machen
artifact_commit="$(git rev-parse HEAD)"
git tag "systemkatalog-provenance-v1/$artifact_commit" "$artifact_commit"
# 3. Manifest an diesen Artefakt-Commit binden und separat committen
python3 scripts/write_ecosystem_map_artifact_manifest.py --source-commit "$artifact_commit"
git add rendered/ecosystem-map-artifact-manifest.json
git commit
# 4. Branch und alle neu benötigten Provenienz-Tags vor der PR-CI veröffentlichen
git push origin HEAD
git push origin "refs/tags/systemkatalog-provenance-v1/$artifact_commit"--check liest die tatsächlich veröffentlichte Datei und prüft den gebundenen Quellcommit sowie die sechs Artefakthashes. Ist der Quellcommit kein Vorfahr von origin/main, muss der deterministische Provenienz-Tag vorhanden und unverändert auf genau diesen Commit gebunden sein. Nach einem Squash-Merge darf der langlebige Commit eine andere Identität besitzen, aber nur wenn alle sechs ausgelieferten Artefakte dort bytegenau dem Manifest entsprechen. Fehlende oder verschobene Tags, fehlende Artefakte, abweichende Bytes oder ein weder genealogisch noch inhaltlich gebundener Hauptstand bleiben fail-closed. Für weitere kataloginterne Quellcommits wird derselbe Tag vor der PR-CI erzeugt und veröffentlicht.
./scripts/ci/validate-repository.sh
python3 -m unittest discover -s scripts/tests -p 'test_*.py'
python3 scripts/check_fleet_coverage.py --fleet-file /pfad/zu/metarepo/fleet/repos.yml
python3 scripts/check_organization_scope.py
python3 scripts/check_organization_scope.py --github-inventory /pfad/zur/github-inventory.jsonEin grüner Lauf belegt Struktur- und Vertragskonsistenz. Er belegt nicht automatisch Runtime-Korrektheit, fachliche Vollständigkeit oder Merge-Reife.