Module breakdown: control units for this repo

State: open/active · Genre: analysis

Reviewed and approved as the first declaration; the planning-roots task T-EIZX applies it.

Survey of sksizer/vision-and-plan (worktree), 2026-09-23. Read-only. Sources: moon project-graph --json (188 projects), a manifest walk, sdlc capability coverage --output json (274 manifest units, 60 capabilities), the planning corpora on disk, and the draft D-XCXA.

1. Summary

12 control units. 1 repo root, 4 solutions, 1 app, 1 nested unit inside Ontological, and 5 suites. Every unit is a folder; four suites move out of packages/{rust,ts}/ into their own (section 3).
Grain: one unit per thing with its own roadmap. Most units are a solution, an adopted app, or a suite of 5–20 packages. None is a single library.
The rule used to draw every boundary: A unit is a set of modules whose work is planned together: a solution, an adopted app, or a suite whose milestones change several modules at once. A module joins the unit whose milestones change it. Twin ports (Rust + TS peers held by one fixture) never split. A module that no roadmap owns stays in the repo root unit.
All 188 moon projects land in exactly one unit (tally in section 2). Non-moon manifests follow their containing module.
Summary rule: a unit’s outside-view summary is derived from its corpus root (a summary block at the planning root), never hand-set per unit. Product entities inside the unit are unaffected.

2. Proposed control units

Planning root paths marked new do not exist. Entity counts are files on disk. A suite’s planning root exists once its code moves into its folder (section 3). members: lists only cross-tree claims (section 5).

