DEV Community: Dhardingsea Developer

Joy in the Build: What the Positivity Wall Taught Me About Making Anything

Dhardingsea Developer — Tue, 15 Sep 2026 03:54:07 +0000

I build a lot of things. Chrome extensions, games, internal tools for the day job, weird little browser experiments nobody asked for. Most of it is technical: state management, manifest permissions, load times, edge cases. But every so often a project reminds me that the point of building something isn't the stack you used — it's what it does for the person on the other end of the screen.

That's what happened with the Positivity Wall.

The idea behind it

The Positivity Wall (https://dhseadev.online/positivity-wall/) is a small, quiet corner of my site. No accounts, no typing, no names attached to anything. You show up, and your browser generates a procedural "stamp" — a little visual mark that's yours and yours alone, tied to nine shared panels: Small Wins, Someone Who Helped, Creatures, Made Me Laugh, Outside, On Repeat, Kindness Received, Still Learning, Showed Up. Come back tomorrow and your stamp is still there, identical, still yours. Nothing is uploaded, nothing is recorded beyond a shared count of how many people have marked something good.

It's a tiny piece of software. There's no monetization angle, no growth loop, no funnel. It exists because I wanted to build something that let people acknowledge a good moment without having to perform it for anyone.

The project leans on a philosophy I didn't invent: Amanda Gore's Joy Project. Gore is a Hall of Fame keynote speaker (CPAE, CSP) who's spent about 35 years and reached over 2 million people across 20+ countries with a simple, research-backed argument — feelings drive results. Her Joy Intelligence framework isn't fluff; the numbers she cites are things like a 37% boost in sales, a 51% reduction in turnover, and a 31% increase in productivity when people actually feel connected and joyful at work, instead of just "fine." Her core diagnosis is that most workplaces (and honestly, most people) suffer from emotional disconnection despite being constantly around each other. Belonging is supposed to be simple. We've made it complicated.

One line from her work anchors the Positivity Wall for me: "You are NOT your story, but your story rules your life." That's the whole reason the wall exists in nine small categories instead of one big blank text box. Give someone "Someone Who Helped" or "Made Me Laugh" as a prompt, and suddenly a good moment they'd have let evaporate becomes something they can point to. You're not asked to journal your trauma. You're asked to notice you laughed today, and that's allowed to be enough.

The candle, for the heavier days

Not everything is a small win, though. Some days call for something quieter. That's what the candle page is for (https://dhseadev.online/candle/?preview=true&frame-nonce=f833df8a41). One button: "Light the Candle." No typing, no sign-in, nothing recorded. You take a moment for someone or something that matters, the candle burns for as long as you're on the page, and then it's gone when you close the tab — like the moment itself. The only shared data point is a live count of how many candles are currently lit, so you know, in some small anonymous way, you're not the only one carrying something right now.

It pairs with Vigil, a Chrome extension I built that does something similar but persistent — candles that can be relit across days instead of disappearing the moment you look away. Same instinct, different shape: sometimes you need a moment, sometimes you need a place to keep coming back to.

There's a Futurama quote I keep coming back to that fits both of these projects better than anything I could write myself: "When you do things right, people won't be sure you have done anything at all." A tool that helps someone quietly feel better for thirty seconds isn't going to trend. It's not supposed to. It's supposed to just work, then get out of the way.

Why this matters for how you build anything

Here's the part that applies whether you're writing a Chrome extension, standing up a FastAPI service, or just doing your day job in a spreadsheet: joy and care aren't separate from craftsmanship — they're a design constraint like any other.

When Gore talks about emotional disconnection driving down performance, she's really talking about attention and trust. A team that feels safe and genuinely good communicates better and catches more problems before they ship. A user who feels respected — not tracked, not farmed for data, not nagged — trusts your product more and actually uses it. That's not a soft metric. It shows up in retention, in support load, in whether people recommend the thing at all.

I think about it at the code level too. A "no-friction, no-account, nothing-recorded" architecture isn't just a privacy stance — it's an act of care. It says: I don't need anything from you to let you have this moment. That constraint shaped every decision on both of these pages, the same way a performance budget or an accessibility requirement shapes a build. Joy, kindness, and consideration for the person on the other end aren't the opposite of rigor. Done right, they are rigor.

So whether you're serving legal documents, shipping a browser extension, or building a nine-panel wall of good moments nobody has to explain to anyone — leave room for the version of the work that makes someone feel a little more human when they're done with it. It costs you almost nothing as a builder. It can mean everything to the person using what you made.

Try the Positivity Wall: https://dhseadev.online/positivity-wall/
Light a candle: https://dhseadev.online/candle/

— DHSeaDev (dhseadev.online)

Sources:

Amanda Gore / The Joy Project: https://amandagore.com/
Amanda Gore speaker bio: https://premierespeakers.com/speakers/amanda-gore/posts/the-science-of-joyful-leadership-with-amanda-gore-insights-from-a-leading-motivational-speaker

CoderLegion - A good, yet different space

Dhardingsea Developer — Mon, 14 Sep 2026 13:45:25 +0000

I got interviewed on CoderLegion about my work and spent some time on the platform. Honestly, it's pretty solid.

It's smaller than DEV.to or LinkedIn, but that actually matters. You're getting real developers talking about real projects instead of engagement bait and recruiter spam.

The gamification stuff they do actually works because it pushes you toward connecting with people doing interesting things, not grinding points.

I came for exposure and got it. Found people worth talking to. I'm happy there, and that's rare.

If you care about actual developer community, it's worth checking out.

https://coderlegion.com/27044/from-html-legal-automation-dhardingsea-developers-journey-building-software-that-solves

Stress Test? Pen Test? Yes Tests!

Dhardingsea Developer — Sat, 12 Sep 2026 22:01:38 +0000

Why Your Game's Security Tests Need to Be Adversarial—Not Just Automated

Published on DHSeaDev. A hard-won lesson from shipping a browser-based TCG.

When we stress-tested Prismwar, our original gate suite reported everything was fine. Then we ran a mutation campaign, and 31 out of 70 carefully crafted bugs survived without raising a flag. Here's what went wrong—and how we fixed it.

The Test That Tested Itself

The first blind spot was the most embarrassing: our test harness shared defects with the code it was supposed to verify.

We had a replay system that recorded matches as a seed, both decks, and the player's actions. The Rival's moves are derived at playback time by running the same AI code. When we tested replay fidelity, we recorded and played back ten matches—and all ten matched perfectly.

Sounds good, right? Wrong.

The issue: our harness omitted the AI's defence step in the replay player, and our scripted human player omitted it in the recorder. So the test round-tripped through the same bug and agreed with itself. A round trip cannot test its own driver. Neither can it test its engine. We rebuilt the test to drive the AI's defence window directly and assert the match phase advances—that found it immediately.

The lesson applies everywhere: when testing a system that has two paths (encode/decode, server/client, record/replay), don't let both paths share the same code on the test side. Property assertions work. Round trips don't.

44% of Bugs Stayed Silent

The mutation campaign replaced 70 isolated lines of code with deliberate defects. 39 made the game unplayable. But 31 made the game fail silently:

Dropped guards: validateDeck checks deck legality before a match starts. We deleted the lower-bound check. The gate passed. Invalid 4-card decks loaded fine and then threw an uncaught error in checkWin as soon as someone attacked. The error boundary swallowed it into a "Something went wrong" message, and the assertion "no console errors" stayed green.
Discarded state: An attacker declared blockers but the code forgot to store which ones. The match proceeded as if nothing was blocked. Replays still worked and reproduced correctly (for the wrong reason—the entire engine had the same bug).
Unsigned profiles: The integrity check exempted unsigned saves to allow mid-session work before signing. An attacker simply wrote a JSON with no sig field, granting 720 cards and a million wins. It imported as integrity:'ok'.

Every one of these would have made it into production without sabotage-driven proof.

What Actually Worked

We stopped relying on "no crash" and "match outcomes are deterministic" as evidence. Instead:

Entry guards at the choke point. The game's state machine enters through newGame(). We made that the single place that refuses invalid inputs: non-array decks, decks under 10 cards, missing players. Everything downstream assumes the precondition is true. One sabotage per boundary, and each one must actually throw (not silently default). We verified that the guard itself catches that attack—not just that the game doesn't crash.

Property assertions instead of outcome comparison. Instead of "does the game end in 50 turns or fewer," we assert that the stall detector measures progress—and if you remove that measurement, the test fails. The property is "this mechanism exists and is consulted," not "bad state doesn't happen."

Pinned baselines for non-observable code paths. The AI engine has zero randomness once seeded. We computed a SHA-256 fingerprint over the outcomes of a 512-game corpus. Any change to the rules, the AI decision weights, or the game logic moves that hash. We assert it doesn't move. If it does, we decide to bump it—or revert. But "no change" is measured, not assumed.

Instrument-proved test instrumentality. Before we ran our 70 mutations, we proved the harness could see a break by installing an attacker key and verifying that it unlocked a legendary card it shouldn't. When we replaced the stall detector with a board-count check, we proved the harness caught it by deliberately deleting the right code and watching the test fail.

The Adversarial Mindset

Security tests are not about passing. They're about finding specific ways the code could fail and then proving you catch every one:

Write a defect (a mutation, a forgery, a code path omission).
Run the test to prove it catches the defect. If it doesn't, the defect is a gap.
Verify that removing the defence that catches it makes the test fail. If removing the defence doesn't move the needle, you have a false positive.
Keep the defect as a proof that the test was actually running.

This is inverse from "does my happy path work." You're asking: "What specifically am I refusing?"

For Prismwar:

ECDSA: we proved the harness detects payload tampering, signature forgery, and algorithm confusion. Nine attacks. All caught.
XSS: 350 real-UI trials on a stripped CSP, zero escapes (our HTML builder uses textContent, not string concatenation).
Determinism: identical results across three runs when entropy is disabled.
Persistence: crossing two concurrent save cycles doesn't lose data (a known limitation, documented as unreachable in the shipped UI).
State legality: illegal actions are refused with a clean Error, not a crash or silent skip.

What We Shipped

Final count: 122 assertions, 99 sabotages, 0 escapes, control green. The gates ran against a real build packaged for the Chrome Web Store. Not a best-case scenario. The actual game.

Three automated checks broke themselves in the process:

A brace-balance one-liner couldn't see regex literals or comments. Fixed with a real lexer.
An AWK scan counted lines across multiple files and reported false positives. Replaced with scoped iteration.
A "no console errors" assertion didn't discriminate real errors from false red runs. Now it routes the specific assertion to the relevant scope.

Ship It Adversarially

When you're shipping something that handles user data—saves, settings, payment—or something competitive where cheating matters, your test suite needs to be adversarial:

Can you add security properties that would break if someone removed the defense? If not, you don't have evidence the defense is real.
Do your round-trip tests share machinery with the code they're testing? If so, rebuild one path to go a different way.
Is your baseline pinned? A green build on "determinism" without a fingerprint is a hope, not a fact.
Did you prove your test is actually running? Before you trust a suite, break something on purpose and watch it fail.

Prismwar ships with a ledger wall where users post their best cards. That wall is read-only. The game's state is signed, and the signature is verified on load. Every one of these decisions is backed by a sabotage that proves what fails if you remove it.

That's not perfection. It's shipping with evidence.

Prismwar is live at play.dhseadev.online./ The gate suite is in the DHSeaDev arcade build at scripts/verify-prismwar.mjs and sabotage-prismwar.mjs on GitHub.

Developer? Engineer? Vibin'? What are we now?

Dhardingsea Developer — Fri, 11 Sep 2026 18:44:44 +0000

The Vibe Coder's Advantage: Why AI Just Made "Professional Developer" Meaningless

The term "software developer" used to mean something clear. You went to school, learned computer science, memorized algorithms, practiced for years, and eventually got hired. You had the credentials. You had the training. You were legitimate.

I'm not a software developer. I'm a vibe coder.

I didn't go to school for this. I learned by building things—usually because I needed them to exist and nobody was going to make them for me. I built Chrome extensions because I had ideas. I built internal tools at HSPS because my colleagues needed them. I built my own way into competency through intuition, experimentation, and a willingness to look stupid in front of my code.

And honestly? That approach just became way more viable for everyone.

What's a Vibe Coder?

A vibe coder learns through construction, not curriculum. You feel your way through problems. You don't need to understand the platonic ideal of an algorithm—you need to know what works right now. You ship first, optimize later. You fail forward. You're driven by curiosity and immediacy rather than foundational theory.

Traditional software developers learn the opposite way. Theory first, application second. Algorithms, data structures, design patterns, architecture—you build a mental model of how systems should work, and then you implement against that model. It's rigorous. It's principled. It's often slower.

Neither is wrong. They're just different operating systems for the same skill.

But here's what's changed: AI just collapsed the activation energy for becoming a vibe coder.

The Democratization Moment

Two years ago, if you wanted to build a Chrome extension and didn't know how, the friction was brutal:

You'd learn JavaScript from scratch
You'd learn the Chrome API surface
You'd hit weird bugs and spend hours debugging documentation
You'd rewrite things three times because you didn't understand the patterns

Today? You describe what you want to Claude or ChatGPT, iterate in real-time, and the system generates the code. You learn by reading what the AI wrote, not by struggling through a tutorial. You're still vibe coding—you're still learning by building—but the friction of "not knowing how" is gone.

This is huge. And I don't think the industry has internalized what this actually means.

It means anyone with curiosity and an idea can now be a developer. Not "kind of" or "technically." Actually. You can ship real, functional tools without a CS degree. Without years of practice. Without memorizing JavaScript event loops.

That's not hyperbole. That's where we are.

What This Means for "Professional" Developers

Here's the uncomfortable question: if AI can generate code, and vibe coders can now ship production tools, what exactly is a "professional developer" providing?

The answer is judgment.

A professional developer (whether they're a vibe coder or classically trained) brings:

Taste: knowing what solutions are over-engineered vs. undercooked
Tradeoffs: understanding the cost of every architectural decision
Sustainability: building systems that don't collapse under maintenance
Security: catching the vulnerabilities AI missed
Empathy: writing code that other humans can understand

None of these things require a degree. None of them require formal training. But they do require experience—which is just a fancy word for accumulated failure.

The AI doesn't fail. It just generates. A human who's shipped a dozen projects and watched three of them break in production has something the AI doesn't: scars.

The Future Isn't "No Developers"

I've heard the fears: "AI will replace developers. In five years, nobody will need to code."

I think this misunderstands how tools work.

When the printing press arrived, people didn't stop writing. Writers became more valuable because the distribution layer solved itself. The bottleneck moved upstream. Same with spreadsheets—Excel didn't kill financial analysis, it killed the human calculator and elevated the analyst.

AI won't kill developers. It'll kill tedious code. It'll eliminate the friction between "I have an idea" and "this tool exists."

What it means for the future:

More tools will exist. Not because we have more developers, but because the activation energy disappeared. Anyone with a problem can become a developer.
Quality will matter more. When everyone can generate code, the projects that survive will be the ones built with actual judgment and care.
Vibe coding becomes the default. You'll be able to build without understanding formal computer science, which is democratizing and scary at the same time.
"Developer" becomes a meaningless title. It'll matter less what you're called and more what you've shipped and whether it breaks.

The Uncomfortable Truth

Here's what actually keeps me up: will the industry adapt to this? Or will it double down on credentials and gatekeeping?

Right now, there's a lot of resistance. "Real developers know algorithms." "You can't ship production code without understanding systems design." "AI-generated code is garbage."

Some of this is true. Some of it is just people protecting the value of the credential they paid for.

The vibe coders are about to have a decade. People who can feel their way through problems, who learn by shipping, who don't need permission to build—those people are about to be unstoppable. Because the thing holding them back (the friction of not knowing how) just evaporated.

The professionally trained developers will adapt or won't. The ones who lean into judgment, mentorship, and architecture thinking will become more valuable. The ones who relied on their credential and their ability to memorize syntax will find themselves competing with a free AI that doesn't forget.

What I Actually Am

I don't have a CS degree. I learn by building. I've failed at more projects than I've shipped. I think in problems, not algorithms. I'm inefficient in ways that a classically trained developer would notice.

But I can ship things. I know what feels right. I can look at code and know whether it'll break in six months. And I can do all of that now faster because I have an AI thinking partner.

That doesn't make me a "real developer" in the old sense. But increasingly, I think the old sense was always wrong.

Maybe the future isn't about becoming a developer. Maybe it's about becoming someone who can think clearly about problems, and then having the judgment to know when to use which tool—including the AI—to solve them.

That was always what development was about anyway.

Check us out at Dhseadev.online

What do you think? Are you a vibe coder or a systems thinker? Have you seen this shift play out in your own work? Drop a comment—I'm curious how other people are adapting to this moment.

I set an 18-hour playtime target for my idle game. A simulation says it has 3.7

Dhardingsea Developer — Fri, 11 Sep 2026 14:10:04 +0000

Ashline is an idle army-vs-army battler I'm building for my browser arcade (not public yet). You get five unit roles, enemy waves that hit back, offline progress, a champion with skill trees and a collection of officers you recruit.

Before putting it in front of people, I wanted a number instead of a feeling. How long does a realistic player take to run out of new things to unlock? My target was 18 hours.

Simulating a player instead of guessing

I already had a headless engine and a reference player for balance testing, so playtime.js puts the two together. The simulated player plays 20 active minutes a day, closes the tab and comes back tomorrow. It records the moment each of the game's 20 achievements first unlocks.

Offline time isn't a multiplier. It runs the actual combat loop at reduced efficiency, so being away advances waves. That's capped at 8 hours.

// the shape of it (simplified)
while (unlocked.size < ACHIEVEMENTS.length && day < MAX_DAYS) {
  for (let t = 0; t < 20 * MIN; t += TICK) {
    referencePlayer(S);            // buy, rally, recruit, prestige
    tick(S, TICK);
    activeTime += TICK;
    for (const a of ACHIEVEMENTS)
      if (!unlocked.has(a.id) && a.test(S)) unlocked.set(a.id, activeTime);
  }
  settleOffline(S, DAY - 20 * MIN); // real combat, reduced efficiency, capped
  day++;
}

The first version hung. The bug wasn't in the game. My reference player had unbounded while loops for recruiting and spending points. They're capped at 200 iterations now.

The result

9 of 20 achievements unlock in the first 40 minutes.
All 12 officers are collected by 1.3 hours.
The last unlock lands at 3.7 active hours.

That's about five times short of the target.

The obvious fix is the wrong one

The quickest way to hit 18 hours is to multiply every threshold. Same unlocks, just further apart.

That adds grind, not playtime. The simulation measures when you run out of new things, and stretching the thresholds doesn't create any. The gap is content.

So I added content, and the number got worse

The biggest addition was Onslaught, a separate mode for the champion:

12 named waves, then Endless
one life, and no full heal between waves
after every cleared wave, pick one of three boons drawn from a pool of 24
boons last only for that run
marks (the champion's progression currency) are banked when you die

I tuned it so a fresh champion dies around wave 2 in about 30 seconds, and an invested one reaches 20+.

Then I re-ran the playtime simulation: 3.1 hours, down from 3.7.

Onslaught banks marks, and marks buy the champion progression that unlocks achievements. So the new mode wasn't a new ladder. It was an accelerator bolted onto the old one. The achievements are still tied to the army's wave counter. A new mode needs goals of its own, like run depth and build variety, or it only shortens the path to the same finish line.

Why "no full heal"

In the main mode, when your army hits 0 HP it routs: it falls back two waves, heals fully and keeps going. An idle game shouldn't dead-end while you're away.

The balance suite exposed a side effect. I had written a test claiming "the champion alone cannot progress." That claim is false by construction. With a full heal after every rout, anything with regeneration can grind forever. I replaced it with a comparative test (the army must out-progress a lone champion by a margin) and built Onslaught so that death actually ends something.

Splitting the modes quietly broke two tests

Taking the champion out of army combat left two balance bands meaningless, and one of them still looked great:

"No dominant skill tree" reported 90 / 90 / 90 / 90. Perfect balance, apparently. In fact, the four trees no longer touched army combat, so every build was identical.
The spell band read 0 / 0, because spells no longer buffed the army.

I retired both rather than leave them green. Eight Onslaught-specific bands replaced them: the stakes are real, investment helps monotonically, the ladder is beatable, no boon dominates, no boon is dead, death is final, marks scale with depth, and a draft follows every clear.

Two more things measuring caught

Correlated randomness. Recruiting rolls a rarity, then an officer within that rarity. Both rolls used the same index into the seeded generator, so they were correlated: 7 out of 7 rares came out as the same officer. Deriving a separate index fixed it, and I checked the fix over 10,000 pulls. Pulls stay deterministic on (seed, pull number), so reloading a save can't reroll a result.

An optimization I didn't make. Officer effects get recomputed several times per tick, and I had flagged it for memoization. Profiling put it at 5.69µs per tick, 0.034% of a 16.7ms frame. Shipping that "fix" would have been claiming a win that didn't exist, so I cut it.

What's next

Achievements tied to Onslaught depth and build variety, so the new mode extends the ladder instead of shortening it.
Real attack classes. The five army roles currently fight identically. Only their HP, armor, regen and splash differ, while the names and the 2.5D ranks suggest melee, ranged and magic. That's the biggest gap between how the game looks and how it plays, and it's an engine change that invalidates every balance band, so it gets its own tuning pass.
Then re-run playtime.js.

The number I didn't want was the most useful thing the simulation produced. 3.7 hours doesn't say the game is bad. It says where the game ends, and that adding a mode isn't the same as adding somewhere to go.

Three of my test gates had never heard of the game I was shipping

Dhardingsea Developer — Fri, 11 Sep 2026 03:47:52 +0000

My browser arcade at play.dhseadev.online deploys when I push to main. Nothing ships unless verify-all.sh prints ALL GATES PASS. This week I was adding a ninth entry, a card game called Prismwar (not live yet). I built it, the index listed it, dist/ contained it.

Three of the gates in that suite had no idea it existed.

The list that didn't grow

The arcade is driven by one table, ENTRIES. The build reads it, and so do the index, the sitemap and llms.txt. Three test scripts didn't: the boot/paint/save gate, the stress battery and the SEO-heading gate. Each one had its own hardcoded list of pages, written back when the arcade was smaller.

So the new row got built, emitted and linked, and none of those three scripts ever loaded it. They reported on everything they knew about, and all of it passed. Nothing in the output was false. It just described a smaller arcade than the one I was shipping.

// what the gates had (simplified)
const PAGES = ['prism-cascade', 'lumenreel', 'veilfall' /* ...frozen in time */];

// what they should have
import { ENTRIES } from '../build.mjs';
const PAGES = ENTRIES.map(e => e.id);

For today I added the missing rows by hand. After that the full run included Prismwar and passed. The real fix is deriving every gate's list from ENTRIES, so a new entry can't be built without also being tested.

This wasn't a one-off. The same week, an idle game I'm building for the arcade gave me five more green results that weren't telling the truth.

A sabotage that everything catches proves nothing

Ashline, an idle auto-battler, has an "instrument proof": break the engine in specific ways on purpose, then confirm the balance suite goes red for each one.

The first run caught four sabotages out of four, and every one reported the same thing: the army stalled at wave 1.

That's what gave it away. Four different breakages shouldn't produce one identical symptom. The unbroken game was also stuck at wave 1, because of a cold-start bug where the starting army did zero damage. The suite wasn't detecting my sabotage. It was detecting a softlock that was already there, four times over.

The fix was a control. Run the unbroken build first and require it to pass. A sabotage only counts as caught if the baseline was green and the broken build fails a check that fits the breakage. After that, each sabotage tripped its own band.

Buttons that exist vs. buttons you can press

Ashline's DOM smoke test was 13 for 13: boot, five buy buttons, accessible names, HUD updates, save writes, offline settle, graceful storage failure.

I opened the game and saw a line across the screen with nothing to click.

On load, the game called buyLoop(). That's the automated player the simulation uses in place of a human. It spent the opening currency before first paint, so every buy button rendered disabled. The test checked that the buttons existed and had names. It never checked whether anyone could press one.

I added four assertions:

an action is available at load
a purchase is affordable at load
the starting grant hasn't been spent
clicking alone clears wave 1 within 12 seconds

Then I put buyLoop() back into load() on purpose. The suite dropped to 15/17, failing on exactly the two grant checks. That's when I started trusting it.

Three asserts that couldn't fail

The quieter version of the problem is an assertion that can't go red at all:

A gravity check for particles that returned true no matter what. It never read velocity before and after a step. Now it does, and it measures +90 vy per 0.1s at G=900.
check('champion drawn larger', true). A literal. I wrote it, and it would pass on a blank canvas forever.
A reduced-motion check that passed for the wrong reason. The attack has a 250ms cooldown, so the second call was refused, and "motion on" and "motion off" looked identical. Once I fixed that, the test failed on the good build. The harness pins Date.now() to 0, so the cooldown never cleared. That's two harness bugs and zero game bugs.

The literal became a spy that records what the renderer actually received:

// passes forever
check('champion drawn larger', true);

// passes only if the renderer actually did it (simplified)
const heights = [];
const draw = Champion.draw;
Champion.draw = (ctx, x, y, h, ...rest) => { heights.push(h); return draw(ctx, x, y, h, ...rest); };
renderLine(); renderArena();
check('champion drawn larger in arena', heights[1] > heights[0]);

The real numbers are 52px on the battle line and 86px in the arena.

The copy that was a version behind

Ashline also has a delivery-path check. It runs the balance bands against the engine extracted from the built HTML, not the source module, because the HTML is what players get.

Good idea, bad execution. My extracted copy of the sim was stale. It predated the army-combat rewrite, so it reported 7 bands under an old label when the real suite had 10. Now both derived files are regenerated from the build on every run, and a copy is never reused.

What I check before I believe a green run

Does the gate's inventory match the product's? Compare what it tested with what shipped.
Was the control green, and did each break fail differently? If every break fails the same way, you're looking at one bug that was already there.
Does the assertion test use, or just existence? "The button exists" and "the button can be pressed" are different tests.
Can I make it fail? Break the thing on purpose. If the test stays green, the test is the bug.
Is the artifact current? Regenerate anything derived. A stale copy tests yesterday's build.

Then open the thing. A gate caught every problem above except the unplayable build. I found that one by clicking on it.

A passing gate is making a claim. The only way I've found to check that claim is to watch the gate fail first.

I added scroll animations to three live pages — and silently corrupted two of them

Dhardingsea Developer — Fri, 04 Sep 2026 20:37:46 +0000

What I was adding

Three DHSeaDev project pages — Dota Companion, Annoying Dino, CaptureTools — were due for scroll animation. Nothing exotic: GSAP 3.12.5 plus ScrollTrigger, cards fading up as they enter the viewport, a screenshot strip that parallaxes on scroll. GSAP went fully free for every plugin at some point this year, which is the only reason this was worth doing at all.

The site has no build step and no staging environment. Every page is a single WordPress Custom HTML block, and every edit is a raw REST write against the live URL. That constraint is what made the next two hours interesting.

The pin that would not hold still

Before touching a real page, I ran a spike on a private draft: pin a card in place while the user scrolls past it, the standard ScrollTrigger pin: true pattern. It failed in a specific way — the pinned element didn't stay pinned. It drifted, about 1,260px over the course of the scroll, like the browser was measuring its position against the wrong coordinate space.

It was. The site's page wrapper does a full-bleed break-out:

.dhsea-page {
  position: relative;
  width: 100vw;
  left: 50%;
  transform: translateX(-50%);
}

Any element with a transform on it becomes a new containing block for its fixed/absolutely-positioned descendants. ScrollTrigger's pin mechanism auto-detects which positioning strategy to use, and its detection doesn't account for an ancestor transform three levels up. It picked the wrong one and pinned against the wrong reference frame.

I didn't trust that read until I had a control. Same test, same page structure, no transform wrapper — the pin held at the exact same offset across the whole scroll range. Then the fix, on the transformed version:

ScrollTrigger.create({
  trigger: '#target',
  pin: true,
  pinType: 'transform',   // stop guessing
  pinReparent: true,
});

Rock solid, matching the control exactly. On this site, any pinned ScrollTrigger needs pinType set explicitly — auto-detect is not safe inside a transformed containing block, and it fails silently enough that you won't notice until you're staring at drift.

The bug my own length check couldn't see

The actual write recipe for a single-block page looks like this: fetch the block's raw content, splice new markup in at a verified anchor, check that the output is exactly original length + inserted length longer, then POST it back. That last check is supposed to be the safety net — if the delta doesn't match exactly, something touched more than intended.

It passed. Every time. And it was still wrong.

Here's the part I missed: the page's content.raw already comes back from WordPress with its own ... wrapper — sometimes three separate ones, stitched together. My splice was correct. But then, out of habit, I wrapped the result in a fresh pair of those comments before sending it, because that's what you do when you're building a block from scratch. I wasn't building one from scratch. I was editing one that already had its wrapper attached.

The length math still balanced, because I was adding a fixed, known amount of text and checking for exactly that much growth — the check never asked where the growth was structurally valid, only that the total was right. The result: two pages ended up with a duplicated block boundary, four open comments and four closes where there should have been three of each.

Nothing rendered wrong. WordPress strips every  comment at render time, so the live HTML was byte-identical either way. That's exactly why it survived a "did the page look right" check. It only surfaced when I diffed an independent re-fetch of the stored content against the literal string I'd sent — same length, same bytes, and still wrong, because "wrong" here was a structural property the byte-length gate was never built to see.

// wrong: re-wraps content that's already wrapped
const body = { content: '<!-- wp:html -->\n' + out + '\n<!-- /wp:html -->' };

// right: content.raw already carries its own wrapper(s) — send the splice directly
const body = { content: out };

The fix was mechanical once I saw it: strip the one extra layer, re-POST, re-verify block count. The lesson is the gate, not the bug — a length check only proves the size is right. It takes a structural check (here, counting block-comment pairs) to prove the shape is right, and I'd been treating "the math balances" as proof of both.

A "free" plugin that was not

The last page, CaptureTools, called for a small SVG path-draw animation on its icon — GSAP's DrawSVGPlugin, part of the "everything's free now" bundle. Except it isn't served from the same place as the rest of GSAP. The plain gsap package 404s on it, on both CDNs I tried. It only resolves from a package literally named gsap-trial.

I opened the file before shipping it. No hard expiry that I could find, but the internals still reference "trial" and "club" — leftovers from before the license changed, maybe, or maybe not. Either way, I wasn't going to ship a script named trial to a page real visitors load, on the strength of "probably fine." Swapped it for a plain scale-and-fade reveal using the ScrollTrigger already on the page. Same restraint, no unverified dependency.

What I'd verify differently next time

Three separate failures, three different shapes: a physics assumption that broke against a CSS property three ancestors away, a correctness check that measured the wrong dimension of "correct," and a dependency that was free in spirit but not in its actual distribution. None of them showed up by looking at the rendered page. All three showed up by re-fetching the thing I'd actually stored or actually shipped, and checking it against something more specific than "is it the right size" or "does it look fine."

The length gate isn't wrong. It's just not sufficient on its own — and on a site with no staging environment, "sufficient" is the only bar that matters, because there's no second chance to catch it before a visitor does.

Found while shipping dhseadev.online's GSAP rollout, September 2026.

My first Firefox add-on was a manifest change

Dhardingsea Developer — Sun, 30 Aug 2026 03:02:53 +0000

KH4 Companion is a small extension I built: it counts down to Kingdom Hearts IV, puts the days remaining on the toolbar badge, pulls series news and trailers from public feeds, carries a lore compendium, and hides a three-lane rhythm minigame in the popup. It has been on the Chrome Web Store since 19 August. As of this week it is also on addons.mozilla.org, which makes it my first Mozilla listing.

I had been putting the port off, because "port" sounds like work. It was not. Same build, same version number, same feature set — what changed was four keys in manifest.json. This is the writeup I wanted to find before I started.

The thing nobody tells you first

The blocker is not your code. It is that AMO rejects the package before it ever shows you a listing form. So the order of operations is: fix the manifest, get the linter to zero errors, then worry about icons and screenshots and copy. Assets built against a package that cannot upload are wasted.

npx addons-linter@latest <extension-dir> is the gate. Run it before you touch anything else.

1. Firefox needs an explicit add-on ID

Chrome derives an extension ID for you. Firefox does not — in MV3 you must state it:

"browser_specific_settings": {
  "gecko": { "id": "kh4-companion@dhseadev.online" }
}

The email-ish form or a {8-4-4-4-12} GUID both work. Pick carefully: this ID is your update identity forever. Changing it later means a new listing, not an update.

2. There are no extension service workers in Firefox

This is the real difference, and it is smaller than it sounds. Firefox runs an event page where Chrome runs a service worker. background.service_worker is simply ignored, with a BACKGROUND_SERVICE_WORKER_IGNORED warning. The cross-browser answer is the dual key:

"background": {
  "scripts": ["core/lib.js", "background.js"],
  "service_worker": "background.js"
}

Chrome reads service_worker. Firefox reads scripts. One file, both browsers.

Two traps live in here, and both pass a manifest review and fail at runtime:

importScripts does not exist in an event page. If your service worker starts with importScripts('core/lib.js'), that is a ReferenceError on Firefox. The fix is to list the dependency in background.scripts before the entry file and guard the call:

if (typeof importScripts === 'function' && typeof KH_CORE === 'undefined') {
  importScripts('core/lib.js');
}

The second half of that condition is not paranoia — it stops a double-load if some future Firefox does provide importScripts.

Script order is load order. background.scripts executes top to bottom in one shared global. A dependency listed after its consumer is undefined at module top level. Chrome's import graph forgave you; an array does not.

While you are in there: no window, no document, no self.clients in the background. Write to the intersection of both runtimes.

3. Declare what you collect

Since November 2025, every new AMO extension has to declare its data collection in the manifest. It is machine-readable and Firefox shows it in the install prompt.

"browser_specific_settings": {
  "gecko": {
    "data_collection_permissions": { "required": ["none"] }
  }
}

["none"] is the whole declaration when nothing leaves the device — which for this extension is the truth: no analytics, no account, no telemetry, everything in local extension storage. If data does leave, you list types (browsingActivity, personallyIdentifyingInfo, and friends) and they had better match your privacy policy and your description word for word. A reviewer reading three different stories about your data handling is not a style problem, it is a rejection.

This was the key I most enjoyed filling in. Answering an honest none took about four seconds and is the payoff for having built the thing without a tracker in it.

4. `strict_min_version` is arithmetic, not a guess

Three floors stack up, and you take the highest one that applies to you:

Constraint	Floor
Certificate expiry (updates break below)	115 ESR / 128
Dual-key background actually starts	121
`data_collection_permissions` supported	140 desktop / 142 Android

Below 121, Firefox refused to start the background page at all when service_worker was present. And declaring the data-collection key under a lower minimum earns you KEY_FIREFOX_UNSUPPORTED_BY_MIN_VERSION warnings. If you are shipping a new MV3 add-on with the data declaration, 140 is the value that lints clean with no version warnings. Go lower only if pre-140 reach is worth carrying the noise.

Also worth knowing: omit gecko_android and you are desktop-only, which may be exactly what you want.

Lint clean is not loaded

The linter is static. Load the thing for real: about:debugging → This Firefox → Load Temporary Add-on → pick manifest.json. Open the popup, exercise the background path, and watch the Browser Console for a ReferenceError. A green lint plus an add-on that never boots is the precise failure the dual-key trap produces.

A few runtime differences that survive a clean lint, in case they bite you where they did not bite me: host permissions are user-grantable and revocable rather than install-time; Firefox maintains a quarantined-domains list where an extension is inert until the user opts it in; web_accessible_resources supports resources/matches/extension_ids but not use_dynamic_url; and chrome.* works in Firefox as an alias, so you do not need the polyfill unless you want promises on old Chrome.

What actually made it cheap

The port took the time it did because of decisions made months earlier, none of which were about Firefox.

The extension has no bundler and no framework. That means the code AMO receives is the code I wrote, which means no source-code submission — the requirement that kicks in when minification or bundling makes the shipped file hard to read, and that ends with a reviewer rebuilding your project and diffing the result. Staying unbundled skipped that gate entirely.

The logic modules are pure: no DOM, no clock of their own, time passed in as an argument. They run identically in Node tests and in the extension, which also means they run identically in a service worker and an event page. There was nothing browser-specific hiding in the parts that matter, because the parts that matter never touched a browser API.

The background is a relay. It holds no durable state, so the service-worker-versus-event-page distinction — which is mostly a distinction about lifetime and what survives a restart — had nothing to disagree with.

I did not do any of that so I could ship on Firefox. I did it because it made the thing testable. The second store was the dividend.

KH4 Companion is an unofficial fan project. It is not affiliated with, endorsed by, or connected to Square Enix or Disney, and it ships no game assets, no logos and no copyrighted text — all art and all compendium prose are original.

Firefox · Chrome · Project page and privacy policy

Five Tools, Zero Interference - CaptureTools Isolation Architecture

Dhardingsea Developer — Fri, 28 Aug 2026 03:00:04 +0000

Building five separate tools inside a single Chrome extension sounds straightforward until you realize it's a recipe for disaster. Without deliberate isolation, one tool's storage leaks into another's, message handlers step on each other, and a single runtime collision brings everything down.

This post walks through four structural mechanisms that keep CaptureTools running smoothly—no tool interference, no data leaks, no architectural finger-pointing.

The Problem

A single Chrome extension is one runtime, one message bus, one storage layer.

When five tools run in that space, they're sharing everything:

chrome.storage.sync (the same key namespace)
Message event listeners (all broadcasting to the same channel)
Content script registry (one global scope)

Without boundaries, tool A's data ends up in tool B's key namespace. Tool C's message handler fires on tool D's request. Unregistering one tool leaves the others hung. It's not if something breaks—it's which failure mode hits first.

The Solution: Four Isolation Layers

1. Storage Isolation via Prefix-Locked Adapters

Every tool gets a dedicated storage key prefix:

ct:sealshot:state
ct:backtrack:history
ct:lantern:settings

A storage adapter wraps calls to chrome.storage.sync and enforces the prefix on every read and write. If Sealshot somehow tries to touch ct:backtrack:state, the adapter rejects it.

This isn't about trust. It's about making mistakes structurally impossible at the API boundary.

// Example adapter interface
const storageAdapter = {
  get: async (keys) => {
    // Prefixes all keys with tool ID before calling chrome.storage.sync
    const prefixed = keys.map(k => `ct:${toolId}:${k}`);
    return chrome.storage.sync.get(prefixed);
  },
  set: async (items) => {
    // Enforces prefix; rejects any attempt to cross the boundary
    const prefixed = Object.fromEntries(
      Object.entries(items).map(([k, v]) => [`ct:${toolId}:${k}`, v])
    );
    return chrome.storage.sync.set(prefixed);
  }
};

The pattern is lightweight. Tools use the same storage API they'd use anywhere else; the isolation just sits underneath.

2. Message Addressing by Tool ID

Chrome's message API broadcasts listeners across the extension. Any script can send a message; any listener can receive it.

CaptureTools routes by tool ID. Every message carries a tool field:

// Sending
chrome.runtime.sendMessage({
  tool: 'sealshot',
  action: 'capture',
  data: { ... }
});

// Receiving
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  // Only process messages meant for this tool
  if (msg.tool !== 'backtrack') return;
  // Handle message...
});

This prevents broadcast storms, message handler collisions, and one tool accidentally triggering another's side effects. It's a simple protocol, but it moves responsibility to the caller—and that's exactly where it belongs.

3. Database Namespacing

CaptureTools uses IndexedDB for larger datasets. Each tool gets a separate object store namespace:

// Sealshot's stores
const sealshot_cache = db.createObjectStore('sealshot_cache');
const sealshot_metadata = db.createObjectStore('sealshot_metadata');

// Backtrack's stores
const backtrack_history = db.createObjectStore('backtrack_history');
const backtrack_snapshots = db.createObjectStore('backtrack_snapshots');

A database adapter wraps all IndexedDB calls and routes them to the correct namespace. One tool's query never touches another tool's data.

This layer is especially critical because IndexedDB doesn't have built-in ACLs. Namespacing is the only control plane.

4. Content Script Lifecycle Management

When a tool is disabled, its content scripts must unregister completely.

CaptureTools tracks which content script belongs to which tool and performs full cleanup:

Deregister from the message bus
Clear DOM state
Remove event listeners
Unsubscribe from runtime events

// Cleanup on disable
const unregisterTool = (toolId) => {
  // Remove all message listeners for this tool
  chrome.runtime.onMessage.removeListener(
    handlers.get(`${toolId}_messageHandler`)
  );

  // Unregister content scripts from tabs
  chrome.tabs.query({}, (tabs) => {
    tabs.forEach(tab => {
      chrome.tabs.sendMessage(tab.id, {
        tool: toolId,
        action: 'unregister'
      }).catch(() => {}); // Tab may not have script
    });
  });
};

This prevents ghost listeners firing on messages meant for other tools and orphaned state lingering after uninstall. It's the most underrated failure mode: a tool that's gone in the UI but still listening in the background.

Design Tradeoffs

This architecture trades runtime overhead for complete failure isolation:

Runtime cost: Adapter calls, namespace checks, lifecycle management
Benefit: A tool crash doesn't cascade. Storage errors in one tool don't corrupt others.

It's not zero-cost, but it's predictable, testable, and scales with the number of tools.

Questions?

This is a working implementation. Things might shift as tooling evolves. If you have questions about isolation strategy, multi-tool extension design, or how this compares to other approaches, I'm curious to hear your thoughts.

For you: If you're building a multi-tool extension or wondering how to keep separate systems in one runtime, does this pattern help? If you're using CaptureTools and curious about stability, now you know.

Also—if you're building something similar, what's your isolation strategy? I'd love to know what works for you and what doesn't.

Read the full post with examples and FAQ: https://dhseadev.online/2026/08/27/capturetools-isolation-architecture/

Counting down to a date that does not exist

Dhardingsea Developer — Wed, 19 Aug 2026 13:51:53 +0000

I build small Chrome extensions under #DHSeaDev, and the newest one is a fan project: KH4 Companion, an unofficial countdown to Kingdom Hearts IV — days-left toolbar badge, series anniversary milestones, news and trailer feeds, a lore compendium in original prose, and a three-lane rhythm minigame called Keyblade Strike. It's packaged at 0.2.0 and the Chrome Web Store listing is in preparation. Three design problems turned out to be interesting.

The target is a window, not a date

Kingdom Hearts IV has no release date. It has a window — Late 2027 — and a countdown app that pretends otherwise is lying with a number. So the countdown carries two modes on its face: window mode, which counts to a conservative end-of-window anchor and says so in its label, and date mode, which activates only when a real announced date is entered in settings. The storage listener flips the toolbar badge the moment the setting changes. The dishonest version of this feature is one line shorter, and I wrote it first.

A countdown you can unit test

The countdown module never calls the clock. Time arrives as an argument — computeRemaining(nowMs, target) — and the module has no DOM, no chrome.*, and no fetch, so the same file runs in Node tests and in the extension unchanged. The service worker is relay-only: it holds no durable state, wakes on a six-hour alarm to re-render the badge text, and everything it knows it reads back out of storage. Milestones are the same shape — an annual month/day pair plus a pure next-occurrence function — so the anniversary list is testable across year boundaries without mocking anything.

Feeds without a backend

News and trailers come from public feeds — KHWiki, Reddit, Google News, YouTube — fetched directly from the popup with credentials: 'omit', so no cookie ever rides along. Responses cache in chrome.storage.local for fifteen minutes, and every cache write goes through a per-key serialize queue, because two concurrent refreshes doing read-modify-write on the same key is exactly the storage race that has bitten this shelf of extensions before. When a feed is down, the panel serves the stale cache and says it's stale — which beats an empty panel every time.

A fan project's honesty posture

This is an extension about somebody else's story. So the project page carries a "what is ours, and what is not" section stating the line plainly: Kingdom Hearts belongs to Square Enix and Disney; series names appear in the extension as facts about the series; every line of compendium prose is original writing with a KHWiki source link; the art — in the extension and in the store assets — is original, with no game assets and no character likenesses anywhere. The store listing will say the same thing in the same words.

The listing chip on the project page reads exactly what's true today: in preparation, not submitted. When it clears review, the chip becomes a button.

Project page (features + full privacy policy): https://dhseadev.online/projects/kh4-companion/
The rest of the shelf: https://dhseadev.online/projects/

I hand-built four things my tooling already shipped. The command I never ran was `catalog`.

Dhardingsea Developer — Tue, 11 Aug 2026 13:25:55 +0000

A build log about agent skills, HTML-to-MP4 video, and the specific cost of not reading the manual — with measured numbers."

The setup

The extension is Dota Companion — a Dota 2
stats popup that also prices your Steam inventory. I needed intro videos: a 30 and a 60 for
YouTube, shorts for TikTok.

The stack is HyperFrames (Apache 2.0) — HTML and
CSS in, MP4 out, no bundler. You write a composition as a plain HTML file, declare timing with
data-* attributes, register one paused GSAP timeline, and a headless Chrome + FFmpeg pipeline
renders it. It's genuinely good for agent work because the artifact is a file an agent can read
and edit, not a React tree it has to reason about.

I also keep a personal "skill" file for it — a markdown doc the agent loads that carries facts
about my environment, as opposed to facts about the framework. The framework has its own docs.
Mine holds things like "this install flag hangs in a non-TTY shell."

Round one was bad in an instructive way

First pass: screenshots on a gradient, an animated outline ring around whatever the narration
was naming, a caption bar, a slow zoom.

Two problems, both visible in the first render:

The ring sat on the text. At video scale a 3px border plus a glow lands on the glyphs of
the thing it's pointing at. The highlight was actively making the subject harder to read.

It looked like a slideshow because it was one — a flat rectangle pasted on a gradient,
with a Ken Burns zoom.

Round two: the fixes that actually worked

Focus became a hole, not a ring. Instead of drawing on the subject, dim everything
except it:

.spot {
  position: absolute;          /* sized to the measured target rect */
  border-radius: 10px;
  box-shadow: 0 0 0 4000px rgba(4, 7, 14, 0.58);
  outline: 1.5px solid rgba(126, 198, 232, 0.85);
  outline-offset: 3px;
}

The scrim is the shadow this box casts outward, clipped by the device frame. The lit region is
negative space, so it is geometrically incapable of covering the text it points at. This is
the Apple/Samsung how-to grammar — the frame goes quiet, the subject stays lit.

Coordinates got measured, not eyeballed. The screenshot script records
getBoundingClientRect() for every control the video will point at, normalised to the image:

rec.targets[key] = {
  cx: (box.x + box.w / 2) / vp.width,
  cy: (box.y + box.h / 2) / vp.height,
  w: box.w / vp.width,
  h: box.h / vp.height,
};

Reading coordinates off a rendered PNG by eye puts the highlight next to the button, and
nothing downstream can detect that.

Depth became three planes. Ambient gradient → the same screenshot blown up and blurred
behind the device (colour spill) → the crisp shot in a window with a chrome bar and a real
shadow. Light behaving like light is what reads as modern; a drop-shadow alone reads flat at
video scale.

Seams got a rulebook. One direction for the whole film, every cut landing mid-motion on
both sides with mirrored power4 eases, and exactly one reserved "arrival" vector spent on
the payoff beat.

Before / after, same product, same screenshots:

Before: https://www.youtube.com/shorts/6oBcZolFoDQ
After: https://www.youtube.com/shorts/SQRhmxUIYlc

The numbers that changed how I plan

Three measurements did more for my throughput than any visual change.

Render cost is dominated by one CSS property. check reports
browserGpuMode probe → software — no GPU, every frame rasterised on CPU:

Composition	Wall-clock
Flat planes, no full-frame filters	~3–4× realtime (63.9s film → 3m17s)
One blurred backdrop plane + `backdrop-filter`	~10–23× realtime (64.2s film → 21m39s)

Same film, same length, ~6× apart. A four-film set cost 43 minutes of wall-clock. That's not a
detail, that's the shape of your afternoon.

Script length is arithmetic. Across 33 TTS segments — 338 words, 131.5 seconds — the rate
was 2.57 words/sec. So a 60-second film is about 144 words. I wrote my first 60s script by
feel; it measured 92 seconds. 53% over, and a full regeneration of every segment.

Three lint errors fire on every first build. gsap_exit_missing_hard_kill (a fade ending
on a clip boundary needs a matching tl.set or a seek restores stale visibility — it fired 7×),
duplicate_media_discovery_risk (two <img> sharing a src; the documented failure mode is a
blank render), and text_occluded (a caption inside a clip paints under any overlay declared
after the clips — DOM order decides).

And one no linter catches: exit opacity has to land exactly on the cut. Fading at 55% of
the exit travel left ~0.14s of empty stage between every scene — four black frames per seam,
passing every automated check.

I wrote all of this into the skill file. Felt good. Version 1.3.0.

Then I ran one command I'd never run

Later, unrelated, someone asked whether I could use stock footage or animated characters. So I
went looking at what the tooling could actually reach:

$ npx hyperframes catalog --json
358 items    # 145 blocks, 213 components

Three hundred and fifty-eight prebuilt, installable motion components. hyperframes add <name>
drops one into your project as a local sub-composition with a paste-ready snippet.

Here is what was in there:

What I hand-built	What already existed
A GSAP proxy tween counting a number up	`apple-money-count` — counts up, flashes green, bursts money icons with sound
CSS device chrome with three fake traffic lights	`device-frame-stage`, or `macos-tahoe-liquid-glass` — a real 3D laptop with a screen slot
A blurred backdrop plane for fake depth	`camera-dolly-zoom` with focal length solved per frame; `rack-focus` with real aperture bokeh
Hand-timed emphasis on headlines	`char-slam-explode`, `caption-particle-burst`, `confetti`, `vfx-shatter`

Four for four. Better versions of all of them. Sitting behind a command I never ran because I
went straight from "read the authoring docs" to "write the composition."

The honest kicker: the before/after above was won entirely by hand. Not one frame of it
uses the registry. I found the registry after those videos shipped. The visible improvement
came from craft; the invisible waste came from not shopping first.

What I actually changed

The skill file gained a section that now runs before any authoring:

Shop the registry BEFORE hand-authoring motion. 358 items. catalog --json first — the
bare form times out per-item. Skipping this is the single largest waste measured in this
skill's history.

Plus a routing table for the things I'd been guessing at: humanoid presenters route to an
avatar-video path (which needs an interactive OAuth login — a human action, not something an
agent can complete headlessly); a 3D rigged character is flatly not viable on a 2-core,
no-GPU box when a CSS blur alone already costs 20× realtime; stock footage is legally clean
from Pexels but works as texture, not actors; and extracted game assets are a hard no.

And I cut it down while adding that. The file went 264 → 236 lines, because a comparison table
re-arguing a decision I'd already made, and a ## Requirements section holding two commands,
were both bloat.

The transferable bit

The lesson isn't "read the docs." I read the docs. I read the authoring model, the data
attributes, the determinism rules — and then implemented, from those primitives, four
components that shipped in the box.

The docs told me how to build. Nothing prompted me to ask what already exists. Those
are different questions and I only asked the first one.

If you're pointing an agent at an unfamiliar framework, the highest-leverage line you can put
in its instructions isn't a code sample. It's: inventory the catalog before you write
anything.

Weather that cannot touch the game: building an ambient layer that stays out of the way

Dhardingsea Developer — Mon, 10 Aug 2026 14:50:43 +0000

A 1D spring water surface, wind gusts drawn as one polyline, and an aurora faked with three additive strokes — plus the one comment in the file that explains a bug I would otherwise have shipped."
tags: javascript, canvas, gamedev, webdev

I built a small Chrome arcade game called Prism Cascade. You throw light-orbs at crystal prisms, the shards fall into a pool, and every splash throws up bubbles carrying points. Thirty-second rounds. The gameplay is deliberately tiny.

The part I want to write about is the part that does nothing.

Underneath the game there is a layer of wind, mist, aurora, drifting motes, fireflies and fish. It is the first thing anyone comments on and it has zero effect on play. That was the design constraint, and it turned out to be the thing that made the whole layer cheap to build and impossible to break.

Here is the entire declaration:

// ============================== Ambient world (visual only — no gameplay physics) ==============================
const fish = [], gusts = [], mist = [], foamBlobs = [], fireflies = [], motes = [], spires = [], drops = [];

Eight arrays. No classes, no entity system, no update graph. Let me go through the three that were actually interesting to write.

1. The water surface is a row of springs, and it wants to explode

The pool is not a sine wave. It is a 1D array of columns, each with a height and a velocity, coupled to its neighbours — the classic Hugo Elias water model that has been floating around demoscene articles since about 2000.

const water = { cols: [], n: 0, spacing: 6 };

function initWater() {
  water.n = Math.max(40, Math.floor(W / water.spacing));
  water.cols = new Array(water.n).fill(0).map(() => ({ h: 0, v: 0 }));
}

function disturbWater(x, power) {
  const i = waterIndex(x);
  water.cols[i].v += power;
  if (water.cols[i - 1]) water.cols[i - 1].v += power * 0.6;
  if (water.cols[i + 1]) water.cols[i + 1].v += power * 0.6;
}

Each frame, every column gets a Hooke restoring force toward zero, gets damped, and then leaks energy into its neighbours over two passes:

function stepWater(dt) {
  const k = 0.025, damp = 0.976, spread = 0.14;
  const hMax = 34 * S, vMax = 46;
  const c = water.cols;

  for (let i = 0; i < water.n; i++) {
    const col = c[i];
    col.v += -k * col.h;
    col.v *= damp;
    if (col.v > vMax) col.v = vMax; else if (col.v < -vMax) col.v = -vMax;
    col.h += col.v * dt * 60;
    if (col.h > hMax) col.h = hMax; else if (col.h < -hMax) col.h = -hMax;
  }

  for (let pass = 0; pass < 2; pass++) {
    for (let i = 0; i < water.n; i++) {
      if (i > 0)             { const d = (c[i].h - c[i - 1].h) * spread; c[i - 1].v += d * 0.5; c[i].v -= d * 0.5; }
      if (i < water.n - 1)   { const d = (c[i].h - c[i + 1].h) * spread; c[i + 1].v += d * 0.5; c[i].v -= d * 0.5; }
    }
  }

This looks fine and is not fine. Run it for a while with a lot of splashes and the surface develops a shimmering sawtooth — every column high, its neighbour low, alternating all the way across the pool. It does not decay, because the neighbour-coupling term is what is feeding it: at that wavelength each column is always being pushed away from both of its neighbours simultaneously.

That is the Nyquist mode. It is the highest frequency the grid can represent — one full wave every two columns — and an explicit integrator on a coupled grid will happily pump energy into it forever.

The fix is three lines and a comment I left in on purpose:

  // spatial smoothing — kills the alternating-column (Nyquist) instability mode
  // while preserving long-wavelength waves
  let prev = c[0].h;
  for (let i = 1; i < water.n - 1; i++) {
    const smoothed = (prev + 2 * c[i].h + c[i + 1].h) * 0.25;
    prev = c[i].h;
    c[i].h += (smoothed - c[i].h) * 0.55;
  }
}

A 1-2-1 kernel is a low-pass filter. At the Nyquist wavelength it has almost no gain, so the sawtooth is annihilated. At the long wavelengths you actually want — the roll of a wave crossing the pool after a big splash — it barely does anything. Blending at 0.55 rather than replacing outright keeps a little crispness.

The prev variable matters more than it looks. Reading c[i-1].h directly would read the already-smoothed value from this same pass, which turns a symmetric filter into a directional one and makes waves drift left. Caching the pre-smoothing value is the difference between a filter and a bug.

Two clamps are also doing quiet work. vMax stops a single enormous splash from launching one column into orbit, and hMax bounds the visual amplitude so the surface can never draw outside the pool. Neither is physical. Both mean the sim cannot produce a frame that looks broken, no matter what the game throws at it.

2. Everything couples through exactly one function

Fish leaping, waterfall droplets landing, crystal debris hitting the pool — all of it reaches the water through disturbWater(x, power) and nothing else.

// a fish landing
disturbWater(f.x, 4);

// a waterfall droplet, only sometimes
if (d.y > G.waterY) {
  drops.splice(i, 1);
  if (Math.random() < 0.12) disturbWater(d.x, 0.7);
}

// debris from a shattered crystal
disturbWater(x, Math.min(26, 6 + energy * 9));

One integer of API surface. The ambient systems do not know about each other, do not know about the game, and cannot be broken by either. When I later changed how splash energy was calculated, the water sim needed no edits — it only ever sees a number.

That Math.random() < 0.12 on the droplets is worth calling out. Ninety pixel-streaks a second all ringing the surface produces mush, not rain. Letting roughly one in eight actually strike gives you distinguishable individual rings and, incidentally, cuts the work by 88%. Sparse is both cheaper and better looking, which is not a trade-off you get very often.

3. Wind is one polyline, and the aurora is three strokes

I did not want a particle system for wind. Particles for wind look like snow.

A gust is a single object with a lifetime, and it is drawn as one 26-segment polyline whose vertical offset is a sine wave — with the amplitude tapering along the tail so it looks like it is trailing off rather than ending:

const segs = 26;
for (let i2 = 0; i2 <= segs; i2++) {
  const px = g.x - g.dir * i2 * 13;
  const py = g.y + Math.sin((g.x - g.dir * i2 * 13) / g.wl + g.age * 2)
                 * g.amp * (1 - i2 / segs * 0.4);
  i2 === 0 ? cx.moveTo(px, py) : cx.lineTo(px, py);
}
cx.stroke();
// little curl at the head
cx.beginPath();
cx.arc(g.x, g.y + Math.sin(g.x / g.wl + g.age * 2) * g.amp, 7, Math.PI * 0.2, Math.PI * 1.5);
cx.stroke();

One stroke, one arc, per gust. A new gust arrives every 4 to 10 seconds, 70% of the time from the left, and self-culls when it leaves the screen. There are usually one or two on screen and often none — the gaps are what makes it read as weather rather than as an effect that is always on.

The aurora is the same trick applied to glow. No shader, no blur filter, no offscreen canvas:

cx.globalCompositeOperation = 'lighter';
for (let rib = 0; rib < 2; rib++) {
  const baseY = H * (0.1 + rib * 0.07);
  const hueA = rib ? 280 : 160;
  for (let pass = 0; pass < 3; pass++) {
    cx.globalAlpha = (game.reduceFx ? 0.03 : 0.05) * (3 - pass);
    cx.lineWidth = 18 + pass * 16;
    // ... two summed sines, sampled every 36px
  }
}

Three passes: progressively wider, progressively fainter, drawn additively on top of each other. That is a bloom. It costs six strokes a frame sampled every 36 pixels, and it is convincing because real glow is a stack of decreasing intensities at increasing radii — you do not need to compute it, you can just draw it that way.

The ribbon shape is two summed sines at different frequencies and opposite time directions. One sine reads as a mechanical wobble. Two never quite repeat.

The rule that made all of it safe

Every one of these populations is bounded:

if (mist.length < 40 && Math.random() < 0.5) { /* spawn */ }
if (drops.length < 90) { /* spawn */ }

36 motes, 8 fireflies, 5 fish, 15 spires, 1400 particles hard cap. Not one of them grows with time, level, score or how long the tab has been open. The frame cost of the ambient layer at minute one is the frame cost at hour three, which is precisely why I never had to profile it.

There is one deliberate asymmetry. The rock spires on the horizon are generated from a seeded RNG:

const srng = L.mulberry32(0xA17A);

while everything else uses Math.random. The skyline is the same every single session; the weather in front of it never repeats. That split is the whole feel of the thing — a fixed place, with something moving through it.

Where reduced-motion actually landed

prefers-reduced-motion maps to a game.reduceFx flag, and I will be honest about how far it goes, because "we support reduced motion" is a claim people make loosely.

It gates the things that move fast or arrive suddenly: wind gusts stop spawning entirely, waterfall droplets stop spawning, fish stop leaping, and the aurora drops from 0.05 to 0.03 alpha. It does not gate the slow continuous drift — mist, motes and fireflies keep going.

That is a judgement call, not an oversight. The vestibular-trigger guidance is about large, fast, unexpected motion, and a mote drifting four pixels a second is not that. But it is a judgement call, and if someone tells me it is the wrong one, the flag is already threaded through every spawn site — it is a one-line change per system.

Prism Cascade is a 30-second physics arcade for Chrome. It makes zero network requests, asks for exactly one permission (storage), and the Chrome Web Store listing is still in preparation at the time of writing.

Watch it in motion: https://www.youtube.com/shorts/6oBcZolFoDQ
Full write-up, mechanics and privacy policy: https://dhseadev.online/projects/prism-cascade/
More things I have built: https://dhseadev.online/projects/

Built solo — physics, rendering, sound and the level generator are all hand-written, no engine and no third-party libraries.