RUNTIME-VALIDATION

Runtime Validation#

Zweck#

Dieser Einstieg validiert die materialisierte Runtime-Struktur. Das Repository ist ein Runtime Repository und benötigt keinen eigenen AI_STARTS_HERE.md, solange kein AI-gesteuerter semantischer Workflow zu seiner Schnittstelle gehört.

Strukturprüfung#

Mindestens vorhanden sein müssen:

• README.md,
• ◆manifest.json,
• INSTALLATION.md,
• test/,
• production/,
• die in ◆manifest.json deklarierten Root- und Validierungseinstiege.

Verantwortungsprüfung#

Das Repository enthält materialisierte Laufzeitstruktur, Konfigurationsorte und veränderliche Zustandsbereiche. Kanonische Architektur- und Engineering-Verträge werden aus den verantwortlichen Knowledge- beziehungsweise Engineering-Repositories referenziert und nicht hier dupliziert.

Sicherheitsprüfung#

• Lokale .env-Dateien und Secrets dürfen nicht paketiert sein.
• Datenbankdateien dürfen nicht versioniert sein.
• Test- und Produktionsbereiche müssen getrennt bleiben.
• Ein Roundtrip muss nach sauberem Entpacken dieselbe deklarierte Struktur besitzen.

Materialisierungsprüfung#

• RESPONSIBILITY.md muss vorhanden sein.
• Inhalte unter Installations- und Reportpfaden gelten als nicht-kanonische Materialisierungen.
• Repositoryqualifizierte Referenzen in RESPONSIBILITY.md müssen auf die verantwortlichen Quellrepositorys zeigen.
• Eine materialisierte Kopie darf nicht als lokale Architektur- oder Engineering-Entscheidung behandelt werden.

Repositoryübergreifende Referenzprüfung#

Die in ◆manifest.json deklarierten crossRepositoryReferences müssen gegen die gemeinsam entpackten Repository-Roots auflösbar sein. Der ausführbare Vertrag liegt unter:

engineering-tools:40-validation/CROSS_REPOSITORY_REFERENCE_VALIDATION.md

Runtime übernimmt dabei keine semantische Ownership; es bewahrt Materialisierungs- und Evidence-Beziehungen.

SE-0026 – Links und Anker#

• Fixture: test/validations/SE-0026/link-fixture/
• Linkreport: reports/SE-0026-link-validation.json
• Validator: ◆engineering-tools:40-validation/validate-links.py

Generierte Reports sind keine kanonischen Linkquellen und werden durch den Validator getrennt gezählt beziehungsweise ausgeschlossen.

SE-0027 – Glossarverweise#

• Report: reports/SE-0027-glossary-reference-validation.json
• Validator: ◆engineering-tools:40-validation/validate-glossary-references.py
• historische Prüfquelle: SolutionArchitecture:85-knowledge/10-glossary/entries/

Die Runtime bewahrt nur den Ausführungsreport. Weder Glossarvertrag noch historische Definitionen werden in die Runtime kopiert oder dort verändert.

SE-0028 – Beziehungstypen#

• Eingabe: test/validations/SE-0028/relationships.json
• Report: reports/SE-0028-relationship-type-validation.json
• Katalog und Validator: engineering-tools:40-validation/

Runtime bewahrt nur Materialisierung und ⌘EvidenceTechnical documentation artifact.; Typkatalog und Prüflogik werden nicht dupliziert.

SE-0029 – Learning Nuggets#

• Report: reports/SE-0029-learning-nugget-validation.json
• Validator: ◆engineering-tools:40-validation/validate-learning-nuggets.py

Runtime bewahrt nur ◆EvidenceTechnical documentation artifact.; historische Nugget-Inhalte und ihr Vertrag werden nicht kopiert oder als automatisiert wahr bestätigt.

SE-0030 – deutsche Primärsprache#

• Report: reports/SE-0030-primary-language-validation.json
• Validator und Ausnahmen: engineering-tools:40-validation/

Runtime bewahrt nur den Sprachreport; unsichere Fälle bleiben Reviewfälle.

SE-0031 – Wissens-Füllstand#

• Report: reports/SE-0031-knowledge-coverage.json
• Tool: ◆engineering-tools:40-validation/measure-knowledge-coverage.py

Runtime bewahrt Mess-Evidence; manuelle Statusentscheidungen werden nicht überschrieben.

