Skip to content

docs: ADR 0005 — dependency classes (runtime vs development-support) #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rxdu merged 1 commit into from
Jul 7, 2026
Merged

docs: ADR 0005 — dependency classes (runtime vs development-support) #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/adr/0005-application-level-composition.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,15 @@ Meanwhile the planning core (~48k LOC), the estimators, the control laws, and th

This mirrors ADR 0004 one level up: there, components instrument against a stateless API and applications choose the machinery; here, components implement algorithms or hardware against the shared foundation, and applications choose the combination.

### Dependency classes (clarification, 2026-07)

The rule above constrains the **deployment closure** — what a robot links at runtime. Its rationale (consumers paying for stacks they don't use; behavior-critical layers entangling release cycles) applies to runtime dependencies only. Two classes are therefore distinguished:

1. **Runtime dependencies**: the deployment closure of an algorithm or hardware component is **xmBase plus mathematical libraries, nothing else**. Unchanged, strict, CI-enforced.
2. **Development-support dependencies**: components *may* depend on family components whose purpose is supporting development — visualization, simulation tooling, test infrastructure — provided the dependency is **always optional (build-gated) and provably absent from the deployment closure**. These support components exist so that domain components can see themselves during development; forbidding the dependency would invert their purpose.

**xmViewer** (quickviz) is the first registered development-support component: xmNavigation consumes its rendering primitives in the visualization-gated modules and demos. The division of labor is deliberate: the *drawers of a component's types live with that component* (they evolve with the algorithms); the support component stays domain-agnostic (canvases, windows, GUI primitives). Deployment builds are verified render-free the same way they are verified hardware-free.

## Alternatives considered

- **Keep the composition layer in xmNavigation** (status quo) — rejected: hardware dependencies in the algorithms component, coupled release cycles, and consumers paying for stacks they never use.
Expand Down