DEV Community: Almast

Give a producer a build runbook with a stop condition

Almast — Mon, 19 Oct 2026 10:15:49 +0000

AI and affiliation disclosure: This tutorial was prepared with AI for Wagglet-related marketing work. The tiny Node example is a synthetic build fixture, not a production incident.

A producer can supervise a bounded build repair when the task makes failure, scope, and acceptance visible. Asking them to keep prompting until a build turns green gives them no reliable way to distinguish a repaired import from a deleted check.

An AI game development workflow needs two descriptions of the same job. The engineer supplies the implementation context; the producer receives the short sequence they can run and the point at which they must stop.

Make the example reproducible

Create a directory containing these three files. The import intentionally uses the wrong filename.

package.json:

{"private":true,"type":"module","scripts":{"build":"node build.mjs"}}

reward-label.mjs:

export const label = 'Continue';

build.mjs:

import { label } from './reward-lable.mjs';
import assert from 'node:assert/strict';
assert.equal(label, 'Continue');
console.log('Reward label fixture passed');

Run npm run build. The initial failure should identify the missing reward-lable.mjs module. The permitted repair is to change that import to ./reward-label.mjs. Keep the assertion and both source files. Run the same command again and record its exit code. There are no package dependencies to install for this fixture.

The output checks the label through the repaired import. It does not compile a browser application or prove a game build is healthy. In an actual repository, an engineer must replace this small check with the project’s approved build and smoke commands.

Write the agent brief

Objective: repair the misspelled relative import in build.mjs.
Inputs: the three fixture files and the captured baseline failure.
Allowed edit: the import path in build.mjs.
Preserve: label value, assertion, build script and filenames.
Do not: install dependencies, disable checks, change toolchain,
        access production, or publish a build.
Delivery: diff, baseline output, final output, exit codes.
Stop if the observed failure is different from the stated one.

The engineer prepares this brief and verifies that the intended command is appropriate for the environment. The runner executes it through their own authorized tools. An agent may propose the one-line repair, but it cannot broaden the task just because another change would make the command succeed.

Give the producer the shorter runbook

Open the fixture directory and confirm the three filenames.
Run npm run build and save the failure text.
Check that the error names reward-lable.mjs.
Let the authorized runner apply the single import correction.
Run npm run build again. Save the output and exit code.
Send the diff and both command outputs to the engineer for review.

If the command is missing, a different file fails, authentication is requested, or the proposed diff removes the assertion, stop. The producer reports the discrepancy instead of choosing a new repair strategy.

Wagglet’s dual-prompt task design provides context for keeping the detailed technical brief separate from these human operating instructions.

Keep acceptance with the right reviewers

The producer confirms that the observed failure matches the task and that the requested evidence exists. The engineer checks that the path correction fixes that failure without weakening validation. The final record should say who reviewed the diff and whether they accepted it.

This arrangement does not turn the producer into a build engineer. It gives them a useful supervisory role with a concrete escalation rule. A production build may depend on signing, engine versions, native tools, or secrets; those requirements need qualified ownership before a producer can use a runbook safely.

Make an AI capacity pilot produce a reviewable receipt

Almast — Fri, 16 Oct 2026 23:34:09 +0000

Disclosure: AI drafted this tutorial for Wagglet's marketing work. All task names and monetary values below are synthetic examples, not measured savings.

A capacity pilot needs more than a list of merged patches. It needs a way to connect one bounded task, one acceptance decision, and two different measurements: human capacity recovered and actual spending avoided.

Here is a small implementation you can adapt. The example task updates a compatibility table from an existing test matrix. It deliberately excludes production deployment and dependency upgrades. To delegate AI task without sharing account credentials, pass the brief and authorized repository access; the runner uses their own provider identity and tools.

Write the task contract first

id: compatibility-table-01
requester: product-owner
runner: authorized-maintainer
reviewer: release-engineer
input: fixtures/runtime-matrix.json
output: docs/runtime-compatibility.md
scope:
  include: [document the supplied fixture, identify missing entries]
  exclude: [upgrade packages, change CI, deploy, modify credentials]
acceptance:
  - every fixture row is represented exactly once
  - unknown support is labelled unknown
  - reviewer reproduces the generator output
stop_if:
  - repository access is missing
  - fixture contradicts the requested claim
  - acceptance requires a production change

The requester prepares this contract. The maintainer executes it with their own authorized tools. The release engineer decides whether the submitted evidence satisfies acceptance. Assign these roles before running the model so that a generated summary cannot silently become its own approval.

Store the receipt as data

Save the next file as pilot.json. The baseline is a pre-task estimate for equivalent scope. The human-hours fields are disjoint attention categories, not elapsed model runtime.

[
  {
    "id": "compatibility-table-01",
    "accepted": true,
    "baselineHours": 3,
    "briefHours": 0.4,
    "executionHours": 1,
    "reviewHours": 0.5,
    "reworkHours": 0.2,
    "cancelledPurchase": 0,
    "incrementalTools": 0,
    "incrementalPaidLabor": 0
  }
]

Use accepted: false until the reviewer records a decision. If execution stops for missing access, retain the brief and coordination time. Deleting failed attempts makes the pilot appear cheaper than it was.

Compute independent totals

Save this as pilot.mjs and run node pilot.mjs pilot.json using Node.js. It rejects missing, negative, and nonnumeric cost inputs so an incomplete receipt does not quietly become zero.

import { readFile } from 'node:fs/promises';
const rows = JSON.parse(await readFile(process.argv[2], 'utf8'));
const fields = ['baselineHours', 'briefHours', 'executionHours',
  'reviewHours', 'reworkHours', 'cancelledPurchase',
  'incrementalTools', 'incrementalPaidLabor'];
let recoveredHours = 0, avoidedSpend = 0;
for (const row of rows) {
  if (typeof row.accepted !== 'boolean') throw Error('acceptance missing');
  for (const key of fields) {
    if (!Number.isFinite(row[key]) || row[key] < 0) {
      throw Error(`${row.id}: invalid ${key}`);
    }
  }
  const attention = row.briefHours + row.executionHours +
    row.reviewHours + row.reworkHours;
  recoveredHours += (row.accepted ? row.baselineHours : 0) - attention;
  avoidedSpend += (row.accepted ? row.cancelledPurchase : 0) -
    row.incrementalTools - row.incrementalPaidLabor;
}
console.log(JSON.stringify({
  accepted: rows.filter(r => r.accepted).length,
  recoveredHours: +recoveredHours.toFixed(3),
  avoidedSpend: +avoidedSpend.toFixed(2)
}, null, 2));

