The vello_gpu 0.3 migration is manifest-only: version pinned, GPU path never uses it, docs still cite 0.10

Источник: dev/fera-research/docs/oc2/vello-version-split-contract-verified-against-rejected-version.md (read-only; сгенерировано scripts/sync-docs.mjs)

The vello_gpu 0.3 migration is manifest-only: version pinned, GPU path never uses it, docs still cite 0.10

• kind: problem
• area: ui
• severity: high
• evidence:
  • ~/dev/fera/chroix-vello/Cargo.toml:16-20 — vello_gpu = { version = "0.3", default-features = false }, vello_cpu = { version = "0.3", ... }, wgpu = "30"
  • ~/dev/fera/chroix-vello/Cargo.lock — resolves vello_gpu 0.3.0, vello_cpu 0.3.0, vello_common 0.3.0, wgpu 30.0.1
  • ~/dev/fera/chroix-vello/src/gpu.rs:58-59 — #[allow(unused_imports)] use {vello_gpu as _, wgpu as _};
  • ~/dev/fera/chroix-vello/src/gpu.rs:67-70,84-88 — pub struct VelloGpu { _private: () }; present() returns Err(Error::GpuUnimplemented)
  • ~/dev/fera/chroix-vello/src/gpu.rs:3-6 — “Status: structural skeleton.”
  • ~/dev/fera/chroix-project/README.md:34 — “vello done on legacy 0.10 — migration to vello_gpu 0.3 next”
  • ~/dev/fera/chroix-project/CHROIX-DISPLAY-LIST.md:243 — “Verified against Vello 0.10.0 / wgpu 30 sources”
  • ~/dev/fera/fera/core/crates/ui-engine-vello/Cargo.toml:18 — vello = "0.10" (the fera reference engine)
  • ~/dev/fera/chroix-project/UI-FRAMEWORK-IDEAS-V2.md:147 — [Decided] backend MUST be vello_gpu 0.3 + vello_cpu 0.3; 0.10/0.11 “now research-only”

Sum (Суть)

Correction to an earlier oc2 finding

My first pass at this asserted that “the shipped chroix-vello backend is on the rejected line” (README.md:34). That was wrong, and I am recording the correction rather than quietly editing it. Measured directly: chroix-vello/Cargo.toml:16-20 declares vello_gpu = "0.3", vello_cpu = "0.3", wgpu = "30", and Cargo.lock resolves vello_gpu 0.3.0 / vello_cpu 0.3.0 / wgpu 30.0.1. The legacy vello crate is absent from the lockfile entirely. So the [Decided] requirement of UI-FRAMEWORK-IDEAS-V2.md:147 is met in the manifest. README.md:34 is the stale artifact — and chroix-vello/TODO.md:3-8 already corrects it, naming commit 7f94a95.

The rest of that earlier finding still holds: CHROIX-DISPLAY-LIST.md §8.1 is still verified against the version the project rejected, which is the real and remaining defect (below).

The actual finding: the migration is declarative, not operative

vello_gpu and wgpu are in the dependency graph for exactly one reason — to make them not be unused:

// chroix-vello/src/gpu.rs:58-59
#[allow(unused_imports)]
use {vello_gpu as _, wgpu as _};

and the type that would use them is an empty struct:

// chroix-vello/src/gpu.rs:67-70
#[derive(Debug, Default)]
pub struct VelloGpu { _private: () }

// chroix-vello/src/gpu.rs:84-88
fn present(&mut self, _buf: &[u8], _ctx: &mut PresentCtx) -> Result<(), Error> {
    // Intentionally not implemented. The module docs list what is
    // missing; do not call this variant in production yet.
    Err(Error::GpuUnimplemented)
}

So: the version decision is recorded in the lockfile, but no line of code rasterizes anything with vello_gpu. Only the CPU path (VelloCpu) is real. This is worse than not migrating, for one reason: the green build is now misleading. cargo test in chroix-vello passes (11 tests) with a Sparse Strips dependency tree in the lockfile, which reads as “the mandated vello_gpu 0.3 backend works”. What actually works is vello_cpu 0.3 — the CPU rasterizer. V2 §16 says the point of the pair is “One Scene API on both, swappable GPU/CPU for free” (:147); that property is entirely untested, because the GPU half is a stub.

