coverage: examples/common has fallen to 90.39% from the 95.85% its target was derived from, and nothing reported it

[Yaraslaut]

What is wrong

examples/common — the ladder's shared hand-written GUI and testkit code — has
fallen 5.46 points below the figure its own coverage target was derived from,
and no check said so.

codecov.yml records the measurement the target was set against:

Together these put today's real ceiling at 478/485 = 98.56% lines

and sets target: 95%, with a comment noting the component was measured at
95.85% when rungs 2-4 entered the report.

Measured on master today: 90.39%.

It is below its own target, and the status is informational: true, so the
build is green. That mechanism is morph#402; this ticket is the regression
itself, which needs finding and closing regardless of how the gate is resolved.

Why this component and not another

codecov.yml describes examples/common as carrying the whole of
examples/IMPLEMENTATION.md rule 5's promise:

The ladder's hand-written GUI/testkit code is held to the same 100% bar
examples/IMPLEMENTATION.md rule 5 sets for models (there are no rung models
yet — rung 0 ships no app — so this component is the whole of that promise
today)

It is also the component whose own file documents a 98.56% measured ceiling
with all seven artifact lines enumerated by name — backend_rig.hpp's three
switch-case closing braces, strand_interleaver.hpp's two post-task() braces,
fault_proxy.cpp's null-guard pair. A component with that level of accounting
sitting eight points under its documented ceiling means real code arrived
untested, not that the artifact set grew.

The likely shape of it

examples/common has grown since that measurement — db_busy_fixture.hpp and
backend_rig.hpp's executor-liveness guard are both named in codecov.yml as
post-measurement additions, and rungs 5-7 (ledger, lims, crm) landed after it.
Testkit code added to serve a new rung, and not itself tested, is the most
probable source. This is a hypothesis, not a finding — see below.

Verification status: reproduced (the regression), inferred (its cause)

Reproduced. Codecov API for LASTRADA-Software/morph,
/components/?branch=master: ladder → 90.39, against target: 95% in
codecov.yml on the same ref. The 95.85% and 98.56% figures are quoted from
that file's own comments.

Not verified: which files regressed. That needs a per-file comparison
against the report from the commit codecov.yml's comment was written at, and I
did not run one. The paragraph above is a hypothesis and should be tested rather
than assumed.

What would close this

1. The per-file source of the regression is identified — which files in
   examples/common are below where they were, with numbers, not a narrative.
2. examples/common is back at or above 95%, or its documented ceiling is
   re-derived with the same enumerate-every-artifact-line discipline the current
   comment uses and the target moved deliberately, with both figures recorded.
3. The seven known artifact lines are re-confirmed as still being the whole
   artifact set. If new ones appeared, they are named individually — a ceiling
   that drifts without an audit is how a target stops meaning anything.

Not closable by lowering the target to 90%. That is the move codecov.yml
already argues against for the rungs, and it would convert a regression into a
new baseline.

[Yaraslaut]

Acceptance reframed: kill named survivors, not reach a percentage

Recording a change of direction rather than editing the text above.

The first framework mutation run (morph#405) scored 64.06% against a library
already measuring 95.69% lines and 91.19% branches. That ~30-point gap is between
executed and would be noticed if it were wrong — and a percentage target is
what produced a suite sitting on the wrong side of it.

So this ticket's coverage-percentage clause is superseded. The work is now driven
by scripts/mutation_survivors.json, which names the missing assertions directly:

• morph#431 — the 255 unasserted survivors in include/morph/core, starting
  with twenty sites where the server's reply(...) can be deleted and the suite
  still passes.
• morph#432 — the 46 in include/morph/forms, mostly boundary comparisons
  exercised only away from their boundaries.

This ticket's non-percentage clauses still stand on their own and are not
superseded — the specific defect it names, the audit it asks for, and any
reachability question it raises are unaffected.

Why the change. The round that produced the measurement added 3013 lines of
tooling under scripts/, cmake/, .github/ and codecov.yml, and 130 lines
under tests/ — of which exactly one was a new test case. Coverage did not
move a point. Sequencing every measurement ticket ahead of every test-writing
ticket is a planning error, and this is the correction: infrastructure is frozen
(morph#430 moved to Backlog) until the survivors are killed.

The guard that comes with it. Do not chase the number. A mutant killed by an
assertion written to kill that mutant, on a path nobody cares about, is worse
than a survivor — it is a test with no reason to exist. Each new test must be
justifiable from the behaviour, with the survivor as evidence the assertion was
missing. Classifying a survivor as equivalent with a stated reason is a valid
outcome; the run already found 11 such.

[Yaraslaut]

Correction: the premise holds, the diagnosis in it was wrong. There was no regression.

I filed this asserting examples/common had "fallen 5.46 points below the figure
its target was derived from". The number is real and reproducible — but nothing
regressed, and the framing sent the work in the wrong direction.

The two figures were never in conflict; they are different arithmetic

llvm-cov report counts a line that executed as covered. Codecov scores
hits / (hits + misses + partials) over the uploaded LCOV, and a line whose
branch is taken only one way is a partial — counted against you. That is the
whole of the gap between the 96.06% single-object figure and the 90.39% the API
reported.

Confirmed rather than asserted: the same arithmetic reproduces codecov.yml's own
recorded framework figure to within 0.01 (93.99% computed, 93.98% recorded), so
it is the arithmetic Codecov actually uses.

And the drop is a denominator change, not a decline

Splitting examples/common by whether a file existed at the 95.85% measurement
(morph#142):

	coverage	lines
code measured then	95.78%	687
four files added since	85.02%	594

qml_surface.cpp, process_pool.hpp, journey.hpp and step_executor.hpp —
594 of 1281 lines, with qml_surface.cpp alone carrying 70 of the 118 non-hits.
The code that was at 95.85% is still at 95.78%. The denominator nearly
doubled with untested testkit, and the component average moved because of that.

So "identify the per-file source of the regression", the first clause I wrote,
was asking for something that does not exist.

Measured on the fixed pipeline

check_coverage_roots.sh: 610 files, zero foreign roots, exit 0 — morph#426's
contamination is genuinely gone, and the 2184 functions have mismatched data
warning alongside it is the count that script's own comment predicts for a
16-object run.

	old	fixed pipeline, before the work	after
examples/common, llvm-cov lines	96.06%	95.22%	96.94%
examples/common, Codecov	90.39%	90.79%	93.68%

What was actually done

13 new cases, each justified from a promise the code makes and verified by
mutating that code — 7 mutations in qml_surface.cpp, 3 in event_poller.cpp,
rebuilt between each, all killed. Two mutations were not killed and are
recorded as unreachable rather than papered over: signalNameOf's shape guards
(both callers match on[A-Z]\w*) and the no-target: skip.

examples/TESTING.md carries the audit — the two units, how to reproduce each,
the pre/post-morph#142 split, and every remaining uncovered line classified.

codecov.yml's seven documented artifact lines are still correct but are no
longer the whole set: step_executor.hpp:89 and qml_surface.cpp:599 are two
more closing-brace artifacts. And ProcessPool::killAll and
ClientProcess::waitForFinished have no caller anywhere in the tree — worth
knowing before anyone writes a test for them.