DEV Community: Dhardingsea Developer

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.

HTML in, MP4 out: rendering a video with HyperFrames instead of an editor

Dhardingsea Developer — Sun, 09 Aug 2026 14:46:52 +0000

Originally published on dhseadev.online.

I did not open a video editor to make this. I described a video, and the agent stack I run every day rendered one.

That is a 13-second vertical short about how many items in a Dota 2 inventory are actually sellable. Every frame of it came out of an HTML file.

What HyperFrames is

HyperFrames is HeyGen's open-source HTML-to-MP4 renderer. Apache 2.0, Node 22+, FFmpeg on PATH. Its README is basically three sentences: write HTML, render video, built for agents.

The authoring model is the whole pitch:

A composition is a plain HTML file. No bundler, no JSX, no build step.
Timing and track assignment ride on data attributes.
Motion comes from whatever seekable animation approach you already know — GSAP, native CSS animations, Lottie, Three.js.
Preview runs in a browser. The final render is headless Chrome driving FFmpeg.

Nothing in that list requires learning a framework, which is exactly why an agent can drive it. The artifact is a file it can read and edit directly, not a component tree it has to reason about through a compiler.

Versus Remotion

Remotion is the obvious comparison and it is a good tool aimed at a different room.

	HyperFrames	Remotion
Authoring	HTML + CSS + seekable animation libs	React components
Build step	None	Bundler required
License	Apache 2.0	Source-available; paid company license past a size/revenue threshold
Agent fit	Plain files an agent reads and edits	Needs React/JSX fluency

If your codebase is already React, stay in React. If the thing holding the pen is an agent, the no-build option wins on the only axis that counts: how many layers sit between the instruction and the pixels.

Three failures, in the order they cost me

1. The installer hangs. The plain install command opens an interactive multi-select picker. In a normal terminal you press space a few times and move on. In a non-TTY agent shell it never returns, and there is no error to read — the process just sits there. Pass the non-interactive flags and redirect stdin from /dev/null.

2. Chrome is not bundled. The doctor command tells you this immediately, which is the entire argument for running doctor first. It is the cheapest possible way to learn what is missing, and it costs one line. Then fetch the headless shell before you try to render.

3. The CDN fails silently, and this is the real lesson. The scaffold pulls GSAP from a CDN. A render container frequently has no outbound network from Chrome even when the shell does — proxied shell, unproxied browser. The script never loads, the timeline registry is never populated, and the render produces a static or blank video with a passing exit code.

Not a warning. Not a non-zero status. A file that exists, plays, and is wrong.

curl -s -o vendor/gsap.min.js https://cdn.jsdelivr.net/npm/gsap@3.14.2/dist/gsap.min.js
# then reference ./vendor/gsap.min.js from the composition

Same rule for fonts and images. Local files only, never hot-linked. I had "host media locally" written down as hygiene. It is not hygiene — it is a silent-failure class, and the difference between those two words is whether you find out before or after you publish.

Narration decides the cuts, not the other way around

The instinct is to author the visuals and then lay voice over them. That desynchronises by the third frame, every time, because an estimated duration and a rendered duration are different numbers and the error compounds.

So the order inverts:

One audio file per sentence, rendered separately.
Measure, never estimate. ffprobe -v error -show_entries format=duration -of csv=p=0 seg.wav. Do not trust a reported length you did not measure.
Concat with a fixed gap. Roughly 0.28–0.32s between segments reads as natural breathing. Less sounds rushed, more sounds like a dropout.
Derive cuts cumulatively: start[i] = start[i-1] + dur[i-1] + gap. Those offsets become each clip's timing attribute.
Mux after render. Render silent, then combine — and verify both streams survived, because a muxed file that lost its audio track still plays perfectly and you will not notice on a machine where you already know what it is supposed to say.

Two runs, measured: eight segments produced 28.90s of video against 28.904s of audio. Nine segments produced 58.26s against 58.26s. That is what deriving from measurements buys you instead of eyeballing.

The part that is not about video

None of the above is hard. All of it is forgettable, which is worse, because a forgotten step here does not fail loudly — it ships a blank video with a green exit code.

So none of it lives in my head. It lives in a skill file: a short instruction document the model loads when the task matches. Mine is deliberately thin — it installs the upstream skill pack and defers to it rather than reimplementing the framework's own workflows badly. What it holds is only the stuff that cost a failed run: the non-interactive install flags, the doctor-first order, the vendoring rule, and the audio-first timing sequence.

Sitting above that is a routing layer that picks which skills load for a task and which checks can block the result before any work starts. I wrote about how that orchestrator layer works separately. One of those checks is the one that matters most here: it will not let me call a video finished because a command exited zero. Both streams present, or it is not done.

The pattern generalises well past video. Every one of those files exists because something failed silently once and I did not want to pay for it twice.

A skill is a receipt for a mistake.

The video itself

The numbers in the short come from Dota Companion, a Chrome extension I build that reads public Dota 2 match data through the free OpenDota API and turns it into things worth knowing about your own play. 833 items in an inventory, 183 of them sellable. It works as a short precisely because it is one number against another number, and that is the shape that survives a vertical crop.

If you try HyperFrames: run the doctor first, vendor everything, generate the audio before you write a single timing value, and verify the output file rather than the exit code. Four rules, and every one of them exists because I broke it first.

I asked an agent to make a product video. It wrote HTML and rendered an MP4 - Dota Companion

Dhardingsea Developer — Sat, 08 Aug 2026 22:24:54 +0000

