Skip to content

Voraussetzungs-Reviewprozess (Requires)

Generated artifact. Do not edit manually.

Generated by: scripts/build_compendia.py Regenerate with: python3 scripts/build_compendia.py --compendium qa-ci-lanes --web-and-tex Source of truth: docs/qa-ci/lanes-source/

Sprache / Language: Deutsch (DE) · English (EN) | PDF: Deutsches PDF · English PDF

Kompendium: §1 CI-Architektur · §2 Qualitätsdashboard · §3 Mapping-Workbench · §4 Paketbereitschaft · §5 Release-Modell-Konformität · §6 Duale Release-Verträge · §7 Relationsprüfungen · §8 Atomizitäts-Review · §9 Voraussetzungs-Review · §10 Menschliche Review-Gates · §11 MEM-SPARQL-Audit · §12 MEM-SPARQL-Runbook · §13 Quellenbegründungen-Runbook · §14 Abi-2026-DeepLink-QA

9. Voraussetzungs-Reviewprozess (requires)

Dieses Kapitel dokumentiert den wiederholbaren manuellen Autoren- und QA-Workflow zur Prüfung der Voraussetzungsqualität auf atomaren Lernzielen (contains: []): Ist der didaktische Lernsprung von den Voraussetzungen zum Ziel klein genug, und werden grobe oder irreführende Kanten durch präzise atomare Routen ersetzt?

9.1. Übergangssemantik vs. kanonischer Zielzustand

Das Report-Werkzeug app/scripts/generateRequiresReport.ts (npm run report:requires) macht beide Schichten des aktuellen Kompatibilitätsmodells mitsamt Herkunft sichtbar:

  • direct requires: Unmittelbar am Atomziel selbst hinterlegte Voraussetzungen.
  • effective requires: Direkte Voraussetzungen zuzüglich aller von Vorgänger-Clustern über contains geerbten Voraussetzungen.

Während diese Sicht für die Bestandsmigration unverzichtbar ist, bleibt der verbindliche Zielzustand eine rein atomare Voraussetzungsschicht \(R \subseteq A \times A\) (Graph-Definition).

9.2. Sechsstufiger Prüf- und Reparaturablauf

cd app
npm run report:requires -- \
  --input ../curricula/<...>/json/<file>.json \
  --decisions ../tmp/requires_decisions_<name>.json \
  --init-decisions
  1. Entscheidungsgerüst erzeugen oder aktualisieren (Standardbericht: ../tmp/requires_findings_<curriculum>.md mit Zusammenfassung, not_ok-Liste und Komplettanhang für direct requires, effective requires und Ursprungscluster/-ziele).
  2. Für jedes Atomziel direkte und effektive Voraussetzungen samt Vererbungsursprung sichten.
  3. Das didaktische Delta formulieren: Was kann die lernende Person nach den Voraussetzungen bereits, was kommt im Ziel neu hinzu, und ist dieser Zuwachs genau ein lehrbarer Schritt?
  4. Entscheidung (ok, not_ok, pending) in der JSON-Datei erfassen (not_ok nur bei echtem didaktischem Problem wie zu großem Lernsprung, fachfremder Blockade oder verdeckter Cluster-Abhängigkeit — nicht für bloße Graph-Kosmetik):
{
  "goals": {
    "<goalId-a>": { "status": "ok" },
    "<goalId-b>": {
      "status": "not_ok",
      "problem": "was didaktisch nicht traegt",
      "proposal": "wie die requires-Struktur repariert wird"
    },
    "<goalId-c>": { "status": "pending" }
  }
}
  1. Bei not_ok eine der vier Standardreparaturen anwenden: (a) Brückenziel ergänzen, (b) Zielknoten aufteilen (8), (c) Cluster-requires durch konkrete atomare Voraussetzungen ersetzen, oder (d) redundante bzw. überblockierende Kanten entfernen.
  2. Nach den Änderungen cd app && npm run validate:graph ausführen.