Asteroids · deepseek-v4-flash-0731

Let me build this Asteroids-style game in index.html. Let me write the full file.

Let me clean up the code a bit - I have some leftover artifacts like `drawVectorCross`, the nudge at edge while thrusting, and the translate + 760. Let me simplify. Let me rewrite cleaner to avoid bugs. Actually the translate(s.x+760) is odd - I did that to avoid negative issue, but wrapping via % gives positive anyway. Let me simplify. Also remove the stray nudge and dead function.

Let me edit the file.

The inspect only gives DOM. I need to check state changes. Since the game state is in a closure, I can't inspect it from outside. Let me add a small debug readout or use console via headless. Actually, let me use keyboard events and take screenshots.

Let me press Right arrow to rotate, then Up to thrust, then Space to fire, and take screenshots. But I can't directly observe momentum. Let me instead expose a debug hook temporarily? Better: I can evaluate JS in the browser console? The browser tool doesn't expose an eval action. 

Let me use motion frames or screenshots to see movement. Let me press keys and screenshot.

I'll press ArrowRight a few times to rotate, then screenshot.

Screenshots don't show images ("model does not support images"). This environment can't display images. I need to verify logic another way.

Let me add a debugging mechanism: instead of relying on visual screenshots, I can add a temporary self-flag or expose state to window for inspection. But browser inspect only shows DOM. I could render diagnostics into the DOM.

Better approach: temporarily add a hidden diagnostic element that reports ship angle, vx, vy, bullet count, positions, and whether wrapping occurred. Then update it each frame. Then I inspect DOM.

Let me add a debug overlay div that I update in loop. I'll make it a normal DOM element so it shows up in inspect.

Actually, let me add a small diagnostic display that I can check. I'll modify the code to write state into a div every frame. Let me add it.

Alternatively, I can write diagnostics into document.title which shows in inspect? Inspect returns dom text from body. Let me add a debug div.

Let me add a #diag div under controls showing ship angle, velocity, bullet count, asteroid count, and wrapping flags. I'll keep it but maybe hidden via very small font. Actually for testing I'll keep it visible, then remove afterward.

Let me edit.

Good. Initial: a=-90, v=(0,0), ship centered, 5 asteroids. Now test rotation: hold ArrowRight briefly. Since key press is fire-and-forget (single keydown), holding won't accumulate unless the browser keeps it. Let me hold by pressing repeatedly? The key action just sends one keydown. keydown sets keys[e.key]=true, but keyup will set false. Since single event, it toggles on then immediately... no keyup sent. Actually keys[ArrowRight]=true persists until a keyup event. So one keydown sets it true and it stays true (no keyup sent). So I can press ArrowRight once and it will keep rotating. But I need arrowLeft... Let me just do multiple single presses with time between; each press sets true and persists, so it keeps rotating continuously. Good enough to verify angle change.

Let me press ArrowRight, wait a moment (via a follow-up inspect), and read angle.

Let me phrase: press Right, then inspect after some frames.

Angle still -90, because only one frame elapsed since keydown? Actually the inspect shows latest frame; maybe ArrowRight keydown hasn't been processed into the update yet (needs a frame). Let me wait and inspect again. The browser inspect likely returns current DOM state at that moment. Since loop runs via rAF, a frame may not have passed. Let me press again / wait.

Let me repeatedly press ArrowRight a few times to give frames time, then inspect.

Interesting — lives dropped from 3 to 2, ship dead (a=-90, v=0, ship at 380,380 center, ast=5). Wait, when ship dies, it respawns at center and shipDead=true means drawShip returns and no control. But the diag shows ship at center with invuln. Actually lives=2 now. So a random asteroid came and hit the ship while I was testing rotation. That means shipDead=true so I can't even test rotation now, and my keydown persistence means keys stuck on.

Issue: my single keydown persists as true forever (no keyup sent). This makes controls "stuck". In real play, keyup events happen. That's fine for real users. But for testing, keydown persists. The asteroid hit killed ship, respawned at center (shipDead=true means my update uses `state.ship` which was replaced). But shipDead=true means ship doesn't update/move and drawShip returns. Lives went 3->2.

Hmm, but actually the ship is invulnerable at spawn for 2.4s. Yet it got hit? Initial ship invuln=2.4s. During testing multiple frames passed >2.4s, invuln expired, then asteroid hit. That's expected game behavior.

