Bouncing balls in a heptagon · ling-3.1-flash

I need build complete single file. Need use browser verify. Need think physics stable. Need implement custom. Heptagon rotating one rev 5 sec. 20 balls compact near center, fall gravity. Need moving wall velocity bounce. Angular motion and number rotates. Pause Resume Reset exact initial arrangement/orientation.

Need perhaps render canvas responsive. Heptagon fully visible. Need initial arrangement compact non-overlap. Center of polygon; gravity downward, balls initially compact. Polygon radius perhaps 46% min canvas dimension, ball radius ~24? 20 radius 22 compact. Container side circumradius R, inradius apothem. Need fit ball arrangement. Ball radius perhaps 22, 20 circle packing radius around ~92? For circles, area 20*pi*22² ~30k / pi => sqrt=98; polygon apothem maybe 320 if canvas 700. plenty. Could radius 30, compact cluster radius 120. Fine.

Need robust collision. Physics with substeps maybe 4, fixed dt. Walls: regular heptagon orientation angle theta. Define normals. Collision half-plane constraints. Each side's inward normal. Need point inside polygon and distance to side <= r. Better compute signed distance to each edge line, with inward normal. If d < r, position correction, relative velocity with wall velocity at contact due rotation. Wall angular velocity. Contact point maybe closest point on edge. Wall point velocity omega cross r = omega * perpendicular(contact - center). In 2D omega scalar, v = omega * (-(y-cy), (x-cx)). Relative normal velocity vrel_n = (ball v - wallv) dot inward normal. If moving toward wall (<0), reflect relative normal with restitution, perhaps friction tangential. Then set v = wallv + tangent*(...) - normal... Need account wall movement. Position clamp.

Heptagon vertices; edge normals. Orientation reset 0. Need ensure fully visible: canvas CSS and canvas internal resolution. Use fixed virtual coordinate 900x700, scale to viewport. R=340? Inradius = R cos(pi/7) ~306. Center 450,350. Balls max ~? radius 25, cluster. Fine. Canvas 900x700. Polygon vertices at center + R(cos(theta+2πk/7), sin...). At theta 0, top vertex? orientation perhaps angle = -pi/2 + omega t. Keep visible with R=340, center 450,350, max extent 340 fits y 10..690, x 110..790. Great.

Need initial compact non-overlapping. Could generate positions in centered hexagonal close-packed cluster. Need exactly 20. Generate rows with hex packing. E.g rows [1,2,3,4,5,?] sum 15? Need 20 rows [1,2,3,4,5,?] 15. Could [2,3,4,3,2,?] 14. Need cluster arrangement. Better generate grid within radius with spacing 2r+1.5. 20 positions sorted by distance from center. Candidate points in hex lattice, select nearest. Ball r=24. Hex spacing ~50. 20 cluster radius perhaps 110. We can generate all lattice points within radius 120, sort distance, take 20. Need ensure exactly and nonoverlap. Let's calculate. Hex axial to pixel x=spacing*(q + r/2), y=spacing*sqrt3/2*r. For radius maybe 115. Count? Let's calculate via node mentally or use command. We can design deterministic array. Hex lattice with spacing 52. Points q,r axial with max maybe. Pixel:
(0,0)
(1,0),(0,1),(-1,1),(-1,0),(0,-1),(1,-1): 6
(2,0),(1,1),(0,2),(-1,2),(-2,2),(-2,1),(-2,0),(-1,-1),(0,-2),(1,-2),(2,-2),(2,-1): 12 => total 19. Need one from next ring, perhaps (2,1) or (-?); but distance 2 rings? axial distance max(|q|,|r|,|q+r|), next point (2,1) pixel x=78, y=90.9, distance 120. So 20. Distances: center 0; first ring 52; second ring some 90.9 and 104 etc. All nonoverlap. Compact. Sort by distance maybe second ring. Numbers assigned based sorted positions. Initial all velocities zero? "near enclosure center and let them fall under gravity." Could zero. Initial arrangement near center. Reset exact.

Angular motion: each ball angle, angular velocity. Need collisions impart spin. Ball-ball collision with rotational dynamics? Required give each ball angular motion and rotate number. Could simple angular velocity updated from tangential relative velocity at contact and wall friction. Need stable. Implement angular velocity in rad/s. Ball-ball collision impulse includes rotation maybe. Could either update angular velocity based on tangential relative velocity and friction, then integrate. Need avoid unbounded. We can implement physically plausible with inertia. Need custom.

Ball-ball collision:
- positions, velocities, radii same.
- normal n from a to b, overlap.
- positional correction split.
- relative velocity at contact including angular surface velocities: vrel = vb + cross(omega_b, contact-b) - (va + cross(omega_a, contact-a)). In 2D cross scalar omega with radial vector = omega * (-ry, rx).
- normal impulse jn = -(1+e)*vn / (2/m) (equal m). Apply.
- tangential relative velocity at contact, jt = -vt / (2/m + r²/I + r²/I). For solid disk I=0.5 m r², r²/I=2/m; denominator 4/m. friction clamp |jt| <= mu*jn. Apply tangential impulses. This changes linear and angular velocities. Need mass 1. This is custom and stable.
- For wall: normal inward. Wall velocity. Contact point. Relative velocity. Normal impulse coefficient. Position correction. Friction tangential. Angular impulse. Formula effective mass. For ball-wall infinite mass: 1/m + r²/I = 1+2=3. jt=-vt/3 clamp mu*jn. Apply linear and angular. Moving wall velocity accounted in vrel and restitution. For normal impulse, if vn<0. jn=-(1+e)*vn/(1/m). v_after = v + jn*n/m; also wall velocity remains. Good.
- Damping: global air drag and angular drag. Gravity. Maybe wall restitution 0.75, ball restitution 0.85, friction 0.25. Gravity 900 px/s². dt 1/120 substeps 4 from frame dt clamp. Speeds likely manageable.
- positional overlap correction. Need ball-wall with polygon sides. We need avoid persistent overlap. For each substep, update velocities then positions then resolve collisions maybe multiple iterations. Sequence:
for substep:
  integrate gravity, drag
  integrate position
  wall collisions (position and velocity)
  ball collisions 2-3 iterations
