# 260802 — challenge to CB-RES-0006

Adversarial review, one round, per InnerLoop §Step 2.

**Fidelity note, first, because it caps everything below.** The spec asks
for a *separate session or agent*. This review was run in the same session
as the survey, because this environment's standing instruction is not to
spawn agents unless asked. So it does not have the property the step exists
to provide: the reviewer inherits the author's sampling, the author's
framing, and the author's blind spots. Every prior instance of this class in
the repo — CB-WP-0002's dedup sample, CB-WP-0005's AM-7 assertion — was a
shared blind spot between author and reviewer who sampled the same way.
Treat the challenges below as a lower bound on what a genuinely separate
reviewer would find.

The claim rests on numbers, so per the table in §Step 2 the reviewer's job
is to reproduce them independently and to mutate the assertions behind
them — not to argue with the prose.

---

## C1 — The survey concluded the sub-100k region was empty without looking

**This is the challenge that lands.**

The survey measures seven candidates. The cheapest windowed one costs
480,501. It then reports the corrected headroom as 92,798 and concludes
that no windowed toolkit fits — a conclusion about the interval
`0 < x < 92,798` drawn from a sample whose smallest windowed member is
480,501. Nothing was measured in the interval the conclusion is about.

The candidate list is not random, either. It is the list a 2026 Rust
developer reaches for, which is a list of GPU-era stacks: everything on it
pulls `wgpu`, `winit`, or `rustix`. Cheap, old, thin bindings to system
libraries were structurally absent from the sample.

Measured, same method, marginal against the same base:

| candidate | marginal lines | vs 92,798 corrected headroom |
|---|---:|---:|
| `tiny-skia` alone | **83,956** | **fits**, at 90% of it |
| `fltk` | **140,079** | 1.5× |
| `sdl2` | **191,973** | 2.1× |
| `sdl3` | 276,445 | 3.0× |
| `raqote` | 286,852 | 3.1× |
| `minifb` | 774,389 | 8.3× |
| `pixels` | 863,528 | 9.3× |
| `speedy2d` | 1,328,008 | 14.3× |

**The survey's central rhetorical move — "this is not a near miss to be
negotiated; it is two orders of magnitude" — is false.** It is two orders
of magnitude for the candidates the survey chose. The real floor for a
windowed toolkit is `fltk` at 140,079, which is **1.5×** the corrected
headroom. That is exactly a near miss to be negotiated.

`tiny-skia` at 83,956 actually fits — it is a pure-Rust CPU rasterizer with
no windowing, so it is not by itself a table, but it disproves the survey's
stated interval claim on its own.

**Required:** the survey must either withdraw the "two orders of magnitude"
framing and re-argue against a 1.5× floor, or concede that its
recommendation rests on something other than dependency cost.

## C2 — "Marginal cost zero" is scored on an axis chosen to produce zero

AM-4a measures vendored third-party **Rust**. The HTML option scores zero
because it relocates the renderer into a runtime AM-4a cannot see. The
browser is tens of millions of lines of unaudited third-party code. Calling
that zero is true under the metric and false in substance.

If a proposal may satisfy a dependency target by moving the dependency
somewhere the target does not look, then the target constrains nothing, and
this pass is the first to demonstrate it. That is a worse outcome for the
project than buying `macroquad` honestly.

**And the same critique convicts C1's cheap candidates.** `sdl2` at 191,973
and `fltk` at 140,079 are thin Rust bindings to large C libraries; their
`.rs` line counts exclude the actual implementation for exactly the same
reason the browser's is excluded. So the metric already permits this move,
and the survey's own table already rewards it — it simply did not notice,
because it never measured a binding.

**Required:** one rule, applied to all three. Either relocating an
implementation into an unmeasured runtime is permissible (and then `sdl2`
and `fltk` are legitimately cheap and must be compared on their merits, not
excluded on cost), or it is not (and then HTML is not free either). The
survey cannot have it one way for the browser and another for `sdl2`
without stating the distinction. It states none.

## C3 — The survey contradicts itself on the second-use rule

Recommendation 1 declares `cb-render-api` a canonical port now.
Recommendation 4 says `cb-render-wgpu` at stage 2 is "where the port
interface gets its second use and only then becomes canonical."

Both cannot hold. INTENT: *"No concept becomes canonical merely because it
looks general. It becomes canonical after surviving a second concrete
use."* A port interface written against exactly one implementation, which
emits whole documents, will acquire a document's shape — retained mode,
full state per update, string identity, no frame timing — and stage 2 will
find it unimplementable and rewrite it. The survey names this risk in §6
and mitigates it with "write it to be implemented twice," which is a wish.
`CommitWindow` is already on record in this repo as the concept that looked
general, has a delete-by date, and has declined two second-use
opportunities.