I needed two videos for a Chrome extension I built: a promo and a walkthrough. I did not want to open a video editor.

So I used HyperFrames — HeyGen's open-source (Apache 2.0) HTML-to-MP4 framework. Compositions are plain HTML and CSS. No JSX, no bundler, no build step. Timing lives in data attributes; motion comes from GSAP. A headless Chrome seeks the timeline frame by frame and FFmpeg encodes it.

That design matters for one specific reason: an agent can read and edit a plain HTML file. It cannot meaningfully iterate on a timeline in a GUI.

Both videos below were authored as HTML, narrated with a local TTS model, and rendered locally. Here's what came out, then the three things that actually cost me time.

The promo (29s)

The walkthrough (58s)

Numbers, for calibration: 1080×1080, 867 frames for the promo, 56 seconds to render. The walkthrough took just over 2 minutes. Both passed the framework's check gate — 0 runtime errors, 0 layout issues, and 22/22 and 23/23 WCAG AA contrast checks respectively.

Failure 1: the CDN script that fails silently

The init scaffold pulls GSAP from a CDN:

<script src="https://cdn.jsdelivr.net/npm/gsap@3.14.2/dist/gsap.min.js"></script>

My render container proxied the shell but not the browser. curl worked. Chrome had no network.

So GSAP never loaded, window.__timelines was never registered, and the render would have produced a static video — with a zero exit code and no error. Nothing in the output says "your animation library is missing."

curl -s -o vendor/gsap.min.js https://cdn.jsdelivr.net/npm/gsap@3.14.2/dist/gsap.min.js

Vendor everything. Fonts too. This is the failure mode I'd most expect someone else to hit, because it doesn't announce itself — you just get a video where nothing moves, and you assume you wrote the timeline wrong.

Failure 2: timing the cuts before generating the audio

My first instinct was to write the storyboard, assign each frame a duration, then generate narration to fit. That's backwards. Speech doesn't land where you guess it will, and the drift compounds — by the third frame the voice is talking over the wrong slide.

Invert it. Generate audio first, one file per sentence, and read the real duration of each:

npx hyperframes tts seg/s1.txt --voice am_michael -o seg/s1.wav --json
# → {"durationSeconds": 4.48, ...}

Then derive every cut point cumulatively — start[i] = start[i-1] + dur[i-1] + gap — and let those offsets become the data-start values. A 0.3s inter-segment gap reads as natural breathing.

Result: a 28.90s video against 28.904s of audio, and 58.26s against 58.26s. No drift, no nudging.

Render silent, mux at the end, and verify both streams actually exist:

ffmpeg -i video.mp4 -i vo.wav -c:v copy -c:a aac -shortest out.mp4
ffprobe -v error -show_entries stream=codec_type out.mp4

That last check matters — a mux that silently drops the audio stream still produces a file that plays.

Failure 3: real screenshots when the browser has no network

The framework is strict that screenshot slots hold real captures, not mockups. Correct rule. But my capture environment couldn't reach the API, so loading the extension gave me an empty UI.

The wrong fix is to mock the interface. The right one is to fetch the real payload out-of-band and seed it through the app's own cache path:

await page.evaluate(d => new Promise(r => chrome.storage.local.set({
  settings: { refreshOnOpen: false },     // the app's documented cache-only path
  ['cache:123']: { ts: Date.now(), ...d } // shape the app itself writes
}, r)), realData);
await page.reload();

Real data, real render code, real pixels. Two conditions make this legitimate and both are required: the data is genuinely fetched, and the cache shape is one the application actually writes. Invent a shape the app never produces and you're fabricating a screenshot.

One caveat I'd underline: inspect every offline capture. Mine painted the full dashboard but left one field empty. Ship that to a store listing and it reads as a broken product.

An honest note on the content

The first cut of the promo showed my real stats — including a 0 improvement streak and a loss streak — directly under narration about tracking improvement.

I swapped the shot rather than faking the numbers. Worth saying out loud, because the tempting move when your generator can produce any frame you describe is to describe a better one.

Would I do it again

For this job, yes. The whole pipeline is text: HTML, CSS, a script file, and CLI verbs. Everything is diffable, re-renderable, and re-narratable by changing a sentence and re-running. Editing a word of narration is editing a text file, not re-recording.

It is not a replacement for a real editor when you want craft. It's very good at "generate this deterministically and regenerate it when the product changes" — which is most product video.

The extension in the videos is Dota Companion — free, local-first Dota 2 stats. More of my projects at dhseadev.online.

WordPress Ate My && — Making a WordPress.com Blog Multiplayer with playhtml

Dhardingsea Developer — Sat, 08 Aug 2026 20:34:26 +0000

My site, dhseadev.online, runs on WordPress.com. Managed hosting, block theme, no server code of my own. It is the least likely candidate for real-time multiplayer you can imagine.

It now has a shared toy room where visitors drag glyph magnets around together, a positivity wall where strangers leave stamps that persist for everyone, an arcade page with a live chat, and — as of this week — a "read receipt" card at the bottom of every blog post, where you can stamp that you read it and see how many other humans did too.

Zero backend. Zero plugins I wrote. One open-source library, one CDN <script>, and a short list of WordPress-specific traps that each failed silently — which is the part worth writing down.

The library: playhtml

playhtml (by Spencer Chang) gives you collaborative HTML elements with a single data attribute. Put can-move on a div and every visitor can drag it — and everyone sees everyone else's drags, live, with the position persisted. can-spin, can-grow, can-duplicate do what they say. can-play is the escape hatch: you define defaultData, an event handler that calls setData, and an updateElement renderer, and playhtml syncs the state object across every open browser via PartyKit.