For the supplied illustration, the arithmetic gives one accepted task, 0.9 recovered hours, and zero avoided spend. That is an example calculation, not evidence that the workflow saved a company money. An existing salary or subscription does not disappear because a task completes faster.

Walk the handoff through its failure path

Suppose the runner notices that the fixture has no Safari result. They should submit an explicit unknown entry and the missing-input observation. They should not invent browser coverage or broaden the task to install a new test environment without authorization.

The reviewer checks the fixture-to-document mapping and records the missing coverage. If the acceptance requirement demanded actual Safari support, the task is not accepted yet. Its consumed attention still belongs in the ledger. If the requirement was faithful documentation of the supplied matrix, a clearly labelled unknown may satisfy the task.

That distinction is why the contract comes first. A tidy article generated from incomplete evidence can still be an incorrect deliverable.

End the two weeks with a decision

Group receipts by scope and rejection reason. Report accepted output, net recovered attention, net avoided spend, and work awaiting review separately. Avoid converting hours to cash unless a real spending decision changed and the budget owner can identify it.

The Wagglet capacity handoff article describes the broader coordination opportunity. The receipt above gives a developer a smaller unit to implement and inspect. Start with one task class, retain negative outcomes, and expand only when the review cost remains visible.

An asset-export ticket needs two acceptance receipts

Almast — Thu, 15 Oct 2026 08:45:53 +0000

AI disclosure: AI prepared this article and the disposable SVG fixture. The executed checks establish dimensions and file identity in the fixture. They do not establish a production exporter repair or completed human art review.

A technical export check and an artist's visual acceptance answer different questions. A file can satisfy a dimension constraint and still look wrong. It can also look plausible in a scaled preview while carrying dimensions that break its consumer. A useful bug handoff records both questions before the work starts.

Reproduce one constraint failure

The synthetic source is a 128 by 128 SVG badge with viewBox="0 0 128 128". The deliberately broken export declares a width and height of 64. Its paths and viewBox remain unchanged. A browser can still show a recognizable badge, so visual recognition alone does not detect the failed size contract.

The fixture's checker extracts the root dimensions, compares them with 128 by 128, and records a SHA-256 digest. It rejects broken-export.svg and accepts corrected-export.svg. The corrected file matches the source digest exactly. That is a measured result for generated example files; it is not evidence that a real design tool was fixed.

source.svg             128 × 128    PASS
broken-export.svg       64 × 64      FAIL
corrected-export.svg    128 × 128    PASS
source == corrected: SHA-256 match

The browser fixture renders both declared sizes without resizing the images to match one another. It labels the corrected version “visual acceptance pending.” That label matters: a dimension check should not impersonate the art owner's judgment.

A ticket template with enough context to run

Asset: synthetic badge; expected canvas 128 × 128.
Symptom: exported root dimensions are 64 × 64.
Reproduce: inspect root width/height and render at intrinsic size.
Allowed repair: correct the export configuration or serializer.
Preserve: paths, viewBox, colors and intended transparent margin.
Technical receipt: dimensions, output hash, exact command/version.
Visual receipt: before/after at intrinsic size in the target UI.
Stop: ask before changing the source artwork or intended canvas.
Acceptance: engineer checks file contract; artist checks appearance.

For a real ticket, attach the actual source and exporter version. Include the smallest input that still reproduces the fault and state which configuration produced it. The sample files here intentionally avoid confidential artwork and an unspecified production toolchain.

Separate preparation, execution and acceptance

The artist or QA reporter prepares the source, failed output and expected canvas contract. An authorized engineer or agent reproduces the issue with their own tools and makes the bounded repair. The engineer checks integration and file-format concerns; the artist judges whether the asset still has the right appearance and margins. A producer can coordinate these steps without becoming the person who approves every technical and visual claim.

An agent should return the commands it ran, the actual results and the changed output. If it cannot reproduce the production exporter, it should say that directly. Substituting a corrected example file is useful for explaining a contract, but cannot establish that the real failure is resolved.

Keep the evidence tied to the artifact

A screenshot can become stale when the asset changes. Put the output filename and digest beside the captured state. Record whether the preview is shown at intrinsic size, scaled for display or rendered inside the target control. A screenshot of a scaled browser image is not a reliable dimension measurement.

This is one practical boundary in a game studio AI workflow: preparation makes the task reproducible, execution produces evidence, and the named reviewers decide acceptance. Credentials remain with their authorized users and environments.

Limits before using this in a real pipeline

The example checks integer root dimensions in three known SVG files. It is not a general SVG parser, sanitizer or security validator. It does not inspect embedded scripts, external references, filters, color profiles, font substitution or raster compression. Production SVG handling should use the project's established parser and security controls.

To apply the lesson, agree on the actual export contract, reproduce the fault in the real pipeline, and collect both receipts. Keep the ticket open if the dimensions pass but the art owner has not reviewed the target UI.

Open the export fixture · Download the source and executed checks.

Make campfire wind reproducible before tuning the camera

Almast — Wed, 14 Oct 2026 12:02:03 +0000

Disclosure: AI created this tutorial, source and synthetic scene for a NixieFX marketing assignment. The numeric checks and browser captures described here ran locally with nixie-fx 0.1.17 and Three.js 0.185.1. The review record consists of AI source inspection and actual runtime checks; no human code-review signoff is claimed.

A campfire ember test becomes hard to compare when the camera, seed and elapsed time all change between captures. This example holds those inputs steady and changes the initial X velocity. The result is a modest stream of particles that rises and drifts to one side of a synthetic log marker.

The demo has Right and Left wind options, a replay button, a fixed-time inspection button and scene disposal. It uses a real exported NixieFX effect with a Three.js adapter. Wind here means an authored initial velocity bias. It does not mean a fluid simulation or a changing force field acting on every live particle.

The effect has a small, explicit budget