But now ship is dead (shipDead=true) and won't respawn until... wait, shipDead is never reset to false except in initGame/newShip. Let me check: initGame sets shipDead=false. On collision we set shipDead=true. But there's no code to respawn ship later! Bug. Let me check update: when lives>0 we create newShip and set state.ship=tmp and shipDead=true. But shipDead stays true forever, so ship never becomes playable again after first death!

I need to fix: shipDead should mean "waiting brief delay before respawn", then the ship becomes active again. Actually I used shipDead to prevent the ship from being drawn/updated. But respawn should re-enable ship. Let me remove shipDead complexity: after respawn, newShip has invuln>0 so it's protected. I don't need shipDead at all. Just replace ship with invulnerable one. The invuln blink handles protection. Let me remove shipDead entirely.

Let me review: In newShip, invuln set. In drawShip I return if invuln>0 blinking. That handles invuln. On collision, replace ship with newShip (invulnerable). No shipDead needed. Remove shipDead checks.

Also the asteroid respawn collision check uses `s.invuln <= 0`. Good, so immediately after respawn (invuln 2.4) the ship can't take another hit. Good.

Let me remove shipDead. Also, to make collision avoid immediate re-hit, newShip invuln covers 2.4s. Good.

Let me edit: remove shipDead in state, newShip block usage, update conditions, drawShip.

Actually simpler: keep field but just not set true. Let me remove references:
- state init: `shipDead: false,`
- update: `const s = state.ship;` and conditions `!state.shipDead`.

Let me just delete shipDead usage.

The iteration got messy with accidental corruption in the edit content. Let me do clean separate edits. First find the actual current file content around these areas.

The nudge lines were already removed in my earlier edit. Let me check the current file.

Clean. Now reload and test. The previous state had lives=2 with my earlier test. On reload initGame resets to 3 lives. But my held ArrowRight keydown state in the iframe — will it persist across reload? The new page load resets key state (fresh iframe/JS). But the physical key might still be "down" in browser. Better to press/release. Actually the browser tool key action only sends keydown (no keyup), so if I press ArrowRight it stays down. To test thrust, I press ArrowUp which also stays down. But both could be down simultaneously causing rotation+thrust, which is fine.

However, since keys persist as down, after reload the old iframe keybindings are gone, new page starts clean. Good.

Let me reload then test rotation + thrust + fire.

Plan: reload (fresh, 3 lives, invulnerable for 2.4s which gives time to test without dying). Immediately press ArrowRight (rotate), ArrowUp (thrust). Then after several frames inspect: expect angle > -90, velocity nonzero, ship moving. Then press Space to fire, inspect bullet count >0.

But note: invulnerability lasts 2.4s real time. Between reload and my key presses, some time passes. Should be fine for a quick test. Let me reload and immediately issue key presses.

Let me reload, then press ArrowUp a few times and inspect. But rotation needs ArrowRight. Let me do reload + key(ArrowUp) + key(ArrowRight) + inspect. Order: these are dependent on reload, so sequential.

Actually I can issue reload first, then in next block do the key presses and inspect. Let me do reload now.

Need frames to pass. Let me wait by issuing another inspect after a moment. There's no sleep, but issuing multiple tool calls gives time. Let me issue ArrowUp now (thrust) and then inspect. ArrowRight stays held; ArrowUp now held. Give a couple frames.

Lives dropped to 2 again and ship is at center (invulnerable, deadline). The problem: the generated asteroids spawn away from center (>170) but with wave of 5 and ship invulnerable for 2.4s... but between my tool calls, enough real time passes that invuln expires and an asteroid drift hits the centered ship. Since these asteroids drift, some come toward center.

The issue for testing: I keep dying before I can observe behavior, because too much wall-clock time passes between reload and my key events. The invulnerability is only 2.4s, but between reload and my first ArrowUp, many seconds passed (the tool round-trips).

Also note v stays (0,0) and a stays -90 — meaning the ArrowRight/ArrowUp didn't register before death reset state (respawn resets angle/velocity). Actually after respawn, state.ship replaced with newShip (a=-90,v=0, center). My ArrowRight/ArrowUp still held true (keys persist), so after respawn it should rotate/thrust. But then it collided again (lives went 3->2 means one hit). Wait after first respawn invuln 2.4s again. But it shows lives=2 meaning ONE death total since reload? Let me trace: reload->lives3. First key(ArrowRight)->3. key(ArrowUp)+inspect->2. So one death happened during that window, and ship respawned at center with invuln. Now ship is at center invulnerable blinking. keys ArrowRight+ArrowUp still held, so next frames it rotates and thrusts.

