Story: Component architecture audit: first run on the drift-free components

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

Run the recurring component architecture audit on the four drift-free components: ores.refdata, ores.dq, ores.iam, and ores.compute. Each run applies the checklist, records the gaps, and fixes the mechanical ones. The method itself becomes a reusable checklist document with tooling behind it, so every later component runs the same checks.

2. Status

Field Value
State DONE
Parent sprint Sprint 25
Now Nothing.
Waiting on Nothing.
Next Review and merge the branch.
Last touched 2026-09-07

3. Acceptance

  • The checklist document exists with 15 items and the triage rules.
  • All four components ran the full checklist, one at a time.
  • Mechanical gaps are fixed and committed on the branch.
  • The lizard complexity measure ran per component with one canonical invocation, and its output is recorded.
  • The audit record of the last component sits in the component overview of ores.compute.

4. Tasks

Task State Start End Description
Run the audit on the four drift-free components DONE 2026-09-06 2026-09-07 First run of the component architecture audit: checklist document, tooling extensions, per-component gap records, and the compute job lifecycle documentation. Branch: feature/component-architecture-checklist.

5. Decisions

  • No compass command for lizard. The checklist document fixes the canonical invocation. A subcommand waits until the audit is a standing program with a second caller.

6. Out of scope

  • Non-mechanical refactors and comment overhauls at template level. The audit records them as findings for a later pass.
  • The ores.marketdata client-part registration gap, recorded for a later audit.

7. Result

Status at close: All four audits are done. The branch carries the records for review.

Emacs 29.3 (Org mode 9.6.15)