T-N3RW-derive-the-structural-module-graph-from-existing-manifests
State: planning/proposed · Impact: high · Complexity: large
The module graph has two dimensions. Structure is the first: every code module and how it relates to the others and to outside systems. It is derived and never declared by hand. The facts already live in manifests, so this task reads them rather than adding a new one.
Proposed
Section titled “Proposed”A library function builds the structural layer for a project root. Nodes are code modules: packages,
crates, apps, and skill packs, each with an id, kind, directory, ecosystem, and the surfaces it
publishes. Edges are directory containment, declared dependencies, and dependencies on external
systems. It reuses @sksizer/manifest-graph for package.json and Cargo.toml,
moon query projects for layer and stack, and .claude-plugin/plugin.json for skill packs. It
lives in a lib service, not under an entity package, because a module is not an entity kind.
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: Run against this repo, the layer lists every package, crate, app, and skill pack the manifest walk and the plugin manifests find, with containment and dependency edges.
- AC-2: External dependencies appear as external nodes, held outside the containment tree.
- AC-3: Each node’s kind and surfaces cite the manifest field they came from.
- AC-4: A repo without moon still resolves; layer and stack are absent, not an error.
- AC-5: A fixture tree pins the output, including a malformed manifest that degrades to an error-carrying node instead of aborting.
Out of scope
Section titled “Out of scope”- Control units and membership (T-CY6T-control-units-a-planning-root-is-the-boundary-and-every).
- Code modules below the manifest grain, such as directories inside one package. The decision leaves that rule open.
- The CLI verb and its wire shape (T-JJHY-sdlc-module-graph-emits-structure-and-control-units-as-json).
Dependencies
Section titled “Dependencies”- None.