**Required:** either defer `cb-render-api` until stage 2 supplies a second
implementation, and ship `cb-render-html` directly against the existing
`Project` trait — or state why this port is exempt from a rule INTENT
states without exception.

## C4 — The 250-line HTTP server is undersold, and "loopback only" is not a boundary

The survey bounds the risk with "listens on loopback only and speaks to a
page it emitted itself." Neither clause holds:

- Any process on the machine can reach a loopback listener. Hot-seat play
  is explicitly *several people at one machine*.
- **Any web page the user visits can reach it too.** A page on the open
  internet can issue requests to `127.0.0.1` — that is what DNS rebinding
  and cross-origin POST are. The browser running the table is the same
  browser reading the internet; that is the whole premise of the option.
- "A page it emitted itself" is an assumption the server cannot check
  unless it is written to check it, and the survey specifies no such check.

An unauthenticated loopback endpoint that accepts `POST /command` and
mutates authoritative game state is a remote-controlled game from any tab
the user has open.

**Required, as concrete controls the survey lacks:** an unguessable token
minted per process and required on every request; `Origin` and
`Sec-Fetch-Site` checked and rejected by default; the listener bound to
`127.0.0.1` explicitly rather than `0.0.0.0`; and a test that a request
without the token is refused. The last one is the one that matters — the
other three are claims until something asserts them.

## C5 — The proposal regresses the finding the previous pass paid for

CB-WP-0011's finding, in its own words: a renderer's defect class is
**silent omission**, no natural renderer assertion catches it, and the fix
is to walk the shape of the input and make silence cost a build.

This proposal moves drag hit-testing and command construction into
JavaScript embedded in emitted strings — a language `cargo test` cannot
run, `clippy` cannot lint, and `M-D1-MUT` cannot mutate. The gate that
CB-WP-0011 built stops at the language boundary, and the survey proposes
putting the interactive half of stage 1 on the far side of it, one pass
after paying to learn why that is dangerous.

§6 lists this as "the strongest argument against, and the one T02 should
press." Naming a challenge in advance is not answering it.

**Required, as controls:**
- **JS may not construct commands.** The emitted page reports raw pointer
  facts — "pointer down on element `id`, up on element `id`" — and Rust
  decides what command that is. That confines JS to input transport and
  makes the decision testable by feeding the Rust side synthetic events.
- **The coverage gate must cross the boundary.** `every_view_field_is_
  classified` must have an HTML counterpart asserting over the *parsed
  emitted document*, not over the Rust that emits it. Emitting a `<div>`
  per field is not evidence the field is visible; the assertion must be
  that the token is in the document.

## C6 — One number in the survey is reproduced; one is not independently checkable

Reproduced: the proc-macro delta. `--edges normal,no-proc-macro` gives 18
crates / 157,202 lines against 23 / 246,250. The 89,048 / 36.2% figure is
correct, and the five crates named are the five that differ.

**Not independently checkable:** every candidate figure, because the
reviewer used the author's script. Per §Step 2 this is precisely the
failure mode — "the reviewer re-derives on a different sample than the
author used" — and no different sample was used. The C1 table above is
*new* data from the same instrument, which tests the survey's coverage but
not its instrument.

**What the harness would report if it silently stopped:** `source_lines()`
returns 0 for a crate it cannot locate, and the probe scripts sum without
a positive control. A registry path change would report every candidate as
0 marginal lines — i.e. as *fitting comfortably* — which is the direction
that flatters the recommendation. `tools/dep-weight.py` has exactly this
control (`unlocatable crate measures zero (so the guard fires)`); the probe
scripts copied the measurement function and not the guard.

The `svg-emit` row in the survey's table reads `0` marginal for reasons
that are correct, but a reader cannot distinguish that 0 from a harness
that stopped. **A zero that means "costs nothing" and a zero that means
"measured nothing" are printed identically.** That is HDN, in the survey's
own instrument, in the row carrying the recommendation.

---

## Verdict

**Not approvable as written.** C1, C2, C3 and C6 each require a change to
the survey, not a clarification. C4 and C5 require controls that must land
in ADR-0007 as conditions on the implementation.

The recommendation may well survive — none of these establishes that a
windowed toolkit is affordable, only that the survey's argument for why it
is not was overstated and partly unmeasured. But the survey as written
argues from a false interval claim, an inconsistently applied metric rule,
an internal contradiction, and a zero that cannot be distinguished from a
dead harness.