DEV Community: Hiroshi TK

Keep crafting sparks inside the inventory slot’s visual budget

Hiroshi TK — Mon, 19 Oct 2026 08:01:05 +0000

This post specifies a bounded effect and host integration; the art values are proposed targets rather than results from a supplied effect bundle.

A crafting success cue belongs to a specific inventory slot. If its particles spill across item counts or nearby controls, the effect makes the result harder to read. The integration should bound both the event count and the visual area.

Start with one successful crafting transaction and one slot anchor. Do not trigger the effect when crafting begins, because a rejected request should not look like a completed item.

Use success identity, not button activity

A double click can create repeated UI callbacks even when the application accepts only one craft. Drive the cue from the confirmed transaction identity and ignore repeated delivery of the same success event.

export function makeCraftCue(play) {
  let lastTransaction = null;
  return function confirmed(transactionId, slot) {
    if (!transactionId || transactionId === lastTransaction) return false;
    lastTransaction = transactionId;
    play(slot);
    return true;
  };
}

This intentionally small controller remembers only the most recent transaction. If older events can arrive out of order, use a bounded ID cache or an authoritative event sequence instead. Do not claim general network deduplication from a one-value memory.

Author a restrained burst

A proposed first asset uses eight particles, no continuous emission, a maximum lifetime of 0.3 seconds, and an upward-biased spread. Keep the brightest area above the slot center, with a short fade before particles reach the neighboring label. These are design targets for review, not measured runtime performance.

Use a distinct effect ID such as craft-slot-spark. Export for PixiJS and inspect the support report. A web game particle editor can make this visual envelope easy to revise; NixieFX's PixiJS workflow explains the bundle path to the host application.

Convert coordinates at the boundary

The slot may live inside a scrolling or scaled container. Obtain its anchor in the effect layer's local coordinates before spawning the cue. If the slot scrolls out of view, skip the decorative effect while still updating the item count and success state.

Choose one policy for overlapping crafts. For example, replace the existing cue for that slot instead of adding unlimited new instances. That bounds visual density during rapid crafting without changing the number of successfully crafted items.

Confirmed craft -> update inventory state
               -> update visible count and success label
               -> reduced motion? keep static confirmation
               -> visible slot? convert anchor to VFX-layer coordinates
               -> replace that slot's previous cue
               -> play one verified bounded burst

Make the result inspectable

Capture the actual Pixi screen with the item count and adjacent slot visible. Include the effect source and host integration with the post, so another developer can reproduce the envelope rather than judging only a cropped image.

Test one craft, a repeated event, rapid distinct crafts, a scrolled slot, and reduced motion. After all bursts finish, confirm that the host removes finished instances. On screen teardown, release the owned resources even if a burst is still active.

Limits worth preserving in the write-up

This controller is not the inventory transaction system. The particle effect cannot confirm a purchase, award an item, or prove a server operation succeeded. Those facts come from application state.

This guide does not establish a device performance budget. Profile the actual asset in the intended layout. Unsupported settings are those blocked by the export's Pixi report; any partial support needs a specific explanation after the asset is available. Publish the visual result only after those checks, and distinguish the tested source from the proposed art targets.

A quest-completion marker needs a persistent state after the animation

Hiroshi TK — Mon, 19 Oct 2026 07:59:15 +0000

This is a proposed integration recipe, not a claim of a completed runtime test.

A quest marker should still communicate completion after its particles disappear. Treat the effect as a short acknowledgment of a state change, while the completed icon and text remain the authoritative UI.

The sequence in this example is deliberately small: update the quest state, show the completed marker immediately, optionally play one decorative burst, and clean up the effect when it finishes. The animation must not delay reward eligibility or hide the completed state from keyboard and assistive-technology users.

Deduplicate the completion event

A reconnect or repeated server message can announce the same quest completion twice. Use an identifier for the completion event rather than assuming each callback represents a new achievement.

export function makeCompletionHandler(onComplete) {
  const handled = new Set();
  return event => {
    if (!event.id || handled.has(event.id)) return false;
    handled.add(event.id);
    onComplete(event);
    return true;
  };
}

Keep that set within the appropriate session or quest-screen lifetime. A long-running application needs a bounded retention policy or an authoritative completion version, not an unbounded global set. The example isolates the deduplication rule without prescribing the server's event model.

Put timing in the asset contract

Use a one-shot marker asset with a proposed 0.45-second maximum particle lifetime and no looping emitter. The persistent check icon should appear at event receipt, not at the end of that lifetime. The exact visual envelope needs review in the game; the value here is an art target rather than a measured result.

A web game particle editor is useful for adjusting the appearance independently of the quest logic. NixieFX's PixiJS guide describes the export and runtime integration path. Create a distinct quest-complete effect, validate it for Pixi, and keep the source alongside the exported bundle.

On a new completion event:
1. Update the persistent completed icon and label.
2. Announce completion once through the host's accessible UI.
3. If reduced motion is enabled, skip the particles.
4. Otherwise create the verified one-shot at the marker position.
5. Remove the finished instance through the renderer's cleanup API.

These steps are host instructions. The particle runtime does not supply the quest state, semantic label, or screen-reader announcement for a canvas UI. Provide those through the application's accessible interface.

Keep the cue out of the reading path

Place the effect behind or beside the marker, with enough separation from the quest title to preserve readability. Test long titles and the smallest supported viewport. If the marker lives inside a transformed Pixi container, compute its position in the effect layer's coordinate space; a global position copied into a local layer can drift.

