
ID	0031
Class	DOCUMENTATION
Severity	1
Status	ready
Models	— (affects every new regression fixture)
Found	2026-09-22 while adding the first `Auv` regression inputs

Evidence

DEVELOPING.md, under "Test setup", tells the author of a new SimObject to give the fixture

<OBSERVERS>
   <FileOutput TOutput="0, 1, 10" Select="objects:all"/>
</OBSERVERS>

A comma-separated TOutput is an explicit list of output times, not a start, step, end range. The parser (fhsim/src/engine/io/OutputScheduleParser.h) spells the range form with colons: start:delta:end, with :delta: and start:delta:Inf as the open variants. So the suggested value asks for output at t = 0 s, 1 s and 10 s — three rows — where the reader plainly intends "every second from 0 to 10".

The wording invites the misreading: the three numbers look like a triple, and 0/1/10 is exactly what a start, step, end triple for that interval would be.

Effect

A new regression baseline recorded from that fixture contains three samples. It passes, and it keeps passing, while testing almost nothing: a model can change its entire trajectory between the sampled instants and the case stays green. Because the recorded file looks correct, nothing prompts the author to re-check. Every SimObject added by following this checklist inherits the problem.

Possible fix

Change the example to the range form and name the distinction, e.g.

and add one sentence: "a comma-separated `TOutput` is a list of explicit times; use `start:delta:end` for a regular interval." Worth also mentioning :delta: for "every delta over the whole run", which is what most fixtures want.

Test that would prove it

Run any existing fixture whose TOutput uses commas and count the rows in tests/out/<Name>/<Name>_res.txt; it equals the number of comma-separated values rather than the number of intervals. Audit the committed baselines under tests/in/*/ for files with suspiciously few rows.

Risk

Fixing the documentation is free. Re-recording any existing baseline that was made with the comma form changes that baseline, and should be done one case at a time so that a genuine behaviour change is not hidden inside a resolution-increase commit.