The mental model is: a tiny shared JSON document per element, keyed by page URL. No auth, no database, no deploy.

That per-URL keying sounds like a limitation. It turned out to be the whole design.

Rooms are per-URL, and that's a superpower

playhtml scopes shared state to the page it lives on. Move an element to a different URL and it gets a fresh, empty room — the old state is orphaned, not migrated. You have to respect that when restructuring pages.

But flip it around: one script, injected sitewide, becomes a per-page feature automatically.

My read-receipts card is a single block in the site footer template. It checks for WordPress's single-post body class, and if present, injects a stamp card at the end of the article. Because rooms are per-URL, every post — past and future — gets its own independent stamp count with zero per-post edits. Publishing a new post wires it up by existing.

The stamp logic is ~40 lines: defaultData: {stamps: []}, a click pushes {s: seed, t: timestamp}, a per-browser seed in localStorage deduplicates so you can only stamp once, a cap of 96 drops the oldest. I clicked the button, reloaded, and the count survived — the state had round-tripped through PartyKit and back. That reload test is the only proof that matters; everything before it is theater.

Trap 1: WordPress silently eats `&&`

This is the one that cost me the most and the reason this article has its title.

WordPress stores raw block content, then runs it through rendering filters on output. Somewhere in that pipeline, bare && sequences inside a Custom HTML block can come out the other side as &&. Your JavaScript now contains HTML entities. It fails at parse.

And here's the killer: no console error you'd associate with your code. The script just... isn't there in any working form. You wrote it, the editor shows it, the save succeeded, and the page behaves as if the feature never existed.

The diagnosis that finally worked: fetch the raw stored content via the REST API (?context=edit), fetch the rendered page, and diff the lengths. A rendered version that's longer than raw is a smell — then grep the rendered bytes for &.

The fix is to write JavaScript with no && at all:

// instead of: if (a && a.b) { ... }
if (a) { if (a.b) { /* ... */ } }

// or collapse with a fallback:
const b = (a || {}).b;

// if you truly need a literal ampersand in a string:
const amp = String.fromCharCode(38);

Ridiculous? Yes. But it's a hard rule on this host, and once you know it, it's cheap to follow. My share buttons build X and Reddit intent links as single-query-param URLs (everything packed into one text= param) specifically so no & ever appears in the script.

Trap 2: `</script>` inside a string

If your injected script writes a <script> tag (say, lazy-loading playhtml itself), the closing tag inside a string literal terminates your outer script at parse time. Classic, but it combines badly with trap 1's silence. Always write it split: '<' + '/script>' or <\/script>.

Trap 3: emoji are stripped on save

Astral-plane emoji get stripped from Custom HTML blocks when saved over REST — as raw characters, as HTML entities, and even when inserted at runtime by JavaScript that survived the save. If a label matters, use text or an inline SVG shape. I stopped fighting this one.

Trap 4: `transform` breaks `position: fixed`

My pages break out of the theme's 620px content column with the standard full-bleed recipe:

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

That transform makes the wrapper a containing block — any position: fixed descendant is now fixed relative to the page wrapper, not the viewport. A fixed overlay, toast, or ambient canvas cannot work from inside page content styled this way.

The escape: put viewport-fixed things in the theme's footer template part, whose ancestor chain has no transform. That architectural accident is what pushed all my sitewide interactive code into the footer — which is also what made the per-URL room trick in the read-receipts section fall out naturally. Sometimes the constraint designs the system for you.

Trap 5: duplicate SVG ids across pasted blocks