For a reproducible visual check, freeze the UI layout, use a fixed seed, and capture the marker at the same elapsed time. Do not describe a screenshot from the editor as proof of the host integration. The runtime screenshot needs to come from the actual Pixi screen.

Check the cases that expose the boundary

Send the same event twice and verify that only one cue occurs. Send a different completion and verify that it can produce its own cue. Enable reduced motion and confirm that the completed state and announcement still appear. Leave the screen during the burst and confirm that teardown removes the effect without changing quest data.

The code in this post covers event deduplication, not a complete game or a verified exported effect. Inspect the actual Pixi support report for unsupported or approximated authoring settings. Do not claim that lighting, depth, or other Three-specific presentation transfers unchanged. The recipe is complete only when the source asset, host integration, and visual check agree.

Send back the delivery, keep the task: a concrete rework loop

Hiroshi TK — Mon, 19 Oct 2026 07:35:00 +0000

This worked handoff uses a synthetic example.

A rejected delivery does not automatically mean a new task is needed. If the requested outcome is unchanged and the same runner can correct the problem, opening another ticket splits the acceptance criteria from the evidence that failed them.

Suppose the task is to preserve the order of records in a CSV export. An agent-assisted patch sorts them alphabetically instead. The output looks tidy, but it violates the original contract. The useful review response names that mismatch and requests proof of correction on the existing task.

Write the rejection against a criterion

Criterion C1: exported rows retain input order.
Observed mismatch: the implementation sorts by display name.
Example input IDs: [42, 7, 19]
Required output IDs: [42, 7, 19]
Rework: remove sorting from this export path; preserve field escaping.
Proof: add an order-preservation assertion and rerun the existing suite.
Scope: no new ordering preference or export UI changes.

This is concrete enough for the runner to reproduce. It does not require guessing what “wrong ordering” means, and it does not expand the task into a configurable sorting feature.

Choose the transition that matches ownership

In Wagglet's workflow, sending a delivery back returns the task to Claimed with the same runner. Reopening returns it to Open and clears the claim. Both preserve earlier evidence, but they make different ownership decisions.

Delivered attempt A
  -> review: C1 failed, preserve input order
  -> send back: same runner, rework attempt
  -> corrected implementation + new evidence
  -> Delivered attempt B
  -> reviewer checks C1 and regression coverage
  -> accept, or request a specific remaining correction

Keep the old report available for context. Make clear that it is no longer the standing answer. Otherwise, a reviewer can accidentally inspect the earlier screenshot or test result while reading the corrected implementation.

Give the agent a bounded rework brief

The human author or reviewer prepares the correction request. The runner executes it with their own authorized tools. The agent receives the current task context and the review feedback, then proposes and checks the repair. A qualified reviewer judges the new evidence rather than accepting the agent's confidence as proof.

For the synthetic export example, a small regression fixture can make the correction visible:

const input = [{ id: 42 }, { id: 7 }, { id: 19 }];
const expectedIds = [42, 7, 19];
// Wire this assertion to the real export-and-parse path in your test suite.
// assert.deepEqual(parseCsv(exportCsv(input)).map(r => Number(r.id)), expectedIds);

The commented assertion is an integration instruction, not a runnable claim about functions supplied by this post. Use the actual serializer and parser in the repository. A test that merely copies the input array would not exercise the defect.

Report the correction by criterion

The new delivery should identify the tested revision, the removed ordering behavior, the regression assertion, and the actual run result. It should also say whether existing escaping checks ran. Preserving order while breaking quoted fields is not an acceptable correction.

A compact report can use three sentences: “C1 is addressed by removing the sort in the export path. The new test sends IDs 42, 7, and 19 through the serializer and verifies their parsed order. The attached run output and diff refer to the recorded revision.” Only use those sentences once the described work actually exists.

Know when separate work is justified

If review reveals a new requirement, such as a user-selectable sort order, the author should decide whether it belongs in the current contract. Do not quietly add it to the repair. Likewise, if the current runner lacks the required access or expertise, reopen for a new authorized runner rather than leaving ownership ambiguous.

Human supervised AI execution benefits from this distinction. Rework preserves the original outcome and corrects the evidence or implementation. New work changes the outcome. Keeping that boundary explicit makes the history easier to read and the next review easier to conduct.

Wall-impact sparks: test the normal before tuning the glow

Hiroshi TK — Thu, 15 Oct 2026 06:46:36 +0000

A laser impact needs two inputs from the game: a hit position and an outward surface normal. The particle effect should consume those inputs. It should not invent a collision result from a bright spot on a wall.

This small Three.js demo uses a fixed planar wall facing positive Z and a synthetic hit at its center. It emits 32 unlit particles and pauses after 18 fixed simulation steps so the direction is easy to inspect. The screenshot shows that constructed test, not a raycast from a shipped game.

Start with an axis you can name

The authored velocity range points outward along positive Z: X and Y each range from -0.8 to 0.8, while Z ranges from 0.4 to 1.1. Lifetime is 1.2 seconds. Continuous emission is zero. A small positive offset keeps the burst origin just in front of the wall.

In a real integration, transform a mesh-local hit normal into world space correctly before using it. A normal is a direction, not a position; translating it as though it were a point is a common orientation bug. Nonuniform scale requires the proper normal transformation.

