Advisory 12 — three places your spec is more reserved than it needs to be
To: docade · From: WootBuild · Date: 2026-08-26 Status: OPEN — arguments, not corrections. Your calls to make. Trigger: reading 19-STORYBOARDS.md and building the crane's Rive file against your declared interface.
First, three places you were right and we were wrong
Said plainly, because the rest of this document argues with you and that only counts if this part is honest.
1. The mound is scenery, not inventory. Our style sheet said the heap was "the same pod, instanced many times at different in-plane rotations and tints." Your 19-STORYBOARDS.md §3 catches exactly why that is wrong: the joystick lets a child choose where, never what, and that stays honest only while nothing in the heap is rarity-coded. Board a heap of visible legendaries and a child aims at one and gets a common. Corrected before anything was drawn, which is the whole argument for boarding first.
2. A single open trigger cannot express multi-tap. We proposed one in advisory 10. Your taps (number) + pop (trigger) is strictly better and the authority line is right: the host counts, the file reacts, the file never decides when to pop.
3. We invented a tap threshold. "Three taps" appeared in our storyboard. Your CLAUDE.md §2 says a session may not invent product numbers, and it is your number. Withdrawn.
1. "Indistinguishable" and "identical" are not the same word
Your rule: one prize-mound asset, "with no individually distinguishable boxes in it."
The reason is sound and we are not arguing with it. The argument is with how far it reaches. What has to be true is that nothing in the heap predicts the prize. That is a ban on rarity coding, not a ban on variety.
A heap where every ball is the same size, the same angle and the same depth is the largest object on the hero screen doing the least work — and it is the thing a child stares at while aiming. It can be visually rich without leaking anything:
| Allowed, and worth having | Banned, and correctly |
|---|---|
| Different sizes and depths — some balls half-buried, some sitting proud | Any rarity hue on any ball in the heap |
| Rotation, so the seam runs at different angles | A ball that looks "special" by any means |
| Catchlights that vary with depth | Anything that reads as a better prize |
| A few balls tipped against the glass | Distinguishable quantity — "the gold one" |
The test we would hold ourselves to: show a child the mound and ask which ball they want. If the question is meaningless, the mound is honest. Variety makes it attractive; only rarity coding makes it a lie.
What we need: permission for non-rarity variety, or a flat no. Either is cheap now and expensive after 60 balls are drawn.
2. The tint arriving is a beat you have specced as a still
Your §3 settles that the tint belongs on the ball after the grab. Right — and it creates a moment nobody has designed.
Scene 4 is chute, declared "static — no state machine". But it is the exact frame where a child learns what they got, before they know what it is. That is the most charged half-second in the whole sequence and it is currently a still image.
We propose chute gains a main machine with one input — arrive (trigger) — so the ball drops in with weight and its rarity colour blooms in over ~200ms as it settles. No new asset, no new key, no host logic beyond firing one trigger you already fire a phase for.
It costs one input. It converts your quietest frame into the one they remember.
3. A container that answers the third tap like the first is not under pressure
Your taps input says the file reacts with "a wobble, a crack, a bulge." We have built it as an escalation, and we want that blessed rather than assumed:
| taps | the ball does |
|---|---|
| 1 | nudge — a small rock, settles |
| 2 | strain — lifts, tips further, the base bulges |
| 3+ | crack — the lid jumps, the seam widens |
pop | the lid leaves with weight; the base recoils and settles. Stops. |
This stays inside your authority line. The file is reacting to a number it is given; it never decides the pop, and it holds at crack forever if pop never fires. But it is a different feel from one wobble repeated, and the difference is whether the third tap feels earned.
It also matters more because of the platform. navigator.vibrate does not exist in Safari on iOS and iOS ships first — a third of the per-tap response is silent at launch, and your 16-ENGAGEMENT.md §4 forbids leaning on it. The visual has to carry what the haptic cannot.
4. And one thing we cannot build with the interface as declared
The claw has one input: closed (boolean). That gives a claw that snaps between two poses.
A claw machine's signature — the thing that makes it read as a real machine rather than a picture of one — is that the claw is hung, not mounted. It trails the carriage, overshoots when the carriage stops, and settles. Nothing in closed can express that, and CSS on the host cannot either, because the swing depends on the carriage's velocity, not its position.
We propose one more input on claw: swing (number, −1…1), which the host sets from carriage velocity and the file uses to lean and trail. It is the same shape as your joystick.x — the host computes, the file leans.
We have already built the other half of the physicality inside the file and it needs no interface at all: when closed goes true the head sags as it takes the load, then recovers. Real claws grip weakly, and that dip is most of the feeling.
What we need back
- Non-rarity variety in the mound — allowed, or a flat no.
arrive(trigger) onchute— one input, and it buys the tint bloom.- Bless the tap escalation, or tell us to keep it flat.
swing(number) onclaw— or tell us the carriage will never move fast enough for it to matter.
None of these blocks. All four are cheaper now than after the art is drawn, which is the only reason they are in front of you today rather than in a delivery note.