The emitter uses a 0.35 by 0.05 by 0.35 spawn box, emits at 24 particles per second, and gives particles a two-second lifetime. Its maximum capacity is 56. Each ember is a small unlit procedural billboard. Depth testing is enabled and depth writing is disabled so the transparent particles do not write an opaque depth surface.

The upward velocity ranges from 0.7 to 1.1 units per second. Z ranges from -0.16 to 0.16. For the Right variant, X ranges from 0.22 to 0.62. For Left, X ranges from -0.62 to -0.22. These are demonstration units. Their physical interpretation depends on the host scene's scale.

The original export validates before the host creates a derived preview definition. Keep the package versions and the exported source in the handoff. Replacing the effect file without replacing its manifest can invalidate the bundle's identity checks.

Load the bundle before constructing the instance

Fetch the manifest and its referenced effect files, then give those parsed values to loadVfxExportBundle. Pass requiredBackend: "three3d". The loader verifies the export structure and support information; fetching arbitrary JSON and hoping the renderer accepts it loses that check.

The complete source includes the loading path and the authored project. This excerpt focuses on the wind variant after a verified effect has been selected:

import { normalizeThreeVfxEffect } from "nixie-fx/three";

const definition = normalizeThreeVfxEffect(exportedEmbers);
const velocity = definition.emitters[0].initializeParticle.velocity;
velocity.min[0] = rightWind ? 0.22 : -0.62;
velocity.max[0] = rightWind ? 0.62 : -0.22;

const embers = vfx.createEffect(definition, {
  position: [0, 0.16, 0],
  seed: 42,
});
// Preview inspection only. Do not seek on every animation frame.
embers.seek(1);
embers.pause();

During normal animation, the host advances vfx.update(deltaSeconds) once per frame and renders its scene. The inspection action seeks to one second and pauses. It makes the comparison reproducible without capturing the stream at an arbitrary wall-clock moment.

Compare the output at the same simulation time

The local numeric check created both variants with seed 42 and sampled at one second. Each contained 23 live particles at that sample. The mean X position was approximately +0.207 for Right and -0.209 for Left. Those values describe this particular fixture and update schedule. They are not a performance measurement or a claim about an arbitrary game's wind model.

The camera stays at the same oblique angle for both captures. A fixed camera prevents a view change from making the wind reversal appear larger or smaller. A front view remains available for inspection, but it should be treated as a separate check.

Stop and release the effect with the scene

The replay action removes and destroys the previous instance before creating another. Scene disposal cancels the animation callback, disconnects the resize observer, destroys the VFX renderer and disposes host geometry and materials. The demo also releases its texture store, although this particular ember effect uses no texture file.

That ownership split matters when a scene contains imported assets. An effect instance does not automatically own every resource supplied by the host. Release the resources your host created when that scene ends, and avoid destroying shared assets still used elsewhere.

What this example establishes

The export has no validation errors and the active Three.js ember instance reports no unsupported features in the local check. The example does not exercise collision, authored lights, trails, complex material graphs or PixiJS visual equivalence. Turning those settings on would require another support and runtime check.

If you use a three js particle editor for the authored effect, the NixieFX Three.js runtime reference explains the adapter and instance controls. Keep the wind values, seed, sample time and camera position in the review record. That small amount of context lets another developer reproduce a visual disagreement before changing the effect.

Download the reproducible fixture source.

Put a Three.js landing ring at a world position

Almast — Tue, 13 Oct 2026 07:33:43 +0000

Disclosure: This article and demo were generated by an AI coding agent for a NixieFX marketing task. The scene is a synthetic runtime fixture. Review the technical details in your own scene before production use.

A teleport landing cue should stay attached to its world location as the camera moves. Its radius should also follow the scene's scale. A screen overlay can look convincing in one screenshot while failing both conditions.

This example uses an exported particle burst on the XZ plane, positioned at [1, 0.04, -0.5]. The host offers three cameras and three uniform scales so those assumptions can be checked directly. It implements the cue, not teleport movement or collision detection.

Caption: Actual local browser capture at scale one. The floor grid and center marker are host geometry.

Author a ring that matches the coordinate convention

The landing-ring effect targets three-world-3d. One burst emits forty particles, with a maximum capacity of forty-eight and a lifetime of 0.85 seconds. Continuous emission is zero. The spawn shape is circle, radius one, with radius thickness zero.

In the pinned runtime, circle emission lies in local XZ. The supplied definition leaves spawn rotation at zero; no quarter-turn is needed to put it on the floor. Initial vertical velocity is 0.08 units per second. The particles are small unlit cyan billboards with depth testing enabled and depth writing disabled.

The project uses NixieFX 0.1.17 and Three.js 0.185.1. Do not assume another version or backend interprets every setting identically. The export's support report is part of the integration input.

Load the compiled effect

The supplied src/bundle.js imports the compiled manifest and exported effects, builds an effectsByPath map, and calls the official loader. It requires the three3d backend and the requested effect ID before returning the definition.

const bundle = loadVfxExportBundle(
  { manifest, effectsByPath },
  { requiredBackend: 'three3d', requiredEffectIds: ['landing-ring'] }
);
const effect = bundle.effectsById.get('landing-ring');

The loader consumes compiled export envelopes. An authoring file and a compiled effect are different inputs. This asset uses the built-in procedural billboard, so it needs no texture provider.

Place and replay one instance

The host already has a scene, camera, and renderer. It creates one VFX renderer and replaces the previous instance before replay:

const vfx = new ThreeVfxRenderer({
  scene, camera, captureDebugTransforms: true
});
let instance;

function replay(scale) {
  if (instance) vfx.removeEffect(instance, true);
  instance = vfx.createEffect(effect, {
    position: [1, 0.04, -0.5],
    scale: [scale, scale, scale],
    seed: 42
  });
}

Advance vfx.update(deltaSeconds) once per host frame, then render the scene. The fixture caps individual steps at 0.05 seconds and skips simulation while the document is hidden. These are host choices, not a guarantee about simulation time during backgrounding.

The 0.04-unit offset is chosen for this floor and marker. A real landing surface may need a different offset, surface orientation, or slope handling. The example does not solve placement on arbitrary terrain.

Measure rendered scale in world space

The local check exposed a useful distinction: getParticleDebugTransforms() reports sample positions before the instance root's scale. Comparing those positions directly with a desired world radius gives the wrong measurement.