const outward = hitNormal.clone().normalize();
const orientation = new THREE.Quaternion().setFromUnitVectors(
  new THREE.Vector3(0, 0, 1), outward
);
const angles = new THREE.Euler().setFromQuaternion(orientation);
const origin = hitPoint.clone().addScaledVector(outward, 0.02);
const burst = vfx.createEffect(effect, {
  position: origin.toArray(),
  rotation: [angles.x, angles.y, angles.z],
  seed: 14
});
burst.emitBurst(effect.emitters[0].id, {count: 32});

effect here is an already prepared definition with the stated zero-rate emitter. Load a validated runtime bundle in a game. The fixed-wall demo uses an authoring definition to keep the experiment self-contained.

Verify the simple case before rotating the wall

On the test wall the outward normal is [0,0,1], so the quaternion is the identity. This is a useful baseline: particles should move into positive Z from an origin at Z=0.02. It is not evidence that every rotated or scaled wall has been tested.

The live lab prints the first debug particle position and active count. Inspect those alongside the screenshot. If the particle motion is correct but the picture looks wrong, investigate camera framing, transparency, depth, and scale before changing the collision normal.

The source below gives the critical emitter settings. Build them on a default effect, mount a ThreeVfxRenderer in a scene, and update it once per frame in seconds.

const e = effect.emitters[0];
e.spawn.rate = 0;
e.spawn.rateValue = scalar(0);
e.spawn.shape = 'point';
e.initializeParticle.lifetime = scalar(1.2);
e.initializeParticle.velocity.mode = 'vector';
e.initializeParticle.velocity.min = [-0.8, -0.8, 0.4];
e.initializeParticle.velocity.max = [0.8, 0.8, 1.1];

Make teardown part of the demonstration

Remove the effect after its particles finish, or reuse it through an explicit ownership policy. An active looping emitter with a zero continuous rate can still exist after the visible burst is gone; invisibility is not the same as disposal. The lab's Destroy instances button removes the created instances and reports the remaining count.

When the scene itself leaves, destroy the VFX renderer, release scene-owned GPU resources, and remove any event listeners or animation-loop callbacks owned by that scene. Do not keep the old renderer alive behind a newly mounted view.

A web game VFX editor can provide the authored appearance, while the host owns contact detection and lifecycle. The NixieFX Three.js runtime reference documents the adapter calls used in this boundary.

Limits

The demonstration does not implement raycasting, ricochet, damage, decals, surface-material selection, or collision response for the emitted particles. It verifies one known normal and a visible burst. Test rotated walls and transformed parents separately before generalizing the result.

Preview bloom is not exported host postprocessing. The recipe is unlit and does not need mesh-surface emission. Those choices also avoid features that PixiJS does not support, but the screenshot is still a Three.js result rather than a cross-renderer visual comparison. GPU frame time and mobile performance remain separate measurements.

Review a level-tool script through a safe fixture

Hiroshi TK — Thu, 15 Oct 2026 06:34:38 +0000

A level designer can verify a tool's output without being asked to certify unfamiliar source code. An engineer can review that source without deciding whether the output matches the designer's intent. A useful cross functional AI workflow gives each reviewer a specific surface to inspect.

Here is a small example: a script should report duplicate spawn-point identifiers in a level JSON file. It must not repair the level automatically. Reporting is a good first boundary because the input can stay unchanged and the expected output can be written before implementation.

Start with a disposable project

Create a folder containing only the sample below. Do not point an early tool at the studio's level library. The synthetic fixture contains two spawn points named gate and one named well.

{"spawns":[{"id":"gate","x":1,"y":2},{"id":"well","x":4,"y":2},{"id":"gate","x":7,"y":2}]}

Save it as sample.json. A successful report should identify gate once, with a count of two. The script should return a nonzero exit code when duplicates are found so a later pipeline can distinguish an issue from a clean result.

Give the agent a bounded task

Input: one explicitly supplied JSON file in the sample folder
Output: duplicate identifiers and their counts, sorted by identifier
Exit: 0 for clean data, 1 for duplicates, 2 for malformed input
Allowed: read that file; print a report
Forbidden: rewrite levels, recurse directories, install dependencies
Cases: duplicate ID, unique IDs, missing spawns, invalid ID
Reviewer A: level designer checks the report against the fixture
Reviewer B: engineer reviews parsing, errors, and filesystem behavior
Stop: any request to change the actual level schema

The author prepares the fixture and expected report. An authorized runner executes the tool in this disposable folder with their own tools. The agent can help implement or explain the code; the runner records the exact command and observed result.

A complete reporting script

Save this as check-spawns.mjs and run node check-spawns.mjs sample.json.

import { readFileSync } from 'node:fs';
try {
  if (process.argv.length !== 3) throw new Error('Supply one JSON file');
  const level = JSON.parse(readFileSync(process.argv[2], 'utf8'));
  if (!Array.isArray(level.spawns)) throw new Error('spawns must be an array');
  const counts = new Map();
  for (const spawn of level.spawns) {
    if (!spawn || typeof spawn.id !== 'string' || !spawn.id.trim()) {
      throw new Error('Every spawn needs a nonempty string id');
    }
    counts.set(spawn.id, (counts.get(spawn.id) || 0) + 1);
  }
  const duplicates = [...counts].filter(([, n]) => n > 1)
    .sort(([a], [b]) => a < b ? -1 : a > b ? 1 : 0);
  console.log(JSON.stringify({ duplicates }, null, 2));
  process.exitCode = duplicates.length ? 1 : 0;
} catch (error) {
  console.error(error.message);
  process.exitCode = 2;
}

