Story: DQ/Refdata service boundary cleanup

Table of Contents

This page documents a story in Product backlog — inbox, carried unfinished from Sprint 24 at close. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

1. Goal

ores.dq bundle publication currently writes directly to ores_refdata_* tables, crossing the service boundary. Route it via refdata.v1.* NATS endpoints instead, so ores.refdata remains the sole owner of its schema and RLS enforcement stays correct. See "Open Questions" in the three-level provisioning plan.

2. Status

Field Value
State BACKLOG
Carried from Sprint 24 (unfinished at close)
Now Not yet started.
Waiting on Nothing.
Next Break the story into tasks.
Last touched 2026-07-11

3. Acceptance

  • No code path in ores.dq's bundle publication pipeline writes directly to ores_refdata_* tables; all such writes go through refdata.v1.* NATS endpoints.
  • Any refdata.v1.* endpoint DQ needs but doesn't yet have is added to ores.refdata.
  • Bundle publish works end-to-end after the refactor (manual or scripted verification).
  • ores.dq's CMake no longer depends on ores_refdata_* table includes/headers.

4. Tasks

Task State Start End Description
         

Planned tasks (not yet scaffolded as task docs):

  1. Identify all direct ores_refdata_* writes inside ores.dq publication pipeline.
  2. Add any missing refdata.v1.* NATS endpoints needed by DQ.
  3. Rewrite DQ publication to use NATS calls instead of direct DB writes.
  4. Verify bundle publish end-to-end after the refactor.
  5. Remove cross-schema table includes from ores.dq CMake deps.

5. Decisions

6. Out of scope

Emacs 29.3 (Org mode 9.6.15)