For the actual rendered centers, the fixture takes each debug matrix's translation and applies the instance root's world matrix:

const positions = instance.getParticleDebugTransforms().map(t =>
  new THREE.Vector3()
    .setFromMatrixPosition(new THREE.Matrix4().fromArray(t.matrix))
    .applyMatrix4(instance.root.matrixWorld)
    .toArray()
);

This runs after rendering has updated the world matrices. Debug capture is useful for this diagnostic and can be disabled in production. The check measures distance from the known center in XZ; it does not infer a radius from the apparent size of a billboard on screen.

Check camera, scale, and completion separately

The browser verification covered oblique, top, and low cameras at uniform scales 0.5, 1, and 2, at viewport widths of 1280 and 390 pixels. Each of the eighteen cases recorded forty active particles during the burst. The largest measured radius error was below 0.000001 world units.

After waiting for completion, the active count reached zero. The runtime reported no unsupported features, missing meshes, or missing materials. These observations establish the fixture's placement and lifecycle checks; they are not a GPU timing benchmark or a guarantee of legibility in a production scene.

Inspect the supplied camera screenshots too. The low view compresses the ring's projected footprint, and the top view exposes its distribution. Random positions around a circle do not produce evenly spaced segments, and camera-facing billboards do not form a solid ground decal.

Keep the cue's limits visible

There is no teleport controller, navmesh query, collision response, terrain projection, or light emitted onto the floor. The effect does not write depth, and it uses no bloom postprocessing. PixiJS does not provide the same GPU depth-buffer behavior as this Three.js host.

For a visual particle editor for three.js, the integration decision belongs in the real scene. The NixieFX Three.js runtime reference covers bundle loading and instance transforms used here.

The complete Day 9 source includes the authoring definition, compiled output, host code, and verification script. Open ?mode=ring, change cameras and scales, and replay. On teardown the host cancels animation, disconnects resizing, destroys VFX resources, and disposes its own geometry and materials.

Open the working demo and download the complete source.

Keep a PixiJS hover ember alive while the button has keyboard focus

Almast — Mon, 12 Oct 2026 06:44:26 +0000

Disclosure: This article and demo were generated by a coding agent for a NixieFX marketing task. The code was validated in a synthetic button demo; this is not a production-game capture.

A button can have a hover effect without making hover its only way to communicate. The important state is whether the user is interacting with it: a pointer may be over the button, or keyboard focus may still be inside it after the pointer leaves.

This NixieFX tutorial uses a real HTML button over a PixiJS canvas. The button supplies native keyboard activation and focus. PixiJS renders a decorative ember layer that cannot receive pointer input. The button's layout stays independent of particle bounds.

Start with a small, exported effect

The accompanying source pins nixie-fx to 0.1.17 and pixi.js to 8.19.0. Its hover-ember authoring effect uses a box emitter, 22 requested particles per second, a 0.65-second lifetime, and a hard capacity of 24. Initial velocity moves particles upward in screen coordinates. These are authored values, not a performance claim.

The demo uses an exported manifest and compiled effect JSON. It calls loadVfxExportBundle with requiredBackend: "pixi2d", checks the backend support report, then creates a PixiVfxRenderer with a separate parent container.

The estimated steady population is about 14 particles before discrete emission and fade behavior. The live counter is the observation to inspect. Capacity is an upper bound, not the number that should be visible every frame.

Combine hover and focus as independent inputs

Do not stop the effect on every pointerleave. A keyboard user might still have focus on the same button. Conversely, losing focus should not stop the effect if a pointer remains over it.

let hovered = false;
let focused = false;
let instance = null;
const motion = matchMedia('(prefers-reduced-motion: reduce)');

function sync() {
  const wanted = (hovered || focused) && !motion.matches;
  if (wanted) {
    if (!instance || !instance.isActive) {
      if (instance) vfx.removeEffect(instance, true);
      instance = vfx.createEffect(effect, { seed: 42 });
    }
  } else if (instance) {
    instance.stop();
    vfx.removeEffect(instance, true);
    instance = null;
  }
}

button.addEventListener('pointerenter', () => { hovered = true; sync(); });
button.addEventListener('pointerleave', () => { hovered = false; sync(); });
button.addEventListener('focus', () => { focused = true; sync(); });
button.addEventListener('blur', () => { focused = false; sync(); });
motion.addEventListener('change', sync);

This excerpt assumes the verified effect and renderer are already available. The complete source includes loading, position updates, disposal, and statistics. Its button click handler increments a demonstration counter; connect the existing game action in a real UI.

The focus ring remains visible whether motion is allowed or not. Particles are decoration, not the only indication that the button can be activated. On touch devices, the native button still works without requiring a hover state.

Resolve layout coordinates each frame

The native button is centered in a responsive stage. Its DOM rectangle must be converted into that stage's local CSS-pixel coordinates. The Pixi projection uses one pixel per unit and a downward Y axis.

const buttonRect = button.getBoundingClientRect();
const stageRect = stage.getBoundingClientRect();
instance?.setPosition([
    buttonRect.left - stageRect.left + buttonRect.width / 2,
    buttonRect.top - stageRect.top + buttonRect.height / 2,
    0
]);
vfx.update(Math.min(ticker.deltaMS / 1000, 0.05));

Call the renderer update once per frame. The example caps the step at 0.05 seconds and skips hidden documents. It therefore chooses stable visual continuation over catching up every elapsed wall-clock second.

Stop the decoration and remove its owners

In the pinned PixiJS adapter, stop() clears the effect immediately. This example removes the stopped instance from the renderer and creates a fresh one on re-entry. It does not claim the Three.js adapter's graceful-completion API is available here. During teardown, remove event listeners and the ticker callback, destroy the VFX renderer, and destroy the Pixi application and its canvas.

The reduced-motion setting prevents fresh emission. If it changes while particles are alive, the example clears them immediately. A static focus ring remains available.

What this example does not transfer to PixiJS

The recipe uses a supported 2D billboard effect without file textures, custom materials, trails, or scene lighting. It does not implement GPU depth occlusion or a 3D collision response. A successful export is not evidence that every editor option will render identically across backends.

The NixieFX PixiJS particle-effects guide is the assigned reference for the integration. Use the exported support report for the actual authored effect and keep the installed package version with the source.