Unit	Kind	Planning root	Member modules (moon ids)	#	Why one thing	Corpus today	Open question
`dev`	repo	`docs/planning` (existing)	`root`, `df-docs`, `eslint-config`, `prettier-config`, `tsconfig-preset`, `atomic-write`, `slug`, `dir-aspect`, `prettier-fmt`, legacy apps `ontological-legacy`, `polish` (apps/legacy-polish), `agentpants`; skill packs `published/.../packs/{dev-agent,pr-tools}`	12	Repo tooling, CI, config presets, the definition corpus, and primitives no roadmap owns	yes: 800 T, 153 B, 52 M, ~52 D, 60 C, 16 P, 16 S, 26 term, 10 ref, 19 DR, 5 PR	Today most of its work is Ontological’s; rollups look wrong until triage
`ontological`	solution	`solutions/ontological/docs/planning` new	`sdlc`, `manifest-graph` (crate), `manifest-graph-ts`, `agent-plugin`, `agent-dev`, `agent-call`, `dashboard-client`; skill pack `solutions/ontological/.claude-plugin`; `site-template`	7	The product: CLI, plugin, substrate, harness model. D-0001 end state gives it its own planning unit	no	Does `agent-call` (tier 2, general) belong here or in `dev`?
`sdf`	app (nested)	`solutions/ontological/desktop/docs/planning` new	`sdf` (+src-nuxt, src-tauri), `product-system-graph`, exp `system-graph` (no moon id), `system-model`	3	SDF and the system-graph view it hosts; M-D2I1 changes all of them	partial: 9 `SG-NN` backlog files in `experiences/system-graph/docs/backlog`	`SG-NN` ids are not sdlc-shaped; mint or drop
`engine`	suite	`packages/engine/docs/planning` new	`foreman`, `graph-scheduler`, `intersect`, `intersect-ts`, `intersect-docs`, `flowline`, `flowline-docs`	7	One ledger (`d-vsli-implementation-plan.md`), one decision (D-VSLI), M-E1YP	no (PR-FRMN, PR-DZTZ, PR-0002, PR-FLWL in root)	none (summary rule, §1)
`markdown`	suite	`packages/markdown/docs/planning` new	Rust: `markdown-util`, `yaml-splice`, `yaml-splice-wasm`, `wikilink`, `vault-fs`, `vault-transform`. TS: `markdown-util-ts`, `yaml-splice-ts`, `obsidian-md`, `obsidian-editor`, `obsidian-editor-demo`, `markdown-ui`, `markdown-ui-playground`, `obsidian-vault`, `obsidian-bases`, `vault-graph-core`, `json-canvas-core`, `json-canvas-vue`, `json-canvas-demo`	19	D-7VMX, C-8FKM tree, 11 milestones, 78 `markdown-ecosystem` entities	no (D-7VMX dossier in root)	none
`app-kit`	suite	`packages/app-kit/docs/planning` new	`ui`, `app-frame`, `panes`, `node-tree`, `graph-canvas`, `code-editor`, `color`, `spec-query`	8	Design language (D-DLNG) and the Nuxt layers every desktop product mounts	partial: `docs/planning/design-language/` (4 files, not entities), 20 tagged entities	Is `spec-query` UI kit or `dev` primitive?
`cli-substrate`	suite	`packages/cli-substrate/docs/planning` new	TS: `cli-tool`, `command-seam`, `easy-git-ts`, `easy-gh`, `detect-runners`, `waypost`, `waypost-docs`, `repo-cleaner`, `sdlc-tool`, `dev-ports`, `fleet-ts`. Rust: `cli-config`, `easy-git`, `fluent-git`, `fleet`, `fleet-tauri`; data `packages/fleet-parity`	16	S-0015 standalone CLI shape; three twin pairs (fleet, cli-config, easy-git) held by parity fixtures; C-0023	no	undecided; split only when a milestone changes one side alone
`agent-pants`	solution + suite	`solutions/agent-pants/docs/planning` new	`agent-pants`, `agent-adapt-core`, `agent-adapt-wasm`, `agent-adapt-typegen`, `agent-adapt` (packages/rust), `agent-adapt-ts`, `exp-agent-pants`, `product-agent-pants`, `product-suspenders`, `suspenders-core`; non-moon `packages/agent-pants` (+wasm), `plugins/obsidian`, `mockups`, `reference/skill-export`, exp `suspenders` (no moon id)	10	One product in three editions; agent-adapt is one three-crate mirror; suspenders/Agent Manager (M-BMFD, 56 `agent-manager` entities in root) is the same kind of thing	partial: `docs/vault/` is an Obsidian vault, slug-named, no ids (66 tasks, 12 decisions, 15 capabilities, 2 milestones, 28 glossary)	Claiming modules out of `solutions/determined` and `solutions/ontological`. Its name: agent-pants or agent-manager for the suspenders half (T-KX4V rename)
`determined`	solution	`solutions/determined/docs/planning` (existing)	`determined-root`, 6 apps, 22 `determined-*` crates, 24 experiences, 24 products, 8 packages, plus `obsidian-astro` and `packages/vaults/fitness`	86	A neighbour suite with its own roadmap, verbs, and corpus	yes: 108 T, 5 M, 3 C in `docs/planning`; 50 D in `docs/decisions` (outside `docs/planning`); own `sdlc.yaml`	Sub-root or separate project (section 7)
`augmented`	solution	`solutions/augmented/docs/planning` new	6 apps (`augmented_dot_com`, `augmented_web`, `augmented-books`, `learn_web`, `vimit`, `vimit_prototype`), 8 packages (`augmented-common`, `books`, `context`, `entity`, `hierarchy`, `logging`, `test-vue-component`, `utils`)	14	Reference application solution; one cluster	no; 22 `augmented-books` entities in root	none
`pumice`	app	`apps/pumice/docs/planning` new	`pumice`, `pumice-core`, `pumice-config`, `pumice-desktop`; non-moon `packages/admin-types`, `packages/nuxt_admin_layer`	4	Adopted app; D-0016, M-0014; 27 `pumice` entities	no (`apps/pumice/docs` holds fixes, mockups)	none
`zoo`	app + tool	`apps/zoo/docs/planning` new	`zoo`, `cage` (tools/cage)	2	cage is the isolation core lifted out of zoo; zoo carries the roadmap (`docs/05-roadmap.md`)	no	own unit once it ships alone (likely)

Tally: 12 + 7 + 3 + 7 + 19 + 8 + 16 + 10 + 86 + 14 + 4 + 2 = 188, the full moon project list. No leftovers among moon projects.

Non-moon manifests (T-N3RW will find these; each follows its container):

