Expand description
The signal graph a devtools panel draws, as JSON.
docs/08-roadmap.md Phase 3 asks for a devtools view of “the
signal graph, patch traffic and pending state”. Two of those three are the client’s own and are
measured where they happen (crate::PATCH_CLIENT); this is the third, and it is the only one
the browser cannot know, because the signal graph is a fact about the program and a Mode A
client is never sent one.
§It is a projection, not a second account
Everything here is read off the running program: the declared signals and their edges come from
[beck_core::graph], the maintained/recomputed verdict from [beck_core::incremental] — which
is what beck explain incremental prints — and the operator counts from the plan the engine
executes. Nothing is recomputed for the panel and nothing is stored for it, so a panel cannot
describe a program this process is not running. That is
docs/23’s argument for the read
models applied to a third kind of reader: the cheapest way for a view of a thing to be right is
for it to be the thing.
§What it does not carry
No source, no Core, no types, no state. A panel says what the shape of the program is and how
its view is maintained; it is not a debugger and it does not put the accumulator on the wire —
which is the one thing here that would be a disclosure, since a Mode A page is precisely the
part of the state its viewer is allowed to see.