SE-0032 – semantische Duplikatkandidaten#

• Report: reports/SE-0032-duplicate-candidates.json
• Kandidatenprüfer und Konfiguration: engineering-tools:40-validation/

Runtime bewahrt nur Evidence. Kandidaten werden niemals automatisch vereinigt.

SE-0033 – Kontextwirkung#

• Eingabe: test/validations/SE-0033/context-impact-input.json
• Report: reports/SE-0033-context-impact-validation.json
• Validator und Vertrag: ◆engineering-tools:40-validation/validate-context-impact.py

und CONTEXT_IMPACT_VALIDATION.md

Die Runtime bewahrt ausschließlich die konkrete Eingabe und deren Ergebnis. not-applicable benötigt eine Begründung; fehlende Kontextwirkungs-Evidence ist ein Fehler und darf nicht als erfolgreicher Lauf materialisiert werden.

SE-0034 – frühes Semantic Quality Gate#

• Eingabe: test/validations/SE-0034/quality-gate-input.json
• Report: reports/SE-0034-semantic-quality-gate.json
• Validator: ◆engineering-tools:40-validation/validate-semantic-quality-gate.py

Die Runtime bewahrt die referenzierten Einzelreports und den zusammenfassenden Gate-Report. REVIEW_REQUIRED wird nicht versteckt, blockiert jedoch keine deterministische Phase-3-Abnahme ohne FAILED oder fehlenden Pflichtreport.

SE-0045 – Zeitkontext und Verschiebungswirkung#

• Eingabe: test/validations/SE-0045/temporal-context-input.json
• Temporal-context-Report: reports/SE-0045-temporal-context-validation.json
• Kontextwirkungsnachweis: test/validations/SE-0045/context-impact-input.json
• Kontextwirkungsreport: reports/SE-0045-context-impact-validation.json
• Validatoren und Verträge: engineering-tools:40-validation/

Die Runtime bewahrt ausschließlich die konkrete Prüfeingabe und Evidence. REVIEW_REQUIRED ist ein vollständig dokumentierter fachlich offener Fall; er wird nicht als automatische Ablösungs- oder Gültigkeitsentscheidung interpretiert.

SE-0025 – genau eine kanonische Quelle#

• Eingabemanifest: reports/SE-0025-canonical-source-input.json
• Ausführungsreport: reports/SE-0025-canonical-source-validation.json
• kanonischer Validatorvertrag: engineering-tools:40-validation/CANONICAL_SOURCE_VALIDATION.md

Die Runtime bewahrt ausschließlich den Ausführungsnachweis. Validatorregel und fachliche Quelle werden nicht dupliziert.

Artifact Manifest Validation Evidence#

test/reports/validation/artifact-manifests.json bewahrt das konkrete Ergebnis der Artifact-Manifest-Validation für RC-0002. Die Datei ist Evidence einer Ausführung und keine kanonische Definition des Manifestmodells.

SE-0056 — Phase-5-Validierung#

• Traceability-Nachweis: reports/SE-0056-traceability-validation.json
• Phase-5-Bericht: reports/SE-0056-phase-5-validation.json
• Landschaftsvalidator: ◆engineering-tools:40-validation/validate-repository-landscape.py

Die Runtime bewahrt die erzeugten Nachweise. Die kanonischen Modelle und Validatoren verbleiben in ihren verantwortlichen Repositories.

SE-0057 — Semantischer Publisher#

• Eingabemodell: reports/SE-0057-semantic-publisher-input.json
• HTML-Landing-Page: reports/SE-0057-semantic-landing.html
• Rendering-Report: reports/SE-0057-semantic-publisher-validation.json
• Publisher: ◆engineering-tools:97-documentation/publish-semantic-landing.py

Die Landing-Page ist eine nicht-kanonische Veröffentlichung. Sie zeigt den Elevator Pitch vor der Navigation und bewahrt Links auf technische Nachweise.

SE-0065A — Veröffentlichter /reports/-Einstieg#

• Materialisierer: ◆bin/publish-reports-entrypoint.py
• ⌘RendererEin Renderer erzeugt eine konkrete technische Ausgabeform aus einer vorbereiteten Dokumentationsprojektion. Beispiele sind HTML, PDF, Markdown, JSON oder ein Suchindex.: ◆engineering-tools:97-documentation/publish-semantic-landing.py
• Ziel: <Runtime>/web/reports/index.html und damit /reports/
• Evidenz: reports/SE-0065-reports-entrypoint-*.json