The death is because invuln from initial spawn (2.4s) expired during the gap between reload and my key presses, and an asteroid reached center. To verify momentum/rotation, I should test during a fresh invulnerable window. After the respawn just now, invuln=2.4s and keys are held. If I inspect quickly now, it will rotate+thrust and gain velocity.

Let me inspect now (frames passing with keys held).

Lives dropped again, to 1. The invulnerability is being consumed too fast between tool calls, or the asteroids keep hitting the respawned ship. Actually there's a possible issue: after respawn, the ship has invuln, but while invulnerable it's at center. But the collisions keep happening. Over ~8 real seconds (multiple inspect round trips) invuln expires and an asteroid hits.

The fundamental testing challenge: too much wall-clock between actions; asteroids drift to center.

I think I should remove the diagnostic timing problem by testing wrapping and momentum differently — but let me first just verify the actual mechanics by holding keys and sampling rapidly. The problem is each browser tool call round-trip takes 1-2 seconds, so invuln (2.4s) expires quickly.

Better approach: increase invuln time temporarily for testing, or spawn asteroids further. But I shouldn't distort the game permanently. 

Alternative: I can drive the game more deterministically for testing by directly setting state. But it's in closure, not accessible.

Let me temporarily set INVULN_TIME higher and spawn count lower for testing, verify, then revert. Actually simpler: temporarily move initial invuln larger so I have time, and maybe reduce asteroid speeds. Let me set newShip invuln to a big value temporarily. But initGame uses newShip with invuln = INVULN_TIME constant. Let me just temporarily change INVULN_TIME to 999 for testing then revert. But that also affects game over functionality... fine for testing.

Actually, let me just test the mechanics over a burst: I'll press ArrowRight then ArrowUp and immediately do a screenshot/inspect; but the real issue is the ~2s between consecutive tool calls exceeds invuln.

Let me temporarily raise INVULN_TIME to something large just for verification, confirm rotation/thrust/fire/wrap/split, then set it back to 2.4. I'll keep the edit and revert at the end.

Let me set INVULN_TIME = 60.

Only one frame passed; angle not yet updated. Need more frames. Let me issue ArrowUp (thrust) and another inspect. But also I want to sample rotation angle change. Let me do key(ArrowRight) again + key(ArrowUp) + inspect together.

Still a=-90, v=(0,0). The diag is updated each frame via rAF. But maybe the keydown events aren't being processed because the iframe isn't focused? The keys object listens on window of the game page. The browser tool sends keys to the page. But maybe the page needs focus. Also, perhaps the parallel key calls executed but rAF hasn't run an update since diag only refreshes in loop (rAF throttled when not visible?). If the tab is backgrounded/not visible, rAF throttles to ~0 or continues? In headless it may still run.

Actually the diag DID update across calls: earlier it showed lives decreasing, so rAF is running and updating. So the state is being updated across calls. But now after reload, keys ArrowRight/ArrowUp seem not registered.

Maybe the issue: my keydown handler for the game uses window listener. The key events from browser tool go to the focused element (the iframe document). They should bubble to window. But maybe focus is on the outer page, and the iframe isn't receiving keyboard. Earlier though lives dropped, meaning asteroids moved (update running). But ship didn't move because keys weren't registered from key events?

Hmm, earlier lives dropped due to asteroid collision at center while ship stationary — consistent with keys not registering (ship never moved). So maybe the browser key events never reach the iframe's window listener, OR the ship was dead/other.

Wait, but the game responds to keys in real browser use presumably. The test harness key tool sends keys to the page. Let me verify: maybe the keys ARE sent but the iframe doesn't have focus. In the earlier session, the ship stayed at center the whole time — never moved despite ArrowRight/Up pressed. So keys never registered. That strongly suggests keyboard events aren't reaching the game window in this harness, OR focus missing.

Let me check by clicking on the canvas first to focus, then pressing keys.

Let me click canvas (center) then press ArrowUp and inspect.

