feat: OKF-Schema-Vertrag schema/wiki-compiler.md autorisieren (Story 1.3)

_bmad-output/implementation-artifacts/deferred-work.md

@@ -17,3 +17,47 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
   summary: Asset-Zuordnung (roh-`assets/` vs. `<quelle>/assets/`) in der Konvention festlegen.
   evidence: Blind-Hunter-Review (Finding 14): README nennt „einer Quelle zugeordnet oder global"; die aktuellen Sources nutzen nur global `raw/assets/`.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Existenzprüfung eines `sources`-`resource`-Pfads (für Validity-Zwecke MUSS die `raw/`-Datei am Validierungszeitpunkt materialisiert vorliegen).
+  evidence: Edge-Case-Review (EC-1): ein `resource` unter `raw/`, das nicht existiert, würde als Provenienz akzeptiert; der Compiler konsumiert fehlende Evidenz. Validator-Verhalten (Story 1.4), nicht Schema-Text.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Kalender-Validität der Datumsfelder (`last_modified`, `stale_after`, `generated.at`/`verified.at`) — Phantom-Daten wie `2025-02-30` müssen abgelehnt werden.
+  evidence: Edge-Case-Review (EC-3): reines Regex-Matching (`YYYY-MM-DD`) akzeptiert nicht existierende Kalenderdaten. Validator-Detail (Story 1.4).
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Operative Konsequenz von `stale_after` festlegen (Lifecycle-Übergang, Nutzungssperre als `sources`-Ziel o. ä.).
+  evidence: Blind-Hunter (BH-8): §3.7 definiert nur die Veraltungsschwelle, nicht was ein veraltetes Concept bedeutet; die Folgeentscheidung gehört in Story 1.4/Lifecycle (Epic 3).
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: `sources`-`id`-Eindeutigkeit (je `resource` bzw. je Concept) für zuverlässige per-Claim-Zitat-Attribution festlegen.
+  evidence: Blind-Hunter (BH-13): §3.3 motiviert `id` für Attribution, ohne Eindeutigkeit/Scoping zu fordern; Claim-granulare Provenienz (A0-3) wird in Epic 2 konkretisiert.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Verhalten nicht-Markdown-Dateien im Bundle (z. B. Bilder/Assets unter `wiki/`) definieren — Ablehnung oder Konvention.
+  evidence: Edge-Case-Review (EC-11): der Vertrag regelt nur `.md`-Dateien; ein `wiki/<area>/logo.png` hat keinen definierten Status. Structural-Seed-/Validator-Frage (Story 1.4).
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Exakte ISO-8601-Form für `generated.at`/`verified.at` festlegen (z. B. `YYYY-MM-DDTHH:MM:SS(Z|±HH:MM)?`, reine Datumsangaben zulässig?).
+  evidence: Blind-Hunter (BH-14)/Edge-Case-Review (EC-7): „ISO-8601-Datetime" lässt den Validator-Spielraum; Story 1.4 muss eine Normalform bestimmen, um Run-Determinismus zu sichern.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Normalisierung von `sources: []`/`verified: []` vs. Absenz für deterministische Ausgabe-/Diff-Baselines klären.
+  evidence: Edge-Case-Review (F2, Loop 2): beide Formen sind laut Vertrag gültig und semantisch gleichwertig; NFR-4 („sinnvolle Diffs") bleibt unterdeterminiert. Normierungsentscheidung des Compilers/Validators — Story 1.4.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Trust-Semantik von `generated.by` mit `human:`-Präfix festlegen (Person als Generator vs. „human-reviewed"-Klassifikation).
+  evidence: Edge-Case-Review (F15, Loop 2): `generated.by: human:michael` ohne `verified` ist formzulässig, aber die Trust-Klassifikation (nicht-human-reviewed trotz `human:` in `generated.by`) ist für Leser missverständlich. Für Story 1.4/Epic 4 (Trust-Metadaten) klären.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Reihenfolge/atomare Kopplung von `log.md`-Eintrag (AD-16b) und `status`-Mutation (Deprecation) in denselben Compilation Run festlegen.
+  evidence: Edge-Case-Review (F5, Loop 2): `status: deprecated` erfordert einen `log.md`-Disagreement-Eintrag; der Vertrag regelt nicht die atomare Kopplung dieser zwei Bundle-Mutationen. AD-16/Story 4.2/Compiler-Verhalten.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Feingranularität von `log.md` festlegen (leeres Log zulässig? Pflicht der AD-16-Konfliktklassifikation je Eintrag?).
+  evidence: Edge-Case-Review (F17, Loop 2): §5 definiert Format (Datum + Eintragsliste), aber nicht, ob ein leeres `log.md` gültig ist bzw. ob die Konfliktklassifikation Pflicht-Inhalt je Eintrag ist. OKF §9-Feinheiten für Story 1.4.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
+  summary: Semantische Konsequenz von `stale_after` im Verhältnis zur Validität klären („veraltet" ist kein struktureller Validierungsfehler).
+  evidence: Edge-Case-Review (F18, Loop 2): §7 zählt die Konsequenz nicht auf; ein vergangenes `stale_after` ist gültiges YAML, aber „veraltet". Lifecycle-Semantik — Story 1.4/Epic 3.