Paste the same inline SVG (with internal <linearGradient id="pg">) into a page twelve times and you have twelve elements sharing one id. Every url(#pg) reference resolves to the first definition; the other eleven gradients are silently dead. My toy room had exactly this. Prefix every internal id per SVG block, and before renaming, assert that your defs and refs actually pair up — mine had 12 defs and 115 refs, so a naive sequential rename would have mis-paired them.

The common thread

Every one of these failures is silent. No error, no warning, a successful save — and a feature that doesn't exist. The discipline that catches them isn't cleverness, it's verification: fetch the served bytes after every write and check them against what you meant to ship. Rendered-vs-raw diffs, entity scans, element counts, a reload test on anything stateful. If I hadn't made that a habit, at least three of these would have shipped as dead code and I'd have blamed the library.

Was it worth it?

A blog is usually a monologue. The cheapest thing multiplayer buys you isn't a feature — it's evidence of other people. Someone dragged the magnets into a shape. Someone stamped a post at 2am. The positivity wall has stamps from browsers I'll never identify. For one <script> tag and some entity-encoding scar tissue, the site feels inhabited.

If you want to poke at any of it live: the toy room, the arcade, or any post on dhseadev.online — scroll to the bottom and leave a stamp. I'll see the count go up, which is the whole point.

Shipping an LLM chat widget with 481 bytes of CMS footprint - Wordpress

Dhardingsea Developer — Fri, 07 Aug 2026 13:00:26 +0000

A chat widget where the CMS holds a loader and nothing else — plus the four failure modes that cost me the most time: buffered SSE, base64 truncation that passes a syntax check, render-time escaping, and a balanced-but-wrong tag tree.

Canonical_url
https://dhseadev.online/2026/08/06/ai-answers-desk-val-town-groq/

I maintain a small site where I write up the internal tooling I build — process-serving
automation, Chrome extensions, desktop utilities. It had a static answers page. The
obvious next step was letting people ask the things that page doesn't cover.

Two constraints shaped the whole design:

No server for me to maintain.
The API key never reaches a browser, and never enters the CMS database.

What follows is the architecture I landed on, and — more usefully — the four things that
actually cost me time. Three of those four are general enough to bite you on a completely
different stack.

The shape

The CMS side is 481 bytes. One block, and all it does is:

window.DHSEA_ASK_ENDPOINT = "https://…";
// then inject <script src="…/widget.js">

That's it. No plugin. No key in the database. No logic in the page.

Everything else — the ~19KB widget, the styles, the chat logic, the proxy — lives in a
single serverless file with three routes:

Route	Job
`GET /health`	Diagnostics. Written so it can never 500.
`GET /widget.js`	Serves the widget itself.
`POST /`	Chat proxy to the model API.

The API key is an env var on the serverless platform. Because the widget is served from
the same function rather than pasted into the CMS, shipping a widget change is one
external deploy and I never touch the site.

/health deserves a note. A health check that can throw is worse than no health check,
because it fails in exactly the situation you're using it to diagnose. Mine returns
{ok, keyConfigured, store, storeError, fatal, day, dayReq, dayTokens, …} — errors
become fields, not exceptions.

Budget, because it's my card

Public endpoint plus paid inference is a bad combination unless you bound it up front:

per-IP: 4/min, 30/day
global: 12/min, 1500/day
hard ceiling: 300k tokens/day

Counters live in the platform's SQLite so they survive cold starts — in-memory counters
on a serverless host reset when the instance recycles, which means no rate limit at all
under exactly the traffic pattern you care about.

On top: an origin allowlist. My domain gets 200. A lookalike domain gets 403. A
request with no Origin header gets 403. Test all three; the lookalike case is the one
naive startsWith checks fail.

Four things that cost me the most time

1. Your platform may buffer SSE

The model API streams tokens properly. My serverless host buffers, so what reached the
browser was roughly two chunks — not a stream.

Total round trip is under a second, so it reads fine. But I'd already started building a
token-by-token typewriter UI that was never going to work on that host.

Verify streaming end to end on your actual deployment target, not on the vendor's
docs page. The vendor streams. That tells you nothing about what your host does with it.

2. A truncated base64 payload passes a syntax check

The widget is base64-embedded into the serverless file by a build script. If a copy step
truncates the blob:

the file still parses — node --check is happy
atob fails at runtime
the panel renders blank

A syntax check attests the file, never the payload. So: never hand-copy the payload
(a build script does it file-to-file), and verify the deploy against the live artifact:

curl -s https://…/widget.js | shasum -a 256

…compared against the same hash computed on the local build. Same byte length is not
the same bytes. Compare hashes. Mine matched at 19,260 chars — that match is the
evidence the deploy worked, not the fact that the paste didn't throw.

3. Verify the served bytes, not the saved content

My CMS applies escaping at render time. So the stored content was byte-clean while the
live page was dead and the console was empty.

Reading back what you just saved proves the write succeeded. It proves nothing about
what the visitor receives. Fetch the rendered output and assert on that.

This generalizes past CMSs: anywhere a transform sits between your write and the user —
a bundler, a minifier, a template engine, a CDN — the artifact you validated is not the
artifact they get.

4. Balanced tags are not a correct tree

This is my favorite, because every mechanical check I had passed it.

A page with opening and closing div counts matching exactly — 14 and 14. And six
sections nested inside a seventh, because one closing tag had been deferred to the end of
the document.

Balance counting cannot catch this. Absence and misplacement are different bugs, and
counting only detects absence. Parse it instead:

const doc = new DOMParser().parseFromString(html, "text/html");
doc.querySelectorAll(".qa .qa").length; // 6 → nested. Should be 0.
doc.querySelectorAll(".in > .qa").length; // should equal total .qa

That assertion is the one that catches it, and it's the one I now run.

The through-line

Every one of these four is the same mistake wearing a different hat: I checked the
thing I could reach instead of the thing the user gets.

The saved content instead of the served page. The file's syntax instead of the payload's
integrity. The vendor's streaming behavior instead of my host's. The tag count instead
of the tree.

Each check passed. Each one attested something adjacent to what I actually needed to know.
Whatever sits between your code and your user — a renderer, a host, an encoder, a build
step — is the boundary your verification has to cross, or it isn't verification.

The result is live at dhseadev.online/ask, sitting next
to the static answers it was built to extend. If you
break it, I'd like to hear how.

One I can't finish, one I can't measure

Dhardingsea Developer — Thu, 06 Aug 2026 14:42:57 +0000

I shipped two things this week that could not be less alike.

One is an integration against the SaaS that most process-serving firms run their dispatch on — a system of legal record, where a wrong write becomes a wrong document attached to a real court case. The other is a 24.92 KiB Chrome extension containing a dinosaur that walks across your page and refuses to leave.

They have exactly one thing in common, and it took me until I'd written both up to notice it: each one has a hole in it that I put there on purpose.

One I can't finish. One I can't measure.

The one I can't finish

ServeManager speaks JSON:API, not flat REST. If you've never hit that shape before, the first thing it does is lie to you quietly:

// Returns undefined. Does not throw. Ships to production as a blank column.
const status = job.data.service_status;

// The scalar actually lives here
const status = job.data.attributes.service_status;

Relationships are worse — they're pointers, not objects, and the thing they point at lives in a separate top-level included array you have to resolve yourself. Getting a court name off a job is three hops:

const resolve = (included, ref) =>
  ref?.data
    ? included.find(i => i.id === ref.data.id && i.type === ref.data.type) ?? null
    : null;

const courtCase = resolve(included, job.data.relationships.court_case);
const court     = resolve(included, courtCase?.relationships?.court);
const courtName = court?.attributes?.name;   // null-guard every hop

Every one of those failure modes is silent. Nothing throws. You get undefined, it flows through your mapper, and it lands in a report as an empty cell — in a domain where an empty cell means "we have no idea whether this person was legally served."

So here's the hole. There is one write I have never confirmed: attaching a file to an already-existing job. The documented flow covers uploading during job creation. The attach-afterward body schema, I have never captured from a real request.

I could infer it. The create flow is right there, the naming is consistent, and I'd probably be right.

"Probably right" is a fine standard for a side project and a terrible one for a system of legal record. A malformed write here doesn't throw an exception — it produces a wrong document on someone's real case, and nobody finds out until the day it matters. So the feature is gated. It does not run against production. It sits there, unfinished, until I spend the hour with a network tab open and capture what the request actually looks like.

The full writeup, with the status codes that look like your bug and aren't (406, 409, and a 403 that's a permissions level rather than a bad payload), is here: The ServeManager API is a document, not a record.