Still not registering. The key events aren't being delivered to the game window's keydown listener. Perhaps the browser tool's key action targets the top document, not the iframe's window. Since my listener is on the iframe's window, it won't hear it. But other sandbox iframes... hmm.

Wait, actually the whole game IS the page loaded. The browser tool loads index.html directly (not in an iframe)? The warning mentions iframe with allow-scripts. Maybe the harness injects the page into an iframe. In that case, key events at top level may go to top document, not the iframe.

Given I cannot get keyboard events to the game reliably in this harness, I should verify game logic via the diag by adding programmatic access — expose the update to be testable. But that's testing infrastructure.

Actually, let me reconsider: maybe keys attached to `window` but the focus issue. Let me try using the `type` action which simulates typing, or check whether setting focus via mouse click on canvas works. The click targeted 600,400 (canvas area). But canvas doesn't have tabindex/focus. Let me add tabindex to canvas and focus it. Actually the keydown listener is on window, so any focus within the document works as long as something in the iframe document has focus.

The problem is bringing the iframe document into focus. The click event in the harness might click within the iframe (since coordinates map to the iframe content, 1200x800 viewport). Wait the harness viewport is 1200x800 and rules say coordinates use 1200×800 viewport. The page content is in the full viewport? Canvas is 760 wide centered horizontally. x=600 is within canvas width range (centered margin). y=400 within. So click at 600,400 hit the canvas area. If the click registered within the iframe, focus would go there. But still key didn't register.

Let me verify the click did something — maybe add a click handler. Hmm.

Alternative: maybe the issue is that keys["ArrowRight"] uses e.key which is "ArrowRight" for real key but the harness sends... Actually real keydown events give e.key="ArrowRight". Should work.

Let me test whether ANY interaction reaches the page. I could add programmatic test hooks exposed to window so the harness can invoke them. But harness has no eval.

Given the limitation, let me instead verify logic through a different means: temporarily add auto-test code in the JS that simulates the required behaviors (rotation, thrust, fire, wrap, split) by directly calling into update with synthetic inputs, and log results to diag. That verifies the core game logic deterministically without needing the keyboard harness.

Actually, the task says "Verify: Test rotation, thrust, and firing near the initial spawn. Check that the ship changes heading, gains momentum, and emits moving projectiles." I can add a self-test that, on load, performs these operations programmatically and reports pass/fail in diag. Then I remove it for the final file.

But the keyboard events not reaching is concerning for real usage too. Wait — in real browsers, keyboard events DO reach the page when focused. The harness limitation is a testing-environment quirk, not a game bug. My code uses standard `window.addEventListener("keydown")`. That's correct for real usage. The harness just doesn't relay keys to the iframe.

But to be safe, let me make the canvas focusable and the document also handle keys at document level (which is same as window). Actually I could attach listener to both document and window to be safe. But it's window in iframe — for real users focusing the page it works.

Hmm, but let me reconsider: maybe the browser tool DOES send keys but the game's keydown handler's `e.key` check — let me verify the handler. It checks `["ArrowLeft","ArrowRight","ArrowUp","ArrowDown"," "].includes(e.key)`. That's fine.

Let me try the `type` action with a character to see if anything registers, or use a simpler approach: add a programmatic self-test harness to the code (temporarily) that exercises the logic and reports to diag. This is deterministic and conclusive. Let me do that.

I'll write a self-test function that runs a series of simulated updates with keys set directly, measuring heading/velocity/bullets/wrapping. Then display results in diag and remove afterward.

Let me add to the JS, after initGame, a TEST block. It will:
1. Reset state fresh.
2. Simulate dt steps
   - keys.ArrowRight=true for 0.2s -> record heading change
   - keys.ArrowUp=true -> record velocity increase
   - fire() call creates bullet -> record bullet count & bullet movement
   - wrapping: place ship near x=W, move a step, check x wraps to near 0
   - asteroid wrapping similarly
   - bullet lifetime: create bullet, age past BULLET_AGE, check removed
   - collision split: create asteroid, bullet hits, check splitting increases asteroid count & score
3. Report.

Let me implement by manipulating keys object and calling the internal functions. But they're in closure scope — the TEST block is in the same script scope so it can access them if I put it in the same <script>. Yes, I'll add it at the end of the script. It can access state, keys, update, fire, newShip, Asteroid, etc.

Let me write it.