And the docs disagree with the code, in both directions

Source	Claims	Reality
chroix-project/README.md:34	vello on legacy 0.10, migration pending	wrong — 0.3 in manifest+lock
chroix-vello/TODO.md:3-8	migration landed in 7f94a95	correct
CHROIX-DISPLAY-LIST.md:243 (§8.1)	damage verified against Vello 0.10.0	stale — but this one matters
OPTIM-RESEARCH.md:372,377	“Vello уже использует compute для path flattening”	wrong for Sparse Strips (“no compute shaders”, V2:147)

§8.1 is the load-bearing one. It is the only source-level verification of backend capability in the whole corpus, and it is the sole justification for three contract decisions:

• “Damage is a hint, not a correctness requirement” (:234-237) — keeps the headless backend trivial (:307);
• rejecting sub-scene patching (:245-248) — forces reset()+full rebuild as baseline (:249-252);
• the persistent-intermediate-texture damage mode (:258-263).

Each of these was checked against vello 0.10’s compute-based coarse/fine-mesh architecture. The shipping target is Sparse Strips — “no compute shaders” (V2:147). Those are different rasterizers, so “rebuilding a few thousand items is microseconds” (:250-251) is a claim about software that will not ship. Note §8.1’s own caveat: the damage path it describes is “an opt-in backend mode, not the baseline” (:263) — so the opt-in path is both unverified and unexercised.

There is also live drift the corpus does not track: OPTIM-RESEARCH.md:385 cites “vello_cpu 0.2 already built and working (per fera-ui-stack)”, :319 cites “Vello 0.10”, and V2:270 / DISPLAY-LIST:146 cite “Parley 0.11.1” — while the actual manifests sit at vello_cpu 0.3 and the fera reference engine at vello = "0.10" + parley = "0.11".

Options (with tradeoffs)

• A. Re-verify §8.1 against vello_gpu 0.3 before writing more spec. Cheap (read two upstream sources); fixes the only real verification in the corpus. Leaves the GPU stub stub.
• B. Make the GPU stub honest. Either finish VelloGpu or make it impossible to mistake for a working backend — a #[cfg(feature = "gpu")] gate plus a README/TODO line saying the GPU path is unimplemented. Cost: near-zero. Removes the false-confidence green build.
• C. Fix the stale docs. chroix-project/README.md:34 is simply wrong; §8.1’s citation and the research dump’s compute-shader assumptions are stale. Cost: near-zero.
• D. Do nothing — rely on chroix-vello/TODO.md to carry the truth. Cost: README.md is the doc that feeds the spec corpus, and it is the one other agents read.

Proposed solution

A + B + C — all three are cheap and they address different failure modes:

1. Re-verify §8.1 against the shipping target (A). Specifically re-answer for vello_gpu 0.3: does a retained/patchable scene exist, or is it still append-only reset()+rebuild? Is there a render_to_texture equivalent, and does it take a scissor? Is there an image-resolver/atlas equivalent to register_texture/mark_image_dirty? Does wgpu 30 expose any partial-present path?
2. Stop the manifest from implying a working GPU backend (B). Gate VelloGpu behind a feature (or delete the use … as _ pin) so a green cargo test cannot be read as “vello_gpu 0.3 works”. Whichever, the README must say the GPU path is unimplemented.
3. Correct the docs and stamp the verifications (C). Fix chroix-project/README.md:34, and give every “verified against X” claim in DISPLAY-LIST.md / OPTIM-RESEARCH.md an upstream version and commit/date. Treat “a backend upgraded” as a blocking review item for the contract — the corpus already shows the failure mode (0.2 / 0.10 / 0.3 coexisting, one of which is stale).

The contract itself is version-independent and survives this: “damage is a hint, not a correctness requirement” holds regardless of which Vello ships. So this is verification hygiene plus one misleading green build, not a schema defect — which is exactly why it is cheap now and expensive to leave until someone tunes a damage path against the wrong rasterizer’s behavior.