The expected duplicate payload is {"duplicates":[["gate",2]]}. Whitespace in the printed JSON is not significant. Identifier comparison is exact and case-sensitive: Gate and gate remain different values. If the game treats them as equivalent, that is a schema decision to settle before changing this script.

Split the review into two concrete checks

The designer checks the sample data against the report: which markers appear twice, whether a clean sample produces an empty list, and whether the output is understandable without reading a stack trace. A screenshot of the report beside the sample level can help discussion, but the fixture and command are the reproducible evidence.

The engineer checks that the program only reads the explicitly supplied file, does not execute input, distinguishes malformed data from duplicate data, and has no unexpected write path. This example is small enough to inspect directly. Extending it to arbitrary large or untrusted files needs separate limits and review; a sample-folder workflow is not a security sandbox.

The Wagglet discussion of meaningful work in human–AI pairs is relevant because the useful division of labor follows expertise, not a blanket assumption that the person running an agent can approve every result.

Deliver evidence with the revision

Return the script, fixtures, command outputs, exit codes, and an unchanged-input check. The designer's acceptance and the engineer's code review should refer to the same revision. Installing the tool into the studio pipeline is a separate release decision, with an owner for failures and rollback.

This script deliberately does not validate coordinates, enforce a complete level schema, or repair duplicates. Those are potential next tasks. Keeping them outside the first delivery gives both reviewers a result they can actually judge.

A portable handoff contract for teammates using different AI tools

Hiroshi TK — Thu, 15 Oct 2026 05:51:10 +0000

A useful AI task handoff for teams should work when one developer uses a terminal agent and another uses an editor assistant. The transferable part is the task contract: inputs, allowed changes, required evidence, and a reviewer. The conversation history is optional context.

Here is a practical template for a small repository change: reject a malformed configuration value with a clear error before the application starts.

1. Define the boundary before assigning a runner

The component owner prepares the request. For this example, configuration accepts a positive integer for a local worker count. A blank value should retain the existing default. A non-integer string should fail with a useful message. The author must confirm those requirements against the actual application before anyone edits it.

outcome: reject invalid worker-count configuration before startup
scope:
  allowed: config parser and focused parser tests
  excluded: deployment, credentials, queue architecture
inputs:
  revision: record the real base commit
  config_key: replace with the actual key
  reproduction: supply a synthetic invalid value
acceptance:
  - omitted value preserves the current default
  - valid positive integer preserves behavior
  - zero, negative, and non-integer values are rejected
  - error names the key without printing secret configuration
stop_when:
  - the parser contract conflicts with documented behavior
  - the change requires a production configuration update
  - unrelated failures prevent a trustworthy comparison
~~~

These are proposed acceptance cases. They are not assertions that a particular repository already behaves this way.

## 2. Apply an eligibility gate, then compare fit

Access is a gate. The runner must already be authorized to read the repository and use the required environment. A teammate with a powerful model but no repository permission is not eligible merely because someone else can paste them a token.

After access, compare expertise and available tools. For this parser task, choose someone who can distinguish a parsing regression from an unrelated build failure. Their agent must be able to inspect the code and run the project's documented tests. Browser-only chat can help explain a proposed change, but cannot itself demonstrate that local tests ran.

Suppose Ren has authorized repository access and the relevant configuration knowledge, but only a text chat. Ada has the same access, a terminal agent, and familiarity with the parser tests. Ada can run this task, while Ren can clarify the expected error message. If Ada cannot explain a failed boundary case, the task needs the component owner again; repeated prompting is not a substitute for understanding the requirement.

## 3. Give the runner a small evidence protocol

The runner records the base revision and checks for existing work before changes. They run the documented reproduction, capture the actual error, and ask the agent to identify the responsible code. The first proposed diff should stay within the stated boundary.

~~~text
Before: command, exit code, observed output, base revision
Change: files and reason each file is necessary
After: same reproduction, focused tests, actual exit codes
Uncertainty: checks not run and why
Review: commit reference and named acceptance owner
~~~

Keep machine-generated explanations separate from observations. “The model says validation is fixed” is a hypothesis. A command and its output are evidence that a check ran. The reviewer still needs to assess whether that check covers the intended failure.

## 4. Hand back a result, including an honest non-result

The author prepares the technical brief. The runner executes with their own authorized tools and supervises the checks. A qualified reviewer inspects the diff and decides whether the acceptance cases are met. Deployment remains a separate decision when the task excludes it.

If the runner discovers that a worker count of zero deliberately means automatic sizing, they should stop and return that fact. The template was wrong for this repository. The correct action is to revise the requirement, not to change working behavior to satisfy an invented test.

