Story: Clean ores.database 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
ores.database meets the Component Clean Standard: every item: All, Protocol and Entity pass, each item that does not apply is recorded with its reason, and ores.database joins COMPONENTS_UNDER_TEST. Order 8 of 35 in the sprint 26 component clean-up, tier 1 (foundation infrastructure).
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Review and merge the branch. |
| Last touched | 2026-09-26 |
3. Acceptance
- Every checklist item that applies to a component of kind Entity passes, with its evidence recorded on the task.
- Every item that does not apply is recorded as not applicable, with the reason.
- Every generator defect found is fixed at its source, with a regression test.
- ores.database is listed in
COMPONENTS_UNDER_TEST, andcheck_component_drift.py --allpasses.
The last criterion resolved differently from the way it was written, and the
decision is recorded under Decisions: the component has no codegen model, so
it has no regeneration to gate and no catalogue entry for the gate to resolve
it through. check_component_drift.py --all passes.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Bring ores.database to the clean standard | DONE | 2026-09-26 | 2026-09-26 | Work ores.database through the Component Clean Standard in order and record each item. |
5. Notes
- Survey on 2026-09-23: 1 entity, junction or operation models; 40 C++ files outside tests, 0 of them generated (0%); 0 messaging headers, 0 of them hand-written.
- One entity model (
database_info) and its SQL. The rest is the database access layer, which stays hand-written infrastructure (B03). - Survey on 2026-09-26, worked: the one entity model was not reproducible and
the component cannot host a generated entity. The generator emits a
bitemporal stack whose handler and registrars link
ores.history,ores.eventing,ores.nats,ores.securityandores.service, andores.servicelinksores.database, so the generated stack cannot link from the foundation layer. The model also contradicted the table: its prose says "Contains exactly one row" and its output says "history". The model and the dead hand-written stack that served it are gone, and the table is hand-written SQL in the SQL technical space. The task record carries the decision and the per-item evidence. - The component now sits with the other model-free foundation components,
ores.storage,ores.security,ores.platform,ores.diffandores.nats, none of which carry a codegen catalogue entry or a model.
6. Decisions
- The component keeps no codegen entity model. The generated stack cannot link from the foundation layer, and the table is one immutable row of bootstrap metadata rather than a domain entity. Full reasoning on the task record.
- The component does not join
COMPONENTS_UNDER_TEST. It has no regeneration to gate, and the gate resolves its members through the codegen catalogue, which the component no longer has an entry in. The task record records this against item V06.
7. Out of scope
- Refreshing the stale ER diagram, which is pre-existing drift outside this component. The capture Refresh the stale ER diagram from its generator covers it.
- The repo-wide
component_files.cmakestaleness: 147 files across 33 components.