Wire the canvas to the engine

Press Run and the page posts its graph to the session server and draws what
comes back. Change a parameter and run again and the numbers move because
the physics moved: set the fiber to 200 km and the received power drops by
exactly the 24 dB the extra loss costs, while the constellation collapses,
because the compensator is still set for the old span.

The canvas now draws the project document itself. The blocks, wires and
parameter values are no longer written into the page -- they are read from
the same `.maiman` document the server accepts, exported from the graph that
produced the reference numbers, and Run posts that object straight back. The
picture on the canvas, the values in the inspector and the graph the engine
executes are one description instead of three kept in step by hand. The
hand-written copy that used to live in the page had already drifted: it was
missing four of the fiber's parameters, added two commits ago.

Wire colours come from the manifest of the block a wire leaves, so one
cannot be drawn the wrong colour. Block captions come from the block's own
parameters, so editing a value changes what the canvas says, and a
measurement block shows its last reading or "--" rather than a number
someone typed once.

The inspector's fields were previously wired to nothing: typing in one
changed the pixels and no more, which is why it accepted 128 for a field
whose own label said "range 1 ... 8". They now write into the document, and
out-of-range input is marked. Validation lives in both places on purpose:
the engine's is the one that must be right, and this one exists so a typo is
answered where it was made. When they disagree the engine wins -- PRBS order
12 is inside the declared range 7...31, so only the engine knows it is not a
maximal-length polynomial, and its message arrives verbatim with the valid
orders listed.

Three states the page could not previously have, because it never called
anything: running, failed, and stale. A failure names its kind from the
status the server chose and opens the log. A graph edited since the last run
marks the dock stale rather than leaving numbers on screen that answer a
question no longer being asked -- reference, live and stale are three
different things and a plot from four days ago must not look like one from
the last click.

Served, the palette is fetched from the engine that is actually running, so
a component from a plugin appears without rebuilding this file. Opened from
disk it falls back to the bundled reference and says so instead of animating
a progress bar for something that is not going to happen.

tests/test_studio.py guards the page's claims from the file: that its
embedded data matches the export, that the schematic is a graph that runs,
that the numbers printed beside the plots are reproducible from it, and that
every block has somewhere to be drawn. This is not hypothetical -- the stale
copy bit twice today, once carrying a palette two components short and once
missing the project document entirely, and nothing noticed either time.
5 sabotages, 5 caught, each by the intended test.

Two bugs found by using it. The dispersion diagnostic is held in s/m and
read in ps/nm, a factor of 1e3 rather than one of the usual ones, and the
page printed "1 ps/nm removed" for a compensator set to 1360; the encoder
now sends both and a test pins them. And a TypeError thrown while rendering
a result that had arrived perfectly well was reported as "session server
unreachable", which sends whoever reads it to look in the wrong place.

Not an editor yet. Blocks cannot be added, deleted, moved or rewired -- that
is the React Flow work, and the empty state arrives with it rather than
before it.

625 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: ehsun-sh

DESIGN.md

@@ -258,9 +258,13 @@ Two findings worth keeping:
   and a schematic nobody can read is not a better demonstration. At 17 blocks
   the current graph is already close to that ceiling.
 - No motion beyond the run pulse and the control transitions.
-- No empty, loading or error states. The session server now produces all three —
-  a run that is still going, a graph that will not run, a component the server
-  does not know — but the page does not yet call it, so nothing here reacts to
-  them. Designing those states is part of wiring the canvas to the API, not
-  ahead of it: the server's own error vocabulary (400 unreadable, 422 readable
-  but unrunnable, 413 too large) is what they have to render.
+- The running, failed and stale states are now real, because the page calls the
+  engine. A run in flight dims the canvas and swaps Run for Stop; a failure
+  turns the engine dot red, names the kind of failure from the status the
+  server chose (400 unreadable, 422 readable but unrunnable, 413 too large) and
+  opens the log with the engine's own message in it; a graph edited since the
+  last run marks the results dock stale rather than leaving numbers on screen
+  that answer a question no longer being asked.
+- What is still missing is the *empty* state, because there is no way yet to
+  empty the canvas — blocks cannot be added or deleted. It arrives with the
+  editing, not before it.

README.md

@@ -35,9 +35,9 @@ link in this simulator descends from.*
 > each channel's phase at twice the rate its own does, sliding past under walk-off derived from
 > the dispersion — and triplets of channels mix to put light where nobody launched it.
 >
