Story: Bring every component to the component clean standard
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
Every C++ component meets the Component Clean Standard, the checklist written from
what ores.iam and ores.refdata did in sprint 25: every wire type
modelled and generated, every model on the current format and bound to
a profile, no legacy or hand-written duplicate left, and every codegen
gate green with the component under test.
This is the first pass of the sprint 26 mission. The user-journey analysis and the UX follow it. Sprint 25 tried many approaches to the codegen problem at the same time; this program uses one method, one component at a time.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-09-23 |
3. Acceptance
- The Component Clean Standard is written, and each item names the check that proves it.
- Every C++ component has a story, in the order below, with its survey snapshot and its known issues.
Each component story carries its own completion: the component passes
the standard and joins COMPONENTS_UNDER_TEST. The registry, not this
story, is the record of which components are clean.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Write the component clean standard and the per-component stories | DONE | 2026-09-23 | 2026-09-23 | Extract the checklist from the sprint 25 ores.iam and ores.refdata work, survey every component, and scaffold one ordered story per component. |
5. Order
Easy infrastructure first, then higher infrastructure,
then the domain components, then the clients and the test support,
which link the domain components. Tier 1 is in dependency order: each
component comes after every component it links. Above tier 1 the
components link each other in cycles at the component level (for
example ores.service and ores.workflow), so no strict order exists
there; a component comes after the ones it links where the links allow,
and smaller components come first otherwise.
Tiers: 1 foundation infrastructure, 2 higher infrastructure, 3 domain components, 4 clients and test support.
6. Decisions
- One checklist for every component. Each item says which kind of component it applies to (All, Protocol, Entity), so an infrastructure component runs a short list and a domain component the whole list.
- One story per component, with one task each. A large component (for
example
ores.trading) splits its story once the baseline and the inventory are done, not before. - The TypeScript UI is retired, so no item concerns it.
- Joining
COMPONENTS_UNDER_TESTis the last step of each story, so the registry is the record of which components are clean.
7. Out of scope
- The tooling projects, which hold no C++ component:
ores.codegen,ores.compass,ores.lisp,ores.org-js,ores.seeder,ores.sqlandores.web. The SQL and seed work for each component happens in that component's story. - The user-journey analysis and the UX, which follow this pass.
8. Result
The Component Clean Standard is written, with 42 items, and the 35 component stories are in sprint 26 in the order above. Work starts with ores.platform.