Manage a chosen set of modules as one thing while seeing the structure across and inside them
State: open/proposed
Statement
Section titled “Statement”A maintainer — or an agent acting for one — decides where the boundary of control goes. The structural graph of packages, crates, apps, and the systems they touch is derived and always visible. The control boundary is chosen: a control unit has one planning directory and one outside view. A unit may be smaller than the structure suggests (a package with several internal code modules is one unit, planned once, with the relationships still visible) or larger (a suite such as the markdown ecosystem — several packages and apps — is one unit with one planning directory).
Who/what it affects
Section titled “Who/what it affects”The maintainer, or an agent acting for one, who sets and moves control boundaries; and everyone who then plans, reports, or hands off work at the unit they chose.
Evidence
Section titled “Evidence”- N-41AZ-vision, “Structure and control are two dimensions”: structure and control are declared as two separate layers, and a control unit can be smaller or larger than the structure it wraps.
- N-41AZ-vision, “The module graph”: every module has its own internal model and is one node from outside, with rollups deriving from members.
Toward resolution
Section titled “Toward resolution”Served by the module graph section of N-41AZ-vision. Rules follow from the use-case directly: every code module belongs to exactly one control unit; structural edges may cross control boundaries; rollups follow control units; moving a boundary is a declaration change, not a code move. The capability area is the module graph (D-XCXA / M-D2I1).