Workspace ruft den Materialisierer nach seiner Dokumentationsrekonstruktion nur noch als Auslieferungsadapter auf. Er enthält keine Landing- oder Publisherlogik.

SE-0058 — Navigation und Einstiegspunkte#

• Menschlicher Solution-Einstieg: solution-architecture:00-overview/SEMANTIC_NAVIGATION.md
• Runtime-Einstieg: README.md
• Linkreport: reports/SE-0058-navigation-link-report.json

Die Navigation trennt Erklärung und direkte technische Arbeit, ohne eine zweite fachliche Quelle oder neue Inhaltskopien zu erzeugen.

SE-0059 — Repositoryübergreifende Landschaft#

• Landscape-Report: reports/SE-0059-landscape-validation.json
• Quality-Gate-Ausführung: reports/SE-0059-semantic-quality-gate.json

Die technische Landschaft ist vollständig geprüft. Offene fachliche Reviewfälle bleiben als Abschlussblocker sichtbar und werden nicht durch die Runtime entschieden.

SE-0059E — Link-Checker und Korrekturreport#

• Batch-Report: reports/SE-0059E-link-correction-report.json und .md
• Exemplarischer HTTP-404-Nachweis:

reports/SE-0059E-example-404-link-report.json und .md

• HTML-Testeingabe:

test/validations/SE-0059E/published-http-404.html

• Checker: ◆engineering-tools:40-validation/validate-links.py

Die Reports enthalten Quelle, Ziel, Fehlerklasse, Status und einen Korrekturhinweis. Sie lösen keine automatische Änderung eines Links aus.

SE-0059F — auswählbare Code-Referenzen#

• Eingabemodell: test/validations/SE-0059F/code-reference-publisher-input.json
• Landing-Page: reports/SE-0059F-code-reference-landing.html
• Codeansicht: reports/[[EA-GLOSS-CODE-001|code]]/validate-primary-language.html
• Publisher- und Linknachweis: reports/SE-0059F-code-reference-publisher-report.json

Die veröffentlichte Python-Ansicht enthält Artefaktpfad, Sprache, ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung., auswählbaren Inhalt und Rückverweis. Sie ist eine freigegebene Materialisierung, nicht die kanonische Quellinstanz.

SE-0069 — Linkbefunde als Check-Evidenz#

• Maschinenlesbarer Befund: reports/SE-0069-link-validation-report.json
• Menschenlesbarer Befundbericht: reports/SE-0069-link-validation-report.md
• Veröffentlichung: web/reports/technical-reports/
• Validator: ◆engineering-tools:40-validation/validate-links.py

Der Befund führt Quelle und Stelle, erwartetes Ziel, Linktyp, Schwere, Vorschau, ⌘BeziehungEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. und technischen Bezug. Die Report-Verweise bewahren den repositoryqualifizierten Rückweg; sie ändern keine Quelle automatisch.

SE-0070 — veröffentlichte Kontextwirkung#

• Strukturierte Eingabe: test/validations/SE-0070/context-impact-input.json
• Nachweis: reports/SE-0070-context-impact-validation.json
• Veröffentlichung: /reports/ → Kontext und PDCA

Die Ansicht verknüpft Plan, Do, Check und Act mit ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung., Kontextvertrag, Linkbericht, Validator und Regressionstest. Sie materialisiert keine neue fachliche Quelle.

SE-0071 — aktuelle Regressionsevidenz#

• Evidence: reports/SE-0071-regression-evidence.json
• Veröffentlichung: /reports/ → Aktuelle Regressionsevidenz

Die Ansicht verbindet Test, Ergebnis, geprüften Bezug, Publisher-Code, Kontextwirkung und Linkbericht. Fehlende Evidence bleibt sichtbar; sie wird nicht als fachliche ⌘FreigabeEin Release ist ein bewusst freigegebener und nachvollziehbarer Stand von Artefakten und ihrer Realisierung. interpretiert.

Automatisch erzeugte Evidence#

