`test_the_marker_is_read_from_the_PARSED_yaml_not_a_text_search` claimed to guard the parser
against regressing to a grep. It asserted only that every tracked job appears as a KEY, so a
reader returning the right keys with wrong VALUES satisfied it — the claim was stronger than the
code. Cold review found it; the same round found the sibling test making the same over-claim, and
that one is now fixed by driving the real reader.
Renamed to what it proves (`test_every_tracked_job_APPEARS_in_the_parse`), with the grep-regression
claim moved to `test_a_commented_out_marker_does_NOT_count`, which actually drives the reader.
Added the property a completeness check structurally cannot express: ATTRIBUTION. A marker belongs
to the job whose `env:` block contains it. A line-oriented reader that attached each
`CI_JOB_ROLE:` to the nearest preceding job header would smear one job's marker onto a neighbour
declaring none, and both jobs still have keys, so nothing phrased over keys can see it. The fixture
is two jobs, only the second marked.
Witnessed, and the control matters: the smearing reader used to demonstrate it is byte-identical
to the real `declared_roles()` on the current tree —
faithful on the real tree? True
REDDENED: the reader attributed a marker to the wrong job — `first` declares none and must
read as None, `second` declares one and must read as its value
— so it satisfies every population and completeness assertion in the file, and only the new
fixture separates them.
Refs #786
timothy
003a13574d