Three places, because the finding has three audiences.
The display spec's §1 table said FR-DSP-3 was unmeasured and FR-DSP-5 untagged.
Both are now false, and §2's decision rule has fired. The body of §2 is left as
written with the verdict quoted above it: a plan overtaken by its own evidence
reads better in order than quietly edited into agreement with the outcome.
TD-4 is the stage that misses the budget. Clarity's kernel is a fraction of the
frame, so it reaches a 52-pixel radius at 4K and costs 34 ms — seven times the
entire fused chain, for one slider. It is debt rather than a bug because the
detail stage cannot yet write a target smaller than it reads, which
`local_contrast`'s own documentation has said since it was written. The entry
says plainly that tiles are the wrong tool for it, since that is exactly the
conclusion a reader arriving from ARCH §5.3 would otherwise draw.
TD-5 is the one nobody was looking for: composing the fused shader costs
2.8–5.2 ms of CPU per frame on a full chain, on the UI thread, which at
1920x1200 is more than the dispatch it precedes. The source depends only on the
graph's structure — what `structure_hash` already identifies and what does not
move during a drag — so the fix is the cache `AdjustPass` already keeps for
compiled pipelines, one level up.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The status table said FR-DSP-8 was absent and §5.2 assumed Slint
reports window moves. It does not — there is no `on_moved` on any
backend — so the position is sampled instead.
§5.4 records the two trades that are worth someone finding later: a
display profile is matched to the nearest of four spaces rather than
applied through a CMM, and on Wayland the canvas follows the first
output rather than the window, because a Wayland client is never told
where its window is and the protocol's own answer needs a `wl_surface`
that Slint does not expose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>