The one I can't measure

Same week. Different universe.

Annoying Dino is a Manifest V3 extension that puts a tiny T-Rex in your browser. You can tap him, feed him, or ignore him. His mood shifts based on which you pick. There's an egg-and-hatch collection running alongside. That's the product. It is the least ambitious thing I have ever shipped.

It is also, by a factor of nearly five, the most-installed thing in my portfolio.

I didn't want to write that sentence without checking it, so I counted every listing:

Extension	Installs
Annoying Dino	19
Arcanum Idle	4
Dino Dots	4
Planet Express Lounge	3
Cobalt Star / Kawaii Time Garden / Spellsurge / Hot Dog Rush	2 each
Devotion	1

Four listings wouldn't surface a count at all, so the honest version is "leads everything I could measure." Nineteen users is not a business or a validation — it's nineteen browsers. But it beats the idle game with nine automated test suites, and that gap is the interesting part.

Here's the hole: I have no idea whether any of those nineteen people have opened it since.

There is no analytics in any of my extensions. No event pings, no install beacon, no heartbeat. I check that the way I check a bug — grep the whole codebase for network APIs before the privacy claims get written. Which means I cannot tell you a retention curve, a DAU number, or whether the feeding mechanic is the part people actually like. I can't even tell you if it's broken on someone's machine right now.

Anyone with an analytics tag would have known all of that on day two.

And I still won't add one — because of what this specific extension is. It runs on the pages you visit. Any usage telemetry worth having from it would be, functionally, a log of when you were browsing and what you were looking at when a cartoon reptile walked past. There is no version of "just a little event tracking" there that isn't a surveillance surface wearing a joke costume.

Full numbers and reasoning: The most-installed thing I have built is a dinosaur that bothers you.

The thing they actually share

I thought these were opposites. A legal-record API and a joke dinosaur; maximum consequence and zero consequence.

They're the same decision made twice.

In both cases there was a shortcut available that would have made the product better on paper. Infer the field shape and ship the attach feature. Add three lines of telemetry and finally know if anyone plays the thing. Both shortcuts are small, normal, and what most people would do without a second thought.

And in both cases the cost of taking the shortcut lands on someone who is not me. A guessed field shape puts a wrong document on a stranger's court case. A telemetry ping puts a stranger's browsing pattern on a server. The benefit is all mine — a shipped feature, a retention chart — and the risk is all theirs.

So the rule I've ended up with is not "be careful." It's narrower than that:

When the shortcut's upside accrues to you and its downside accrues to your user, the shortcut isn't a tradeoff. It's a transfer.

The follow-on is that you have to be willing to hold the gap. Ship the integration with the feature switched off and say so. Ship the extension and admit publicly you can't measure it. Both look like weakness in a portfolio. Both are the actual engineering.

The unglamorous coda: neither hole is permanent. The attach schema needs one hour with DevTools open. The dino telemetry is never coming — but the install count is a real signal, and it already told me something I didn't want to hear about the gap between what I find interesting to build and what a stranger will actually click.

If you want the longer versions, I keep the case studies at dhseadev.online/writing and the running devlog at dhseadev.online/updates. Everything I ship is local-first, no accounts, no telemetry — which, as established, is occasionally very inconvenient for me.

What's the shortcut you refuse to take, and what does it cost you?

Every key failed in exactly the same way

Dhardingsea Developer — Wed, 05 Aug 2026 01:16:35 +0000

Cloudflare error 1010 rejects Python's default User-Agent before the API's auth layer ever sees the request. How to tell it from a real 401, and the four headers that fix it."

Originally published on dhseadev.online.

I lost an hour to a credential that was never wrong.

The task was small: a read-only Model Context Protocol server over a vendor REST API, so an assistant could read job records without me pasting spreadsheet exports into a chat window. The vendor authenticates with the customer's own API key over HTTP Basic. Two lines of urllib. Done before lunch.

Every request came back the same way:

HTTP/1.1 403 Forbidden

error code: 1010

The short version

Cloudflare error 1010 is not an authentication failure. It is a browser-signature ban issued at Cloudflare's edge — "the owner of this website has banned your access based on your browser's signature" — and Python's default User-Agent is enough to trigger it.