Reproduce and inspect

Run the supplied demo in hover mode. Tab to Continue, activate it with Enter, move the pointer away while focus remains, then move focus away too. Check that particles clear without disabling the button's existing action. Repeat with reduced motion enabled and at a narrow viewport.

Open the working demo and download the complete source.

Keep a PixiJS item reveal out of the layout calculation

Almast — Fri, 09 Oct 2026 08:52:04 +0000

AI disclosure: This tutorial and its sample code were prepared with AI assistance. It is a local implementation recipe, not a device-performance benchmark.

A rarity reveal should draw attention to an item without moving the item card. The common trap is to let the particle container participate in the bounds used to size or center the interface. The effect expands, the measured bounds change, and the card appears to jump.

The sample uses a fixed card, a preloaded crystal icon, and a separate effect layer. The item and its rarity label remain in the layout container. Particles are siblings of that container rather than children whose bounds determine its position.

Actual local fixture capture (1424 × 1343 image). This synthetic scene shows the integration and counters, not a device-performance benchmark.

Load before enabling the reveal

The accompanying source includes an original SVG item icon and the compiled rarity-reveal effect. The particle effect uses procedural circles, so its export has no file textures. That distinction matters: an empty effect asset list does not mean the UI image can be loaded after the first click.

Keep the replay button disabled until the export loader accepts the bundle and Assets.load resolves the item image. Failed fetches should leave a visible error and a disabled trigger. In a game using textured particles, preload every referenced particle texture into the provider as well.

For readers working with a pixi js particle editor, the NixieFX PixiJS integration guide supplies the export and renderer context. This example focuses on the host layout boundary rather than reproducing the guide's reward fountain.

Reserve the layout and add an independent layer

Here is the core arrangement from the supplied runnable source. app is an initialized PixiJS application and effect is the validated exported effect.

const content = new Container();
content.position.set(450, 210);
app.stage.addChild(content);

const card = new Graphics()
  .roundRect(-150, -110, 300, 220, 20)
  .fill(0x243146);
content.addChild(card);

const texture = await Assets.load("./item.svg");
const icon = new Sprite(texture);
icon.anchor.set(0.5);
icon.position.set(0, -25);
content.addChild(icon);

const effectLayer = new Container();
app.stage.addChild(effectLayer);
const vfx = new PixiVfxRenderer({
  parent: effectLayer,
  projection: createPixiVfx2dProjection({
    originX: 0, originY: 0, pixelsPerUnit: 1, yAxis: "down"
  })
});

function reveal() {
  const p = content.toGlobal({ x: 0, y: -25 });
  return vfx.createEffect(effect, {
    position: [p.x, p.y, 0], seed: 42
  });
}

The full source handles button state, bundle loading, diagnostics, and teardown. Import createPixiVfx2dProjection from nixie-fx/pixi alongside the renderer. The demo explicitly selects pixels and a downward Y axis to match Pixi UI coordinates. The adapter's default projection points Y upward, which would place a positive UI Y coordinate above the canvas. If the host transforms the effect layer, also convert the point into its local space before spawning.

Give repeated triggers one policy

The demo replaces an existing reveal before creating the next one. This avoids stacking bursts when a player taps repeatedly. A different game might deliberately overlap reveals, but then it needs an explicit capacity budget and cleanup policy.

Use the Pixi instance's documented lifecycle rather than assuming that it has the Three.js adapter's controls. The supplied host advances the renderer once per ticker callback, removes inactive instances, and removes the callback before destroying the renderer. Pause in this example gates the update call; it is a host control.

Check the card and the effect separately

The diagnostics compare the card's width and height and the content position against their baseline. In the local browser check, three trigger actions left the tracked maximum bounds delta at zero. An active reveal showed 18 particles and no missing texture, material, or sub-emitter references. After completion, the effect count returned to zero.

That is evidence about this fixed-size fixture. It does not establish correctness for a responsive inventory, transformed parents, or a scrolled panel. Test those cases with the host's actual coordinate conversion and layout rules.

The capture above shows an active frame with the item, rarity text, and diagnostics visible. The source's zero-delta counter proves only the properties it measures. A visual comparison still needs to check the label baseline, card alignment, and whether particles obscure the item.

Limits to keep visible

The export validation has no errors, warnings, or blockers for this recipe. There are no mesh emitters, custom materials, sub-effects, or particle file textures to resolve. Adding any of those features changes the integration obligations.

This Pixi UI example does not demonstrate GPU depth-buffer behavior, 3D lighting, or automatic responsive positioning. It also does not claim that every authored editor setting has equivalent behavior in every backend. Inspect support reports for the actual export and preserve any reported limitation.

Try the runnable item-reveal fixture and download its editable source. The source includes assets/src/pixi.js, the authoring effect, compiled bundle, and original item image.

Two prompts for one coding-agent task: implementation and supervision

Almast — Thu, 08 Oct 2026 06:37:42 +0000

AI assistance disclosure: This article was prepared with AI assistance. The example is illustrative.

A coding task often has one long prompt that mixes implementation instructions with managerial decisions. That makes the handoff brittle. The implementer needs a precise scope and tests; the reviewer needs a short record of what changed, what evidence exists, and when to stop the run. These are different documents for different readers.

Here is a small example: a team wants a feature flag around a new checkout summary. The flag must default off. A coding agent can prepare the change, but the release owner must decide whether it goes live. This is an illustrative task template, not a report of a completed rollout.

Prompt A: the execution brief

Task: Put the new checkout summary behind `checkout_summary_v2`.
Scope: Change only the summary component, its flag lookup, and focused tests.
Starting point: Work from a clean branch. First locate the current summary
and the project's flag abstraction; report both paths before editing.
Behavior: With the flag off, keep the current summary. With it on, show the
new summary. Keep totals, tax, and accessibility labels unchanged.
Verification: Run the focused component tests and the relevant type check.
Record exact commands, exit codes, and any test failures. If you cannot run
them, say why; do not infer success from code inspection.
Pause when: the existing flag abstraction is absent; totals calculation
would change; tests require unavailable credentials; or a dependency needs
an upgrade outside scope. Ask the task owner for a decision.
Deliver: diff, test evidence, remaining risks, and a rollback note.
Do not merge, enable the flag, or deploy.

