Skip to content

T-CY6T-control-units-a-planning-root-is-the-boundary-and-every

State: planning/proposed · Impact: high · Complexity: medium

Control is the second dimension. A control unit is the set of modules managed as one thing, with one planning directory and one outside view. A unit can be one package that holds several internal code modules, or a suite of several packages and apps. The boundary is a declaration, so moving it changes config, not code.

A planning root declared under planning_roots: (D-SK9G-cross-project-addressing) is a control boundary, and the project root is the default unit. Membership is derived: a code module belongs to the deepest unit whose directory contains it, unless another unit claims it by name under members:, as agent-pants claims modules out of solutions/determined. A validation checks that every code module belongs to exactly one unit. Structural edges may cross unit boundaries.

  • AC-1: With no planning roots declared, every code module belongs to the root unit.
  • AC-2: Declaring a planning root moves the modules under it into the new unit with no file moved.
  • AC-3: A unit that names members outside its own directory takes them, and a fixture pins this for a unit that claims a module out of another unit’s folder.
  • AC-4: A module claimed by two units fails sdlc entities audit with an error naming both units.
  • AC-5: A dependency edge between modules in different units is kept, not rejected.
  • AC-6: members: is for cross-tree exceptions only: a module a unit claims from outside its own folder, such as agent-pants claiming exp-agent-pants and product-agent-pants out of solutions/determined. An explicit claim beats containment. Every other module joins its unit by containment.

T-N3RW-derive-the-structural-module-graph-from-existing-manifests, T-K9AI-slug-projects-and-planning-roots-keys-in-sdlc-yaml-with


← Back to Tasks