Two families were the weak points: FR-DSP at 37%, which is the architecture's
central performance claim, and FR-PLG at zero. They are one document because
the same property decides both — the pipeline composes its work from
declarations, which is why the display path is fast and is also, already, most
of a plugin format.
Two findings change the size of the job.
**Some of FR-DSP is done and untagged.** Zoom already meets FR-DSP-5: the
sampled region shrinks while the render target keeps its size, so zooming
raises the resolution the pipeline works at — arrived at without tiles.
**FR-DSP-2 may not be worth satisfying as written.** It predates the fused
shader and assumes a chain of passes over a large buffer, where recomputing
per frame is ruinous and tiles are the way out. What exists composes every
active operation into one dispatch over a viewport-sized target. So the spec
fixes three measurements and a decision rule *in advance*: if a frame sits
inside budget at the 99th percentile, the requirement is rewritten rather than
implemented, and tiling becomes what it actually is here — a scheduling
concern for export, which already runs off the frame path. Writing a tile
scheduler the design does not need would be the most expensive way to find
that out.
**The plugin format already exists**, resolved at build time: `ops/*.yaml`
through `build.rs` produces something indistinguishable from a hand-written
operation, and everything it produces is data plus a WGSL string. The blocker
is one line — `descriptor()` returns `&'static` — and the rest is an
interpreter over declarations, load-time WGSL validation, and namespaced ids,
because the sidecar stores parameters by id and a collision is a wrong edit
silently applied.
Recorded last and deliberately: traceability counts a tag, not a behaviour.
`FR-DEV-8` is tagged against plumbing a future spot-removal op would use and
`FR-DEV-7` against a history row for a frontend that does not exist, so 51% is
an overstatement of unknown size. Every requirement this plan closes should be
closed by a test that fails if the behaviour is removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