Evidence unter test/reports wird durch den jeweiligen Engineering-Erzeuger atomisch geschrieben und im selben Lauf mit ⌘ProvenienzTechnical documentation artifact. versiegelt. Manuelle Nachpflege von Hashes ist nicht zulässig. Vor Wiederverwendung oder ⌘PromotionTechnical documentation artifact. muss die Freshness-Prüfung erfolgreich sein.

Evidence Promotion und ⌘RetentionTechnical documentation artifact.#

test/reports/evidence-retention-index.json darf pro Evidence-Identität höchstens einen Eintrag active enthalten. superseded und failed bleiben nachvollziehbar und werden nicht stillschweigend gelöscht. Nur automatisch versiegelte und aktuell fresh validierte Evidence darf über ◆engineering-tools:40-validation/promote-evidence.py aktiv werden.

Failure- und Rollback-Evidence#

Fehlgeschlagene Ausführungen werden automatisch versiegelt und unter test/reports/retained/<evidence-id>/failed/ bewahrt. Der Retention-Index enthält Fehlerphase und Rollback-Ergebnis. Solche Evidence bleibt unabhängig vom Rollback-Ausgang nicht promotierbar.

Execution lifecycle end-to-end evidence#

test/reports/validation/execution-lifecycle-end-to-end.json records the validated success, controlled failure/rollback and ◆retentionTechnical documentation artifact. transition for KT-0012.

Build Contract Evidence#

test/builds/engineering-platform/build-manifest.json und das zugehörige Binary materialisieren einen konkreten erfolgreichen Build für RC-0003. test/reports/validation/build-contract.json bewahrt die im selben Lauf versiegelte Evidence. Runtime besitzt weder den kanonischen Build-Vertrag noch die ausführbare Validierungslogik.

RC-0004 Deployment Contract#

test/reports/validation/deployment-contract.json ist der versiegelte Nachweis der aktuell geprüften Testinstallation. Die Datei definiert keine Architektur und dokumentiert ausdrücklich keine Production-Promotion.

RC-0005 Workspace Contract#

• Workspace-Materialisierung: test/workspaces/KT-0015/workspace-manifest.json
• versiegelte Evidence: test/reports/validation/workspace-contract.json

Diese Dateien dokumentieren einen konkreten Validierungslauf. Sie sind keine kanonische Workspace-Architektur und führen keine ◆PromotionTechnical documentation artifact. aus.

RC-0006 Validation Contract#

• Materialisierung: test/validations/KT-0016/validation-manifest.json
• versiegelte Evidence: test/reports/validation/validation-contract.json

Die Dateien dokumentieren ausschließlich einen konkreten Validierungslauf. Sie definieren keine kanonischen Regeln und führen weder Deployment noch Promotion aus.

KT-0017 Contract Coverage Gap Review#

• Materialisierung: test/validations/KT-0017/contract-coverage-review-manifest.json
• Evidence: test/reports/validation/contract-coverage-gap-review.json
• Pflichtumfang: RC-0003 bis RC-0006
• Ergebnisziel: keine ⌘Completion BlockerTechnical documentation artifact.; optionale Findings getrennt

KT-0018 Automated Roadmap Progress Validation#

• Materialisierung: test/validations/KT-0018/roadmap-progress-manifest.json
• versiegelte Evidence: test/reports/validation/roadmap-progress.json

Der Nachweis dokumentiert die automatisch abgeleiteten Pflichtzahlen, den Phasenstatus und den nächsten freigegebenen Work Item des GAP-Baseline MVP-001. Runtime besitzt weder die Roadmap noch deren Governance und führt keine Aufnahme neuer Pflichtarbeit aus.

KT-0019 Work Item Admission and Change Control#

• Materialisierung: test/validations/KT-0019/admission-control-manifest.json
• Evidence: test/reports/validation/work-item-admission-change-control.json
• Ergebnis: Der MVP-001-Baseline blieb unverändert; keine Pflichtarbeit wurde aufgenommen.

KT-0020 Repeatable Bundle ⌘IntakeTechnical documentation artifact.#

• Materialisierung: test/validations/KT-0020/bundle-intake-manifest.json
• Evidence: test/reports/validation/bundle-intake.json

KT-0021 Operational Runbook and Recovery#

• Recovery-Checkpoint: test/validations/KT-0021/recovery-checkpoint.json
• Materialisierung: test/validations/KT-0021/operational-recovery-manifest.json
• Evidence: test/reports/validation/operational-runbook-recovery.json