The request never reaches the API's own auth layer. That is why every credential you try fails identically. The fix is four request headers, not a new key.

If that solves your afternoon, you can stop reading. The rest is the part I found more useful: how you can tell, from the failures alone, that you are not talking to the thing you think you are talking to.

Why a correct key still returns 403

I did what everyone does. Key as the username with an empty password. Key as a Bearer token. Key in an X-API-Key header. Re-checked the base64 padding. Regenerated the key. Tried again.

Six variants. Every one returned 403 and error code: 1010.

That is the shape of a permissions problem. It is where you start drafting an email to support asking which scope your key is missing, and where the hour goes.

The tell is that the failures were identical

An authentication layer discriminates. That is the entire job description.

A malformed header should not fail the same way as a well-formed header carrying a revoked key, which should not fail the same way as a valid key hitting an endpoint it cannot see. Those are three different conditions and a competent auth layer says three different things about them.

When six materially different requests produce byte-identical responses, nothing is reading those bytes. The answer is coming from something standing in front of the thing you are trying to talk to.

That generalises well past Cloudflare, and it is the part worth keeping: identical failure output across varied input means the input is not being examined. Vary something that should matter. If the error does not move, you are debugging the wrong layer.

In this case the thing in front was Cloudflare's browser-integrity check. Python's standard library announces itself as User-Agent: Python-urllib/3.x, and the User-Agent header is the cheapest fingerprint an edge can filter on. That string alone got every request I sent discarded before the vendor's servers ever saw it.

The fix

Four request headers. No proxy, no scraping framework, no third-party HTTP client.

HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/126.0.0.0 Safari/537.36"
    ),
    "Accept": "application/json, text/plain, */*",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
}

I proved it side by side with a key I made up on purpose:

Headers	Result
Python default	`403` · `error code: 1010`
Browser set above	`401 HTTP Basic: Access denied.`

A 401 was the win condition. A correct rejection of a deliberately fake credential meant the request had finally reached the application.

The honest caveat: this defeats User-Agent fingerprinting and nothing else. If the edge escalates to TLS or JA3 fingerprinting, urllib stops working again and the answer becomes a browser-impersonating client. I have not tested that, because it has not happened.

The trick I took away: 401 is evidence you can collect for free

The useful consequence showed up later. I had written tools against seven endpoint paths. Five of them I had never successfully called — I had them from documentation, which is a claim, not a measurement.

So I called all seven with the correct headers and no credential at all: account, jobs, companies, court cases, courts, employees, invoices.

Every one returned 401. Not one returned 404.

Those two codes answer different questions. RFC 9110 §15.5.5 defines 404 as the origin server finding no current representation for the target resource — the route does not exist. §15.5.2 defines 401 as a request lacking valid authentication credentials — the route exists and is refusing you.

That distinction confirmed all seven paths, using zero credentials and touching zero customer data. It is the cheapest verification step I know of, and I had never deliberately reached for it before. You can run it against an API before you have a key, before you have written a client, before you have permission to do anything at all.

It does not confirm everything. Proving a door exists is not the same as knowing what is behind it — the field mappings behind five of those tools are still inferred rather than captured, and they are labelled that way in the README until someone runs them against a live key.

One unrelated landmine, since it will cost somebody an afternoon

The mcp package on PyPI is at 2.0.0, and FastMCP is gone from it.

# stale — every tutorial I could find still says this
from mcp.server.fastmcp import FastMCP

# current
from mcp.server.mcpserver import MCPServer

The .tool() decorator and .run(transport="stdio") are unchanged, so the migration is one line. Checked against the SDK rather than against the tutorials, on 4 August 2026 — if you are reading this much later, check it again.

What I actually took from it

Identical failures are a signal, not noise. If varying the input does not vary the output, the input is not being read.

A written environment fact is still a hypothesis. My own handoff notes said neither sandbox could reach that host at all. That was wrong. The network route was always fine and the original blocker had only ever been a missing key — I nearly designed around a constraint that did not exist.

Ask the question that costs nothing first. The unauthenticated probe took ninety seconds and settled something I had planned to settle with a credential I did not yet have.

The server shipped read-only: ten tools, 28 unit tests, no mutating operations. Anything that writes back into a system of record stays behind a confirmation gate, which is its own problem and its own post.

I write these up as I go at dhseadev.online. If this was your kind of thing, the nearest neighbours are the orchestrator layer that routes this work, ServeBoard — the same data seen from the other end, where deciding what counts as one job turned out to be the hard part — and a longer piece on how I work.

I built a local-first Dota 2 companion as a Chrome extension — and learned what "minimum permissions" actually means

Dhardingsea Developer — Tue, 04 Aug 2026 10:45:03 +0000

Building a no-account, no-API-key Dota 2 stats extension, and three Chrome/Steam lessons that cost me a Web Store rejection.
https://dhseadev.online/projects/dota-companion/

Most Dota 2 stat sites answer "how did that game go?" I wanted one that answers a harder question: am I actually getting better?

So I built Dota Companion — a Chrome extension that lives in your toolbar. No account, no API key, no signup. Paste a Steam profile URL and it works.

The build taught me three things worth passing on, one of which got the extension flagged by the Chrome Web Store.

The feature I actually cared about: improvement streak

Win streaks measure luck as much as skill. In a five-player team game, you can play well and lose.

So the headline metric isn't wins — it's an improvement streak: consecutive games where your GPM beat your own 20-game baseline. It's a metric you control, and it moves when you improve rather than when your team cooperates.