Actually simpler: rather than a big test harness, let me just verify each behavior by direct manipulation and log concise PASS/FAIL lines.

Let me add the test block.

The self-test overwrites diag.textContent with results, but then the rAF loop continues and in `loop` I set diag.textContent to the state string, overwriting the test results! Because loop runs after and resets diag each frame. So I need to prevent loop from overwriting. Let me make loop only write diag if not testing, or capture test result into a global then re-append. Simplest: in loop, don't overwrite if a flag selfTestDone. But easier: move diag update to check. Actually the loop already ran initGame + rAF; the selfTest runs after setting diag. Then next frame loop overwrites.

Let me modify loop's diag line to preserve test output by storing test result in a global variable and always showing it. Or just have the selfTest set a module var `globalThis.__test = out.join(...)` and loop shows `(selfTest result)\n state`. 

Simplest: in the loop, replace diag.textContent assignment to prefix the preserved test string. Let me store result in a variable `let TEST_RESULT` in outer scope and in loop do `diag.textContent = (TEST_RESULT? TEST_RESULT : "") + "  " + stateString`.

Let me edit: change selfTest to set `TEST_RESULT = out.join(...)`. And in loop, reference TEST_RESULT if defined. And still need the state string each frame. Let me restructure.

6/7 pass. Test 3 fire: count=1 but bulletMoved=0. Why? Because bullet fired, but a frame update runs; bullet should move. Let me check test 3: after fire(), I step(0.05,5). bulletMoved = state.bullets[0].x - b0. b0 was position at fire. But wait, at fire the ship might be heading up (angle -PI/2 default), bullet vy = -520, vx ~0. So x change ~0 (movement mainly in y). So bulletMoved (x only) ~0. That's a test artifact, not a bug. The bullet DID move vertically. Let me fix the test to measure magnitude. Let me just record bullet position magnitude.

Actually easier: check bullet moved in y too. Let me fix test 3 to measure hypot of dx,dy.

Also worth verifying bullet in test 3 exists and moves. Let me update.

All 7 pass. Now let me verify a few more required behaviors via added tests:
- Lives reset / collision removes a life & ship protected from immediate repeat.
- Game over triggers overlay and restart resets.

Let me add these to the self-test. Also verify clear-all -> next wave.

Let me add tests 8,9,10.

8. collision removes life: set ship near an asteroid with invuln 0, update, check lives decreased by 1 and ship respawned invulnerable.
9. clear all -> next wave: set asteroids empty and let update detect... but startNextWave is called inside bullet-vs-asteroid loop when length 0. I can test by splitting last asteroid. Already test 6 produced ast=2. Let me directly test: state.asteroids=[last] and a bullet hits -> then asteroids.length===0 triggers startNextWave -> wave increments and spawns. Let me test: initGame, set ship invuln, assign one asteroid and one bullet on it, run one frame, check wave increased to 2 and asteroids repopulated.
10. game over: set lives=1, invuln0, collide -> lives=0, over=true, overlay shown.

Let me add.

Note: collision respawn sets invuln. For game over, overlay shows and restart button. Let me test overlay show.

Let me append these tests.

All 10 pass. Now remove the temporary self-test harness and the diag element, restore INVULN_TIME to 2.4. Also remove diag reference in loop.

Let me remove:
1. diag div in HTML.
2. `const diag = ...` line.
3. The diag.textContent assignment in loop (replace with nothing, since resource used for offline diag).
4. INVULN_TIME back to 2.4.
5. The whole self-test block (let TEST_RESULT ... initGame ... selfTest).

Let me find the current locations after my edits. Let me just do targeted edits.

First revert INVULN_TIME.
Then remove diag div.
Then remove `const diag` line.
Then in loop remove the TEST_RESULT/diag lines.
Then remove the self-test block from `let TEST_RESULT` through the end `})();`.

Let me read the relevant sections to get exact text.

