Task: Mark generated C++ files as generated

Table of Contents

This page documents a task in the Redesign ores.trading on data-oriented principles story. It captures the goal, current status, acceptance, and any notes or results.

1. Goal

A generated C++ file says it is generated and names the template that produced it, as the generated SQL already does.

2. Status

Field Value
State DONE
Parent story Redesign ores.trading on data-oriented principles
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-17

3. Acceptance

  • Every generated C++ header and implementation carries the AUTO-GENERATED marker naming its template.
  • The marker is emitted at the render seam, so no template needs editing and a new C++ template gets it for free.
  • The marker reaches no output that is not C++, even where the template carries the C++ licence.
  • The nine drift-free components regenerate clean, and the drift gate passes.

4. Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

5. Notes

6. Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

7. PRs

PR Title
#2087 [codegen] Mark generated C++ files as generated

8. Review

Round 1, PR #2087. The review found no correctness issues and approved pending the full build.

# Comment summary File Decision Notes
1 No unit test for the new helpers; the drift gate checks stability, not correctness core.py Accept Correct, and the reason matters: the gate stays green if the marker stops being emitted and the tree is regenerated to match. Seven tests added in test_generated_marker.py.
2 _emits_cpp is defined after its caller core.py Accept Moved above render_template.

9. Result

Every generated C++ header and implementation now opens with the AUTO-GENERATED block naming the template that produced it, matching what the generated SQL has always carried.

The marker is emitted at the render seam in core.py rather than by each template. All seventy C++ templates share the cpp_license variable and all emit .hpp or .cpp, so one insertion point covers every one, names the actual template per file, and gives a new C++ template the marker without anyone remembering to add it. _emits_cpp keeps it out of any output that is not C++.

Acceptance, against the four bullets:

  • The marker reaches every generated C++ file in the nine drift-free components: 3557 files, each +5 -0, nothing deleted.
  • It is emitted at the render seam, so no template was edited.
  • The guard excludes no template today, since every template carrying the C++ licence emits C++. It is pinned by test against a synthetic template so the intent survives the template that does not yet exist.
  • The drift gate passes across all nine registry components.

Verified: full build passed, run by the author. Codegen suite 202 passed, compass suite 164 passed and 1 skipped, drift gate clean, and an audit confirming the diff adds only the marker block.

9.1. What this does not cover

The nine components outside the drift-free registry keep unmarked generated C++, because regenerating them would drag pre-existing drift into the diff. ores.trading is the one that prompted this work; it gains its markers through the instrument-identity collapse, which regenerates the component anyway.

9.2. What it found

Regenerating ores.trading to test the change surfaced a hand-edited generated file: ascot_table.cpp in the tree lacks a [[maybe_unused]] the template emits. That is the failure the marker exists to prevent, found by looking for it.

Emacs 29.3 (Org mode 9.6.15)