feat(check): allow a number-typed template hole as a pixel arbitrary value

[SunkenInTime]

Stacked on #78 (shares the capture smoke). Merge #78 first; this PR's base then moves to master.

What

weaver check requires every class to resolve to at most 32 literal strings so it can validate every utility before the widget runs. A width computed from data had no route, and the error named the cap and nothing else. In the render-loop cadence experiment, all twenty agents building the same progress bar needed exactly this and produced six workarounds: <canvas> (14), 21-branch ternary ladders (3), a fraction table, a gradient hard stop, a tick meter.

This adds the one dynamic shape that keeps static validation intact: a number-typed template hole as the number of a pixel arbitrary value.

<stack class={`w-[${sessions * 14}px] h-full rounded-full bg-[#5eead4]`} />

• The utility prefix (w-[) and suffix (px]) are literal, so check still knows the utility and validates it with a placeholder number.
• The hole must be typed number by TypeScript. Check already built a program for the media-capability check; it is now built once per project and shared, so there is no second type-check pass.
• The number is validated by the same class compiler at runtime, once per change to the class string. Measured cost in isolation: 1000 distinct dynamic class strings compile in 6 ms. A negative, non-finite, or non-numeric value throws the existing UtilityError and fails the widget onto its error surface.
• A string-typed hole, a hole spanning a whole utility, a color, or a percentage is rejected with a message naming the rule. Both that message and the generic cap message now name the three routes: pixel hole, fraction utility, <canvas>.

Contract gains an amendment describing the rule.

Receipts

• CLI tests: accepted w-[${sessions * 14}px] with a useState<number>; rejected string hole, whole-utility hole, percent hole, each asserting the specific message and the routes sentence. Existing "must resolve to at most 32" tests unchanged and passing.
• Capture smoke fixture test/fixtures/class-hole: the fill's snapshot bounds are 0x8 initially and 42x8 after three clicks on "Log" through test/capture/log-three.actions, and the accent pixel count rises.
• npm test 119 passed. npm run test:capture passed.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[greptile-apps]

Greptile Summary

This change allows widget class templates to use a number-typed interpolation for the numeric portion of a static pixel utility, such as w-[${value}px]. The CLI accepted the supported numeric form and rejected malformed utility shells plus string, unknown, and boolean values.

The class-hole capture fixture cannot render on the available Linux null backend: both the initial state and the three-click state stop with UnsupportedViewKind before a frame or accessibility snapshot is produced. The required visual confirmation that width changes from 0px to 42px is therefore not available here.

T-Rex validation blocked

A supported native rendering backend is unavailable in this environment. The available Linux null backend was built and retried, but it reports UnsupportedViewKind before rendering the fixture. Run the existing baseline and three-click class-hole captures on a supported macOS or Windows backend before merging. Configure VMs

Confidence Score: 3/5

The CLI boundary is verified, but merge safety depends on confirming the rendered state update on a supported native backend.

Temporary fixtures exercised successful numeric validation and rejection of malformed and non-numeric forms. The visual regression fixture could not produce either baseline or post-click output because rendering stopped with UnsupportedViewKind before creating UI nodes or commands.

Files Needing Attention: Verify test/fixtures/class-hole/widget.tsx, test/capture-smoke.mjs, and the native runtime capture path on a supported macOS or Windows backend.

T-Rex Logs

What T-Rex did

• Rebuilt the CLI in an isolated repository copy and verified that a valid number-typed w-[${value}px] fixture passes validation, while a malformed dynamic utility shell fails before runtime, and no tracked repository files were modified.
• Located the pixel-hole validator and its TypeScript number-type oracle, and verified that a numeric-state fixture passes CLI validation while equivalent string, unknown, and boolean fixtures are rejected with the required number-typed-expression diagnostic.
• T-Rex produced proof for a posted P1 finding and linked to the corresponding review comment for details.
• Validated specific runs: the acceptance command completed with weaver check passed (exit 0) and the malformed-shell run failed with a validation error at widget.tsx:12:16 (exit 1), with the corresponding build and repository-integrity logs captured.
• Encountered a UI proof block; the initial captures reported UnsupportedViewKind with no nodes or commands and zero width/height; after building a local runtime and retrying, the runtime reached but did not render the target widget, with no tracked repository files changed and several untracked runtime outputs produced.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Class-hole capture fixture cannot render on the Linux null backend

   • Bug
     • Both the baseline capture and the capture containing three Log clicks fail with UnsupportedViewKind before a rendered frame or snapshot is produced. Therefore the required 0px-to-42px rendered-width observation cannot be made in this environment.
   • Cause
     • The available verification host is Linux; after building runtime/zig-out/bin/weaver-widget using -Dplatform=null, the runtime rejects a view kind required by the fixture. The capture receipts show zero rendered nodes and commands.
   • Fix
     • Run the same two capture commands on a supported macOS or Windows runtime backend, or make the Linux verification backend capable of rendering the view kind used by this native widget fixture. Then inspect the generated class-hole-01-before.snapshot.txt and class-hole-02-after.snapshot.txt for 0x8 and 42x8 respectively.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "feat(check): allow a number-typed templa..." | Re-trigger Greptile}

[greptile-apps]

Class-hole fixture cannot render

The capture fixture that is meant to prove w-[${sessions * 14}px] updates after interaction does not render on the available Linux null backend. Both the baseline capture and the three-click capture fail with UnsupportedViewKind before emitting a frame or accessibility snapshot, so the expected 0px-to-42px width transition is not covered by an executable regression check in this environment.

_{Ran code and verified through T-Rex}

[SunkenInTime]

Re the Greptile P1: the block is T-Rex's Linux host, not the fixture. The null platform reports UnsupportedViewKind for every native widget capture, so no capture fixture in this repo can render there. On a supported backend the fixture produces exactly the two states the review asks for.

Receipts on this commit (f301c2d), macOS headless capture, Weaver 957baf4 base + this change, Native SDK 464ff65f:

• initial: role=group name="" bounds=(12,12 0x8) for the fill
• after three Log clicks via test/capture/log-three.actions: role=group name="" bounds=(12,12 42x8), and the accent pixel count rises

npm run test:capture passes with those assertions included, and the macOS headless (apple-silicon) job on this PR is green.