Capability containment proposal

State: closed/archived · Genre: analysis

Containment proposal for the 51 unnested capabilities.

Source: origin/main checkout at dev-planning-view, 127 capabilities, 51 open with no parent that are not kind: system. (C-HRNS is a closed, retired system with no parent; it is ignored.) Rule applied: a parent only where the child’s own Statement and locations make it part of the parent; no nesting by directory proximity; unnested is a normal outcome.

1. Summary counts

Proposal	Count
Nest under an existing capability	2
Nest under a new capability	19 (all under one new root, “Determined”)
Leave unnested	27
Unsure	3
Total	51

2. Proposed roots

Only one additional root is supported by the capability files.

Determined (new, kind: system, audience system, new root; no product file exists, so none is invented). Evidence:

18 capabilities (C-0091, C-0093 to C-0109 less C-0092) anchor to solutions/determined/crates/* and describe parts of one running system. C-0104 says “Every Determined product calls the same API implementation” and “wires domain crates (notes, index, polish, fitness, …)”. C-0102 says “Determined’s Rust backends each serve one experience … This crate defines what they share.” C-0095 says “Any determined capability that needs a SQLite file opens it the same way.” C-0100 is “the only place in the determined fleet that may depend on the macOS platform”.
C-0040 states it is the component library “for every app in the determined ecosystem”.
These are not part of C-0050 (control plane) or C-8FKM (markdown core) by definition: they are an end-user app platform. Several already relate to C-8FKM children (C-T9GW, C-N6RH, C-K3TQ) as dependencies; keep those as related, not parentage. C-0110 already sits under C-V5JD (vault query and index); leave it there, it is the one determined crate placed by plane rather than by app.
Optional later sub-grouping (not proposed now): C-0104 (platform) and C-0102 (port vocabulary) as hubs. Their definitions describe wiring and shared vocabulary, not containment of the domain crates, so flat under the root is the conservative choice.

Considered and not proposed (no or too few capabilities): Foreman (3 capabilities, but C-0080 already places the contract inside Coordinate), Flowline (one), Intersect (one), Graph scheduler (C-D2GO subtree sits under Decide), Pumice, Zoo (only C-0074, already under Act), Agent Pants, Augmented, local-site-marketer (none). Root candidates for a shared-libraries bucket were rejected: that would be nesting by directory (packages/ts).

3. Table

Capability	Title	Kind	Proposal	Parent	Reason
C-0011	Agent Skills authoring derivations	module	Nest under existing	C-0044	Defined as “the TypeScript peer of the agent-adapt Rust crate” holding a subset of its derivations; C-0044 is that crate (same pattern as C-0047 under C-0023).
C-0045	Distributed work-runner contract types	module	Nest under existing	C-0080	C-0080 is the Foreman engine contract and already lists C-0045 as related; C-0045 is the contract’s type layer (work orders, DAG format, leases, ports). Low risk, C-0080 has no locations of its own.
C-0040	Determined UI component library	module	Nest under new	Determined (new root)	Statement: shared components “for every app in the determined ecosystem”.
C-0091	Vault image asset substrate	module	Nest under new	Determined	Crate `determined-attachments`; library for the determined crates that handle vault images (photos, media, OCR).
C-0093	Read-only vault query agent	module	Nest under new	Determined	`determined-agent`; the query agent over a Determined vault.
C-0094	Fitness training log store	module	Nest under new	Determined	Statement: “determined-platform consumes its generated” port; one experience of the platform.
C-0095	SQLite platform service	module	Nest under new	Determined	”Any determined capability that needs a SQLite file opens it the same way.”
C-0096	Face detection and photo identity matching	module	Nest under new	Determined	One of the Determined experiences (photo annotator, photo-match).
C-0097	Vault git state and commits	module	Nest under new	Determined	Maps onto determined-core wire types; applies the writes Polish makes.
C-0098	Git-backed vault snapshots	module	Nest under new	Determined	Backup experience, `determined-backup`.
C-0099	Markdown-native workflow authoring	module	Nest under new	Determined	`determined-authoring`, one Determined experience.
C-0100	Apple platform bridge	adapter	Nest under new	Determined	”The only place in the determined fleet that may depend on the macOS platform.”
C-0101	Google Calendar pull sync	module	Nest under new	Determined	”The Rust port of the calendar-sync app”, a Determined backend.
C-0102	Determined backend port vocabulary	module	Nest under new	Determined	Defines what Determined’s backends share.
C-0103	Rust backend parity harness	module	Nest under new	Determined	Compares two implementations of Determined’s port traits.
C-0104	Determined platform backend	module	Nest under new	Determined	”Every Determined product calls the same API implementation.”
C-0105	Vault OCR scan, search and sidecars	module	Nest under new	Determined	OCR experience, `determined-ocr`.
C-0106	Vault-engine scheduler client	adapter	Nest under new	Determined	`determined-engine-client`, status client for Determined’s vault-engine.
C-0107	Agent Pants vault authoring and publish	module	Nest under new	Determined	Composes vault note operations behind determined-core’s `VaultNotesPort`.
C-0108	Vault lint, scan and batch maintenance	module	Nest under new	Determined	Polish experience, implements `PolishBackend`.
C-0109	Duplicate image scanning and safe resolve	module	Nest under new	Determined	Media experience, `determined-media`.
C-0030	Markdown viewing and editing UI chrome	module	Unsure	n/a	A Nuxt layer “a host product mounts”; composes C-0034 and C-0035. Need: is it meant to be part of the markdown ecosystem (C-8FKM) or a UI-layer capability of its own?
C-0035	Live-preview markdown editing engine	module	Unsure	n/a	Edits via “exact-range swap writes so untouched bytes never change” (echoes C-N6RH fidelity) and is the counterpart of C-0034, which sits under C-8FKM; but C-8FKM’s Statement is about parse/validate/transform/query, not editors. Need the owner’s call on whether editors are inside C-8FKM.
C-0092	Local ONNX model runtime	module	Unsure	n/a	Crate `determined-models`, but its Statement says it “has no opinion on what a model is for” and mentions nothing Determined-specific. Need: is it used outside Determined? If not, it joins the Determined group.
C-0012	App frame shell	module	Leave	n/a	Explicitly “decoupled from any one product’s domain code”; hosts extend it. A dependency of apps, not a part of one.
C-0013	Headless agent CLI call spec	module	Leave	n/a	General glue for calling coding-agent CLIs; only related to retired C-HRNS. C-0072 (harness engines) hosts sessions, a different job.
C-0014	CLI substrate package	module	Leave	n/a	Substrate for any standalone CLI.
C-0015	Changeset rule-source verification	module	Leave	n/a	Standalone verifier; nothing makes it part of another capability.
C-0016	sRGB colour arithmetic	module	Leave	n/a	Dependency-free utility “consumed by”, not part of, design-token tooling.
C-0017	Injectable subprocess seam	module	Leave	n/a	Used by everything; use is not containment.
C-0018	Task runner detection and normalization	module	Leave	n/a	Library plus CLI; C-0042 is built on it (a dependency).
C-0019	Dev port allocation and leasing	module	Leave	n/a	Repo-wide registry; covers every directory band.
C-0020	Dashboard API client	module	Leave	n/a	Client for the SDLC dashboard server; no capability exists for the dashboard itself.
C-0021	Typed GitHub client over gh CLI	module	Leave	n/a	Standalone client.
C-0022	Typed git client (easy-git)	module	Leave	n/a	Standalone client (TS and Rust arms already in one capability).
C-0023	Fleet state-location resolution	module	Leave	n/a	Already a parent (C-0047); nothing makes it part of another.
C-0024	Path-pattern overlap engine	module	Leave	n/a	Pure pattern algebra, product PR-0002.
C-0025	Manifest graph walking	module	Leave	n/a	See open question 3: could join C-0037 under a new “structural graph” capability, but neither definition says so yet.
C-0026	JSON Canvas editing engine	module	Leave	n/a	Framework-agnostic model; has a child (C-0029).
C-0027	Leveled workflow-authoring kit	module	Leave	n/a	Own product (Flowline); “authors only, never executes”, so not part of the engine.
C-0028	Interactive graph canvas rendering	module	Leave	n/a	Standalone Vue component.
C-0031	Lazy paged tree browsing	module	Leave	n/a	Generic tree over an “opaque, paged node source”.
C-0033	Pane layout primitive	module	Leave	n/a	”Structural only”; no coupling to the app frame beyond a CSS variable contract.
C-0036	Repository branch/worktree cleanup sweep	module	Leave	n/a	Standalone library and CLI.
C-0037	System graph wire contract	module	Leave	n/a	Structural-graph types and ports; not the capability graph of C-0063.
C-0039	View-state query codec	module	Leave	n/a	Generic codec.
C-0042	Multi-runner task browser	module	Leave	n/a	Builds on C-0018 (dependency); a product in its own right.
C-0046	Directory aspect detection	module	Leave	n/a	Tiny standalone crate; consumers (vault pickers) are not named parents.
C-0048	Generated TypeScript formatting	module	Leave	n/a	Utility for ontogen output.
C-0049	Slugify and deterministic collation	module	Leave	n/a	Shared utility used by many.

(Rows sorted by proposed parent: C-0044, C-0080, Determined, then no parent.)

4. Model subtree candidates (C-0052: C-0062, C-0063, C-0064)

The corpus has almost nothing that is by definition part of these three; I would deepen the subtree by authoring new capabilities (entity kinds, contracts, identifiers, OKF check, graph ops, skills) rather than by moving existing ones. Candidates, all weak or overlapping:

C-K3TQ Markdown contract and validation (now under C-8FKM): its locations are solutions/ontological/lib/model/entities/*/schema.ts, which are C-0062’s territory too. Overlap, not clear containment. Do not move; ask the owner which one owns the schemas.
C-0037 System graph wire contract under C-0063: only if the planning view consumes the SystemGraph; its definition speaks of project structure, not capabilities. Unsure.
C-0020 Dashboard API client under C-0063: Statement mentions browsing “including the capability graph”, but it is a general dashboard seam. Unsure, lean leave.
C-0085 Roadmap and milestone tracking (under Record): C-0063 says “milestones name the capabilities they move to building and verified”. Overlap; flagged under section 5.
C-0044 / C-0011 (skill authoring and export) are tooling that skills use, not part of C-0064 (“script-free prose skills”). Not candidates.