The brief supplies the agent with observable boundaries. A pause point is an instruction to stop and ask, not an invitation to choose a convenient workaround. The runner uses its own authorized repository and tool access. The person preparing this brief does not provide their login or tokens to the runner.

Prompt B: the human supervision note

Owner: product engineer who prepared the task.
Review gate 1 — scope: Does the diff touch only the approved files? If not,
request a narrower patch or an explicit scope decision.
Review gate 2 — evidence: Are the test commands and outputs attached? Re-run
the critical checkout path in the review environment.
Review gate 3 — expertise: Have a payments-qualified reviewer examine any
change to price, tax, or transaction semantics. The task owner alone should
not approve those changes.
Acceptance: Reviewer records pass/fail against the flag-off baseline and
flag-on behavior. A delivered patch is not an accepted release.
Release: Only the release owner merges, schedules enablement, observes
metrics, and decides whether to roll back.

This note is intentionally shorter. It says who judges acceptance and names decisions that an agent's test output cannot settle. A product or engineering lead prepares the handoff; the agent or teammate executes with their own permissions; a qualified human reviews the evidence and signs off. The separation is the core of human supervised AI execution.

Worked handoff

Suppose the runner finds that checkout_summary_v2 already exists. It changes the component and adds two tests: flag off retains the old layout; flag on renders the new layout. It then discovers a screenshot baseline differs because a test fixture has an obsolete tax label. The correct next action is a pause with the failed command and diff attached. Updating tax labels quietly would cross the brief's boundary.

The reviewer can now distinguish three outcomes: implementation is ready for review, evidence is incomplete, or the task needs a new decision. None is the same as deployment. That is why this dual-prompt design for human and agent tasks is useful context for teams building a handoff process.

The example does not prove that two prompts prevent every mistake. It does make the stop condition visible before the work begins. For a small change, the two notes may fit in one task. For a risky change, add a named reviewer, a test environment, and a rollback owner before anyone claims it.

A claim state that stops two AI agents from doing the same backlog task

Almast — Wed, 07 Oct 2026 07:30:58 +0000

Two agents can both be “available” and still be a bad match for the same task. If each reads a backlog row and starts work without an atomic claim, they may both edit the same files, both spend model time, and produce two deliveries that a reviewer must reconcile. The fix is a state transition, not a longer prompt.

The minimal state diagram

OPEN --claim(runner, revision)--> CLAIMED
CLAIMED --release(runner)-------> OPEN
CLAIMED --deliver(evidence)-----> DELIVERED
DELIVERED --request changes-----> CLAIMED
DELIVERED --accept(reviewer)---> DONE

Only one runner owns CLAIMED at a time. DELIVERED means evidence is ready for review; it does not mean the change has merged or deployed. A second agent reading an old OPEN snapshot must lose its claim attempt when the record's revision has changed.

Here is an original task template for a small engineering team:

task: "Add an empty state to the billing history view"
scope:
  files: ["src/BillingHistory.tsx", "src/BillingHistory.test.tsx"]
  excluded: ["billing API", "payment settings"]
access: "runner has repository access through their own account"
acceptance:
  - "No invoices: show the approved empty-state copy"
  - "Invoices present: preserve current list and pagination"
  - "Keyboard focus remains in a sensible order"
evidence:
  - "diff or branch"
  - "commands and actual test output"
  - "real screenshots at 390px and 1280px"
reviewer: "named frontend maintainer"

The preparer supplies the scope, approved copy, and reviewer. The runner can execute only with their own authorized tools. The reviewer judges whether the delivered evidence meets the acceptance criteria. If the runner cannot access the repo, the task stays unclaimed; sharing another person's token is not a workaround.

The handoff in practice

Imagine agents A and B both poll at 09:00. Each sees revision 18. A submits claim(task, A, expectedRevision=18) and the server records revision 19. B submits the same transition with revision 18 and receives a stale-revision response. B rereads the task, sees A as the runner, and selects another item. This is a compare-and-swap pattern; it requires the task store to enforce the transition atomically. A spreadsheet status cell edited by hand does not provide the same guarantee.

A then changes the empty state and attaches a branch, a real test log, and screenshots. The task moves to DELIVERED. The reviewer notices that the empty state disappears when the network request fails, which was outside the original happy-path proof but within the UI's expected behavior. They request a fix. A revises the change and resubmits. Only the reviewer moves the task to DONE after checking it. That review may still be separate from merge and release.

This kind of shared AI execution capacity is useful only when the ownership boundary is explicit. The Wagglet workflow guide gives context for separating a request, a prepared task, delivery, and acceptance. The state diagram above is a portable design example; it is not a claim that every backlog tool implements exactly these transitions.

Failure cases to keep visible

Claim timeouts need a deliberate policy. Do not silently reclaim a task just because a runner was quiet for ten minutes; the runner may have work in progress. A human can inspect the attempt and release or reassign it. Retries need idempotency so a network timeout cannot create duplicate deliveries. A reviewer also needs authority to reject thin evidence instead of accepting a polished summary.

If you keep those rules in the task system, two agents can look at the same queue safely. They will still make mistakes in the work itself. The claim transition only removes one avoidable class of waste.

AI disclosure: This article was prepared with AI assistance. The example state machine is an illustrative design, not a report of a shipped implementation.

Move a Claude Code task to a teammate without sharing a login

Almast — Mon, 05 Oct 2026 10:47:20 +0000

A coding task often stalls because the person who wrote the brief cannot run it right now. Passing a provider login to someone else blurs who executed the work and what access they had. A better handoff transfers the task specification, then lets the next person work with their own authorized tools.

Here is a small template for doing that. It works as a Markdown issue even if your team never adopts a task platform.

The handoff file

# Task: Add an empty-state message to the projects list

## Outcome
When the API returns zero projects, show:
“No projects yet. Create one to get started.”

## Scope
- Change the projects-list component and its focused tests.
- Keep loading and API-error states distinct from the empty state.
- Do not change the API or create a project automatically.

## Starting point
- Repository: <repo URL>
- Base branch or commit: <exact ref>
- Relevant paths: <component>, <tests>
- Command to run: <project's documented test command>

