Task: Bring ores.database to the clean standard

Recorded at 5de59e3fb8 (the branch point, before any edit).

$ projects/ores.compass/venv/bin/python \
    projects/ores.codegen/scripts/check_component_drift.py \
    --component database-cpp --dry-run
19 file(s) would change, 25 file(s) would be created (44 file(s) in total).
exit 1

The 19 changed files were the whole database_info stack the component hand-writes: domain/database_info.hpp and its JSON I/O, the sqlgen entity, the mapper, the repository, export.hpp, the four CMake files and the generated table SQL. The 25 created files were the families the hand-written stack has no counterpart for at all: the table and table I/O, the generator, the protocol header, the handler, the messaging, event and history-provider registrars, the event type, the presentation history mapper, the service, the three scaffold stubs and three SQL trigger and drop scripts.

check_model_drift.py at the same revision: "No model drift: every bound model agrees with its profile (2 known exception(s))". The exception list is compute.result and reporting.report_definition; neither is this component. database_info declared no :profile: at all, so the check skipped it.

validate_docs.sh at the same revision reported one violation, unrelated to this component: MISSING_PUML ores.shell.iam.

Two codegen model files, by metatype:

File	Metatype	Variability
ores.database.database_info.org	ores.codegen.entity	carries it
ores.database.module.org	ores.codegen.module	none; docs-only index, excluded by the documented module rule
component_overview.org	ores.codegen.component	none; drives the CMake scaffold and the C++ stubs

49 tracked files at 5de59e3fb8, tests excluded.

Generatable, 15 present: CMakeLists.txt, modeling/CMakeLists.txt, src/CMakeLists.txt, src/component_files.cmake, export.hpp, the four database_info C++ headers, the four database_info C++ sources and ../ores.sql/create/database/database_database_infos_create.sql.

Generatable but absent, 25: the whole protocol, handler, registrar, event, service, generator, table, presentation and stub families, plus the SQL trigger and drop scripts. No hand-written counterpart exists for any of them.

Infrastructure that stays hand-written, 32: the connection pool (tenant_aware_pool), bitemporal_operations, db_types (it defines the canonical db_timestamp the generated entities consume), the mapper helpers, helpers, the exception types, database_options, context, session_utilities, database_configuration, the two umbrella headers, the service layer (context_factory, health_monitor, party_context, postgres_listener_service, tenant_context), the aggregate header, the component overview, the module model, and the PlantUML source and image.

Dead, 3: modeling/ores.database.database_info.org, ores.sql/create/database/database_info_fn_create.sql, whose ores_database_info_fn() had no consumer in C++ or in Python, and ores.sql/drop/database/database_info_drop.sql, superseded by the generated drop script and kept alive only by a WIRE_001 exception.

The first draft of this classification called the function unread as well, and that was wrong. The independent review found one caller the audit missed, utility/dump_database_version.sh, which selected from it five times. The bash consumer is a real one, so the script now reads ores_database_info_tbl directly and the wrapper function is gone with no callers left. The Review table records the finding and the fix.

The sprint 25 story Entity classification and drift baseline: ores.database and its one task were both abandoned at sprint 25 close; the task record says sprint 26 replaces the codegen approaches tried so far with one method. No branch or capture for this component is in flight. The other component clean-up stories in sprint 26 touch their own components and do not overlap ores.database.

This environment cannot run the fleet or the SQL pass of the standard. Every compass command that needs the environment stops at:

=== ERROR: .env is out of date ===
  Your .env:  version 22
  Required:   version 23

The fix compass prints is compass env configure, which regenerates the whole .env. The version 23 delta is the removal of ORES_CONNECTIONS_MASTER_PASSWORD for the retired ores.connections, so the missing variable is inert here; the version guard stops the command before it reads anything. Regenerating a working local .env is the owner's call, not this branch's, and the user is working in this checkout. The same guard blocks the fleet, so the NATS-backed suites cannot run either.