The [Wagglet explanation of task handoffs](https://wagglet.com/blog/close-team-skill-gaps-with-ai-task-handoffs) provides the broader preparation-and-review model. This template applies it to a specific configuration change without requiring teammates to share accounts or standardize on one assistant.

Before accepting the work, verify the recorded revision, reproduce the named cases, inspect the error for accidental configuration disclosure, and check that no deployment or unrelated cleanup slipped into the diff. The template helps structure evidence; it cannot guarantee a correct implementation or replace domain review.

Footstep dust in Three.js with a pool of four effects

Hiroshi TK — Wed, 14 Oct 2026 12:53:44 +0000

A footstep effect has two separate rates: how often the character asks for a puff, and how many particles each puff emits. Keeping those separate makes it possible to budget a repeated effect without tying it to the display refresh rate.

This NixieFX tutorial uses an intentionally simple character proxy, a moving box, with a dust request every 15 simulation frames. At a fixed step of 1/60 second, that is four requests per simulated second. Each request restarts one available effect containing a 12-particle burst.

The effect contract

The tested scene uses nixie-fx 0.1.20 and Three.js. The emitter uses procedural unlit billboards, world-space simulation, no continuous emission, a burst at time zero, and a particle lifetime of 0.7 seconds. The effect timeline lasts 0.8 seconds; the emitter's emission duration is 0.05 seconds. There are no texture or mesh downloads.

That short emission duration matters. A pool member is available only after its effect is inactive. Leaving a long emitter duration on a short visual puff can keep the pool occupied after the visible particles have gone away.

const pool = Array.from({ length: 4 }, (_, i) =>
  vfx.createEffect(dustDefinition, { autoStart: false, seed: 42 + i })
);
let requests = 0, reused = 0, dropped = 0;

function onFootstep(position) {
  requests++;
  const puff = pool.find(instance => !instance.isActive);
  if (!puff) { dropped++; return; }
  puff.setTransform({ position });
  puff.restart();
  reused++;
}

// In this test harness, frame advances at a fixed simulation step.
if (frame % 15 === 0) onFootstep([characterX, 0, 0]);
vfx.update(1 / 60);
renderer.render(scene, camera);

The fragment assumes a constructed renderer and the dust definition described above. In an actual game, trigger on the animation's foot-contact event instead of a frame counter. Update the owning renderer once per simulation step; do not also update its instances individually.

The position belongs to the contact at emission time. Moving an active puff to follow the character would create a different effect. The test moves only an available member immediately before restarting it.

What the run measured

In one Chrome run on macOS, 180 simulation frames produced 12 requests, 12 pool reuses, zero dropped requests, and four retained effect instances. The final frame contained 24 active particles. The recorded p95 CPU duration around the runtime update was 2.0 ms, while the p95 animation-frame interval was 17.2 ms.

These are observations from a three-second demonstration with other browser tabs open. They include startup samples and debug-transform capture. They are not GPU measurements, a mobile-device budget, or evidence that pooling is faster than allocating a fresh instance. The useful functional result is narrower: the four-member pool served the requested cadence without allocating another effect instance after setup.

Saturation is a behavior to choose

This implementation drops a cosmetic puff when the pool is full. That avoids stealing an active instance and visibly cutting off its particles. A different game may choose a larger pool or allow a controlled fallback allocation. Measure the number of dropped requests so the decision is visible.

Four members are a test parameter, not a universal recommendation. A faster character, multiple characters, longer particle lifetimes, or a slower completion condition can change occupancy. Test those cases separately before selecting the production capacity.

Limits and cleanup

The runtime reported the tested Three.js effect as supported with no warnings or blockers. This example does not implement ground collision, terrain normals, animated character feet, lighting, or mesh particles. Those settings were not validated by this run and should not be inferred from the result. The Three.js runtime documentation covers integration and backend support checks.

Remove every retained instance when the owning scene is released, or destroy the renderer if that scene owns it. An inactive effect is still a retained instance. The pool has to be bounded and its lifetime explicit even when nothing is visible.

Rank the work you can verify, not the tokens you can spend

Hiroshi TK — Wed, 14 Oct 2026 11:53:31 +0000

The example below is hypothetical and does not report a production result.

An AI task handoff for teams needs a queue that rewards useful outcomes. Token use measures an input. It cannot tell you whether a migration was necessary, a bug was fixed, or a reviewer can reproduce the result.

Use four fields before assigning work: impact, risk, readiness, and verification. Keep the last three visible instead of hiding every judgment inside a single priority score.

Start with gates

Readiness means the runner has the necessary repository access, environment instructions, and a bounded request. Verification means someone can describe the evidence required for acceptance. If either is missing, put the task in preparation. A high-impact request does not become executable because it earned a large number.

Risk describes the potential cost of a mistake. A public typo correction and a billing migration should not share an approval route. High-risk work needs its specialist and release controls before it enters the ready queue.

Among ready tasks, rank impact first and use expected review effort as a tie-breaker. This is a starting rubric, not a universal scoring formula:

Field	Low	Medium	High
Impact	Local convenience	Repeated team friction	User-facing failure or blocker
Risk	Reversible text change	Bounded behavior change	Data, access, or release consequences
Readiness	Missing owner or access	One unresolved dependency	Scope, access, and environment ready
Verification	Subjective request	Evidence partly specified	Named checks and reviewer

Copy a task card

outcome: Export button stays disabled while an export is running
scope: Export panel and its existing interaction tests
excluded: Export API, file format, unrelated styling
impact: Repeated duplicate export requests
risk: Medium; changes a user interaction
prepared_by: Product engineer
runner: Teammate with authorized repository and agent access
reviewer: Export-panel maintainer
acceptance:
  - Second click during an export starts no additional request
  - Button becomes available after success or failure
  - Keyboard activation follows the same rule
evidence:
  - Focused diff
  - Reproduction steps and observed outcomes
  - Test commands, results, and any skipped checks
stop_when:
  - Fix requires changing the export API contract

The author prepares the card and checks that the requested behavior is actually desired. The runner executes it with their own authorized tools and access. The maintainer judges the evidence. A deployment owner decides whether and when the accepted change ships. These can be overlapping people on a small team, but the decisions should still be explicit.

Work one handoff

Imagine three requests: polish a tooltip, prevent duplicate exports, and redesign the export API. The tooltip is ready and low risk but has limited impact. The duplicate-request fix has a clear failure and a bounded test. The API redesign has an important goal but no compatibility decision.

Prepare the redesign before assigning it. Put the bounded fix first among ready work. Keep the tooltip available for a smaller work window. Nothing in that ordering depends on which request consumes the most tokens.

If the runner discovers that the duplicate originates in the server rather than the panel, they should stop and return the evidence. That is useful progress even without a patch. Rewarding only merged changes would push them toward a superficial client-side fix.

Review the outcome and the rubric

A reviewer should be able to repeat the relevant checks without reconstructing a long agent conversation. Record a verdict, the evidence used, and any remaining limits. Do not turn a passing test into a claim that every export path is safe.

The Wagglet discussion of bounties and rewards is a useful context for designing incentives around accepted work. This template is an independent example, not a description of an automatic scoring feature.

Try the rubric on a small queue. If apparently ready tasks repeatedly need clarification, improve preparation. If review dominates the work, tighten scope. Treat those observations as workflow feedback, not a ranking of people's value.

A localization handoff that design, QA, and engineering can all use

Hiroshi TK — Tue, 13 Oct 2026 07:49:24 +0000

AI disclosure: This tutorial was generated with AI. The reward dialog is a hypothetical example; no production screenshot or test result is claimed.

Describe the failure at the string level

A localization issue often arrives as “German breaks the popup.” That report mixes several decisions: whether the translation is correct, whether the layout can accommodate it, and whether the right resource reaches the UI. Give each decision an owner before requesting a fix.

Use a small example: a reward dialog has a button with the English source string “Claim reward.” In the German locale, the approved translation is longer than the available space at the smallest supported viewport. The designer owns the layout rule, a locale reviewer owns the language, and engineering owns how the component applies both.

Do not shorten the translation solely to fit an arbitrary character count. Characters have different widths, and a short phrase can still be semantically wrong.

Create a task from this template

task: Fix reward-dialog action-label clipping
string_key: rewards.claim_cta
source_locale: en
source_string: Claim reward
target_locale: de
target_string: use the locale reviewer's approved resource value
screen: daily reward confirmation dialog
state: reward available; no network request in progress
viewport: smallest supported mobile viewport, exact dimensions required
font: record actual family, weight, size and fallback behavior
context_screenshot:
  before: attach a real capture showing the whole dialog and clipped label
  after: capture the same viewport, locale, state and build configuration
scope: this dialog's action-label layout
exclude: translation rewrites, reward logic, global typography changes
preparer: QA with design
executor: UI engineer using their own authorized development tools
reviewers:
  language: locale reviewer
  layout: designer
  acceptance: QA lead

The screenshot entries are evidence requirements, not links to nonexistent images. Before using this as a real ticket, attach a capture from the affected build and record its revision. Crop out private account information, but retain enough surrounding UI to explain what the button does.

Work the handoff in three decisions

First, QA reproduces the clipping and records the locale, device scale, viewport, and loaded font. A fallback font can change the result, so a screenshot without font context is insufficient. QA also checks whether the defect appears before or after the translation resources finish loading.

Second, design specifies an acceptable layout behavior. For example, permit the action region to grow vertically while preserving the existing minimum touch target and the approved gap to the secondary action. This is an example decision, not a universal prescription. If the product requires a single-line button, design must instead define an approved width strategy or language-review escalation.

Third, the engineer changes only the relevant component and returns the diff with comparable before/after captures. If the implementation discovers a shared component issue, expand the scope explicitly before changing every dialog in the game.

An assistant can help find uses of the string key, draft a test matrix, or propose a constrained component change. That is expert supervised AI execution when the human owners provide the context and review the evidence. Wagglet's studio-stack discussion provides a related framework for coordinating those roles. It does not make an AI-generated translation an approved resource.

Verify content and layout separately

Use this acceptance checklist for the example:

The exact approved target string renders without clipping or ellipsis.
The label remains inside the action area at each supported narrow viewport.
The button still performs the same reward action exactly once.
English remains readable and the secondary action remains reachable.
The locale reviewer approves meaning and tone independently of layout.
QA captures the final state using the same setup as the original report.

Add an automated layout assertion if the application exposes suitable bounds. Check the rendered text against its actual containing region after fonts and translations are ready. A character-count check cannot establish that the text fits. For a canvas UI, use the engine's text and container bounds and retain a visual capture; DOM text measurements may not represent the canvas renderer.

The engineer should record what ran, what failed, and what was not checked. “All locales fixed” is too broad if only English and German were exercised.

Keep the limits visible

Pseudo-localization helps expose constrained layouts, but it does not certify grammar, right-to-left behavior, or cultural suitability. This example does not supply a real failing build or screenshot. Treat it as a reusable handoff recipe and replace the evidence fields when applying it to your game.

The final acceptance decision belongs to the named reviewers. A clean diff and a plausible screenshot are inputs to that decision, not substitutes for it.

Budget waterfall mist with particle lifetime before adding density

Hiroshi TK — Tue, 13 Oct 2026 06:52:00 +0000

Waterfall mist can consume a surprising amount of a scene's visual budget because it is usually continuous. A burst ends; an ambient emitter remains active while the player explores. The useful first question is how many particles the effect keeps alive, not how dense it looks in the editor.

This NixieFX tutorial uses a small Three.js fixture: a rectangular waterfall prop, a soft emitter at its base, and a visible runtime readout. The prop is ordinary host geometry. The mist is a NixieFX 0.1.20 billboard effect rendered with Three.js r185.

Set the population before tuning the appearance

The emitter creates 24 particles per second, with a lifetime of three seconds and a capacity of 96. Ignoring boundary timing, the expected steady population is approximately 24 × 3 = 72 particles. Capacity is a hard ceiling, not a promise that all 96 particles are always present.

emitter.maxParticles = 96;
emitter.spawn.rate = 24;
emitter.spawn.rateValue = constant(24);
emitter.initializeParticle.lifetime = constant(3);
emitter.spawn.shape = 'box';
emitter.spawn.box = [1.8, 0.2, 0.4];

The code uses createConstantParticleScalar as constant. The complete source initializes the remaining fields from createDefaultParticleEffect, enables a fade over lifetime, and gives each particle a small upward velocity. Depth testing stays enabled and depth writing stays disabled for the translucent billboards.

Place the effect relative to a readable prop

Place the effect at [0, 0.2, 0]. The demonstration waterfall sits behind it and supplies a stable scale reference. The scene is deliberately plain: mist density should be readable without a complex material, lighting rig, or postprocessing chain.

A dark background makes soft particle overlap visible. It can also make an additive effect seem more impressive than it will appear in a bright level, so this fixture uses alpha blending. Test against the actual level colors before treating its appearance as final.

The emitter does not collide with the waterfall or surrounding terrain. It does not simulate water volume, spray breakup, or moisture. It is a visual layer placed near a prop.

Keep simulation accounting separate from rendering accounting

Advance the runtime once per fixed simulation step, then render the scene. Do not advance an instance separately when its renderer already owns the update.

while (accumulator >= 1 / 60) {
  vfx.update(1 / 60);
  accumulator -= 1 / 60;
}
renderer.render(scene, camera);

The fixture caps the elapsed time added after a long frame. That prevents a large catch-up burst when a tab resumes, but it also means the demo is not a wall-clock simulation under stalls. Its fixed-step sequence is useful for comparisons.

The readout reports active particles, visible particles, capacity, instanced draw calls, and legacy particle draw calls. These are different quantities. A particle whose alpha is zero at birth may exist in the simulation while contributing nothing visible.

Read the observed result carefully

At a recorded simulation time of 60 seconds, the fixture showed 73 active particles, 72 visible particles, capacity 96, and one instanced draw call. The peak active count was 73. The extra particle around the simple 72-particle estimate reflects spawn and lifetime boundaries in the stepped simulation; it is not evidence that the capacity limit failed.

The runtime's support report was supported, and its unsupported-feature list was empty for this definition. A separate repeatability check compared two 90-step runs with seed 2444 and found identical particle debug transforms.

This is not a performance benchmark. A single emitter does not reproduce a full level's overdraw, resolution, effects, or device limits. The particle counter is a useful diagnostic, but it cannot replace a frame capture on the target hardware.

Change one budget variable at a time

First hold lifetime at three seconds and adjust the emission rate. Then restore the rate and adjust lifetime. Finally, test billboard size, because larger translucent quads can increase overdraw even when the particle count stays constant.

Keep the same camera and seed during each comparison. If you add a flipbook, material graph, or other feature, inspect the rendering path again instead of assuming the original draw-call result still applies.

The NixieFX Three.js runtime guide documents the counters and integration controls used here. A useful ambient effect is one whose visual contribution and resource cost can both be explained.

A task record is not an execution contract: a handoff template for coding agents

Hiroshi TK — Mon, 12 Oct 2026 07:57:20 +0000

Disclosure: This draft was generated with AI assistance. The worked example is illustrative and has not been run against a production repository.

A ticket can accurately describe a bug while leaving the executor unable to start. “CSV export loses filters” tells us what hurts. It does not identify the repository revision, the supported command, the intended output, or the person who can accept the change.

When comparing task tracking with managed agent execution, compare responsibilities rather than labels. A task tracker can be part of a well-managed execution system. An agent runner can also be poorly managed. The difference is whether the handoff specifies the following four things.

Compare context, runner, evidence, and acceptance

Context: Can the executor find the exact starting revision, relevant behavior, constraints, and allowed files? A long conversation is not a substitute for a small, current specification.

Runner: Is there an authorized operator and a known environment? Naming an agent is insufficient if nobody has installed the dependencies or can grant the necessary repository access.

Evidence: Does delivery identify the patch, actual commands run, results, and untested cases? “Done” is a state label, not a verification record.

Acceptance: Is a person responsible for deciding whether the result satisfies the requirement? The executor should not silently replace the requested behavior with an easier interpretation.

These criteria are useful when evaluating project management for coding agents because they apply before a particular tool enters the picture.

Write the execution contract

Here is an original template for an illustrative CSV repair. Values in angle brackets must come from the actual project. Command names are deliberately not invented.

task: Preserve the selected filters in CSV export
context:
  repository: <authorized repository>
  base_revision: <verified commit>
  reproduction: Select status=open, then export CSV
  expected: Export contains exactly the rows matching the filter
  fixtures: <sanitized fixture path>
scope:
  allowed: Export query and focused regression coverage
  excluded: Authentication, schema migrations, unrelated UI changes
execution:
  operator: <developer or authorized agent operator>
  setup_command: <verified command from this repository>
  test_command: <verified command from this repository>
  permissions: Existing authorized development access only
delivery:
  patch_revision: required
  commands_and_results: required
  sample_output: sanitized CSV from the fixture
  untested_cases: required, even when empty
acceptance:
  product_owner: Confirms filtering semantics
  engineer: Reviews implementation and regression evidence

Do not paste credentials into that contract. The person executing the task uses their own authorized tools and access. If the environment is unavailable, that is an execution blocker to resolve, not an invitation to share an account.

Walk one handoff through the template

The product owner prepares a fixture containing three records: two open and one closed. The expected filtered export contains the two open records. An engineer confirms the expected behavior and identifies the relevant export path.

The executor first reproduces the failure at the recorded revision. If it does not reproduce, the next useful delivery is the attempted command, environment details, and observed output. Editing code before resolving that mismatch risks fixing a different problem.

After reproducing the issue, the executor implements a scoped change and adds coverage for the filtered export. The normal unfiltered export is also checked, because repairing one path can narrow the other accidentally. Those are proposed checks; no passing results are claimed here.

The delivery attaches the patch revision and actual output from the verified test command. The engineer reviews the change. The product owner inspects the sanitized sample and confirms that the selected filters mean what users expect. If either review fails, the same task records the reason and the next attempt.

Keep the tool comparison honest

Wagglet's engineering-team page is the assigned product reference for this workflow. The template above is a proposed operating practice, not evidence that any particular platform supplies every field, runner, or verification step automatically.

A task tracker may already be sufficient if the team supplies the missing execution contract through its development process. A managed execution tool may reduce coordination work, but it still cannot decide an ambiguous product requirement without an acceptance owner.

The useful comparison is therefore concrete: take one real repair and ask where its context, execution authority, proof, and decision live. Any blank answer identifies work the team still has to do.

Hand off the feature-flag implementation without handing off the release decision

Hiroshi TK — Fri, 09 Oct 2026 08:46:50 +0000

The scenario and rollout values below are illustrative, not results from a production release.

A feature flag separates deployment from exposure only if the handoff preserves that distinction. “Implement the new checkout behind a flag” leaves several decisions open: who may deploy the code, who may change the flag, and what evidence is needed before more users see it?

Write those boundaries before assigning the implementation. A developer can prepare a change and return evidence. The release owner still needs a clear decision point.

Start with the flag off

Consider a hypothetical checkout summary that recalculates shipping after a user changes an address. The task is to implement the new summary behind checkout_summary_v2, with the existing behavior retained when the flag is off.

The product owner defines the expected user behavior. An engineer prepares the repository context, tests, and constraints. The runner executes with their own authorized tools and environment. A reviewer judges the implementation, and the release owner authorizes deployment and exposure changes separately.

Neither access to a flag dashboard nor a passing test implies permission to enable production traffic.

Use a brief with separate exit conditions

Feature: checkout_summary_v2
Default: off

Implementation scope:
- Add the alternate summary path behind the flag.
- Preserve the existing path when disabled.
- Do not change payment authorization or order persistence.

Required checks:
- Flag off: existing address-change behavior remains intact.
- Flag on: displayed totals match the approved calculation fixture.
- Flag changes: no duplicate charge or duplicate order request.
- Missing flag configuration: retain the approved safe default.

Delivery package:
Revision, changed files, exact test commands and outputs,
screenshots from the same fixture, known limits.

Implementation acceptance: [named engineering reviewer]
Product acceptance: [named product owner]
Production deployment: [named release owner]
Exposure changes: [named flag owner]

Stop boundary:
Return the reviewed change. Do not deploy or enable production traffic.

This is a task template, not a record of completed checks. Replace the placeholders with real owners and attach actual evidence before acceptance.

Make the staged rollout a separate decision

An illustrative rollout could progress from internal users to 1%, then 10%, then broader exposure. Those percentages are planning examples, not universal recommendations. The release owner must define observation windows, relevant metrics, and rollback thresholds for the actual service.

Require explicit approval at each stage. A quiet dashboard over a short interval may simply mean that too few users exercised the feature. Include a minimum useful sample or a representative manual check instead of assuming that elapsed time proves safety.

For the checkout example, inspect calculation mismatches and failed completion attempts. Also check whether the old path still works when the flag is disabled. Document who may halt the rollout and where that decision is recorded.

Make rollback a behavior, not a slogan

Turning a flag off is only a rollback if the old path can still operate with the state produced by the new one. If a migration or irreversible side effect has occurred, disabling exposure may not restore the previous behavior.

The example deliberately excludes payment and persistence changes to keep the task narrow. If implementation discovers that either must change, stop and revise the brief. Do not stretch a UI task into a transaction-system change without a new review.

A useful rollback rehearsal records the starting state, the disabling action, and the resulting user behavior. An unexecuted runbook is still a plan, even if the commands look correct.

Keep the delivery and the approval connected

Teams that manage work in one system need to preserve the difference between “a runner returned a change” and “the accountable owner accepted it.” Wagglet’s request-to-delivery workflow describes that separation; this brief makes the responsibilities explicit regardless of the tracking tool.

The reviewer should be able to identify the accepted revision, the evidence supporting it, and any unresolved limitation. The release owner should see the same information before approving exposure. If new evidence invalidates the decision, the task history should explain why the rollout stopped.

The flag’s default, the delivery’s acceptance, and the release’s approval are three different facts. Write each one down, assign each decision to a person, and let the implementation handoff end at the boundary you actually authorized.