Same idea drives goals. Pick GPM, KDA, last hits, or win rate; the baseline snapshots your current 20-game average when you set the goal. You compete with past-you.

The rest is the between-games layer: today's W/L, a GPM trend sparkline, recent matches with hero, K/D/A, duration and how long ago, most-played heroes, and private notes and tags on players you run into — stored on your device, never uploaded.

Lesson 1: `chrome.tabs.create()` does not need the `tabs` permission

This one cost me a rejection email.

I had one tabs call — opening a bundled inventory page:

chrome.tabs.create({ url: chrome.runtime.getURL('inventory.html') });

So "tabs" went in the manifest. Reasonable, right?

Wrong. Google flagged it under their minimum-permissions policy:

The following permission(s) need not be requested for the methods/properties implemented by the item: tabs

chrome.tabs.create() has never required the tabs permission. No tab-creation API does. That permission gates exactly one thing: reading sensitive tab metadata — url, pendingUrl, title, favIconUrl — off Tab objects.

I passed a URL in and ignored the returned object. I was declaring a capability I never used.

I verified the fix rather than trusting the docs — loaded the extension with tabs removed and called the API in a real browser:

runtime granted permissions: {"permissions":["storage"],"origins":["https://api.opendota.com/*"]}
chrome.tabs.create -> {"ok":true,"tabId":210614909}
pages before/after: 2 / 3
errors: NONE

Tab opened. Zero errors. The permission was pure liability.

Takeaway: grep your actual call sites before declaring anything. "This API sounds tab-related, so I need tabs" is exactly the reasoning the policy exists to catch. Ask instead: do I read the returned object's sensitive fields? If no, you don't need it.

Lesson 2: rate limits you share with the user are a design constraint, not an error case

The extension can estimate your Dota 2 inventory value from Steam Community Market prices. Steam rate-limits those endpoints hard — and critically, the limit applies to the whole IP, not to your extension.

Blow through it and you don't just break your feature. You break the user's normal Steam browsing. That reframes the problem: you're not optimizing your own throughput, you're spending a budget that isn't yours.

So the design is deliberately timid:

Nothing fetches automatically. Every request traces back to a button the user pressed.
A visible request budget, capped well short of the real limit, shown in the UI.
Hard backoff. If Steam pushes back, it stops for hours rather than retrying.
No Steam login cookies are sent. Public data only.

Slower than technically possible, on purpose. A tool that degrades the rest of your browsing isn't a good tool.

Lesson 3: optional permissions are worth the extra state

The inventory feature needs steamcommunity.com access. Most users never open it.

Requesting that host at install time means every user sees a scary permission prompt for a feature they may never touch. So it's an optional host permission, requested at the moment of use:

chrome.permissions.contains({ origins: [ORIGIN] }, cb);  // gate the UI
chrome.permissions.request({ origins: [ORIGIN] }, cb);   // only on click

Cost: a real permission-state machine — gated UI, a grant screen, a declined path. Benefit: the install prompt asks for nothing surprising, and the request arrives with obvious context.

Worth it. Install-time friction is where extensions die.

Testing logic that lives in a popup

Extension code resists testing — everything wants chrome.* or the DOM. The fix was a hard boundary: all pure logic (streaks, baselines, formatting, aggregation) sits in modules that touch nothing — no chrome.*, no DOM, no fetch, not even the clock. Current time is passed in as an argument.

Those modules dual-export: a global for the extension, module.exports for Node. The whole stat layer runs headless with zero browser mocks.

That caught a genuinely nasty one. OpenDota returns start_time in epoch seconds. new Date(start_time) expects milliseconds — so every match silently renders as 1970. There's now a regression test asserting exactly that.

Try it

Chrome Web Store: Dota Companion
Project page: dhseadev.online/projects/dota-companion

Data comes from the OpenDota API — you'll need "Expose Public Match Data" enabled in Dota 2 settings for matches to show up. English and Simplified Chinese.

Not affiliated with Valve.

Twelve gradients, one id - DHSeaDev

Dhardingsea Developer — Mon, 03 Aug 2026 22:51:32 +0000

A markup defect with no visual symptom, the audit that missed it five times, and the guard that stopped the fix from being worse than the bug.

The page in question: dhseadev.online/play

MARKUP · A DEFECT WITH NO SYMPTOM

Twelve gradients, one id

Eleven of them were dead. The page looked exactly right, and that was the problem.

A site scan flagged nothing. My own audit reported zero defects across forty-six pages.
The page rendered precisely as designed. Eleven of its twelve gradients had never been
used by anything.

THE DEFECT ————————————

What twelve copies of one emblem actually produces

I had an SVG emblem I liked, so I pasted it into a page twelve times. Each copy brought
its own gradient definition along with it.

<svg viewBox="0 0 40 40">
  <defs>
    <linearGradient id="pg">
      <stop stop-color="#C4B5FD"/>
      <stop stop-color="#93C5FD"/>
      <stop stop-color="#F0ABFC"/>
    </linearGradient>
  </defs>
  <path fill="url(#pg)" d="..."/>
</svg>