Could ball-ball after walls push into walls; then wall resolve again. Do ball collisions then wall resolve. More stable:
- integrate
- ball collisions (2 iterations)
- wall collisions
- ball collisions maybe.
Could use 5 iterations each. 20 balls trivial.
Need ensure balls contained. Wall normal inward. Position correction to d=r. For each edge. Since convex polygon, if inside all edge lines with d>=0. Compute signed distance d = dot(p - point_on_edge, inward normal). For vertices v[i], v[j], edge vector e=v[j]-v[i], inward normal? Need orientation. Vertices CCW for angle increments. For CCW polygon, interior is left of edge, inward normal = (-ey, ex)/len. Check theta=0, vertices at -90°, then 61.7? cos? k increments CCW. Edge from top (0,-R) to (R cos -pi/7? Actually angle -90+51.4=-38.6, point (265.7,-213.8)), edge (265,113), left normal (-113,265) points up/right interior yes. Good. d.
Wall contact point closest along edge: p - d*n (surface point). Wall velocity omega * perpendicular(contact-center). Since angular velocity positive CCW. At top edge, contact near (maybe 100,-306), perpendicular = (306,100), correct CCW.
If ball center d<r:
 p += n*(r-d)
 contact = p - n*r (after correction)
 wall velocity.
 vrel normal.
 if vn<0:
   jn=-(1+e)*vn / invMass
   v += jn*n*invMass
   tangent t=(-n.y,n.x)
   surface relative tangent.
   jt=-vt/(invMass + r²*invI)
   clamp.
   v += jt*t*invMass
   omega += (contact - p) cross (jt*t) * invI. Cross r x F = rx*Fy - ry*Fx.
Need maybe restitution threshold to avoid jitter. Use if vn < -20 maybe restitution e else e=0? Moving wall adds energy; if wall moves into ball, vn negative, bounce. At slow rotation, wall speed at radius ~0.8 px/s? Wait omega=1.256 rad/s * 300 = 377 px/s, significant. Actually one revolution every 5 sec = 1.256 rad/s, wall speed 380 px/s. Gravity 900. Good. Restitution can cause high speeds but drag. Need no unbounded. Use restitution 0.65 maybe. Wall moving can inject energy, but bounded due drag and collisions. Could use velocity threshold 40. Yet moving wall normal speed up to 377, bounce. Fine.
Potential issue wall rotating polygon can trap balls and accelerate. Drag v *= exp(-0.25 dt), omega *= exp(-0.5 dt). Terminal ~3600 under gravity, but wall impacts. Fine.
Could add max speed clamp 2500. "do not gain unbounded speed." Explicit clamp reasonable. Max angular 30 rad/s.

Need visual:
- canvas maybe 900x700, CSS max.
- HUD controls, status, maybe speed.
- Heptagon fill/stroke, ball gradient? No external.
- numbers rotate with ball. Draw circle, number rotated by angle. Need spin visible. Use contrasting ball colors deterministic.
- Maybe trail? no.
- Draw small rotation marker dot to make spin visible. Number itself rotates.
- Ball angular motion from collisions. If no initial spin, gravity and initial fall no contacts maybe zero until collisions. Numbers won't rotate until bounce. Requirement "Give each ball angular motion and rotate its number with ball so spin is visible." Could initialize small angular velocities to visibly show spin. Give each ball angular velocity maybe 1.5 rad/s alternating. Then numbers rotate even before collisions. But "initially place ... let them fall" okay. Reset restores. Use initial angular velocities deterministic maybe (i%2? 2 : -1.5). This makes visible. Also collisions change.
- Need "visible ball contacts produce bounce responses" verification via simulation instrumentation perhaps console logs? We can inspect. Could include collision flash. For verification, sample moments. Browser tool can inspect DOM/console but no direct JS evaluation? Browser actions inspect returns maybe console and DOM. We can use screenshot. We can add debug? Better perhaps run and screenshot at times. Need verify reset orientation. Could use browser inspect to read canvas? We can maybe use JS evaluation? Tool only actions no eval. It returns DOM and console. We can inspect page, maybe DOM includes status. Could add data attributes for orientation and stats. Or console logs. But final report can say checked via screenshots. Need actually use browser.

Need write index.html. Then browser open? functions.browser action maybe no open param; likely current? Use reload/screenshot. Need perhaps browser tool automatically loads index. We'll call screenshot.

Let's formulate code carefully.

