DEV Community: Wayne Ma

Building Mythcastera with Blender Truth and Saccade

Wayne Ma — Wed, 16 Sep 2026 16:03:04 +0000

We started Mythcastera with a simple wish: a fantasy town where AI residents have things to do. An inn to run, supplies to gather, a place to sit, someone to talk to. Goblins, pigfolk, and creatures outside town belong in that world. We want their choices to have visible consequences.

Then we spent rather a lot of time staring at a goblin's shirt.

That detour has been useful. Before a resident can convincingly live in a town, we need to get a character into the scene, give it an action, and see what actually happens when it moves. This update is about that work, and the small town taking shape around it.

Watch the 20-second town tour

The scene now has an inn, a workshop, a strawberry patch, and the smaller things that make those places readable: baskets, crates, fences, and stacks of wood. We built and arranged the town assets through our Blender workflow. Mududu is the innkeeper; Kakka is the repairer. Their character definitions keep their appearance, background, and starting possessions separate from the animation files.

We're experimenting with resident behavior too, including walking to places, sitting, conversation, and gathering. Some household activities still use placeholder motion. The longer-term aim is a town whose residents can keep themselves occupied; this is still a development preview.

Starting with a body that already works

Our characters began with a purchased, licensed library of rigged models. That gave us a useful starting point: an existing skeleton, skin weights, and native animation. We kept the shared 44-bone rig while making character variations and clothes in Blender.

The walking and running in these character studies originally came from that Blender asset. The fantasy clothing, species variations, and character-specific work are additions to that base. Keeping that distinction clear also helps us debug: we can compare a changed character with the original instead of guessing which part of the pipeline introduced a problem.

Mududu now uses a separate head-and-neck module on the shared rig. The earlier rough-cloth goblin remains useful for comparison, but it isn't the current Mududu asset.

Watch the 15-second character reel

These clips are manually staged motion demonstrations, not a demonstration of autonomous resident behavior.

Getting a swing into the browser

For additional actions, we've been using Mixamo. Our upload candidate contains a skinned human mesh and its armature, exported in the rest pose with the existing animation removed. We download the chosen animation as an FBX with skin, at 30 fps, without keyframe reduction.

From there, we retarget locally and review the result. Some clips go back through Blender for adaptation; the combat lab can retarget and adjust timing directly in the browser. Three.js loads the character as GLB, while our shared runtime library loads reusable animation curves separately. That separation matters because adding another action shouldn't require rebuilding every character or hard-coding another preview button.

Two early combat experiments were Bayonet Stab, used as a spear thrust, and Great Sword Downward Slash. The source motions felt leisurely for the attacks we wanted. We tried a 1.5× overall speed, then compressed the actual strike interval further. The sword experiment also shortens part of the preparation.

We are leaving those attack clips out of this showcase while we correct the weapon presentation. Those settings are tuning choices for these clips. Different actions need different preparation and recovery. The combat previews still need work on weapon grip and character-specific contact; a convincing swing alone doesn't implement combat.

What Blender Truth and Saccade helped us see

The visual and scene-inspection features below are from our Saccade development build. They are not included in the published 0.2.2 package / 0.4.7 Extension. This is a progress report, not a new release announcement.

Blender Truth gives the agent structured access to Blender state and operations. Saccade handles browser interaction and lets us inspect the running WebGL preview, including sampled image sequences and the application's reported animation state. We also used it to select and download the Mixamo candidates.

The two views answer different questions. Blender can expose geometry and attachment measurements. Browser footage shows the exported character under the actual runtime animation, lighting, and camera. We need both, and we still have to interpret the evidence carefully.

The shirt supplied a good example. We gave the goblin a loose, coarse-cloth tunic with rolled sleeves and small neckline details. A front view looked reasonable. Weight checks didn't raise an obvious problem. Later inspection showed a neckline detail floating away from the shirt, with a measured gap around 8.5–9 mm in the sampled poses.

We had not measured the attachment gap before calling the detail fixed. There is also a trap in using minimum distance alone: one end of a detail may touch while the other lifts away. We changed the neckline stitches into faces integral to the garment and added an attachment check across explicit animation frames. It reports maximum separation and the worst sampled frame and vertex, so a touching tip can't hide a raised end.

That check has limits. Sampled frames don't cover every instant, and unsigned surface distance doesn't prove that nothing penetrates. We pair the numbers with side-view motion inspection. The agent missed the original problem; the useful result was a better repair and a more specific check.

We're now able to spend more time on what the residents do. We'd like the next clips to show Mududu managing his inn, Kakka finding useful work, and the consequences of leaving the safety of town. There are still feet, hands, clothes, and transitions to fix along the way. At least we can now trace those problems through the same pipeline we'll use for the next character and the next action.