-> The session server is in: `python -m maiman.server` puts the engine behind an HTTP API and a
-> browser can build a link, post it, and get real numbers back. What is still missing is the
-> editor — the canvas that lets you draw the graph instead of describing it. See the
+> The interface runs: `python -m maiman.server`, open the page, press Run, and the numbers come
+> from the engine. What is still missing is the *editing* — the canvas draws a fixed schematic,
+> so you can change what a block does but not which blocks there are. See the
 > [roadmap](#roadmap).
 >
 > This is not yet a useful simulator. It is a foundation with the expensive decisions made and
@@ -48,18 +48,34 @@ link in this simulator descends from.*
 
 ## The interface
 
-**The engine is behind an API; the canvas is not wired to it yet.** The schematic, the component
-palette, the parameter panel and every number in the results dock come from a real engine run,
-exported by [`examples/export_ui_data.py`](examples/export_ui_data.py). What has changed is that
-those numbers no longer have to be exported ahead of time — see
-[the session server](#the-session-server) below. What has not changed is the page: it still draws
-one fixed schematic, and making it an editor is the next piece of work.
+**It runs.**
 
     python -m maiman.server
 
-serves it at `http://127.0.0.1:8765/`, or open
-[`docs/ui-mockup.html`](docs/ui-mockup.html) directly to click through it. See
-[DESIGN.md](DESIGN.md) for why it looks like this.
+then open `http://127.0.0.1:8765/`. Press Run and the page posts its graph to the engine and draws
+what comes back: the constellation, the measurements, the block captions, and a log in which every
+line is a fact from the response. Change a parameter in the inspector and run again, and the
+numbers move because the physics moved — set the fiber to 200 km and the received power drops by
+exactly the 24 dB the extra loss costs, while the constellation collapses, because the dispersion
+compensator is still set for the old span.
+
+**The canvas draws the project document itself.** The blocks, the wires and the parameter values
+are not written into the page. They are read from the same `.maiman` document the server accepts,
+exported from the graph that produced the reference numbers, and Run posts that object straight
+back. So the picture on the canvas, the values in the inspector and the graph the engine executes
+are one description instead of three kept in agreement by hand — the hand-written copy that used
+to live in the page had already drifted, and was missing four of the fiber's parameters.
+
+**What it is not yet: an editor.** You can select a block, change its parameters and run. You
+cannot add a block, delete one, move one, or draw a wire — the canvas is still a fixed schematic.
+That is the React Flow work, and it is the next piece.
+
+The page also still opens straight off disk with nothing running, which is how it should be read
+if you only want to look. It says which mode it is in rather than leaving it to be inferred: a
+badge in the results dock reads **live** when the numbers came from this session's last run,
+**stale — graph edited** when the graph has changed since, and **reference** when they came from
+the run baked into the file. Numbers from four days ago and numbers from the last click must never
+look alike. See [DESIGN.md](DESIGN.md) for why the rest of it looks like this.
 
 ![The Maiman Studio schematic editor on its paper ground](docs/images/studio-paper.png)
 
@@ -639,7 +655,7 @@ time window, and results are reproducible.
 | **1 — MVP: linear link** *(essentially done)* | ✅ PRBS → NRZ → laser → MZM → fiber (α + CD) → PIN → filter → eye/Q/BER, validated end to end. **Python only, no GUI.** | ~2–3 months |
 | **1.5 — Nonlinear & amplified** ✅ | Adaptive-step SSFM, Kerr, EDFA with ASE, OSNR, PMD, APD | ~2 months |
 | **2 — Coherent transceiver** ✅ | Gray-coded M-QAM to 256, IQ modulator with bias and quadrature error, 90° hybrid, balanced detection, blind carrier phase recovery, dual polarization with a blind butterfly equaliser, root-raised-cosine shaping and matched filtering, differential quadrant encoding, receiver-side dispersion compensation over spans to 1000 km, EVM/MER, constellation diagram, validated against closed-form SER | ~3 months |
-| **3 — GUI & WDM** | ✅ Wavelength-selective filters, an OSA, coupled-channel propagation (XPM with walk-off, FWM), and the session server. React Flow graph editor · 400G/800G references, CuPy back-end | ~6 months |
+| **3 — GUI & WDM** | ✅ Wavelength-selective filters, an OSA, coupled-channel propagation (XPM with walk-off, FWM), the session server, and a browser that runs the graph and edits its parameters. React Flow canvas — add, wire and move blocks · 400G/800G references, CuPy back-end | ~6 months |
 | **4 — PIC** | Waveguides, ring resonators, MMI, MZI via integration with an existing S-matrix solver; PDK import | — |
 
 ¹ One developer, part-time. Estimates, not commitments.