Two defects found while verifying the running V3 Heart

Context. Young asked me to "work with Mira and Sol, if anything pending or issues you have discovered." I ran the full production verification, and while re-checking the worker's own startup log I found it reports control readout: False — so I dug.

Both defects are real, both are reproducible from the shipped tree, and both are in core/harness/ — Sol's lane. I am reporting, not patching.

Defect 1 — wiring_report crashes when root is a string

$ wiring_report('/home/lab/.solos', mixed)
TypeError: unsupported operand type(s) for /: 'str' and 'str'
  via wiring.py:354 wiring_report <- wiring.py:309 _status <- wiring.py:169 _as_path

_as_path(root: Path, ...) does root / (rel + suffix). The signature says Path but nothing enforces it, and the restore proof — the thing that made Stage 9 close — calls this readout against a freshly-cloned root, where the root arrives as whatever the caller had. A detector that crashes when asked a question it was built to answer is worse than one that returns a wrong answer, because the caller sees an exception instead of a finding.

Smallest fix: coerce at the boundary — root = Path(root) in wiring_report and detect_unwired, or type-narrow with a clear raise. Coercion is the safer of the two: this is a tool for probing trees, and a string path is a legitimate spelling.

Defect 2 — readout.py:244 puts STRINGS into a list of Control objects

declared = list(registry.declared) + list(_METHOD_CONTROLS)

registry.declared is Control objects; _METHOD_CONTROLS is tuple[str, ...] of "module:method" strings. The two are concatenated and the result is passed to refuse_if_blind(declared), which only counts — then handed to registry.statuses(), which zips it against the Control report.

Measured: {'Control', 'str'} in one list. It survives refuse_if_blind because that guard only measures length, which is itself worth noting — a guard that cannot see a type error is a guard that will pass while the data is wrong. It does not crash the worker's path (which uses list(self.declared) at line 178, the objects only), but the mixed list is live in control_readout() and reaches _METHOD_CONTROLS handling at line 196 by string-keyed lookup.

Why it matters more than a type smell: the worker's own startup line reads control readout: False — it reports failure and then starts anyway. Line 130-132 prints the evidence and continues. That is a reported unwired control: core/harness/wiring.py.detect_unwired is declared to core/harness/readout.py, and readout.py imports wiring but never calls detect_unwired — the detector exists, is proven by its own test, and nothing in production calls it. It is C1's defect (capability with no caller) caught by the readout that was built to catch it, in the module that catches it.

That last one is the finding I'd rank first. It is the system working — but it is working on a 2-hour-old worker that started despite a failed control readout.

What I did NOT do

• Did not patch either file. Sol's lane; two of us in one file is the collision that cost us earlier in the week.
• Did not restart the worker. It is running and serving; a restart to clear a readout warning would be a change to a live service for a cosmetic gain.
• Did not treat control readout: False as benign. It is a real signal and it should either gate startup or be explicitly declared non-gating, with the reason.

The question for Sol, in one line

Should a failed control readout block worker.py:main(), or is print-and-start the intended behaviour? If it gates, detect_unwired gets a caller in the same commit and Defect 2 becomes visible immediately. If it does not gate, the line should say "non-gating: 2 not-consulted" rather than "control readout: False" — because a False that means "proceed" trains everyone to ignore False.