What that leaves unproven is small and named: the database was not recreated from scratch and the fleet did not serve. The schema change itself is proven by the SQL validator, and the deleted C++ had no consumers, so nothing on the build path can fail from it. The two checks are the first thing to run in an environment that is up.

The audit ran over the component on 2026-09-26 and its record is here, as the sprint 25 first run did for its four components.

Shape. A simple component: CMakeLists.txt, include/, src/, tests and modeling/ at the root, and no #+component_kind:, which the loader reads as flat. Its layer page listed it under a "Sub-component" column; the page now names it as a component, with its own dependencies.

Folder morphology. Every folder is in the signed-off catalogue: include/, src/, tests, modeling, and the facet directories config, domain, repository, service. The new scripts/ directory holds the clean-standard lever; it is the component's own tool, alongside modeling/'s diagram target, so the audit records it here rather than treating it as an unregistered folder.

Technical space. No create/, populate or venv/ tree in the component. The SQL lives where it belongs, under projects/ores.sql.

Leftovers. None. No *stub*, *.orig, *.rej, .DS_Store or __pycache__.

Tests. ores.database.tests is a ctest target and passes in 12.34 s.

Comments. The diff deletes comments. It adds two: the reason the table is not temporal, in the SQL, and the reason the component has no catalogue entry, in the registry. Both state a why the code cannot show.

Naming. Every file and type is snake_case and matches its home folder.

Registries. The component is absent from component_catalogue.org by the same decision that removed its model, and its layer page is corrected. It carries no messaging reference, so there is no subject table to keep in step.

Model and profile hygiene. No bound model remains, so there is no redundant feature line to remove.

Platform placement. No _WIN32, __linux__ or compiler macro, and no OS header, anywhere in include/ or src/.

Documentation and diagrams. component_overview.org carries the six required sections and a #+brief:; validate_docs.sh reports no violation for the component. The .puml and .png are present. The table's shape is unchanged, so the diagram does not misdescribe it; its generator-vs-committed gap is pre-existing and recorded as a capture.

Complexity. The canonical measure, projects/ores.compass/venv/bin/lizard projects/ores.database/include projects/ores.database/src:

Total nloc   Avg.NLOC  AvgCCN  Avg.token   Fun Cnt  Warning cnt
      2075      13.3     2.5      103.3       119            1
  NLOC  CCN  token  PARAM  length  location
   117   20    875      0     166 tenant_aware_pool::acquire@143-308

One hotspot, tenant_aware_pool::acquire at CCN 20. It is the pool's acquire path with its timeout and retry handling, it is hand-written infrastructure with no generator to blame, and no threshold gates it. The audit records it; a refactoring pass would start from this number. There is no generated source in the component, so the totals read as a component signal rather than a template signal.

projects/ores.database/scripts/check_clean_standard.sh runs the mechanical items of the standard against this component and prints a PASS, FAIL or N/A line with the evidence for each. A reviewer reruns it instead of re-deriving the table above. V01 to V04 are out of its scope because they need a built tree and a running fleet; their evidence is recorded here.

The script asserts the number of checks it emits, so an item that stops being checked fails the run rather than leaving a silent gap in this record. It raised this record's own first count, which read 20 pass and 21 not applicable; the true split is 21 and 20.

• The committed ER diagram projects/ores.sql/modeling/ores_schema.puml is stale against its own generator by 26 hunks, all outside this component: table notes and column order in iam, trading and others. Regenerating it for this component's no-op column change would have carried that unrelated churn. The capture Refresh the stale ER diagram from its generator covers it. This component's table shape is unchanged, so the stale diagram does not misdescribe it.
• regenerate_cmake_component_files.py --all --check is red repo-wide: 147 stale component_files.cmake files across 33 components, including ores.workspace and ores.refdata. It is out of scope here because the command lifts the catalogue entry, which this component no longer has.