Der Nachweis dokumentiert Wiederanlauf aus verifizierten Eingaben ohne Chat-Vorwissen. Er führt weder Deployment noch Promotion aus.

KT-0022 Mandatory ⌘DiscoveryTechnical documentation artifact. Closure Review#

• Materialisierung: test/validations/KT-0022/mandatory-discovery-closure-manifest.json
• Evidence: test/reports/validation/mandatory-discovery-closure.json
• Ergebnisziel: keine offene verpflichtende oder completion-blocking ◆DiscoveryTechnical documentation artifact..

Optionale und deferred Findings bleiben außerhalb des verpflichtenden MVP-Baseline.

KT-0023 Full Repository Landscape Validation#

• ⌘MaterializationEine Materialisierung ist die technisch erzeugte und persistierte Darstellung einer Projektion.: test/validations/KT-0023/repository-landscape-validation-manifest.json
• Evidence: test/reports/validation/full-repository-landscape.json
• Validator: ◆engineering-tools:40-validation/validate-repository-landscape.py

KT-0024 GAP MVP Completion and Maintenance Handover#

• Materialisierung: test/validations/KT-0024/gap-mvp-completion-manifest.json
• Evidence: test/reports/validation/gap-mvp-completion-maintenance-handover.json
• Zielzustand: MVP-001 v1.0, 24 / 24, fünf abgeschlossene Phasen, keine ◆Completion BlockerTechnical documentation artifact. und GAP-Zustand MAINTENANCE_READY.

Die Evidence ist ein konkreter Abschlussnachweis. Sie nimmt keine optionale Arbeit auf und führt weder Deployment noch Promotion aus.

ZIP-Erzeugung#

• ◆config/repository-zip.example.json muss ohne umgebungsspezifische Secrets parsebar sein.
• ◆bin/create-repository-zip.py darf die Implementierung nicht duplizieren, sondern muss ◆engineering-tools:60-packaging/deterministic_zip.py aufrufen.
• Der Roundtrip wird mit sauberem Entpacken, Root-Prüfung und byteidentischer Wiederholung validiert.
• ◆bin/create-repository-set.py validiert alle Namen, Quellen und das neue

Ausgabeziel vor dem Schreiben, erzeugt jedes ZIP ueber engineering-tools und veroeffentlicht die vollstaendige Menge atomisch.

• python3 -m unittest tests/test_create_repository_set_adapter.py prueft

vollstaendige Erzeugung und Schutz eines bestehenden Ausgabeziels.

GAP-Aktivierung#

• ◆bin/activate-gap.py validiert ZIP-Struktur und genau ein GAP-Manifest vor der Aktivierung.
• Vorgängerversionen werden mit erkannter Version und UTC-Zeitstempel unter current-gap/old/ archiviert.
• Ein ungültiger Kandidat darf den aktiven Vorgänger weder verschieben noch verändern.
• Automatisierte Tests liegen unter ◆tests/test_activate_gap.py.
• SE-0039A prüft zusätzlich direkten Pfad, eindeutige timestamp-präfixierte

Auflösung, fehlenden und mehrdeutigen Kandidaten. Die Auflösung wählt nie automatisch den neuesten Kandidaten.

SE-0005#

• python3 -m unittest tests/test_import_roundtrip_adapter.py prüft die Delegation an die kanonische Engineering-Tools-Implementierung.
• Die fachliche Importvalidierung liegt in engineering-tools/98-tests/test_changed_only_import.py.

SE-0006#

• ◆config/work-package.example.json muss ohne umgebungsspezifische Secrets parsebar sein.
• ◆bin/create-work-package.py darf die Paketlogik nicht duplizieren, sondern muss ◆engineering-tools:60-packaging/gap_work_package.py aufrufen.
• python3 -m unittest tests/test_create_work_package_adapter.py prüft Delegation, Pfadauflösung und vollständige Argumentweitergabe.
• Die fachliche Format-, Scope-, Determinismus- und Sicherheitsvalidierung liegt in engineering-tools/98-tests/test_gap_work_package.py.

SE-0007#