HTML:
<!doctype html><html><head><meta charset...><title...><style>...
body background, .app, header, canvas, controls.
Canvas width=900 height=700, aria.
Buttons.
Status spans: state, wallAngle, balls, maxSpeed, overlaps maybe.
JS:
(() => {
const canvas = ...
const ctx...
const W=900,H=700,CX=450,CY=350,POLY_RADIUS=340,BALL_RADIUS=24,SIDES=7;
const WALL_PERIOD=5, OMEGA=2π/5;
const GRAVITY=900, REST_BALL=.86, REST_WALL=.68, FRICTION=.28, AIR_DRAG=.22, SPIN_DRAG=.8, MAX_SPEED=2400, MAX_OMEGA=25;
let balls=[], wallAngle=0, paused=false, last=0, accumulator? Use fixed timestep.

function makeInitialBalls() {
 const positions=hexCluster();
 return positions.map((p,i)=>({id:i+1,x:CX+p.x,y:CY+p.y,vx:0,vy:0,angle: initialAngles[i], omega: initialOmega[i], color:...}));
}
Need initial angle maybe 0 and omega alternating. If angle 0, number upright. Reset exact.
hex cluster:
const s=BALL_RADIUS*2+3; // 51
const pts=[];
for q -3..3 for r -3..3:
 x=s*(q+r/2), y=s*Math.sqrt(3)/2*r;
 if Math.hypot(x,y)<=? Need include next ring point at distance 120. If radius=122, includes 20? Let's count. Axial distance for (2,1): pixel x=76.5,y=88.3, dist 116.7. All within 122. Are there other third ring points within 122? (2,2) dist x=102,y=176.7 dist204 no. (3,0) dist153. (2,-? (2,-1) dist? x=76.5,y=-88.3 116.7). So exactly 1 center+6+12+2? Wait second ring has 12 points, all distances:
(2,0):102
(1,1): x=76.5,y=88.3 dist116.7
(0,2): x=51,y=176.7 dist184! Ah axial q=0,r=2 pixel distance 184, not 104. Wait hex geometry. Let's recalc. For q=0,r=2: x=s*(0+1)=102, y=s*1.732=176.7, dist204. Actually x=102. So second ring points are not all same distance? Hex ring should same? Axial coordinates with cube distance 2: (2,0) pixel (102,0) dist102; (1,1) pixel (76.5,88.3) dist116.7; (0,2) pixel (51,176.7) dist184. This seems wrong? Hex axial to pixel formula x=s*(q + r/2), y=s*sqrt3/2*r. For (0,2), x=51 not 102 (I mis multiplied). Dist184. But in axial, (0,2) cube coords (0,2,-2), distance 2, pixel should maybe 2*s? Let's transform basis: q basis (s,0), r basis (s/2, s√3/2). (0,2)= (s, s√3)= (51,88.3)? Wait s* r/2 = 51, y=s*√3/2*r = 88.3. I erroneously y 176.7 (for r=2, s*0.866*2 = 88.3). Yes dist102. Good. All second ring 102 or 116? (1,1): x=76.5,y=44.1, dist88.3. Actually s√3/2=44.1. So second ring distances 88.3 and 102. Fine. Third ring some at 129 etc. If radius <=120 includes 19. Need one next ring point with distance maybe (2,1): x=127.5? s*(2+0.5)=127.5, y=44.1, dist135. Hmm. Let's calculate all. To get 20 compact, maybe use rows arrangement simpler.

Rows [2,3,4,3,2,?] sum 14. Need 20. Hex close packed rows [2,3,4,3,2] =14. [2,3,4,3,2,?]. Could use rows [2,3,4,3,2,?] no.
Rows [2,3,4,3,2] plus 6? Maybe [2,3,4,3,2,?].
Could use rows [2,3,4,3,2] =14; add row 6? [2,3,4,3,2,?].
Rows [2,3,4,3,2] and extra 6 in another row? 20 = 2+3+4+3+2+? 6. Rows [2,3,4,3,2,?] weird.
Hex rows [2,3,4,3,2,?] maybe [2,3,4,3,2,?] no.
Rows [2,3,4,3,2] =14; rows [2,3,4,3,2,?] with 6 =20. Could use [2,3,4,3,2,?] not symmetric.
Rows [2,3,4,3,2] plus [1,?]. Better 20 = 2+3+4+3+2+? 6. Use rows [2,3,4,3,2,?] maybe [2,3,4,3,2,?].
Could use rows [2,3,4,3,2,?] no.

Hex lattice selection radius can include 19 then add one at next ring. That's fine, still compact though asymmetric. Or choose spacing 48 and radius 125 includes maybe 20? Third ring nearest points distance maybe? For (2,1): x=120, y=41.6, dist127; (2,-1): x=72,y=-41.6 dist82.8? Wait q=2,r=-1: x=72, y=-41.6, cube distance max(2,1,1)=2 actually it's second ring. Right. Third ring nearest (2,1) cube distance 2? max(2,1,3)=3, pixel x=120,y=41.6, dist127. So radius 130 adds 6 points maybe total 25. Need select 20 sorted by distance: 19 within 102 plus one of six at 127. Asymmetric but okay. Could instead use rows to get symmetric 20.

Let's construct hex rows with 20: row counts [2,3,4,3,2] =14. Add [1,?] maybe 6 points in two rows? 20 = 2+3+4+3+2+? 6. Could use [2,3,4,3,2,?] with row 6. Or [2,3,4,3,2] plus a small row of 6 below, but compact-ish.
Alternative rows [2,3,4,3,2] and [1,?] no.
Rows [2,3,4,3,2,?] maybe [2,3,4,3,2,?].
Rows [2,3,4,3,2] =14; add row [1,?] 1 =15; add row [?] etc.
Could use rows [2,3,4,3,2,?] no.

Hex rows [2,3,4,3,2] is 14. For 20, rows [2,3,4,3,2,?] with 6. Maybe [2,3,4,3,2,?] =20 if last 6. That's a broad row, still cluster.
Or rows [2,3,4,3,2,?] maybe [2,3,4,3,2,?].
Could use rows [2,3,4,3,2,?] no.

Hex rows [2,3,4,3,2,?] with last 6. Let's use rows [2,3,4,3,2,?] maybe last 6. But vertical extent 6 rows * 44 =264, horizontal row 6*48=288, compact. Could use row counts [2,3,4,3,2,?] not aesthetically symmetric.
Maybe rows [2,3,4,3,2,?] and offset. Better 20 = 2+3+4+3+2+? 6. Could use [2,3,4,3,2,?] with last 6. Fine.
But "compact, non-overlapping arrangement near enclosure center" no symmetry requirement. Hex lattice selection 20 sorted is compact. Let's do lattice candidate within radius 130, sort by distance then axial tie, take 20. This yields 19 inner ring + one at 127. Non-overlap guaranteed. Compact enough. Initial numbers assigned sorted. Could perhaps use 20 points from a circle packing algorithm? Not needed.

Maybe use 2D grid with spacing 50, select points within ellipse, take 20. But hex is better.

Let's verify count with node quickly maybe. Use bash node.

Only 19 within 130; nearest third ring maybe 153? Let's list.

Great 19 + one at 135. Radius 135 includes 25? There are 12? Actually six at 134.9? list 12? Let's count: -3,1; -3,2; -2,-1; -2,3; -1,-2; -1,3; 1,-3;1,2;2,-3;2,1;3,-2;3,-1 maybe 12. Radius 135 includes 31. Need choose one. Could use radius 134.8 to 19. Need 20. We can take 19 plus one selected at 134.9. Fine.

Could use spacing 49 and radius 130: 19 + maybe third ring at 129.9? Scale 49/51*134.9=129.7, so radius 130 includes all 31. Not.

Could use 20 via lattice and remove some? 19+one. Fine.

Maybe create rows [2,3,4,3,2,?] with 6. Let's use hex lattice 19 + one, but initial cluster has a protrusion. Accept.

Could generate 20 using "centered hexagonal numbers": 1,7,19,37. 20 is just one beyond 19. That's compact by definition. Great.

Need initial ball radius 24, spacing 51. Cluster radius 135. Polygon inradius 306. Good.

Initial angular velocities maybe 2.2 rad/s alternating. At 2.2 rad/s number rotates ~0.35 rev/s visible. Reset exact.

Need maybe initial positions sorted by distance and tie. Number assignment. We can assign id by sorted order. The one at 134.9 choose first tie maybe (-3,1), so protrusion upper-left. Fine.

Potential issue initial balls at center and gravity, but polygon rotates. At t=0 wall orientation maybe top vertex. Balls fall. Good.

Need reset:
- initialBalls = createInitialBalls(); balls = deep copy.
- wallAngle=0; paused=false; elapsed=0; simTime=0; collisionCount=0; update button.
- last=performance.now(); requestAnimationFrame already.
Need not recreate? Reset restores arrangement and wall orientation exactly. Deep copy.

Pause/resume button label. On pause, stop physics but render. Use rAF continues. last reset on resume to avoid dt jump.

Fixed timestep:
let simTime=0;
function frame(now){
 requestAnimationFrame(frame);
 if(!paused){
   let frameDt=Math.min((now-last)/1000,1/30);
   last=now;
   const step=1/240? 20 balls, 4-8 substeps. Use fixed 1/240 with accumulator? Simpler substeps = Math.max(1, Math.ceil(frameDt/(1/240))) but variable. Use fixed dt=1/240, accumulate frameDt, max 12 steps. At 60fps 4 steps. Good.
   while(acc>=DT && iterations<max) step(DT)
 } else last=now;
 render();
}
Need wall rotation constant. wallAngle += OMEGA*dt in step. Keep angle mod 2π. Reset 0.
Physics step:
for ball: vy += g*dt; drag factor Math.exp(-AIR_DRAG*dt); v *=; omega *= exp(-SPIN_DRAG*dt); clamp.
x += vx*dt etc.
resolveBallCollisions(2)
resolveWallCollisions()
resolveBallCollisions(2)
Maybe wall after ball. Good.
Collision detection ball-ball:
for i<j:
 dx, dy, dist; min=2r; if dist<min:
   if dist<1e-6 n=(1,0), else.
   overlap=min-dist; totalInvMass=2; correction=overlap/2*1.0? Use 0.8 to avoid jitter, but persistent overlap? Use 1.0. x -= n*overlap/2, other +=.
   contact = a + n*(r - overlap/2?) For equal, contact at midpoint. r vector from each to contact = n*r. Good.
   surface velocities.
   vn = dot(vrel,n)
   if vn<0:
      e = vn < -30 ? REST_BALL : 0? Use restitution threshold. But requirement bounce response. Use e=REST_BALL always; with small overlap numerical. Fine.
      jn=-(1+e)*vn/2.
      tangent = (-n.y,n.x)
      vt=dot(vrel,t)
      invMass=1, invI=2/(r²) (since I=0.5 m r²)
      denom=2 + r²*invI*2 = 2+4=6? Wait formula 1/m_a+1/m_b + (r²/I_a + r²/I_b) = 2 + 2+2=6. Earlier I said 4/m for r²/I=2/m each => total 6. Yes.
      jt=-vt/6.
      friction clamp: maxFriction=FRICTION*Math.abs(jn); jt=clamp.
      apply:
       a.vx -= jn*n.x? Impulse on a is -jn n? Define n a->b. Normal impulse on b = jn n, on a=-jn n. If jn positive (for vn negative, jn positive). So a.vx -= jn*n.x; b +=.
       tangential impulse on b = jt*t, on a=-.
       angular: torque on a from impulse -jt t at r_a=n*r: r x (-jt t) = -jt*(r n x t). n x t = n.x*t.y - n.y*t.x = n.x*n.x? t=(-n.y,n.x), cross=n.x*n.x - n.y*(-n.y)=1. So torque a=-jt*r. For b, r_b=-n*r, impulse jt*t, cross=(-n*r)x(jt*t)=-jt*r*(n x t)=-jt*r. Both same? If tangential impulse direction, spins both same? For collision, yes depending.
       a.omega += -jt*r*invI; b.omega += -jt*r*invI? Let's check b r=-n*r, impulse=jt*t, cross = (-n) x t * r*jt = -r*jt. yes same. For normal no torque.
   collision count if vn < -10 maybe.
Need maybe positional correction before velocity. Good.
Wall:
for each ball, for each edge:
 d = dot(p - v0, n)
 if d < r:
   p += n*(r-d)
   contact = p - n*r
   rx=contact.x-CX...
   wallVx=-OMEGA*rx? omega × r = (-omega*ry, omega*rx). yes.
   vrel = ball - wall
   vn=dot(vrel,n)
   if vn<0:
      e = WALL_RESTITUTION maybe if vn<-25 else 0? Moving wall can make vn negative. Use threshold 20. But if ball rests on rotating wall, normal velocity due wall may be zero if tangential, no bounce. If wall moves into ball, bounce. If e=0 for low, friction. For high, bounce.
      jn=-(1+e)*vn / invMass (1)
      v += jn*n
      t=(-n.y,n.x)
      vt=dot(vrel,t)
      denom=invMass + r²*invI = 1+2=3
      jt=-vt/3 clamp FRICTION*|jn|
      v += jt*t
      torque = r_contact_ball? contact - p = -n*r. impulse jt*t. cross = (-n) x t * r*jt = -r*jt. omega += -r*jt*invI.
   collision count if vn < -15.
Need moving wall velocity in bounce response. Yes.
But wall collision position correction can add energy? no.
Potential issue with wall edge normals and contact point if ball near vertex, multiple constraints. Sequential. Fine.
Need wall velocity at contact based on current wallAngle. Since wall rotates, contact point moves. Good.
Need maybe account angular wall velocity in normal velocity. yes.

Stability:
- max speed clamp after collisions perhaps each step. If speed > MAX, scale. omega clamp.
- positional correction.
- restitution maybe 0.72. With moving wall, energy bounded by drag.
- Use substeps 1/240, collision speeds up to maybe 2000, movement 8 px per step less radius 24. Good.
- wall rotation 1.256 rad/s, per step 0.005 rad, wall displacement at radius 1.6 px. Good.

Rendering:
function render(){
 ctx.clearRect...
 draw background maybe radial gradient (no external).
 draw polygon:
 vertices.
 fill rgba, stroke.
 maybe draw dashed center cross.
 for balls:
   ctx.save(); translate; rotate(angle); draw circle with radial gradient? Create per ball each frame okay. Could use color. Draw number with font bold 20px. Number width. For two digits, 20px. Ball radius 24. Use font `bold 20px system-ui`. Text align center baseline middle. Add small dot at (r*0.55,0) to show rotation. But number enough. Use marker.
   Draw shadow.
 Need number rotates with ball. Since context rotated, yes.
 Draw wall orientation marker maybe small line from center to vertex? Could show a subtle spoke to visualize rotation. But balls may obscure. Draw polygon vertex markers.
 HUD update:
 state text, angle degrees, elapsed, max speed, contacts.
 Need collision count maybe.
}
Need "sample several moments initial fall and collisions" perhaps add event log? Could include `lastContact` and collision count. Browser console maybe log collisions? Not necessary. But for verification, can use screenshots at times. Maybe add `data-*` attributes to status to inspect. Browser inspect returns DOM. We can update.
Could add `canvas` no DOM values. HUD.
Need perhaps use `ResizeObserver`? Canvas fixed internal. CSS scale. Keep fully visible. Canvas aspect 900x700 and CSS width min(96vw, 900px), height auto. Good.
Need no external fonts. Use system-ui.
Need controls keyboard maybe Space pause, R reset. Nice.
Need accessible.

Need perhaps handle DPR for crispness. Canvas width=900 height=700. Could set canvas.width=W*devicePixelRatio and scale. But CSS. Simpler use fixed 900x700. On high DPI slightly less crisp. Could implement DPR:
const DPR=Math.min(window.devicePixelRatio||1,2);
canvas.width=W*DPR; canvas.height=H*DPR; canvas.style aspect; ctx.setTransform(DPR,0,0,DPR,0,0). But CSS width from style. Good.
Need if DPR changes not important.

Need maybe use `requestAnimationFrame` and initial last. Reset sets last=performance.now.

Need test with browser. Let's write file.

Need run browser. Use browser reload maybe.

Browser says images not supported, no screenshot. Need inspect at moments. We can use inspect.

Interesting contacts 481 in 1.79 sec, high but plausible due dense cluster. Fastest 491. Need inspect several moments. At 1.79. Wait maybe contact count increments every substep for each collision while normalVelocity < -12, could count many repeated contacts. Fine. Need check initial fall at 0.2, 0.5, collisions. We can reload and inspect quickly. But time between tool calls maybe. Need verify reset orientation. We can click reset then inspect. But need compare initial view. We have initial DOM angle 5.4 elapsed .07. Reset should 0. Need click.

Click coordinates maybe wrong due responsive? x 770 y57 likely pause? It didn't pause? DOM running. Maybe coordinates not accurate because viewport 1200x800 and app centered. Need click reset. Need locate via DOM? Browser click only coords. We can estimate. App width min(960,96vw)=960, centered x120..1080. Header reset button right around x? header padding 16, controls. Button reset maybe x~? In viewport, app starts 120, width 960. Header right side maybe x~1000. y~? body padding 18, app padding 16, header height ~70. So y~70. I clicked 770,57 maybe maybe pause? It says running, maybe pause then resume? Actually if paused, state Paused. Not. Need use keyboard R perhaps browser key action. Use key "r".

Key text maybe not recognized? Maybe action key expects text? It didn't reset. Could click reset coordinates. Need determine actual button positions. Could inspect DOM not coordinates. Maybe browser action screenshot unsupported. We can use bash with playwright? No external network but maybe installed. Check tools? We can use browser only. Could add reset button id and use keyboard. Maybe key action needs `text` but perhaps sends key? It should. Why not reset? Maybe event listener key is "r" but browser action key sends text to focused element? It should. Could click approximate. Let's calculate viewport. Body padding 18, app width 960 (96vw=1152, min 960), centered in 1200 => left 120. App padding 16. Header flex. Title left at x136. Controls right. Buttons padding 9x16, font. Pause width maybe 82, Reset 78, gap 8. Total 168. Right edge of app content x=120+960-16=1064. Reset right edge 1064, left 986, center 1025. Header y: body top 18 + app top 16 + maybe h1 line height ~? h1 font 26, line 1.2=31, subtitle 18+3, total ~52, center ~18+16+26=60. So click reset x1025 y60. I clicked 770,57 (pause maybe center? Pause center left maybe 947? Actually controls total 168, left = 1064-168=896, pause center 896+41=937, reset center 1025. So 770 was title area). Click x1025 y60.

Still not reset? Maybe coordinates not mapping due iframe scaling? Or click action perhaps x/y but not accepted? It should. Maybe DOM update from simulation after click, but reset should wall angle 0 immediately. It shows 111, so click didn't hit. Maybe viewport is 1200x800 but browser tool coordinates use CSS pixels? yes. Maybe app not 960 because body grid place-items center and width min(960,96vw) but perhaps iframe width not 1200? Tool says coordinates use 1200x800 viewport. Should.

Could use browser action type? Maybe click x/y but canvas? Let's use screenshot though images unsupported. It returns no image. Could inspect DOM with `data-*` and maybe use keyboard. Key action perhaps needs `text` but maybe it sends characters to active element; our keydown listener on window should catch. It didn't. Maybe key action's `text` parameter is for type action, key action uses `text`? Documentation says action key, text. Should. Maybe uppercase R? Try text "R".

No. Maybe browser tool actions not actually interacting? But inspect shows changing. Click perhaps coordinates wrong due viewport actual 1280? Need get dimensions via DOM? Could add window dimensions to stats? Not necessary but for testing. Could use `window.innerWidth` maybe DOM doesn't show. We can modify to include? Or use browser action scroll? Hmm.

Maybe the page is in iframe with sandbox and actual viewport 1200x800, but click coordinates are relative to canvas? It says coordinates use 1200×800 viewport. Should.

Could use browser action `click` on reset by finding via `document` impossible. Maybe use keyboard with action `type`? There is action type. Try type "r".

No. Maybe actions don't dispatch due iframe sandbox? But click should. Could be coordinates. Let's use click at top right maybe x900 y60 for pause.

Still running. Maybe click not working at all? But tool likely. Could be buttons are at different y due viewport scaling. Let's use browser screenshot maybe no images but action returns?

No image. Need perhaps use browser inspect to get bounding boxes? The DOM output is text only, no rect. Could add temporary debug element showing button bounding boxes? We can modify file to display? Not desirable final. Could use querySelector via console not available. Browser action maybe `inspect` returns DOM text only. Could add `data-test` and maybe DOM includes? Not coordinates.

Maybe use URL hash? no.

Could use bash with a headless browser via node? Check installed packages. `ls /app/pipeline/node_modules` maybe playwright? Use bash.

Playwright installed maybe browsers not. Could use playwright to open file and evaluate, screenshot. Network no. Let's check.

Great. We can use playwright for detailed verification, including canvas pixels maybe. Need not violate browser tools? We can use bash. We'll write a temporary node script or inline. Need test initial moments, reset. We can launch file, evaluate JS? Page context can access variables? They are inside IIFE, not global. But DOM stats enough. We can sample stats at times. To verify ball positions and angles, could expose debug globals? Not necessary but helpful. We can perhaps use canvas pixel analysis. But requirement verify numbers rotate. We can add temporary `window.__sim`? Not in final maybe could expose for debugging, but not needed. We can use DOM stats and canvas screenshot. Better perhaps modify code to expose a debug object? It might be okay but unnecessary. Could use Playwright to click buttons by selectors, evaluate DOM, screenshot. Also can use `page.evaluate` to dispatch events. To inspect internal state, we could temporarily add `window.__physics = ...` but final maybe not. Could use canvas OCR? Not needed. We can verify visually via screenshot saved and maybe read image with read tool. We can use Playwright screenshot to /tmp and read. Great.

Need first test current page with Playwright. Use inline script:
- launch, viewport 1200x800
- goto file://...
- wait 0.15, get stats, screenshot initial.
- wait 0.4, stats.
- wait 1.2, stats.
- click pause, check state.
- click reset, check angle 0, elapsed 0, state running, maybe screenshot reset.
- compare reset screenshot to initial? Initial at t=0.07 vs reset immediate. Could navigate and reset immediately, screenshot. Compare pixel difference maybe using PNG pixelmatch not installed. Could use screenshots and read visually. Or use canvas screenshot at t=0 after reset and initial by pausing immediately? We can use page.evaluate to click reset then pause? But pause button label. We can get stats.
Need verify wall orientation reset: angle stat 0.0. Arrangement reset: initial positions not exposed. Could compare canvas image immediately after reset to a reference captured at reload and immediately paused? But reset at t=0 and initial at t small differ due fall. To compare arrangement, we can capture after reset and after reload with pause immediately. We can use keyboard? Playwright can click pause quickly. Or evaluate dispatch click. At t=0, balls at initial positions. Reset then pause immediately. Reload and pause immediately. Compare images. But pause at slightly different times (few ms) negligible. Could use page.evaluate to directly click reset and pause. Then screenshot. Reference: reload, click pause immediately. Since simulation starts at t=0 and pause before frame maybe. Compare via pixel difference using PNG decode? Could use playwright screenshot and `pixelmatch` maybe installed? Check. Or use canvas `toDataURL` and compare strings if exact. If same time and state, rendering deterministic except wall angle 0 and balls positions. At pause immediately, elapsed 0, wallAngle 0, ball angles 0, so screenshots should be exact except maybe antialiasing deterministic. Could compare Buffer.equals. Great.

Need test contacts and bounce. Stats contact count >0. Need sample several moments. We can log stats at 0.1, 0.5, 1.0, 2.0. Need maybe check max speed bounded. Run 10 sec and sample max speed. Also check containment by internal positions not exposed. Could expose positions via debug or analyze canvas. Better add a debug global in code? Could perhaps use `page.evaluate` to access closure? No. Could instrument code with `window.__physicsState` but final not needed. We can temporarily modify then revert, or add a harmless debug hook? Better not. We can verify containment by checking ball pixels within polygon from screenshot? Hard. But code logic sound.

Could use Playwright to evaluate `document.querySelector` and click. Let's run script.

Interesting after pause says Running, after reset says Paused. The click order? We clicked pause but stats sampled before UI update? Actually after pause should Paused. It shows Running. Then after reset shows Paused. Maybe click pause registered one frame later? Wait page.click waits action, but stats update next frame; should immediate. Could be click on pause toggled paused, but then our `page.click('#resetButton')` maybe clicked? Hmm after pause Running means pause click didn't toggle? After reset Paused means reset click maybe toggled pause? Could selectors? Maybe page click coordinates and events weird due button? Let's inspect. Wait our pause button event toggles paused and sets text. If after pause Running, not toggled. After reset Paused, reset doesn't toggle paused, so impossible unless pause click took effect just after sample and before reset. Maybe stats sampled before event due page.click returns before event? Playwright click should dispatch. But maybe requestAnimationFrame delay. Then reset sets paused=false, but after reset shows Paused, so sequence delayed. Could be page.click actions are asynchronous and stats sampled too soon? But page.click resolves after input dispatch, event should be handled. Hmm maybe browser page is throttled? Yet stats update. Could wait.

After reset+250ms Running and elapsed .1, so reset did work eventually. Good.

Need verify reset exact. Use immediate evaluate to click and pause? Let's use page.evaluate to call buttons click and then wait 0. But stats maybe. We can use `page.evaluate(() => { document.getElementById('resetButton').click(); document.getElementById('pauseButton').click(); })`; then read. This should set reset then pause. Then screenshot. Reference reload and pause immediately. Compare. Let's do.

Use Playwright for exact.

Reference not exactly t=0 due event after one frame. Reset is exact. Need compare arrangement maybe reset screenshot vs initial at t=0.02 differs due fall 0.02 sec (ball displacement ~0.18 px, angle 0.04 rad) and wall angle 1.8 vs 0. Could capture initial by reset then pause (same). To compare reset to initial, both reset state. We can capture reset twice and compare exact. But requirement compare restored arrangement and wall orientation with initial view. Stats show wall 0, elapsed 0. Need perhaps expose positions or use canvas pixel compare after reset twice. Do that.

Screenshots not identical perhaps due browser rendering nondeterminism or state? Both stats same. Could compare canvas toDataURL maybe. But likely slight due animation? Paused, render same. Maybe screenshots include cursor? Cursor position same? Maybe page click? Could be focus outline? Buttons? Hmm. Not important.

Need verify ball-ball collision and bounce response. Stats contacts. But contact count increments for ball-ball and wall. Need distinguish. Could instrument code temporarily or expose. We can add a debug output maybe not needed. But for our verification, we can modify to count ball and wall separately? Could be useful final UI maybe "Contacts" total. Requirement doesn't require counts. We can use code reasoning. But to verify visible ball contacts produce bounce responses, we can create a debug global or log. Maybe add `window.__physics` to expose balls and contact types. Is that acceptable? It doesn't affect. But final artifact can include debug hook? Not necessary and maybe undesirable. Could temporarily add, test, remove. But we have time. Let's consider physics correctness.

Potential bug: Ball-ball angular impulse sign. Let's verify. For two balls colliding, tangential impulse should produce opposite angular velocities maybe? Our formula gives both same sign torque because contact radius vectors opposite and impulses opposite. Let's calculate:
n from a to b, t = (-ny,nx). Suppose t velocity of b relative a positive (b moving along +t), tangentImpulse negative (on b -t). Torque a: r_a = n*r, F_a = -jt t. cross r_a x F_a = r*n x (-jt t) = -r*jt (n x t)= -r*jt. Torque b: r_b=-n*r, F_b=jt t => -r*jt. Both same. Is that physical? Consider two balls side by side horizontally, n=(1,0), t=(0,1). b above? Actually b to right. If b moves up relative a, jt negative, force on b down, force on a up. For a at left, r to contact points right, force up => torque into screen negative. For b at right, r to contact points left, force down => cross left x down = negative. Both spin same direction (negative). That seems plausible for shear between adjacent balls: both rotate same direction? Imagine two wheels in contact, if top surface? Actually if b moves up relative a, friction on b down, on a up. Left ball force up at right edge => CCW? Coordinates y down, cross negative = clockwise in screen? Right ball force down at left edge => also clockwise. Yes same. Good.

Wall torque: n inward, contact = ball - n*r (wall side), r_ball_from_center = -n*r. Tangential impulse on ball jt*t. torque = (-n*r) x (jt*t) = -r*jt. Good.

Ball-ball positional correction with overlap 0.5 each. If one ball overlaps wall, after ball collision may push into wall; wall resolves. Fine.

Wall collision: We compute vertices once per physics step. But ball position corrections don't affect vertices. Good.

Potential issue: Wall rotating at constant rate and polygon is fully visible. R=340 center 450,350, top y=10, bottom 690, left 110, right 790. Fully visible in 900x700. Good.

Potential issue: Canvas CSS width 100% and stage border, app width 960. Fine.

Potential issue: initial balls near center but cluster extends radius 135. At t=0, balls 24 radius, all inside polygon. Good.

Potential issue: exactly 20 balls. sites count 20. Good.

Potential issue: numbers rotate with ball. ctx.rotate(ball.angle), draw number. Good.

Potential issue: angular motion. Initial omega nonzero, collisions change. Good.

Potential issue: moving-wall velocity accounted. Yes.

Potential issue: damping/friction. Air drag, spin drag, friction, restitution. Good.

Potential issue: stable. Need run longer maybe 30 sec and max speed. Use Playwright sample every 5 sec.

Interesting elapsed less than wait due page throttled when browser not focused? Playwright background maybe rAF throttled. But simulation stable. Wall angle increments ~? 5 sec waits but elapsed 3.22 due throttling. Fine.

Need maybe check exact one revolution every 5 sec. Stats wall angle vs elapsed: at 30s elapsed 19.76, angle 342.9 (not 19.76*72=1422 mod 360 =342). Yes. Good.

Need verify ball positions contained. Could expose state. Let's temporarily use a query parameter? We can modify code to expose `window.__physics` perhaps permanently could be useful but not required. Maybe add in final:
`window.__physics = { get balls(){return balls;}, get wallAngle(){...} }`? Not necessary and might be seen as extra. Better temporary via sed then revert. But we can reason. Yet verification asks sample moments and check. We can use canvas pixel analysis to see balls within polygon. But internal positions easier.

Could use Playwright `page.evaluate` to add a breakpoint? Closure variables inaccessible. Could use `page.pause` no. Could instrument by editing file to add debug hook, run, then remove. Let's do temporary with edit? Add after variables:
`const __debug = { get balls(){...}}; window.__physics=__debug;` Then test, then remove. But editing and reverting risk. Use copy file to /tmp/test.html and sed? We can create test copy with insertion using node string replace, run, then original unchanged. Good. Use bash cp and node replace. But browser file path. Let's do.

Great. minWallClearance ~0 (ball edge exactly at wall) due correction, no penetration. Overlaps 0. Max speed <600, spin <20. Good.

Need verify ball-ball collision response specifically. We can instrument contact types. Create test copy with counters. Or use internal state and detect a collision frame? We can modify to count ball contacts. Let's do temporary.

Good. Both ball-ball and wall collisions with negative approaching velocity, bounce.

Need verify numbers rotate. Could use canvas pixel or internal angles. We already saw maxSpin. But visual rotation of number specifically code. Could sample ball.angle changes. Test.

Need maybe no need. But we should inspect initial output and console via browser tool already. No errors. Need maybe check reset with browser tool? We used Playwright. Good.

Need consider if code has any issue with `dpr()` called before canvas width set? render after set. Fine.

Need maybe use `window.devicePixelRatio` in canvas width. If DPR >2, okay.

Need maybe initial arrangement "compact, non-overlapping" verified. Good.

Need maybe "Keep it fully visible." R=340 in 900x700. Yes.

Need maybe "Rotate heptagon at constant rate one revolution every five seconds." WALL_OMEGA exact. Stats verify. Good.

Need maybe "Account for moving-wall velocity in bounce response" code does. Good.

Need maybe "include damping or friction" both.

Need maybe "Give each ball angular motion" initial omega and collisions. Good.

Need maybe "Rotate its number with ball" yes.

Need maybe "reasonable sizes and physical constants stable" tested.

Need maybe "Provide Pause/Resume and Reset." yes.

Need maybe "Reset restores initial ball arrangement and wall orientation." code deep copies initial and wallAngle=0. Verified stats and positions via test copy maybe not positions but code.

Potential issue: Pause/Resume button click not working in built-in browser tool but Playwright click worked? We saw delayed. It works. Keyboard works maybe built-in tool not. Fine.

Potential issue: Reset button in built-in browser click didn't seem due coordinates; Playwright selector works. Fine.

Potential issue: contact count high and increments repeatedly during collision. Not a problem.

Potential issue: `MAX_STEPS_PER_FRAME` and accumulator. At 60fps, frameDt ~0.0167, 4 steps of 1/240 = 0.0167. Good. At throttled 30fps, 7 steps. Max 16 supports 15 fps. If below, drops time, okay.

Potential issue: wall angle update inside physicsStep with fixed dt. Constant. Good.

Potential issue: wall velocity at contact uses WALL_OMEGA constant. Good.

Potential issue: restitution threshold `normalVelocity < -20 ? WALL_RESTITUTION : 0`. This means at low impact no bounce, but moving wall can still friction. Fine. For ball-ball always restitution even low, could cause jitter but drag. Could threshold too? Not needed.

Potential issue: ball-ball collision normal impulse denominator 2, but for equal mass 1, correct. Tangent denominator 6, correct for disks. Good.

Potential issue: positional correction can cause balls to overlap due multiple constraints but tested no persistent overlaps.

Potential issue: initial cluster site count. We should maybe verify exactly 20. Code throws if not. Browser no errors. Good.

Potential issue: color shading function with amount -0.55 can produce negative? It clamps. Good.

Potential issue: `ctx.font` uses template literal with backticks inside script. Fine.

Potential issue: no external assets. All inline. Good.

Need maybe final report concise with checked and unverified. But before final, perhaps use read to ensure file exists and maybe line count.

Need maybe use browser tool final inspect to ensure console no errors. Already. Could maybe use browser reload and inspect initial. Done.

Need perhaps check reset arrangement visually via screenshot. We have /tmp/reset-a.png but can't read image? functions.read supports images. Let's read to visually inspect.

Reset stats 1.5° due one frame after reset, not exact immediate but close. In previous immediate evaluate 0.0. Good.

Need maybe test reset arrangement with internal positions. We can create test copy exposing and compare initial vs reset. Let's do for report.

Great.

Need maybe final answer mention file path and checks. But user asked build, not necessarily report? Addendum says report checked and unverified. We'll do concise.

Before final, ensure no temp files in current dir besides index.html. `ls`.