Twelve <svg> blocks. Twelve elements carrying id="pg". Duplicate ids are invalid
HTML, and url(#pg) resolves to the first match in the document — so every emblem on
the page was painted by gradient number one, and the remaining eleven were parsed, held
in memory, and referenced by nothing.

The reason it stayed invisible is almost insulting: all twelve definitions held
identical stops. There was no visual symptom because there was nothing to see. A bug
like this waits patiently for the day you change one gradient and the change lands on
the wrong element, or on none of them.

THE AUDIT ————————————

Why five passes of my own tooling missed it

My checks looked for missing alt attributes, broken links, absent structured data.
"Are any ids duplicated" was not among them, because it had never yet cost me anything.

It costs four lines to add.

const ids = {};
for (const el of document.querySelectorAll('[id]')) {
  ids[el.id] = (ids[el.id] || 0) + 1;
}
console.log(Object.keys(ids).filter(k => ids[k] > 1));

THE FIX ————————————

The trap sitting inside the repair

The obvious remedy is a unique id per gradient. My first attempt renamed sequentially
across the whole document, and I put a count assertion in front of it out of habit
rather than suspicion.

let n = 0;
html = html.replace(/id="pg"/g,    () => `id="pg${++n}"`);
let m = 0;
html = html.replace(/url\(#pg\)/g, () => `url(#pg${++m})`);

The assertion failed.

defs = 12 · refs = 115

Each emblem defined one gradient and referenced it roughly ten times. A sequential
rename would have paired the second definition with the second reference — which
belonged to the first emblem. It would have converted an invisible defect into a
visibly broken page, and it would have done so while reporting success.

The correct repair scopes the rename to each <svg> block, so a definition can only
ever be paired with references from its own subtree.

let n = 0;
html = html.replace(/<svg[\s\S]*?<\/svg>/g, (block) => {
  if ((block.match(/id="pg"/g) || []).length !== 1) return block;
  const id = `pg${++n}`;
  return block
    .split('id="pg"').join(`id="${id}"`)
    .split('url(#pg)').join(`url(#${id})`);
});

Twelve blocks renamed. Zero leftover definitions, zero leftover references, twelve
distinct ids, and no duplicate id anywhere on the page.

WHAT IT LEAVES BEHIND ————————————

Inline SVG pasted more than once duplicates every internal id it carries — not only
gradients, but filters, masks, clipPaths, patterns, and every aria-labelledby target.
A duplicate-id check belongs in the audit precisely because this class of bug produces
nothing to look at.

And a bulk find-and-replace that assumes definitions and references pair up should be
made to prove it before it writes a single byte. Mine was guarded by habit rather than
foresight, and habit was the only reason a twelve-against-one-hundred-and-fifteen
mismatch never shipped.

Found while auditing dhseadev.online, August 2026.

I built a shared wall that can't be spammed, by removing the text box

Dhardingsea Developer — Mon, 03 Aug 2026 19:38:06 +0000

Why the Positivity Wall has no text field, no accounts and no likes — and what subtraction has to do with building alongside AI.

https://dhseadev.online/2026/08/01/joy-is-what-is-left/

I spent a day making a website easier for search engines to find, and finished it by
building a page that has nothing to do with search engines. Nine panels. You click one,
you leave a stamp, and the stamp is still yours the next time you come back.

The interesting part isn't the feature. It's the three things I took out.

The first version was worse

The original idea was a 3×3 grid of embedded videos from people who make cheerful
things — reposted on my site. I talked myself out of it in about ten minutes, for a
reason that turned out to matter: embedding someone else's video sends my visitor to
their platform. It borrows nothing and gives away the only thing I have.

So the content had to come from the visitor. And the moment content comes from
visitors, you're running a moderation problem whether you meant to or not.

Why there's no text box

The obvious design is a text field. Leave a nice message. I didn't build that.

Three characters is enough for a slur. Any free-text field on a public page is a
commitment to moderate it forever, and I'm one person who won't always be paying
attention. A field I can't supervise is a field I shouldn't ship.

What I built instead is a stamp generated from a random seed in your browser:

// seed -> shape, glyph, hue. no assets, no storage, no input.
function rnd(s) { s = (s * 9301 + 49297) % 233280; return { s, v: s / 233280 }; }

function stamp(seed) {
  const r = seq(seed, 4);
  return {
    hue:   Math.floor(r[0] * 360),
    sides: 3 + Math.floor(r[1] * 5),   // triangle .. heptagon
    rot:   Math.floor(r[2] * 360),
    glyph: Math.floor(r[3] * 4)
  };
}

You can't type anything. You can't be obscene with a hexagon. And the stamp is more
personal than initials would have been, because it's yours and you didn't choose it.

Identity without accounts

No sign-up. No name. The page doesn't know who you are and has no way to find out.

What it has is one integer in localStorage. That's enough to say this mark is yours
and welcome back, and nothing else. Clear your browser and you become a new person,
which feels correct.

Shared state runs on playhtml, which is CRDT-backed — two people
stamping at the same moment both land, with no server I run and no database I have to
secure. The less I store, the less there is to leak.

What this has to do with AI

I build alongside AI constantly. What I notice is that the tools are very good at
producing more — more pages, more features, more words — and the discipline I keep
having to apply is subtraction.

The wall could have had comments, likes, leaderboards, streaks, a login. Every one was
available and cheap. Every one would have made it worse: more surface to moderate, more
data to hold, more reasons to visit out of obligation instead of pleasure.

Joy in software isn't a feature you add. It's what's left when you stop adding things
that create obligation.

Credit

The premise isn't mine. It came from Amanda Gore and The Joy
Project, whose work is about
helping people reconnect with themselves and each other. Her version happens in rooms
full of people. Mine is nine rectangles and some SVG — but the mechanism is the same
one she's pointing at: a person feels better when they're briefly, specifically seen.

You can leave a stamp here.