fix: refuse a deck that nothing drives, instead of reporting its zeros

[dc0sk]

The defect

With no EX card the Hallén system is homogeneous and solves to the zero vector. All four frontends solved it; they split on what they did with the answer, and that split is why the check belongs in none of them.

$ fnec no-ex.nec        # geometry + FR, no EX
warning: [validator] deck has no EX card — no feedpoint impedance will be computed
...
CURRENTS
TAG SEG I_RE I_IM I_MAG I_PHASE
1 1 0.000000e0 0.000000e0 0.000000e0 0.0000
...                                              (51 rows)
diag: ... abs_res=0.000000e0 rel_res=0.000000e0
$ echo $?
0

A flat response, advertised as perfect convergence. With an RP card it also printed a RADIATION_PATTERN of -999.9900 rows.

frontend	before
CLI	printed the zeros, exit 0
GUI (currents / pattern)	drew the zeros as a coloured overlay, no caveat at all
worker, fnec_py	refused — but after the wasted solve, and with the wrong reason: "no driven feedpoint (EX voltage source) found in deck", the sentence a plane-wave receive deck gets

The GUI had nothing to check with: the only no-EX test in the tree was a NoExCardValidator declared inside the CLI's own main (FND-145).

Why the check is where it is

In validate::pre_solve_error — the gate all four frontends call. That placement is the fix, not an implementation detail.

The obvious spot is the Hallén RHS builders, since that is where the zero vector is born. That guard would have been inert for --solver pulse and --solver continuity, which drive off build_excitation instead:

mode	before	after
hallen	exit 0, 51 zero rows	exit 1, 0 bytes
pulse	exit 0, 51 zero rows	exit 1, 0 bytes
continuity	exit 0, 51 zero rows	exit 1, 0 bytes
sinusoidal	exit 0, 51 zero rows	exit 1, 0 bytes
mpie	exit 1	exit 1

The "after" column is now a standing gate, not a hand measurement: the CLI test parses the --solver <a|b|c> alternation out of the binary's own usage line and sweeps it against both output formats. There was no enum to sweep — SolverMode is pub(super) with no ALL, and SolverKind::ALL has two members rather than five. That split is logged as FND-148.

Breaking, deliberately

docs/json-output-schema.md documented [] and exit 0 for this deck under "Absence of feedpoint data" — not under that file's "Stability guarantee" section, which covers the field set. Documented rather than guaranteed; consumers relied on it either way. stdout now carries nothing at all — not [].

Measured consequence: a deck with neither EX nor FR also goes exit 0 → exit 1, since validators run ahead of the FR check. A deck with EX but no FR is unchanged at exit 0 / 0 bytes — that is FND-084, still open.

fnec diverges from nec2c conditionally: given an undriven deck with an execute card, nec2c exits 0 and prints a zero currents table; with an RP it prints -nan gains rather than a floor value; with neither it never executes.

Sabotage, in three parts

sabotage	result
drop the check from pre_solve_error	GUI, worker and nec_solver tests fail — every CLI test still passes
demote the CLI validator to a warning	the CLI's own test fails
both	deck_validator.rs fails; all three controls stay green

The first row is the interesting one. The CLI keeps a second route through its own validator, so a CLI-only suite would certify a fix that left three frontends broken — the same shape as the original bug. That blind spot is written into the test's doc comment rather than left for the next reader to rediscover.

Ledger

• FND-145 new, fixed here.
• FND-112 closed by measurement, credited to fix: remediate the 2026-08-28 audit — 10 findings closed, 8 opened #432 (4e7170f) which actually fixed it — re-measured at max_ma=1.232144e0 and +2.147 dBi against the audit's 0e0 and −999.99 floor.
• FND-108 re-scoped — its central grep claim is now false.
• FND-146 / 147 / 148 / 149 recorded, not fixed.
• FND-070 / FND-084 NOT closed — the no-FR case, re-measured today at exit 0 / 0 bytes.

Review

Design reviewed before any code was written, which caught the inert-guard placement above. The diff was then reviewed and returned 14 defects, several of them false claims in my own prose — including "every frontend reported that zero" (false for two), a comment asserting the new fnec_py Rust test runs in CI (it does not; that crate is outside the workspace), an "O(N²) fill" the validator never saves, and a reversed account of why a fixture changed. All corrected here, and the rewrite of json-output-schema.md no longer re-asserts the false general claim that FND-084 exists to correct.

Also carries the ### Fixed changelog entry for #448's FND-142, which that PR landed without.

🤖 Generated with Claude Code

https://claude.ai/code/session_018p7FxX7QMWNJVNp9LbaLkB