Requires Review Process

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/

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

Compendium: §1 CI Architecture · §2 Quality Dashboard · §3 Mapping Workbench · §4 Package Readiness · §5 Release-Model Conformance · §6 Dual Release Contracts · §7 Relation Checks · §8 Atomic Review · §9 Requires Review · §10 Human Review Gates · §11 MEM SPARQL Audit · §12 MEM SPARQL Runbook · §13 Source Rationales Runbook · §14 Abi 2026 DeepLink QA

9. Requires Review Process

This chapter documents the repeatable manual authoring and QA workflow for reviewing prerequisite quality on atomic learning goals (contains: []): verifying that the didactic jump from prerequisites to target is teachably small and replacing coarse or misleading edges with clean atomic routes.

9.1. Transition Semantics vs. Canonical Target State

app/scripts/generateRequiresReport.ts (npm run report:requires) exposes both layers of the current compatibility model together with their origin:

direct requires: Prerequisites authored directly on the atomic goal itself.
effective requires: Direct prerequisites plus prerequisites inherited from ancestor clusters via contains.

While inspecting inherited origins is essential during migration, the binding target state remains a purely atomic prerequisite relation \(R \subseteq A \times A\) (Graph Definition).

9.2. Six-Step Review and Repair Workflow

cd app
npm run report:requires -- \
  --input ../curricula/<...>/json/<file>.json \
  --decisions ../tmp/requires_decisions_<name>.json \
  --init-decisions

Initialize or update the decisions scaffold (default output: ../tmp/requires_findings_<curriculum>.md containing summary counts, not_ok findings, and a full appendix listing direct requires, effective requires, and source clusters/goals).
Inspect direct and effective prerequisites plus inheritance origins for each atomic goal.
Formulate the didactic delta: what can the learner already do after the prerequisites, what is genuinely new in the target goal, and is that delta a single teachable step?
Record ok, not_ok, or pending in the JSON decisions file (mark not_ok only for real didactic defects — oversized jump, unrelated blocking prerequisites, or cluster edges hiding atomic dependencies — rather than graph neatness alone):

{
  "goals": {
    "<goalId-a>": { "status": "ok" },
    "<goalId-b>": {
      "status": "not_ok",
      "problem": "what is didactically wrong",
      "proposal": "how to repair the requires structure"
    },
    "<goalId-c>": { "status": "pending" }
  }
}

For not_ok goals, apply one of four standard repairs: (a) add a bridge goal, (b) split the target goal (8), (c) replace cluster-level requires with specific atomic prerequisites, or (d) remove redundant or over-blocking edges.
Re-run cd app && npm run validate:graph after accepted edits.