Story: Entity classification and drift baseline: ores.compute

Table of Contents

This page documents a story in Sprint 25. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

1. Goal

Bring ores.compute to the same proven state as the ores.refdata pilot: every codegen-eligible entity bound to a profile or recorded as a genuine no-match, zero-diff regeneration verified, and any real gap the check surfaces fixed rather than skipped. Once trusted, compute-cpp is added to the CI regeneration-drift check.

2. Status

Field Value
State DONE
Parent sprint Sprint 25
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-05

3. Acceptance

  • Every ores.compute entity is bound to a matching Variability Profile, or recorded as a genuine no-match with a documented reason. Done 2026-09-05.
  • Every rebound entity is regenerated and diffed against its pre-rebind checked-in output; zero diff is the pass condition, and any non-zero diff is fixed, not worked around. Done 2026-09-05.
  • Full local build clean, validate_schemas.sh green, full ctest suite green after regeneration. Done 2026-09-05 (build clean at 100%, ctest 71/71; compass db status reports schema drift current, the successor of validate_schemas.sh).
  • check_component_drift.py –components is extended to include compute-cpp, and the refdata-codegen-drift CI job is updated so future PRs touching ores.compute fail on any regeneration drift. Done 2026-09-05 (08b6f23193).
  • The superseded ad hoc task 'Apply safe drift to compute-cpp' is marked ABANDONED, pointing here. Done (State ABANDONED, Result re-pointed at this story).
  • This is the heaviest known exclusion catalogue of any component: the 6 hand-written service files, result_repository (read_by_workunit), workunit_repository (read_by_batch), 3 mappers (nullable vs non-optional), and 2 repositories (system_tenant union filter) are each resolved – either brought under codegen properly, or verified as a genuinely correct, documented exclusion – not carried forward as an unexamined restore-from-HEAD step.

4. Tasks

Task State Start End Description
Bind ores.compute entities to profiles; verify zero-diff regen DONE 2026-08-10 2026-09-05 Implement profile binding for the compute-cpp catalogue entry, rebind every matching entity, regenerate, and confirm byte-identical output. Known starting point: heaviest exclusion catalogue of any component – 6 service files, result_repository (read_by_workunit), workunit_repository (read_by_batch), 3 mappers (nullable vs non-optional), 2 repositories (system_tenant union filter).

5. Decisions

  • All six legacy entities bind to uuid-identified-lookup; the app_version_platform junction binds to tenant-scoped-junction via file-level #+profile:. result is the one change-reason exception: a list-only entity whose rows the grid machinery writes, so it has no human edit flow and no change-reason cache.
  • The hand-crafted messaging protocol, the six entity handlers and the six hand-written service files are replaced by the standard codegen'd set; the custom reads (read_by_workunit, read_by_batch) generate from FK :list_by: true.
  • app and app_version keep the system-tenant union read filter as a documented exclusion: a genuine business rule (system-tenant apps are visible to every tenant) with no template feature yet. The :system_tenant_visible: template feature is the recorded candidate; report_submit_handler and registrar.cpp stay excluded as a custom flow that sits on no template output path.
  • Regeneration surfaced two pre-existing defects, fixed at source rather than worked around: the JSON-to-org migration had silently dropped the legacy entities' Table display sections (restored verbatim in the orgs), and the qt dialog/table generator mis-derived cell optionality and emitted a phantom display-name row for nameless entities (fixed in codegen/core.py). Both fixes carry to every later component in the rollout.

6. Out of scope

Emacs 29.3 (Org mode 9.6.15)