Nested shells: every src-nuxt, src-tauri, src-frontend, src-astro, src-directory, src-indexer, workers/contact-form, runners/sqlite/builder, and the 24 determined products/*/src-tauri.
Unregistered determined apps: connector, mail-sync, photo-match, todo-sync, vault-digest, vault-graph, vault-search, workflow-designer; package family-cli; .claude/skills/family-events. All go to determined by containment.
packages/ts/obsidian-bases/demo, packages/ts/yaml-splice/wasm → markdown. tools/cage/crates/* → zoo. Legacy sub-crates → dev.
Exclude from the graph: test fixtures that carry manifests (solutions/ontological/crates/manifest-graph/tests/mini-repo/**, packages/ts/manifest-graph/test/fixtures/**, packages/ts/waypost/tests/fixtures/showcase). sdlc capability coverage counts them as units today.

3. Suites

A suite is a unit of several modules planned together. Every unit is a folder, so each suite moves into one: under solutions/ when it ships a product, under packages/<suite>/ when it is a library suite. The engine is a library suite: Ontological consumes Foreman, and D-0001’s tier rule puts what one solution consumes from another in packages/. Moving is optional per suite; until a suite moves, its modules stay in dev. Units that already have a folder keep it and claim outlying modules under members:.

Suite	Target folder	Paths today	Why one thing
`markdown`	`packages/markdown/` (move: T-Z0KK)	`packages/rust/{markdown-util,yaml-splice,yaml-splice-wasm,wikilink,vault-fs,vault-transform}`, `packages/ts/{markdown-util,yaml-splice,obsidian-md,obsidian-editor,markdown-ui,obsidian-vault,obsidian-bases,vault-graph-core,json-canvas-core,json-canvas-vue}`	D-7VMX plans one core with planes over one tree. Its milestones (M-6TQL, M-2VYE, M-D3KP, M-C6XN, M-J9TB, M-N2HG, M-F4RZ, M-8DQW, M-3PVK) each touch several of these. Twin pairs (markdown-util, yaml-splice) share conformance corpora. Capabilities C-0030/32/34/35/41/43, C-T9GW, C-V5JD land here.
`engine`	`packages/engine/` (move: T-SKMB, after the foreman stack merges: T-FW23)	`packages/rust/{foreman,graph-scheduler,intersect}`, `packages/ts/{intersect,flowline}`	Foreman consumes graph-scheduler; the Rust intersect peer exists for the scheduler tick. One implementation ledger. Graph-scheduler’s six capabilities (C-409J, C-D2GO, C-GUGX, C-PC3N, C-PPXU, C-V44L) and three unanchored children (C-0UBY, C-551W, C-FD3Q) land here.
`cli-substrate`	`packages/cli-substrate/` (move: T-G6KG)	`packages/ts/{cli-tool,command-seam,easy-git,easy-gh,detect-runners,waypost,repo-cleaner,sdlc-tool,dev-ports,fleet}`, `packages/rust/{cli-config,easy-git,fluent-git,fleet,fleet-tauri}`, `packages/fleet-parity`	What every standalone tool mounts (S-0015). Fleet is one capability in two languages (C-0023), kept identical by one parity fixture. Ten capabilities land here.
`app-kit`	`packages/app-kit/` (move: T-PLW6)	`packages/ts/{ui,app-frame,panes,node-tree,graph-canvas,code-editor,color,spec-query}`	The design language and the shared Nuxt layers. Determined, Ontological, and Augmented all mount them. Seven capabilities.
`agent-pants`	`solutions/agent-pants/`; the rest claimed under `members:`	`solutions/agent-pants/**`, `packages/rust/agent-adapt`, `packages/ts/agent-adapt`, `solutions/determined/{experiences,products}/agent-pants`, `solutions/ontological/{crates/suspenders-core,experiences/suspenders,products/suspenders}`	One product (Personal Obsidian, Personal Desktop, Enterprise). The desktop edition is built on the determined shell but planned with agent-pants. agent-adapt, agent-adapt-core, and agent-adapt-wasm release as one mirror. Suspenders/Agent Manager (M-BMFD) is the same kind of thing: crate, experience, and product move together.
`sdf` (nested)	`solutions/ontological/desktop/`; the rest claimed under `members:`	`solutions/ontological/{desktop,experiences/system-graph,products/system-graph}`, `packages/ts/system-model`	The module-graph milestone changes all four together. `system-model` restates SDF’s Rust schema for TS.
`zoo`	`apps/zoo/`; `tools/cage` claimed under `members:`	`apps/zoo`, `tools/cage`	Same problem (agent sandboxing); cage was lifted from zoo.

4. Nesting

Every unit is a folder, and its planning root is <folder>/docs/planning/. * marks a unit that also claims modules outside its folder under members:.

dev (repo root: docs/planning)
├── ontological*        solutions/ontological + 5 packages/ts modules
│   └── sdf*            solutions/ontological/desktop + system-graph + system-model
├── determined*         solutions/determined − agent-pants exp/product
│                       + packages/ts/obsidian-astro + packages/vaults/fitness
├── agent-pants*        solutions/agent-pants + packages/{rust,ts}/agent-adapt
│                       + 2 modules claimed out of solutions/determined
│                       + suspenders: 3 modules claimed out of solutions/ontological
├── augmented           solutions/augmented
├── pumice              apps/pumice
├── zoo*                apps/zoo + tools/cage
├── engine              packages/engine (after T-SKMB)
├── markdown            packages/markdown (after T-Z0KK)
├── app-kit             packages/app-kit (after T-PLW6)
└── cli-substrate       packages/cli-substrate (after T-G6KG)
    (dev keeps: root project, sites/df-docs, config presets, atomic-write,
     slug, dir-aspect, prettier-fmt, legacy apps, published skill packs)

After the four suite moves, six of 11 sub-units work by containment alone: augmented, pumice, engine, markdown, app-kit, and cli-substrate. Five keep cross-tree claims under members:: ontological, sdf, determined, agent-pants, and zoo. Each claim can go away if its module moves. Two units carve modules out of another unit’s folder (agent-pants out of determined and, for suspenders, out of ontological; sdf out of ontological), so an explicit claim must win over containment.

5. What exists vs. what to declare

State	Units
Corpus exists, sdlc-shaped	`dev`, `determined`
Corpus exists, not sdlc-shaped	`agent-pants` (Obsidian vault, no ids), `sdf` (`SG-NN` backlog)
Planning root to create	`ontological`, `sdf`, `engine`, `markdown`, `app-kit`, `cli-substrate`, `agent-pants`, `augmented`, `pumice`, `zoo`
Id de-collision needed	`determined`: 19 ids clash with root — C-0001..C-0003 and D-0002..D-0014, D-0016..D-0018 (e.g. root D-0011 markdown-formatting-tool vs determined D-0011 polish-as-platform-experience; D-0018 sdf-control-plane-app vs determined-state-plane). Basenames differ, so D-SK9G’s duplicate-basename check misses them, but `D-0011` and union minting do not.
Layout fix needed	`determined`: decisions live in `docs/decisions/`, outside `docs/planning/`; one unprefixed file (`0001-obsidian-vault-...`); a second `sdlc.yaml` that D-SK9G forbids under a sub-root

The planning_roots: block below uses D-SK9G’s two optional keys:

scope: the directory whose modules the unit takes by containment. Default: the parent of docs/planning when root ends in it, else none.
members: paths outside the unit’s folder that it claims, each with everything under it. Only cross-tree exceptions use it. An explicit claim beats containment. Two explicit claims on one path fail audit.

A unit’s summary is never hand-set through this block; see the summary rule in section 1.

slug: dev
planning_roots:
  ontological:
    root: solutions/ontological/docs/planning
    label: Ontological
    members:
      - packages/ts/agent-call
      - packages/ts/agent-dev
      - packages/ts/agent-plugin
      - packages/ts/dashboard-client
      - packages/ts/manifest-graph
  sdf:
    root: solutions/ontological/desktop/docs/planning
    label: SDF
    members:
      - solutions/ontological/experiences/system-graph
      - solutions/ontological/products/system-graph
      - packages/ts/system-model
  engine:
    root: packages/engine/docs/planning
    label: Foreman engine
  markdown:
    root: packages/markdown/docs/planning
    label: Markdown ecosystem
  app-kit:
    root: packages/app-kit/docs/planning
    label: App kit and design language
  cli-substrate:
    root: packages/cli-substrate/docs/planning
    label: CLI and fleet substrate
  agent-pants:
    root: solutions/agent-pants/docs/planning
    label: Agent Pants
    members:
      - packages/rust/agent-adapt
      - packages/ts/agent-adapt
      - solutions/determined/experiences/agent-pants
      - solutions/determined/products/agent-pants
      - solutions/ontological/products/suspenders
      - solutions/ontological/crates/suspenders-core
      - solutions/ontological/experiences/suspenders
  determined:
    root: solutions/determined/docs/planning
    label: Determined
    members:
      - packages/ts/obsidian-astro
      - packages/vaults/fitness
  augmented:
    root: solutions/augmented/docs/planning
    label: Augmented
  pumice:
    root: apps/pumice/docs/planning
    label: Pumice
  zoo:
    root: apps/zoo/docs/planning
    label: Zoo
    members: [tools/cage]

The four suite roots register once their moves land. A suite’s root sits at the suite folder, above its packages. A planning directory inside packages/ts/intersect would be copied to the public mirror by the snapshot channel, and one inside a crate would ship in the crate unless include excludes it; the suite folder avoids both.

6. Implementation order

Step	What	Needs	Tasks
0	Build the structural layer. Exclude fixture manifests and gitignored copies (`sites/df-docs/src/content/docs/planning`).	nothing	T-N3RW
1	Settle the declaration shape: `scope`, `members`, `product`; claim beats containment; how determined joins. Amend D-SK9G or fold into D-XCXA.	a decision	D-XCXA open question 2
2	Land the `slug`/`planning_roots` keys.	M-ZLTF P0	T-K9AI
3	Declare the contiguous units with no existing corpus: `ontological` (members can wait a step), `augmented`, `pumice`. Scaffold empty roots.	step 2	T-EIZX (partial)
4	Land membership with `members:` and the one-unit audit check. Declare `sdf`, `agent-pants`, `zoo`.	step 2; T-CY6T	T-CY6T, T-EIZX
4a	Optional, per suite, any time after step 0: move a suite into its folder and declare its root. `engine`, `markdown`, `app-kit`, `cli-substrate` → `packages/<suite>/`. Can trail the SDF slice.	step 0; step 2 to declare	T-SKMB, T-Z0KK, T-PLW6, T-G6KG
5	Land union loading, union minting, and the duplicate checks. Then bring determined in: renumber its 19 clashing ids and rewrite links, move `docs/decisions/` under `docs/planning/`, retire its `sdlc.yaml`.	M-ZLTF P2	T-G3EH, T-EIZX
6	Rollups and SDF views.	steps 4–5	T-JJHY, T-SX0F, T-S4K4, T-9TBQ, T-KWJS
7	Triage (can wait): move execution entities out of `dev` by tag — `markdown-ecosystem` 78, `agent-manager` 56, `pumice` 27, `augmented-books` 22, `design-language` 20, `graph-scheduler` 16, `foreman` 15, `sdf` 14, `agent-pants` 9. Convert the agent-pants vault and the `SG-NN` backlog to minted ids.	step 5	new tasks
8	Peer repos (`markdown-contract`, `polish`) as roster entries.	M-ZLTF P1	T-CTEV

The smallest first instance is steps 0, 2, and 3: structure plus three declared units, none of which touches an existing corpus. T-EIZX’s criteria name this list. Everything past step 0 is blocked on M-ZLTF (status open/draft).

7. Risks and open questions

Determined does not fit D-SK9G as written. It has its own sdlc.yaml with different check verbs, 50 decisions, and 3 capabilities. D-SK9G forbids a second sdlc.yaml under a sub-root. Options: (a) sub-root with per-root verbs, or (b) a nested project with its own slug, which D-SK9G does not define. This report assumes (a).
Definition kinds per unit. Resolved: D-SK9G and D-XCXA let every unit carry its own definitions, inherited down the containment tree.
Rollups are skewed until triage. The root corpus holds 800 tasks, most of them Ontological’s. Declaring units without moving entities gives dev Ontological’s numbers and ontological zeros.
Modules below manifest grain. solutions/ontological is one module (sdlc) holding lib/, cli/, 43 skills, and the entity model. D-ME8T’s four packages (sdlc-core, -model, -definition, product) will become modules once they have manifests. Until then the definition/execution cut is invisible in structure.
Legacy trees. apps/ontological-legacy, apps/legacy-polish, and apps/agentpants are frozen or reference-only. They sit in dev so they add nothing to live rollups. Salvage work is planned in the unit that receives it. A separate legacy unit is the alternative.
Experiences are modules. Each has a package.json and a moon id, so each is a structural node. Products depend on experiences. An experience joins a unit by directory unless claimed, as agent-pants claims exp-agent-pants.
Capabilities that cross units. C-0017 (command-seam + sdlc), C-K3TQ (sdlc + vault-contracts + determined-contracts), and C-V5JD (obsidian-bases + determined-notes) land on two or three units. T-SX0F AC-1 lets each unit claim them; the parent total would count them twice.
Unmoved suites. A suite that has not moved has no folder and no root, so its modules sit in dev. A new package under packages/ also lands in dev unless it is created inside a suite folder. An audit report of dev’s unclaimed library modules would help.
Stale docs found while surveying (not edited; read-only brief):
- .moon/workspace.yml says “24 products and 24 experience layers”; there are 25 of each. The “fitness tracker” comment above the solutions/ontological/crates/* glob describes a different project.
- docs/LIBRARIES.md lists vault-graph-core under Rust (it is packages/ts/vault-graph-core) and a biome-fmt crate that does not exist (packages/rust/prettier-fmt does).
Engine folder. Decided in D-XCXA: packages/engine/. Ontological consumes Foreman, and D-0001’s tier rule puts what one solution consumes from another in packages/.

← Back to Notes