• ◆config/work-package.example.json verweist mit filterConfig auf die versionierte Engineering-Tools-Konfiguration.
• ◆bin/create-work-package.py löst den Pfad auf und übergibt ihn mit --filter-config an die kanonische Implementierung.
• Die fachlichen Positiv- und Negativtests weisen umschließende und flache Runtime-Roots, unveränderte Originalarchive, ein unverändertes Runtime-Target sowie die Manifest-Evidence nach.

SE-0008#

• Das Arbeitspaket enthält exakt package-manifest.json, SHA256SUMS.txt, sources.zip und targets.zip.
• Der kanonische Validator prüft Repositoryrollen und -identitäten, GAP-Identität, Allowed Target Scope, alle deklarierten SHA-256-Prüfsummen sowie sichere und unbeschädigte ZIP-Strukturen.
• Die Veröffentlichung erfolgt ausschließlich aus einem vollständig validierten Staging-Verzeichnis auf ein zuvor nicht vorhandenes outputDirectory.
• Manipulierte Prüfsummen, doppelte Einträge, ZIP-Slip, unerwartete Roots, beschädigte Archive und vorhandene Ausgabeziele müssen ohne teilweise veröffentlichte Ausgabe scheitern.

SE-0013A — Bedienkorrektur#

• ◆bin/prepare-work-package.py liest Work Item, Sources und Targets

ausschließlich aus dem aktiven, pfadsicher validierten Semantic GAP.

• requiredSourceRepositories und allowedTargetRepositories müssen

nichtleer, duplikatfrei und über ◆config/repository-map.json lokal auflösbar sein. Manifest und Work Item werden als Mengen verglichen; abweichende Deklarationsreihenfolge ist zulässig, echte fehlende oder zusätzliche Repository-Identitäten werden mit der symmetrischen Differenz gemeldet.

• Repository-ZIPs werden nicht dauerhaft materialisiert und ausschließlich

über ◆bin/create-repository-set.py erzeugt.

• Jeder Lauf erhält ein neues Ziel unter out/chatgpt-upload; ein vorhandener

Lauf wird nicht überschrieben.

• Veröffentlicht werden ausschließlich die vier validierten Paketartefakte.
• python3 -m unittest tests/test_prepare_work_package.py prüft automatische

Auswahl, vollständige Ausgabe, fehlenden Source-Vertrag und Kollisionsschutz.

SE-0009#

• Alte und neue Paketbildung müssen auf identischen Repositoryständen ausgeführt werden.
• Gemeinsame Repositorypfade müssen byteidentische Inhalte besitzen.
• Legacy-only-Pfade müssen exakt durch die Filter-Evidence des neuen Paketmanifests erklärt sein.
• Die vollständigen Target- und GAP-Archive müssen gegenüber den ursprünglichen Eingaben byteidentisch bleiben.
• test/reports/validation/package-equivalence-se-0009.json muss PASSED und eine leere Liste ungeklärter Differenzen enthalten.

SE-0019 – Runtime-Textbaseline#

• unveränderte Source-Population: 32 Markdown-Dateien;
• Wortmenge: 4.389;
• Zeichenmenge: 44.003;
• Abgrenzung von semantischer Abdeckung dokumentiert unter reports/SE-0019-runtime-textbaseline.md;
• Manifest und Changed-Files-Inventar konsistent: PASSED.

SE-0021 – Knowledge Dashboard#

• Runtime-Snapshot verweist auf die kanonische Solution-Datenquelle: PASSED;
• quantitative Summen 59 + 66 + 62 = 187: PASSED;
• qualitative Summen 46 + 0 + 59 + 0 + 82 = 187: PASSED;
• Review und Freigabe bleiben bei fehlender Evidence not_assessed: PASSED;
• Abweichungscodes und drei Zielerweiterungen separat ausgewiesen: PASSED.

SE-0022 – Phase-2-Baseline#

• 307/307 Quellenkartenpfade und IDs eindeutig und auflösbar: PASSED;
• Coverage- und Reifegradsummen konsistent: PASSED;
• unzugeordnete Legacy-Einheiten als Befund ausgewiesen: PASSED;
• Evidence: reports/SE-0022-knowledge-baseline-validation.json.

SE-0024 – Semantic IDs#

• zwei Semantic-Manifeste repositoryübergreifend geprüft: PASSED;
• zwei eindeutige kanonische IDs und ein Legacy-Alias: PASSED;
• Kollisionen: 0;
• Evidence: reports/SE-0024-semantic-id-validation.json.