## Access
- Author may write the brief and review the result.
- Executor uses their own repository and Claude Code access.
- Executor stops if either permission is missing.
- No provider credentials, session cookies, or personal tokens are included.

## Evidence to return
- Commit or pull-request URL
- Files changed
- Test command and actual output
- Screenshot only if captured from the running app
- Any untested behavior or remaining risk

## Acceptance
A reviewer checks the empty, loading, and error states,
then accepts or returns the task with specific changes.

The exact repository paths and command belong in the real task. Leaving them vague forces the executor to rediscover scope and makes review harder.

A worked handoff

Suppose Maya prepares this brief but has no time to implement it. Arun has authorized access to the repository and uses his own Claude Code account. Maya gives Arun the task, not her login. Arun checks out the stated base ref, inspects the three UI states, edits the component, and runs the repository's documented tests.

His delivery should identify the changed files and real commit, name the exact test command and result, and say whether he performed a visual check. Those details must come from the actual run. “Tests passed” is not acceptable unless the executor ran them and can identify the command that produced the result.

Maya then reviews the diff and evidence. If the empty message appears while the API is still loading, she returns the task with that finding. If it meets the acceptance criteria, she accepts it. Delivery and acceptance are different events.

What the separation buys you

This pattern gives a team shared AI execution capacity through transferable work while keeping each person's account and permissions separate. The author owns scope and acceptance criteria. The executor owns the work performed with their own authorized environment. The reviewer owns the verdict.

A task system can preserve those boundaries and make the handoff easier to inspect; Wagglet's discussion of AI task handoffs is one example. The same discipline still matters in a plain issue tracker.

It does not solve missing access, unclear requirements, or unreliable tests. When those are absent, improve the brief or stop the run. Borrowing another person's credentials is not a fix.

This article was drafted with AI assistance.

A reviewable task bounty for a game team's non-engineering work

Almast — Fri, 02 Oct 2026 12:32:38 +0000

Imagine a five-person game team preparing a playtest. A producer needs 30 issue reports sorted into reproducible bugs, design feedback, and duplicates. A developer can write a classifier, but the judgment about whether each report is useful belongs to the producer. This is bounded technical work for non engineers: the task touches a technical workflow, yet the acceptance test has to make sense to the person who owns the outcome.

A bounty can help if it pays for an accepted result. It becomes noisy if it pays for claims, submissions, or a score that only approximates usefulness. The design problem is an acceptance contract, not a leaderboard.

Write the contract before opening the task

Here is a compact format I would use for this hypothetical playtest job:

task: Triage 30 playtest reports
owner: playtest producer
worker: one assigned contributor using their own authorized tools
input: reports exported by the producer, with personal data removed
scope:
  include: reproducible bugs, design feedback, duplicates
  exclude: player identity research, account access, production changes
deliverables:
  - triage.csv with report_id, category, duplicate_of, rationale
  - review.md listing uncertain cases and decisions needed
acceptance:
  mechanical:
    - 30 input ids appear exactly once
    - category is one of bug, feedback, duplicate
    - duplicate_of points to an input id or is empty
  human:
    - producer samples 5 records and reviews every uncertain case
    - producer accepts or returns the work with specific corrections
reward_rule: release only after acceptance, never on submission count
review_budget_minutes: 20

The mechanical checks catch missing rows and broken references. They do not decide whether the triage is good. The producer still reads uncertain cases and a sample. For a safety-sensitive task, a five-record sample would be far too weak; the reviewer would need a different process or should decline the bounty entirely.

Make evidence cheap to inspect

The submission should point the reviewer to the work, rather than asking them to trust a summary. A small script can check shape before a person spends review time:

function checkTriage(inputIds, rows) {
  const ids = new Set(inputIds);
  const seen = new Set();
  const allowed = new Set(['bug', 'feedback', 'duplicate']);
  const errors = [];

  for (const row of rows) {
    if (!ids.has(row.report_id)) errors.push(`unknown id: ${row.report_id}`);
    if (seen.has(row.report_id)) errors.push(`duplicate row: ${row.report_id}`);
    seen.add(row.report_id);
    if (!allowed.has(row.category)) errors.push(`bad category: ${row.report_id}`);
    if (row.duplicate_of && !ids.has(row.duplicate_of)) {
      errors.push(`bad duplicate target: ${row.report_id}`);
    }
  }
  for (const id of ids) if (!seen.has(id)) errors.push(`missing id: ${id}`);
  return errors;
}

This is a shape check, not a quality score. A clean result means the producer can begin review; it does not mean the bounty is complete. In a real implementation, also reject a report that marks itself as its own duplicate and validate the CSV parser's handling of quoted fields.

Keep the reward behind review

A practical state sequence is open → claimed → submitted → reviewed → accepted or returned. Record who changed the state and link the evidence used at each step. A submission is a request for review, not an automatic pass. If a worker corrects returned work, keep both revisions visible so the reviewer can see what changed.

I would track three separate numbers for a pilot: accepted tasks, reviewer minutes, and corrections requested. Do not collapse them into one score. A high submission count paired with a growing review queue is a warning, even if every participant appears busy. Review time is part of the bounty's cost, and the producer needs room to stop a task whose acceptance criteria proved too vague.

The same pattern applies to a release-note draft, asset naming audit, or support FAQ cleanup. It is a poor fit for security decisions, player safety reports, or anything requiring private account access. In those cases, a named owner and a more controlled review path matter more than a bounty mechanic.

For a broader discussion of gamification, AI work bounties, and evidence-based rewards, see Wagglet's workflow article. I work with the Wagglet team. This guide is an illustrative implementation sketch; it does not report results from a live bounty program. AI generated the initial draft.

A reproducible Three.js particle burst with NixieFX

Almast — Thu, 01 Oct 2026 09:16:49 +0000

If you are evaluating a three-nebula alternative, start with a small integration test: author an effect, export it, load it in your Three.js scene, and trigger it from a user action. This tutorial does that with a short orange burst. It is not a performance or feature comparison with three-nebula.

The example was run with Node 22.13.1, NixieFX 0.1.17, Three.js 0.185.1, and Vite 8.3.1. The CLI reported 0 errors and 0 warnings for the Three.js target, the export completed, and the browser rendered the effect. The screenshot below is from that running browser demo.

1. Create the app and the effect project

Create a vanilla JavaScript Vite app and install the pinned packages:

npm create vite@latest nixie-burst-demo -- --template vanilla
cd nixie-burst-demo
npm install
npm install nixie-fx@0.1.17 three@0.185.1

Create a folder named vfx-project. Inside it, create vfx-editor.prj:

{
  "app": "vfx-editor",
  "kind": "project",
  "version": 1,
  "id": "nixie-burst-demo",
  "name": "Nixie Burst Demo",
  "settings": {
    "effectDataPath": "particle-data/effects",
    "assetRootPath": "assets",
    "outputPath": "out/vfx",
    "materialsFolder": "materials",
    "allowExternalOutput": false
  },
  "createdAt": "2026-10-01T00:00:00.000Z",
  "updatedAt": "2026-10-01T00:00:00.000Z"
}

Now scaffold a valid procedural effect. The CLI starter is a white stationary emitter; the next step turns it into the burst shown above.

npx nixie-fx effect create --project ./vfx-project --name "Impact Burst" --profile three-world-3d

Create configure-effect.mjs in the app root:

import { readFile, writeFile } from "node:fs/promises";

const path = "vfx-project/particle-data/effects/impact-burst.json";
const effect = JSON.parse(await readFile(path, "utf8"));
const emitter = effect.emitters[0];

function constant(scalar, value) {
  scalar.value = value;
  scalar.min = value;
  scalar.max = value;
  for (const point of [...scalar.curve, ...scalar.curveB]) point.y = value;
}

emitter.loop = false;
emitter.duration = 0.8;
emitter.maxParticles = 48;
constant(emitter.spawn.rateValue, 0);
emitter.spawn.rate = 0;
emitter.spawn.bursts = [{
  time: 0, count: 24, cycles: 1, interval: 0.1, probability: 1
}];
emitter.spawn.shape = "sphere";
emitter.spawn.radius = 0.1;
constant(emitter.spawn.radiusValue, 0.1);
emitter.modules.velocity = true;
emitter.initializeParticle.velocity.mode = "shapeDirection";
constant(emitter.initializeParticle.velocity.speed, 4);
constant(emitter.initializeParticle.lifetime, 0.7);
emitter.initializeParticle.color.color = [1, 0.55, 0.08, 1];
emitter.initializeParticle.color.colorB = [1, 0.55, 0.08, 1];
emitter.billboard.sizeStart = 0.05;
emitter.billboard.sizeEnd = 0.05;
constant(emitter.billboard.sizeValue, 0.05);

await writeFile(path, JSON.stringify(effect, null, 2) + "\n");

Validate, export, and copy the game bundle into Vite's public folder:

node configure-effect.mjs
npx nixie-fx validate ./vfx-project
npx nixie-fx export ./vfx-project
mkdir -p public/vfx
cp -R vfx-project/out/vfx/. public/vfx/

The validator also printed two informational PixiJS notes about depth behavior. This effect targets Three.js; those notes were not Three.js warnings. Do not publish an effect if validation or export reports an error or backend blocker.

2. Load it in Three.js

Use this minimal index.html:

<!doctype html>
<html lang="en">
  <meta charset="UTF-8">
  <title>Three.js effect burst</title>
  <style>
    body { background: #101827; color: white; font: 16px system-ui; }
    main { width: min(760px, 95vw); margin: 2rem auto; }
  </style>
  <main>
    <h1>Three.js effect burst</h1>
    <button id="replay">Replay burst</button>
    <p id="status">Loading...</p>
    <div id="stage"></div>
  </main>
  <script type="module" src="/src/main.js"></script>
</html>

Replace src/main.js with:

import * as THREE from "three";
import { loadVfxExportBundle } from "nixie-fx/export";
import { ThreeVfxRenderer } from "nixie-fx/three";

const stage = document.querySelector("#stage");
const status = document.querySelector("#status");
const replay = document.querySelector("#replay");
replay.disabled = true;

async function getJSON(url) {
  const response = await fetch(url);
  if (!response.ok) throw new Error("Could not load " + url);
  return response.json();
}

async function start() {
  const scene = new THREE.Scene();
  scene.background = new THREE.Color(0x101827);
  const camera = new THREE.PerspectiveCamera(55, 760 / 400, 0.1, 100);
  camera.position.set(0, 0, 5);
  camera.lookAt(0, 0, 0);

  const renderer = new THREE.WebGLRenderer({ antialias: true });
  renderer.setSize(760, 400);
  stage.appendChild(renderer.domElement);

  const root = "/vfx";
  const manifest = await getJSON(root + "/manifest.json");
  const effectsByPath = Object.fromEntries(
    await Promise.all(manifest.effects.map(async ({ path }) => [
      path, await getJSON(root + "/" + path)
    ]))
  );
  const bundle = loadVfxExportBundle(
    { manifest, effectsByPath }, { requiredBackend: "three3d" }
  );
  const effect = bundle.effectsById.get("impact-burst");
  if (!effect) throw new Error("impact-burst was not exported");

  const vfx = new ThreeVfxRenderer({ scene, camera });
  const burst = vfx.createEffect(effect, {
    position: [0, 0, 0], seed: 42
  });
  replay.disabled = false;
  replay.addEventListener("click", () => burst.restart());

  const clock = new THREE.Clock();
  renderer.setAnimationLoop(() => {
    vfx.update(clock.getDelta()); // seconds, exactly once per frame
    renderer.render(scene, camera);
  });
  status.textContent = "Ready. Select Replay burst.";
}

start().catch((error) => {
  status.textContent = error.message;
  console.error(error);
});

Run npm run dev, open Vite's local URL, and select Replay burst. You should see a short orange burst in the dark canvas. If the button stays disabled, read the status text and browser console, and confirm that public/vfx/manifest.json exists.

What this test does and does not establish

This checks the authoring-to-export-to-runtime path for one procedural, asset-free Three.js effect. The export loader checks backend support, and the renderer advances the effect once per frame using seconds. An asset-backed effect needs the appropriate texture or mesh provider. A production choice also needs visual review in your actual scene and frame-time measurements on the devices you support. The NixieFX Three.js runtime guide covers those additional integration points.

Disclosure: This article was generated with AI for NixieFX marketing. The code was run and the screenshot came from the working browser demo; readers should verify the result in their own environment.