Requires Relation Checks
This document lists the checks we can run around requires and effective requires.
Goal: keep prerequisites minimal, correct, and inherited via contains.
Scope
A subset of these checks is implemented in app/scripts/validateGraph.ts and run in CI via npm run validate:graph.
Minimality checks are recommended but not enforced in CI at the moment.
Definitions
- Direct requires: the
requiresarray on a goal. - Effective requires: direct requires of the goal + direct requires of all
containsancestors.
Hard checks (CI errors)
- Reference integrity: every
requires/containsid resolves (local IDs, or cross-landscape refs viaLANDSCAPE:ID). - No self-requires / self-contains: a goal must not require or contain itself.
- Acyclic direct requires: no cycles in the direct
requiresgraph. - Acyclic effective requires: no cycles after inheritance.
- Acyclic contains: no cycles in the
containshierarchy.
Minimality checks (recommended)
- Inherited redundancy: if a direct
requiresis already inherited from an ancestor, remove it. - Transitive redundancy: if a
requiresedge is implied by another path in the effective-requires graph, remove it. - Shared requires lifting: if all children of a cluster share the same direct
requires, move those to the cluster and remove from children.
Heuristic checks (not automated)
- Forward-phase edges: flag
requiresthat point to a later phase (order: E < Q1 < Q2 < Q3 < Q4; ignore GLOBAL). - Subtree requires: flag
requiresthat point into a goal's owncontainssubtree (often indicates inverted modeling). - Sparse later-phase requires: if a later-phase goal has empty effective requires while siblings are constrained, review for missing prerequisites.
Output format
- CI output lists violations with landscape id and goal id (errors only for now).
Rule of thumb
Prefer effective requires (inheritance via contains) over direct requires.
Never add a direct requires if it is already implied transitively.