A bullet leaves a mark: pooled decals in the engine's scene, and each game says what a hole looks like #284

Shoot a wall and it forgets you in a quarter of a second. src/client/scene.ts:212 draws an impact for 0.25 s and nothing stays, so a room that has had a firefight in it looks untouched — you cannot read where you have been shooting, where a teammate sprayed, or which corner is being watched. Bullet holes are a large part of why a Counter-Strike wall reads as a wall, and they are engine work: all three games want them and none of them should own the pool.

Done looks like

• [ ] src/engine/scene.ts gains a decal pool on exactly the terms the instance pool already states: made once at a capacity, refilled, never grown, nextDecal answers null when it is spent, and nothing allocates in a frame. Decals outlive a frame, so resetScene does not clear them; expireDecals(scene, now) drops by age and rewrites indices the way expireEffects does.
• [ ] A decal is plain data and knows no game: a position, the surface normal it lies on, a size, a rotation, a uv rect into whatever atlas the game handed the renderer, and a birth time. No material, no colour name, no weapon.
• [ ] The renderer draws them in one instanced pass, oriented to the normal, with a depth bias that does not z-fight at the far end of the map, blended, and costing one skipped call when the list is empty.
• [ ] The shooter places one wherever a shot's trace ends on level geometry and not on a player, with the uv rect chosen from the material it hit — src/client/materials.ts already names nine — and blood stays what it is.
• [ ] The capacity is a number stated and justified in src/client/scene.ts beside the others, and oldest-out at capacity is what a player sees rather than a hole that refuses to appear.
• [ ] Engine tests that would fail without this: the pool hands out exactly its capacity and then null, nothing is allocated after creation, expiry keeps the newest and rewrites indices, and a renderer test asserts the pass is skipped when there are none.
• [ ] The frame holds: src/budget.test.ts and src/frames.test.ts pass, and the pull states the measured scene-build and frame time with a wall of decals up against the same numbers without.
• [ ] The door grows: new names in src/engine/index.ts, the pinned list in boundary.test.ts, bun run scripts/surface.ts --write for the version, and the scene and renderer sections of GUIDE.md saying what a decal is and what a game supplies.
• [ ] The golden digests in src/client/replay.ts do not move. Decals are drawing, not simulation — a digest that changes means something leaked into the world.
• [ ] Both other games are weighed: a tool set ships whole, so say what the pass costs the range's and the example's bundles even though neither places a decal, and move their ceilings in src/games.ts only with the measured numbers beside the reason.

Files I expect to change

src/engine/scene.ts, src/engine/renderer.ts, src/engine/index.ts, src/engine/boundary.test.ts, src/engine/surface.json, src/engine/GUIDE.md, src/client/scene.ts, src/client/materials.ts, the tests beside each, src/games.ts if a ceiling moves.

Risks

• #279 (contact shadows) is the same pool and the same pass. Whichever lands second rebases onto the first rather than merging around it; if #279 is in flight, read its branch before starting.
• Depth bias is the part that looks wrong on someone else's GPU: bias along the normal in world space rather than trusting polygonOffset alone, and say in the pull what you tried.
• A decal that survives a map change or a round reset is a bug: state where they are cleared.

Suggested: Vesper.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.