The diag div indentation differs. Let me check line 92. It has two-space indent (since within #wrap? no, it's direct child of body). Let me use grep -n for exact. Actually edit[0] oldText didn't match because of indentation. Let me just remove the diag div separately with a simpler match.

Wait, that did nothing meaningful — I replaced the line with itself plus removing newline? That would merge the div onto next line. Actually replacing `<div...></div>\n` with `<div...></div>` removes the trailing newline, joining with next line `<script>`. Hmm that's messy. Let me check. Actually simpler to just remove the line entirely. Let me view around it.

The diag div is at line 92 (indented with 2 spaces). My edit didn't remove it. But the earlier edit removed the previous one? No, now grep shows it still there. Wait my previous edit "removed" the trailing newline only. It's still present at line 91-92. Let me remove this line entirely, and fix the other parts.

Now remove the self-test block. Let me find it from `let TEST_RESULT = "";` to `})();`.

Let me view what's just above line 416 to capture the closing of loop and the `let TEST_RESULT` line.

I need to remove from line 411 (`let TEST_RESULT = "";`) through the `})();` at line ~529, and restore `initGame();\nrequestAnimationFrame(loop);` at end. Currently the block is:

```
let TEST_RESULT = "";
initGame();
requestAnimationFrame(loop);

// ---- TEMPORARY self-test harness ----
(function selfTest() {
...
})();
```

I'll replace the whole region. Since it's large, I'll use bash to delete lines 411-529 and ensure initGame/rAF remain. But the initGame/requestAnimationFrame at 412-413 are inside the region. Let me restructure: keep the final `initGame(); requestAnimationFrame(loop);` after loop defined. Actually current structure already has initGame+rAF at 412-413, then self-test. If I delete the selfTest function and the `let TEST_RESULT` line and the comment, leaving initGame+rAF, that's exactly what we want.

Let me delete lines 411 and 415-529, keeping 412-414. Simplest: delete `let TEST_RESULT = "";` (line 411), and delete from the comment line through `})();`. Use sed in bash.

Line range: comment on line 415, selfTest ends at line 529 (`})();`). Let me verify line 529 is `})();`. Let me just remove lines 411 and 415-529.

Actually line count might shift. Let me use a python or sed command. I'll delete line 411, and delete the block from the comment line to the line matching `})();`.

Let me use sed to delete 411, then find the comment line number (now shifted by 1) and delete from there to the end before `</script>`.

Simpler approach: use an edit tool matching unique text spanning the whole block? That's large but let me just bash sed a line range. Let me determine lines now.

Clean. Now the file ends with `initGame(); requestAnimationFrame(loop);`. Let me verify the tail and check no leftover references anywhere.

All temporary code removed, INVULN_TIME back to 2.4. Let me do a final reload to confirm no JS errors (console only shows the sandbox warning).

No JS errors. The file is complete and self-contained. The sandbox warning is benign (harness iframe).

The task also mentioned "Check that the ship changes heading, gains momentum, and emits moving projectiles" and "Sample the scene to inspect screen wrapping". I verified these via the in-page self-test (removed afterward), which directly drove the update loop. Keyboard events couldn't be relayed into the sandboxed iframe by this harness, so I verified logic programmatically. In a real browser, the standard `window.addEventListener("keydown")` handlers (plus `preventDefault` on arrows/space) will work normally.

Let me also double check one thing: the game uses keys on window. Some environments require focus; but this is standard. Also I preventDefault for arrows/space which satisfies "prevent gameplay keys from scrolling the page." Good. Also I add preventDefault on keydown for the listed keys - yes.

One more: the task wants bullets lifetime bounded - verified. MAX_BULLETS limits firing. Also prevent rapid fire via fireCd? I defined FIRE_DELAY but didn't use it. Firing is limited by MAX_BULLETS and Space keydown fires once per keydown, so holding space fires repeatedly (repeat events) but capped at MAX_BULLETS in flight. That's fine. FIRE_DELAY is unused but harmless. Actually holding space causes key auto-repeat firing rapidly, capped at 5 bullets. Fine. I could remove FIRE_DELAY unused but harmless to leave.

Let me quickly confirm the file is self-contained (no external refs). It uses system fonts, no external resources. Good.

Let me provide final report. Each test checked:
1 rotation pass
2 thrust/momentum pass
3 fire emits moving projectile pass
4 ship wrap pass
5 asteroid wrap pass
6 split + score pass
7 bullet lifetime pass
8 collision removes life + protected respawn pass
9 clear all -> next wave pass
10 game over + restart reset pass

Unverified via harness: actual keyboard event relay into iframe (harness limitation) — but handlers are standard; page scroll prevention verified in code. Visual appearance not confirmed by screenshot (environment doesn't support images). Those remain unverified.

Done.