5. Possibly wrong existing parents

C-0029 under C-0026: the Statement of C-0026 says the Vue rendering surface “lives in the sibling @augment/json-canvas-vue package, which imports this engine”. A renderer that depends on the engine is not obviously part of a framework-agnostic engine that has “no DOM or UI framework dependency”. Check by asking whether C-0026’s Statement should include board rendering.
C-0034 under C-8FKM: renderer is a consumer of the markdown core; same question as C-0035 (open question 2).
C-0085 under C-0058 Record versus C-0063: same job (milestones and capabilities), two places.
C-K3TQ under C-8FKM versus C-0062 (see section 4).

6. Open questions for the owner

Do you want a new system root “Determined” (with 19 members) for the solutions/determined crates and @determined/ui?
Are markdown editors and renderers (C-0034, C-0035, C-0030) part of the markdown ecosystem C-8FKM, or consumers of it?
Should C-0025 (manifest graph) and C-0037 (system graph contract) become parts of a new “structural graph” capability, under Model or as its own root?
Is determined-models (C-0092) used outside Determined? If not, it joins the Determined group.
Should C-0045 sit under C-0080 (Foreman engine contract) given C-0090 is the future Rust implementation and C-0089 the TypeScript one?
Is there a capability for the SDLC dashboard (server and SPA) that C-0020 would belong to, or should one be created?
Who owns the entity schemas, C-0062 or C-K3TQ?
Should C-0029 stay under C-0026, or does a board renderer stand alone?

Owner’s decisions, 2026-10-03

A new root, Determined, with 19 members; C-0092 is excluded and C-0110 stays where it is.
The markdown editors and renderers (C-0030, C-0035, C-0034) are part of the Markdown ecosystem core, C-8FKM.
A new Structural graph capability under Model, containing C-0025 and C-0037.
C-0092 Local ONNX model runtime stays unnested.
C-0045 goes under C-0080.
A new SDLC dashboard capability containing C-0020.
Entity schemas belong to C-0062; C-K3TQ is the general contract library; each names the other.
C-0029 and C-0026 both sit under C-8FKM.
C-0011 goes under C-0044.

← Back to Notes