We're building Saccade in public on GitHub. The development showcase includes the clips and the limits of what we tested.

Written with AI assistance from our development notes; the examples are from our own project.

Stop AI agents from reviving old project decisions

Wayne Ma — Wed, 02 Sep 2026 02:47:30 +0000

Long-running repositories collect Markdown files that disagree about what is current. Once Codex, Claude, and humans work across many sessions, an old architecture note can quietly become "the plan" again.

Markdown Gatekeeper keeps one current revision per topic. Competing docs stay proposals; superseded sources remain recoverable.

Local-first. Plain Markdown and Git. No account or cloud service.

npm install -g github:nanlogic/markdown-gatekeeper
mdg setup codex
mdg init .

Source: https://github.com/nanlogic/markdown-gatekeeper

Your AI Can Write the Sales Email. Can You Trust It to Click Send?

Wayne Ma — Mon, 31 Aug 2026 18:20:40 +0000

Ask AI to write a sales email and it can finish before you take a sip of coffee.

Ask it to open the right account, update the CRM, attach the right file, change a status, click Save, and confirm the change—and the babysitting begins.

Every browser click becomes a tiny trust exercise.

Is this the right customer? Is the page still current? Did the button move after a rerender? Did Save actually work? If the connection dropped after the click, will the Agent do it twice?

This is the browser gap. AI is already good at talking about work. Finishing work inside real browser tabs is harder.

The loop is simple: the Agent owns one authorized tab, reads the current page, receives small changes, acts on the current object, and gets evidence back.

The work nobody wants to supervise

Sales and operations teams live in CRMs, partner portals, support tools, recruiting systems, product dashboards, and old admin pages.

The repetitive work sounds easy:

research a prospect and update the account;
move a lead to the right stage;
prepare outreach, then record what happened;
upload an asset and check the required options;
work through a long form without losing progress.

These jobs are tedious for people and surprisingly risky for Agents. Two records can look almost identical. A modern form can replace a control while keeping it visually unchanged. An old portal may mix rich text, iframes, uploads, dynamic choices, and a separate Save button.

The worst failure is uncertainty. An action may have happened just before a timeout. Retrying could create a duplicate message, upload, or submission. Refusing to retry means the person has to inspect the page anyway.

That is why we built Saccade.

Give the Agent a tab it can be responsible for

Saccade is a live browser Truth and verified-action layer for AI Agents working in authorized Chrome and Edge tabs.

An Agent knows exactly which tab it owns. It can ask for the current semantic page or only the changes since its last read. When it acts, it uses a current page object—a field, button, choice, table, upload control, or rich-text editor—instead of guessing from an old page description.

The result comes back with a receipt. Saccade reports whether the action was accepted and whether the expected page change was observed.

If the object was replaced, the old authority stays stale. If an action may have happened but cannot be verified, the outcome stays unknown and Saccade does not quietly replay it.

In practical terms, the Agent gets clear answers to four questions:

Which tab am I working in?
Is this still the object I meant to use?
Did the action take effect?
Is it safe to try again?

That is what starts to turn browser automation from a demo into work you can hand off.

Use it where the browser is actually the best route

Saccade is the browser layer underneath an Agent, not a replacement for every API and integration.

If a purpose-built API can complete a job faster and more reliably, use it. Saccade is for the steps that genuinely live in the browser: authenticated back offices, partner sites, legacy tools, and interfaces that have no useful connector.

For sales, that may be the last mile between researched information and a correctly updated account. For operations, it may be a product listing, an upload flow, or a partner portal. For an automation builder, it means the Agent can work in the user's real session without receiving a free-form browser remote control.

We tested the part people usually wave away

The Saccade 0.2.0 release candidate went through the same blocking gates in Chrome and Edge: forms, semantic tables, iframe rich text, uploads, reconnects, replaced controls, multiple Agent sessions, and fast moving targets.

In the Mouse Accuracy gate, it completed 96 of 96 exact-target actions across the two browsers. Mean action latency in those runs ranged from 7.22 ms to 8.50 ms. The release evidence keeps those numbers attached to their test conditions.

Playwright was an important reference for strict resolution, actionability, assertions, and isolation. It remains an excellent choice for reproducible browser tests. Saccade focuses on a different job: keeping an Agent attached to the user's current, authorized browser state and returning evidence about what changed.

Try Saccade 0.2.1

The Node package is public on npm:

npx -y @nanlogic/saccade install
npx -y @nanlogic/saccade doctor

The source, Extension build, setup guide, and release evidence are public:

If your AI can already write the email but you still have to watch every browser click, this is the problem we want to solve.