What happens
Booting a T-Deck under a third-party firmware (wadamesh-tdeck-merged.bin) provisions cleanly and then prints:
set name Deck Error: unknown config: name Deck
That is our provisioning speaking MeshCore's console vocabulary at a firmware that is not MeshCore. It is harmless here — the board boots, draws, and answers touch — but it is noise in the log, and it is the kind of noise that hides a real refusal next to it.
Why it matters
Provisioning is not optional decoration. provisionLinesFor sends the settings an arm or a scenario pins, and an experiment cell that silently fails to apply them compares two cells that were both configured the same way and reports no difference. On MeshCore that path is load-bearing; on a firmware that does not speak it, every line is refused and we say nothing about it.
Today the only signal is a line in the console that somebody has to read.
What to do
Let a firmware declare what console vocabulary it speaks, and act on it:
- an image imported with
firmware.import carries a dialect — meshcore, or none, or a named other
- provisioning is skipped for a firmware that does not speak MeshCore's commands, rather than sent and refused
- the node view and the board view say so, the way the board view already says a part is not modelled: an absence somebody recorded, not a gap
- an experiment or a sweep arm that pins settings onto a node whose firmware cannot take them is refused before the run, not discovered in a log afterwards
The last one is the point. Everything else is tidiness; that one is the difference between a result and a wrong result.
Where it was found
Bringing up WadaMesh on an emulated T-Deck while testing the board view (#598). The firmware works — it boots, lights its panel and responds to the touchscreen — so this is not a compatibility failure, only an unstated assumption.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6
What happens
Booting a T-Deck under a third-party firmware (
wadamesh-tdeck-merged.bin) provisions cleanly and then prints:That is our provisioning speaking MeshCore's console vocabulary at a firmware that is not MeshCore. It is harmless here — the board boots, draws, and answers touch — but it is noise in the log, and it is the kind of noise that hides a real refusal next to it.
Why it matters
Provisioning is not optional decoration.
provisionLinesForsends the settings an arm or a scenario pins, and an experiment cell that silently fails to apply them compares two cells that were both configured the same way and reports no difference. On MeshCore that path is load-bearing; on a firmware that does not speak it, every line is refused and we say nothing about it.Today the only signal is a line in the console that somebody has to read.
What to do
Let a firmware declare what console vocabulary it speaks, and act on it:
firmware.importcarries a dialect —meshcore, ornone, or a named otherThe last one is the point. Everything else is tidiness; that one is the difference between a result and a wrong result.
Where it was found
Bringing up WadaMesh on an emulated T-Deck while testing the board view (#598). The firmware works — it boots, lights its panel and responds to the touchscreen — so this is not a compatibility failure, only an unstated assumption.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6