DEV Community: PatilRB

A profiling brief that routes a frame-time regression to the right specialist

PatilRB — Mon, 19 Oct 2026 12:02:31 +0000

An AI game development workflow needs a way to route uncertainty. “The new effect is slow” is a symptom. It does not tell you whether the next owner should be a graphics engineer, gameplay programmer, technical artist, or build engineer.

This tutorial uses a fictional arena scene to show a bounded handoff. All performance numbers below are example values for the brief, not measurements from a real project. This article was drafted with AI assistance.

1. Freeze the comparison before naming a cause

Record a known-good build and a candidate build. Use the same device, browser, render resolution, camera route, scene population, and capture procedure. Keep the changed feature identifiable with a toggle if possible.

For this example, imagine a 60 Hz target with an observed baseline p95 frame interval of 15 ms and a candidate interval of 24 ms. Those fictional values would justify investigation. They would not prove that particles are responsible.

The 16.7 ms frame budget is a target derived from 60 frames per second. The brief must distinguish that target from a measured baseline, a measured regression, and a proposed acceptance threshold.

2. Prepare a task another person can execute

Title: Investigate arena frame-time increase when impact effects are enabled

Prepared by: QA owner for the arena scene
Execution owner: performance engineer, assigned after first trace review
Acceptance reviewers: graphics engineer + gameplay QA

Inputs:
  known-good and candidate commit IDs
  exact device / OS / browser / GPU
  drawing-buffer dimensions and device pixel ratio
  scripted 30-second camera route and scene population
  effect toggle and fixed random seed

Baseline and symptom:
  attach raw captures; report p50, p95, sample count
  separate first-use compilation from steady-state frames
  example only: baseline p95 15 ms; candidate p95 24 ms

Investigation:
  compare effects enabled / disabled
  inspect CPU trace, draw calls, and available GPU timing
  test render-scale sensitivity without changing particle count
  retain image captures for visual comparison

Proposed acceptance:
  steady-state p95 <= 16.7 ms on the named target device
  same route, resolution, and capture procedure
  no missing impacts or visual change without artist approval
  reviewer compares raw data and rendered output

Stop and ask:
  no GPU timing available; device overheats; baseline cannot reproduce

The target must be negotiated with the project owner. A task should not promise that a complex scene can meet 60 Hz on unspecified hardware.

3. Route on evidence, not the effect's name

If the main thread spends additional time updating objects or allocating arrays, route the next step toward the code that performs that work. If reducing render scale substantially changes the regression, investigate pixel cost and overdraw with a rendering specialist. If the hitch appears only on first use, investigate asset loading and shader compilation before rewriting steady-state simulation.

These are diagnostic clues. A resolution-sensitive frame can still have CPU work, and asynchronous GPU execution can make a CPU trace misleading. Keep the initial assignment an investigation with a named follow-up owner.

For the worked handoff, suppose the first trace suggests excessive per-frame allocation. The performance engineer sends the gameplay programmer the allocation stack and reproduction. The programmer can repair object reuse, while the graphics engineer checks that no renderer workaround has hidden the symptom. This is a hypothetical routing decision, not a claim that a particular fix was tested.

4. Keep execution and acceptance independent

QA prepares the comparison. The assigned engineer can use a coding agent with their own authorized development tools to inspect and change the relevant code. The engineer remains responsible for the patch. The graphics reviewer and gameplay QA judge whether the performance and visual requirements are met.

The Wagglet studio-stack article is context for coordinating that work across disciplines. The task itself should carry enough evidence to remain understandable without the article.

5. Deliver the comparison, including a failed hypothesis

Attach the patch, the capture configuration, raw before-and-after data, and the same camera view. Name any feature disabled during measurement. Report whether the first suspected cause survived testing.

A faster empty scene is not proof that the shipped scene improved. Desktop CPU throttling is not a substitute for a physical phone, and a short capture cannot establish behavior after prolonged thermal load. Limit the acceptance statement to the configuration that the reviewers actually checked.

Turn a QA repro into a repair an agent can actually execute

PatilRB — Mon, 19 Oct 2026 07:26:51 +0000

A video can show a bug without giving anyone enough information to fix it. A tester taps a reward button, closes a popup, and opens it again. The button appears enabled and submits a second claim request. The clip captures the symptom. It does not establish the starting state, the build, or the expected behavior.

For a game studio AI workflow, the useful handoff is a small repair contract: reproducible inputs, a bounded change, and evidence that a reviewer can judge. The agent should not have to invent the product decision before it can investigate the code.

The example below is an executed standalone browser fixture of a mobile-game UI defect. It is synthetic teaching code, not evidence from a shipped game. Its before/after recordings and observed regression results are linked below.

Start with a state transition

Suppose the reward panel has three states: available, claiming, and claimed. After a successful claim, reopening the panel should show the claimed state. If a request fails, the player should be able to retry.

That gives QA two distinct cases. A successful claim must stay claimed after reopening. A failed claim must become available again. “Fix the button” hides that difference and invites a patch that solves one case by breaking the other.

Record the successful case with the panel and input indicator visible:

Launch the identified build with a fresh test profile and an available reward.
Open the reward panel and tap Claim once.
Wait for the success response and the reward confirmation.
Close the panel, reopen it, and tap the button again.
Record the visible state and any additional claim request.

The recording should show the whole transition, without cuts between the initial state and the failure. Attach the clip to the task with its build identifier. Keep access tokens, personal data, and internal notifications out of the recording.

Make the environment reproducible

“Android” is not an environment description. Capture the device model, OS version, app build, source revision, backend environment, feature flags, account fixture, and network condition. Say whether the issue reproduces after a clean launch or only after earlier play.

For the fictional case, a useful report would name a test profile with one unclaimed reward and a stubbed success response. A second fixture would return a failure response. The companion fixture executes both responses locally; these are test doubles, not backend measurements.

If QA cannot reproduce the issue consistently, keep that uncertainty in the task. Ask the executor to investigate and report the conditions before promising a repair.

Write the contract before the implementation prompt

Here is a template a QA lead can adapt:

Title: Preserve reward claim state when reopening the panel

Evidence
- Repro clip: https://patilrb.github.io/assets/day10/W-481-faulty.webm
- Fixture source SHA-256: c4790242f821760224eb8e90827bbc525fac94f1895f855e7d73641ffd0353d6
- Environment: Chrome 155 on macOS; standalone local browser model; no backend
- Fixture: one available reward; success and failure responses

Reproduction
1. Open the panel with the reward available.
2. Claim it and wait for a successful response.
3. Close and reopen the panel.

Expected
- The reward remains claimed after reopening.
- The claimed control cannot submit another request.
- A failed request restores a usable retry state.

Allowed scope
- Reward-panel state restoration and its focused tests.
- A shared-state change only if investigation proves necessary;
  explain the dependency before expanding the repair.

Excluded scope
- Reward amounts, economy rules, network protocol changes,
  account migration, and unrelated UI cleanup.

Required delivery
- Root cause with relevant source references.
- Patch and focused regression test.
- Exact test command, environment, and observed output.
- Before/after clip using the same reproduction steps.
- Remaining uncertainty and any untested device cases.

Acceptance owner
- QA verifies the original reproduction and retry case.
- An engineer reviews correctness and shared-state impact.
- The product owner resolves disputed expected behavior.

The missing evidence fields are deliberate. Filling them with plausible values would make the task look complete while removing the ability to reproduce it.

Give the executor a narrow first move

The execution prompt can now be specific:

Reproduce the attached reward-panel issue in the supplied environment. Trace how claim state survives panel destruction and recreation. Identify the authoritative state before changing code. Make the smallest justified repair within the allowed scope. Add a regression test for reopening after success and for retrying after failure. Report what you observed and what remains untested.

Do not prescribe a boolean reset before the investigation. Clearing a loading flag may restore input while also allowing a second claim. The implementation depends on whether the panel owns transient view state, reads persistent claim state, or receives a stale response.

QA prepares the reproduction and expected behavior. A developer or an agent executes the investigation using tools and repository access that they are individually authorized to use. The reviewing engineer and QA judge the resulting change. Writing the task does not establish who has access to run it.

Ask for proof that can reject the patch

A useful regression test needs to fail for the defect it describes. Arrange the available reward, complete a successful claim, recreate the panel, and assert that the claimed state remains visible and cannot trigger another submission. In a separate case, simulate failure and verify that retry becomes available.

For example, pseudocode can make the intended boundary clear:

await panel.open({ reward: availableReward });
await panel.claim({ response: success });
await panel.close();
await panel.recreate();
expect(panel.claimState()).toBe("claimed");
expect(panel.canSubmitClaim()).toBe(false);

This is a test outline, not runnable code for a particular engine. Adapt it to the project's actual state model and harness. Record the real command and output rather than turning the outline into a claim that tests passed.

The reviewer should also inspect the before/after recording, failed-request retry, and any shared state touched by the patch. An automated assertion cannot prove that the final button label is readable on the original device.

Keep coordination separate from acceptance

For a wider discussion of how these responsibilities fit into a studio stack, the Wagglet article on an AI-native mobile game studio stack provides related context. The repair contract above is usable independently: preparation establishes the inputs, execution produces a candidate change, and acceptance requires human judgment against the evidence.

A bounded task cannot remove an intermittent backend fault or replace device testing. It can make those limits visible before someone mistakes a plausible patch for a verified repair.

Disclosure: This draft was prepared with AI assistance. Its fictional example and test outline need review by someone familiar with the project's implementation before publication or use.

Executed reproduction and regression evidence

The faulty reward view reopens as available even though its persistent claim is already complete. Replaying the same steps sends two requests. The repair changes only reopening: it derives the view from persistent claim state. The corrected run sends one request and keeps the claimed view. A failed request still permits a successful retry.

Watch the faulty reproduction and the repaired replay. Both clips continuously capture the actual fixture canvas, with scripted actions labeled inside the frame. They are not recordings of manual device testing. The interactive example and full source include the model, recording harness and exact checks.

The environment was Node v22.23.2 on macOS arm64 for the assertions, and Chrome 155 for the browser recordings. The model source SHA-256 is c4790242f821760224eb8e90827bbc525fac94f1895f855e7d73641ffd0353d6. Run node check.mjs from the extracted QA source folder. Across the three distinct examples, the faulty models fail the three intended regression assertions; all three neighboring cases pass. After repair, all six checks pass. The machine-readable results record each assertion.

The fixture has no real server, production account or commercial-game integration. Its measurements establish this bounded example. Human acceptance and any real-game repair still require the relevant owner and environment.

Turn particle polish into a visual acceptance contract

PatilRB — Thu, 15 Oct 2026 12:37:52 +0000

An artist can reject an effect that passes every code check. The timing can feel wrong, the focal point can disappear, or the effect can compete with the reward label. A technical test and a visual decision answer different questions.

This tutorial proposes a small acceptance contract for a fictional coin pickup effect. It is deliberately about the evidence an artist receives, rather than a particular renderer or particle tool.

Define the visual decision first

Use an approved reference from your own project. Record its revision, viewport, camera, background, and the instant at which the pickup event occurs. Compare the delivery with that reference under the same conditions.

For an example contract, the pickup starts at time zero. A ring becomes visible by 80 milliseconds, reaches its largest radius by 240 milliseconds, and is absent by 600 milliseconds. Those numbers are proposed art-direction requirements. They are not measurements of an existing effect.

The artist should approve the reference and timing before execution. Otherwise, the runner is being asked to invent the acceptance test as well as the implementation.

Write the technical brief separately

task: coin-pickup-polish
reference:
  source: approved project reference, revision recorded in task
  viewport_css_px: [390, 844]
  camera: fixed gameplay camera
  trigger_seconds: 0
scope:
  - adjust pickup ring timing and opacity only
  - preserve coin award logic and event count
capture_seconds: [0.08, 0.24, 0.60]
proposed_visual_checks:
  - ring visible at 0.08 seconds
  - ring reaches approved maximum radius by 0.24 seconds
  - ring absent by 0.60 seconds
  - reward label remains readable throughout
stop_if:
  - reference is unavailable or contradicts timing
  - implementation requires changing gameplay logic
review:
  engineering: lifecycle, event count, cleanup, regression risk
  art: timing, shape, focal hierarchy, reference match

The person preparing the task fills in the real reference and component locations. The authorized implementer uses their own environment and tools. An engineer reviews event handling and resource ownership. The artist judges the visual result. Expert supervised AI execution requires all four responsibilities even when two are held by the same person.

Make the capture process repeatable

The review scene should have a fixed trigger, a fixed camera, and a way to return to the same initial state. If the effect is randomized, record the seed. Avoid comparing a bright result on a dark background with a muted reference on a light background.

A review controller can expose the following adapter contract:

// Implement these methods using your project's existing test scene.
async function captureForArt(scene, captureFrame) {
  const samples = [0.08, 0.24, 0.60];
  const receipts = [];
  for (const seconds of samples) {
    await scene.reset({ seed: 461 });
    await scene.triggerPickup();
    await scene.advanceTo(seconds);
    receipts.push(await captureFrame({ seconds }));
  }
  return receipts;
}

This is an integration sketch, not a drop-in engine API. advanceTo must advance the real simulation using the project's time units. captureFrame must capture the rendered scene. Naming these methods does not mean screenshots or tests have been produced.

The reset before every sample avoids a common mistake: advancing from 80 milliseconds by another 240 milliseconds and labelling the result “240 ms.” A receipt should record the absolute sample time and the tested revision.

Give the artist a decision form

Revision:
Reference revision:
Camera / viewport / seed:
80 ms: visible? yes / no
240 ms: approved radius and shape? yes / no
600 ms: completely absent? yes / no
Reward label readable? yes / no
Art decision: accept / request changes
Correction, if any: state the failed criterion and frame
Engineering reviewer:

If the artist asks for a slower expansion, revise the requirement and capture again. If the ring stays on screen because a cleanup callback fails, keep that as an engineering correction. Both deserve a precise reason; neither should be hidden inside “needs polish.”

For the broader arrangement of art, implementation, and review tools, Wagglet's AI-native studio stack discussion provides related context. The contract here remains usable in a plain repository issue: the useful artifact is the agreed reference and decision record.

State what the contract cannot prove

Still frames cannot prove smooth motion. Add a short clip for temporal judgment, and retain stills for specific timing checks. Performance needs a separate device and rendering budget. A synthetic review scene can miss gameplay clutter, localization, and overlapping effects.

The artist's sign-off means the scoped visual request is acceptable under the recorded conditions. It does not replace engineering review, integration testing, or release approval.

Disclosure: This draft was prepared with AI assistance for a Wagglet-related content task. The contract and timing values are illustrative; no project screenshots or performance results are claimed.

Give a coding-agent delivery enough evidence to review

PatilRB — Thu, 15 Oct 2026 11:49:52 +0000

A delivery message saying “fixed and tested” leaves the reviewer with the hardest part: reconstructing what changed, which check ran, and whether the screenshot matches the patch. A small evidence packet makes AI task handoff for teams easier to inspect.

This tutorial was prepared with AI assistance for Wagglet-related marketing work. The example is a deliberately small local fixture. It does not describe a production incident or claim that a screenshot has already been captured.

Start with one reviewable behavior

Suppose a level-tool report lists objects in the order it receives them. Two exports of the same level produce different row order, so a designer cannot compare reports reliably. The requested behavior is stable ordering by object ID. The tool must report empty labels while leaving the input level untouched.

The designer prepares the expected report and sample level. An authorized technical teammate uses their own development tools and, if useful, a coding agent to implement the change. A qualified engineer judges the code; the designer confirms the report is useful. Those responsibilities belong in the brief before anyone begins.

Here is a standalone fixture. Save it as report-check.mjs and run node report-check.mjs with Node 22:

import assert from 'node:assert/strict';

function audit(level) {
  return [...level.objects]
    .sort((a, b) => a.id.localeCompare(b.id))
    .map(o => ({
      id: o.id,
      label: o.label.trim(),
      warning: o.label.trim() ? '' : 'empty label'
    }));
}

const level = { objects: [
  { id: 'b', label: ' Exit ' },
  { id: 'a', label: ' ' }
] };
const before = JSON.stringify(level);
assert.deepEqual(audit(level), [
  { id: 'a', label: '', warning: 'empty label' },
  { id: 'b', label: 'Exit', warning: '' }
]);
assert.equal(JSON.stringify(level), before);
console.log('PASS: stable report; input unchanged');

The copied array matters: sorting the original array would modify the input. Trimming belongs in the report, not in the source level. These are concrete boundaries a reviewer can inspect without reading an entire game project.

Attach evidence to claims

The corresponding local sample check was run under Node 22.23.2. It confirmed stable ordering, the empty-label warning, and unchanged input. That supports only this fixture. It does not establish file permission safety, large-level performance, or compatibility with a studio's editor.

For an actual patch, collect four items:

Test result: exact command, runtime version, exit code, and full output. Include the failing baseline if the change fixes a regression. A cropped green badge cannot show which tests ran.
Changed files: the revision and a short explanation for each file. For this example, the proposed scope is tools/audit.mjs, fixtures/level.json, and tests/audit.test.mjs. These are illustrative paths, not claims about an existing repository.
Screenshot: a real capture of the report opened in the delivered build. Its caption should identify the build and sample. Suggested capture: “Level audit showing object a with an empty-label warning above object b, Exit.” This is a capture specification; no image is being presented as evidence here.
Known limits: tests not run, environments not checked, and behavior intentionally excluded. Keep these beside the positive results.

Use a delivery template with a reviewer action

Task/revision: [ID and commit]
Requested behavior: stable report order; unchanged input
Changed files: [actual paths and purpose]
Reproduce: [clean setup and exact command]
Baseline: [failure command/output or not applicable]
After: [command, exit code, output]
Visual evidence: [real capture, build, fixture, effect age if relevant]
Known limits: [specific unchecked cases]
Reviewer: [person authorized to accept]
Requested decision: accept scope / request changes

A screenshot cannot prove that a script leaves files untouched. A unit assertion cannot prove that a report is readable at the designer's normal display scale. Match each piece of evidence to the claim it can support.

Keep delivery separate from acceptance

The executor submits the packet. The engineer checks that the implementation matches the stated scope and reproduces the result. The designer checks whether the ordering and warnings solve the original problem. Acceptance is recorded by the authorized reviewer; merge and deployment remain separate decisions.

Wagglet's request-to-review workflow provides context for making those handoffs explicit. The useful practice is portable: a task should arrive with the information needed for its next human decision.

Before accepting, check that the revision matches the screenshots, the commands run from a clean checkout, and every unchecked environment is still listed. If an artifact is missing, request that artifact specifically. “Please rerun the report with the included level and attach the output” gives the implementer a bounded next action.

Triage a CI boolean parsing failure with a human runner and coding agent

PatilRB — Thu, 15 Oct 2026 08:35:50 +0000

EDITORIAL HOLD — W-411 / NEEDS REVIEW. This private draft omits the assigned Wagglet promotion because DEV prohibits business promotion in AI-assisted articles and posts primarily intended to build backlinks. Resolve the platform/link requirement before publishing. The tutorial below is ready for technical review.

An environment variable contains the string "false", but the job still enters its dry-run branch. The problem can be one line: Boolean(process.env.DRY_RUN). Any nonempty string is truthy in JavaScript.

This small example shows how to hand that failure from a human runner to a coding agent without turning a configuration bug into a broad CI rewrite. It is a local Node fixture, not a report of a production incident or a hosted CI run.

1. Reproduce the failure before assigning the repair

Use Node 22 and an empty directory. Save this as broken.mjs:

export const readDryRun = value => Boolean(value);

Save this as config.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';

const { readDryRun } = await import(
  process.env.CANDIDATE || './broken.mjs'
);

test('unset defaults to false', () =>
  assert.equal(readDryRun(undefined), false));
test('true enables dry run', () =>
  assert.equal(readDryRun('true'), true));
test('false disables dry run', () =>
  assert.equal(readDryRun('false'), false));
test('invalid input fails closed', () =>
  assert.throws(() => readDryRun('maybe'),
    /DRY_RUN must be true or false/));

Run node --test config.test.mjs. In the prepared fixture, using Node 22.23.2, the result was exit code 1. This excerpt removes variable timing details:

ok 1 - unset defaults to false
ok 2 - true enables dry run
not ok 3 - false disables dry run
not ok 4 - invalid input fails closed
# tests 4
# pass 2
# fail 2

The third test receives true where it expects false. The fourth reports a missing expected exception. These are two consequences of the same parser: it interprets presence, not the permitted values.

The human runner owns this first step. They run commands through their own authorized terminal or CI interface, preserve the output, and confirm the intended configuration contract with the project owner. A test cannot decide whether an unset variable should default to false; that is a product or operations decision recorded here as an explicit assumption.

2. Give the agent a narrow repair brief

A useful coding agent task management record includes the failure, allowed change, and acceptance evidence together. Here is a copyable task template, filled in for this example:

Task: Parse DRY_RUN as an explicit boolean

Owner / executor: coding agent in its authorized workspace
Preparer: human runner
Acceptance reviewer: named human maintainer

Observed failure:
  node --test config.test.mjs exits 1.
  "false" becomes true; "maybe" does not throw.

Required contract:
  undefined -> false
  "true" -> true
  "false" -> false
  anything else -> TypeError("DRY_RUN must be true or false")

Scope:
  Replace the parser only. Preserve the four assertions.
  No workflow edits, dependency updates, deployment changes,
  secret access, network calls, or credential changes needed.

Deliver:
  Parser diff, exact test command, exit code, and test summary.
  State what was not exercised outside this local fixture.

Acceptance:
  Reviewer inspects the branch conditions and reruns all four tests.
  A passing parser test does not establish that a real CI job is fixed.

In a real repository, replace the fixture filenames with the actual module and test paths. Attach a sanitized failure log rather than a screenshot containing tokens or private job variables. Name the reviewer before execution begins so delivery does not become an unowned message saying “done.”

The coding agent uses its own authorized tools to implement and verify the change. The runner can supply missing evidence, but neither role needs another person's account or token to execute this fixture.

3. Repair the contract without widening the scope

Save this candidate as fixed.mjs:

export function readDryRun(value) {
  if (value === undefined || value === 'false') return false;
  if (value === 'true') return true;
  throw new TypeError('DRY_RUN must be true or false');
}

Then run:

CANDIDATE=./fixed.mjs node --test config.test.mjs

The prepared candidate returned exit code 0 with four passing tests and zero failures. The baseline remains available, so the reviewer can rerun both commands and see that the test distinguishes the broken and corrected implementations.

Do not quietly accept FALSE, an empty string, whitespace, or 1 while making this repair. Those values are outside the stated contract. If the real job requires them, agree on that behavior and add corresponding cases before changing the parser.

4. Let the human judge acceptance

The reviewer checks that the parser implements the agreed contract, no assertions were weakened, and the diff stays inside scope. They rerun the candidate command from the same directory and inspect the baseline if the failure is unclear.

For an actual failing CI job, one more check remains: confirm that the job imports this parser and rerun the relevant job through an authorized account. This fixture exercises configuration parsing only. It does not run a deployment, contact a service, or prove that an unrelated pipeline failure has disappeared.

Keep three artifacts together at handoff: the original failure, the small patch, and the verification output. That lets the human reviewer accept a specific change with visible limits.

AI assistance disclosure: This tutorial and its demonstration fixture were prepared with AI assistance. The baseline and candidate commands were executed locally. The publishing author should review and understand the explanation before publication.

Make an order-dependent test reproducible before handing it to a coding agent

PatilRB — Wed, 14 Oct 2026 07:48:01 +0000

This tutorial was drafted with AI assistance. Its small JavaScript fixture was executed locally; it is not a production incident report.

A test that passes alone and fails after another test is often called flaky. That label describes the symptom, but it is a poor implementation brief. Before assigning a repair, make the order dependence explicit.

This example uses a shared cache. It gives a coding agent a failure that can be reproduced without waiting for CI to get unlucky, plus an acceptance condition that does not weaken the test.

1. Reduce the failure to two tests

One test warms a greeting service. The other expects a fresh fixture. When both use the same cache, the second test inherits state it did not create.

Save this as order-fixture.mjs and run node order-fixture.mjs:

import assert from "node:assert/strict";

const sharedCache = new Map();

function makeService(cache) {
  return {
    greet(name) {
      if (!cache.has(name)) cache.set(name, `Hello, ${name}`);
      return cache.get(name);
    },
    get size() { return cache.size; }
  };
}

function warm(service) {
  assert.equal(service.greet("Ada"), "Hello, Ada");
}

function cold(service) {
  assert.equal(service.size, 0, "fixture must start empty");
}

const shared = makeService(sharedCache);
warm(shared);
try {
  cold(shared);
} catch (error) {
  console.log(
    `BEFORE warm -> cold: FAIL (actual=${error.actual}, ` +
    `expected=${error.expected})`
  );
}

for (const order of [[warm, cold], [cold, warm]]) {
  for (let run = 0; run < 10; run++) {
    for (const test of order) test(makeService(new Map()));
  }
  console.log(
    `AFTER ${order.map(test => test.name).join(" -> ")}: ` +
    "10/10 order runs passed"
  );
}

The fixture's equivalent local run observed a cache size of one where the cold test expected zero. With a fresh cache for each test, both orders passed ten consecutive runs. The first failure is caught so the demonstration can continue; a real test suite should let the assertion fail normally.

This is a controlled example of state leakage. It does not demonstrate that every intermittent test failure involves a cache.

2. Rewrite the assignment around the evidence

The weak ticket is:

Fix the flaky greeting test. It usually passes when rerun.

That leaves the agent free to add retries, reorder the suite, clear production state, or change the expectation. None necessarily addresses the underlying fixture problem.

Use a brief like this instead:

Problem
The cold-fixture test fails after the warm-cache test.
The cache is shared between tests; expected size is 0,
but the failing order observes size 1.

Reproduction
Run the named tests in warm -> cold order.
Also run each test alone and in cold -> warm order.
Record exact commands and output.

Scope
Give each test an independently owned fixture.
Change test setup and test-only helpers.
Preserve production cache behavior and both assertions.

Acceptance
Both orders pass with fresh fixtures.
The cold test still requires an empty cache.
The warm test still verifies the returned greeting.
The relevant suite passes without retries or skipped tests.

Stop condition
If production singleton state prevents test isolation,
report the dependency and proposed design change first.

Delivery
Patch, reproduction before the fix, verification after it,
and any behavior the checks do not cover.

In a repository task, include the actual test names, paths, runner options, and failing output. Do not present this fixture's evidence as if it came from the repository.

3. Give the human runner a separate operating checklist

The task author prepares the failure evidence and scope. The teammate executing the task uses their own authorized workspace, tools, and coding agent. The reviewer decides whether the result satisfies the brief.

The runner's checklist can stay short:

Confirm the selected repository and test environment.
Have the agent reproduce the named order-dependent failure.
Inspect fixture ownership in the patch.
Check that production behavior and assertions remain intact.
Return the exact test output and unresolved questions.

For an AI-assisted repair, separate the detailed implementation brief from the human operating checklist. The author supplies the failure evidence and boundaries, the runner inspects the proposed patch, and the reviewer decides whether the result satisfies the original test. A named reviewer and exact verification output make those responsibilities visible.

4. Review the mechanism, not just the green result

Fresh fixtures solve this example because neither test needs the other's state. Clearing one global cache between tests can still be unsafe if another test is using it concurrently. A production singleton may need a deliberate test seam rather than an improvised reset.

Two passing orders also do not prove that a larger suite has no hidden dependencies. They provide evidence about the failure you isolated. Run the relevant surrounding suite, and inspect whether timers, connections, or other resources survive teardown.

Keep the conclusion narrow: the named fixture no longer inherits another test's cache, the original assertions still hold, and the required checks passed. That is a repair another engineer can review.

A PixiJS healing glow with a readable health bar and explicit cleanup

PatilRB — Tue, 13 Oct 2026 13:29:57 +0000

A heal button has two jobs: change the player's health, then acknowledge the change. The second job should never make the first harder to read. This NixieFX tutorial builds a small PixiJS health-bar cue with particles behind the bar, an immediate numeric update, and explicit teardown.

Disclosure: an AI agent prepared this original tutorial and demo for a NixieFX linkbuilding assignment. The screenshots and results below come from the running fixture. They are not performance benchmarks or claims from a production game.

What this fixture does

The starting health is 35/100. Heal +25 updates it immediately and plays one green burst. Health clamps at 100. Damage −25 and Reset to 35 stop the current cue. A test-only button holds the burst at 0.20 seconds, using seed 61, so a screenshot can show a reproducible state.

The particle container is added before the bar graphic. Pixi's draw order therefore keeps the bar in front. The numeric label is HTML outside the canvas, with a progressbar role and current value; neither color nor animation carries the health value alone.

Real held frame: health 60/100, 32 active and 32 visible particles, t=0.20 s. The green dots rise from a narrow box surrounding the bar.

Export a small, bounded effect

The fixture pins nixie-fx 0.1.20 and PixiJS 8.19.0. Its effect targets pixi-ui-2d, uses one burst of 32 procedural billboards, and has a 0.65-second particle lifetime. It uses additive blending and unlit rendering, with depth settings disabled. No texture provider or external image asset is needed for this effect.

The spawn field is box, with dimensions [4, 0.18, 0] in effect units. At 100 pixels per unit, that spans 400 pixels around the bar's center. With the projection's Y axis pointing down, negative Y velocity sends particles upward. Resetting the existing effect instance restarts the cue; a click does not create a new renderer or instance.

For the broader authoring and integration context, the NixieFX PixiJS particle-effects documentation is the assigned reference. The source below includes the exact procedural authoring fixture used here.

Run it from the complete source

Create a directory containing the three files below: make-effect.mjs, index.html, and main.js. Then run:

npm init -y
npm pkg set type=module
npm install --save-exact nixie-fx@0.1.20 pixi.js@8.19.0 vite@7.1.9
node make-effect.mjs
npx vite --host 127.0.0.1

Open the local URL printed by Vite. The builder validates the authoring project, exports it, and copies the exported bundle into public/vfx. Vite serves those files as /vfx. Serving unbundled main.js with a plain static server will not resolve its npm imports; use Vite for this source version.

Trigger and cleanup

The health update happens before start(). The animation branch checks both the demo's Reduce motion checkbox and the operating-system preference. Reduced motion still updates the health value, without starting particles. Changing that preference while the cue is active stops the cue.

The runtime uses a manually driven animation loop, with Pixi's ticker stopped. The loop advances the effect, renders the stage, and stops updating after the cue window. This is a UI example, so elapsed frame steps are capped at 0.05 seconds. It is not a simulation clock for gameplay logic.

Dispose demo cancels the animation frame, removes motion listeners, destroys the NixieFX renderer and Pixi application, removes the canvas, and disables controls. A pagehide listener uses the same guarded disposal path. Reload the page to create a fresh instance.

What was actually checked

The export validator reported 0 errors and 0 warnings. The loaded effect's PixiJS backend support report was supported. In Chromium, the following UI actions were checked:

Action	Observed result
Hold the first heal at 0.20 s	Health 35 → 60; active 32, visible 32
Hold a second heal	Health 60 → 85; still active 32, visible 32
Advance the held effect by 1 s	Active 0, visible 0
Enable Reduce motion, then heal	Health 85 → 100; active 0, visible 0
Dispose	Canvas removed; buttons and motion checkbox disabled

Limits worth keeping visible

This fixture exercises a fixed 560×300 WebGL canvas and one assetless PixiJS effect. It does not establish mobile performance, screen-reader compatibility across browsers, or a frame-rate budget. The canvas can scroll horizontally on a narrow viewport; a real responsive HUD should fit its own layout and recalculate the effect origin when that layout changes.

Mesh rendering, lit materials, GPU depth behavior, textured effects, and Three.js are outside this example's tested scope. Do not assume a different export is supported because this one is: inspect its target report and add required asset providers. The held-frame and advance buttons are debugging controls, not player-facing features.

The useful pattern is small: update state immediately, make the cue decorative, reuse one bounded effect instance, and destroy the resources when the UI leaves.

Complete authoring and runtime source

The code blocks contain the full files, including the HTML controls. No omitted helper or private repository is required.

make-effect.mjs

import { mkdir, writeFile, cp } from 'node:fs/promises';
import { execFileSync } from 'node:child_process';
import { createDefaultParticleEffect, createConstantParticleScalar as scalar, normalizeParticleEffect } from 'nixie-fx';
import { normalizeEditorProjectFile } from 'nixie-fx/project';
const stamp='2026-10-13T00:00:00.000Z';
await mkdir('authoring',{recursive:true});
const project=normalizeEditorProjectFile({app:'vfx-editor',kind:'project',version:1,id:'n308-health-glow',name:'Healing glow',createdAt:stamp,updatedAt:stamp,settings:{effectDataPath:'.',outputPath:'out/vfx',assetRootPath:'.',allowExternalOutput:false}});
await writeFile('authoring/vfx-editor.prj',JSON.stringify(project,null,2));
const effect=createDefaultParticleEffect('healing-glow','Healing glow');
effect.targetProfile='pixi-ui-2d';effect.timeline.duration=0.8;effect.timeline.loop.enabled=false;
const e=effect.emitters[0];
e.maxParticles=32;e.duration=0.05;e.loop=false;
e.spawn.shape='box';e.spawn.box=[4,0.18,0];e.spawn.rate=0;e.spawn.rateValue=scalar(0);
e.spawn.bursts=[{time:0,count:32,cycles:1,interval:0,probability:1}];
e.initializeParticle.lifetime=scalar(0.65);
e.initializeParticle.size=scalar(0.09);e.billboard.sizeValue=scalar(0.09);e.billboard.softness=0.5;
e.modules.velocity=true;e.initializeParticle.velocity.mode='vector';
e.initializeParticle.velocity.min=[-0.12,-0.8,0];e.initializeParticle.velocity.max=[0.12,-0.35,0];
e.initializeParticle.color.color=[0.25,1,0.45,1];e.initializeParticle.color.intensity=scalar(1);
e.initializeParticle.color.intensity.editorMin=0;e.initializeParticle.color.intensity.editorMax=16;
e.modules.color=true;e.color.gradient.alphaStops=[{position:0,alpha:1},{position:0.6,alpha:0.75},{position:1,alpha:0}];
e.render.blend='additive';e.render.shading='unlit';e.render.depthTest=false;e.render.depthWrite=false;e.render.depthInk=false;
await writeFile('authoring/healing-glow.json',JSON.stringify(normalizeParticleEffect(effect),null,2));
const cli=new URL('./node_modules/nixie-fx/dist/cli.js',import.meta.url).pathname;
execFileSync(process.execPath,[cli,'validate','./authoring'],{stdio:'inherit'});
execFileSync(process.execPath,[cli,'export','./authoring'],{stdio:'inherit'});
await mkdir('public/vfx',{recursive:true});await cp('authoring/out/vfx','public/vfx',{recursive:true});

index.html

<!doctype html><html lang="en"><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Healing glow — PixiJS / NixieFX</title><style>body{margin:32px auto;max-width:760px;padding:0 20px;background:#091515;color:#e9fff1;font:16px/1.5 system-ui}h1{font-size:30px;margin-bottom:6px}p{color:#b4c9bf}#stage{width:560px;max-width:100%;overflow:auto;border:1px solid #375b48;border-radius:12px}#health{font-size:24px;font-weight:700;margin:18px 0 8px}button{background:#215c3f;color:white;border:1px solid #65b28b;padding:10px 14px;border-radius:6px;margin:6px 5px 6px 0;cursor:pointer}button:disabled{opacity:.5}pre{white-space:pre-wrap;background:#183027;padding:12px;border-radius:6px}label{display:block;margin:12px 0}</style><h1>A healing cue that leaves the health value readable</h1><p>PixiJS 8.19.0 · nixie-fx 0.1.20 · one 32-particle burst · procedural, assetless fixture</p><div id="health" role="progressbar" aria-label="Health" aria-valuemin="0" aria-valuemax="100" aria-valuenow="35">Health 35 / 100</div><div id="stage"></div><div><button id="heal" disabled>Heal +25</button><button id="hold" disabled>Heal +25 · hold at 0.20 s</button><button id="damage" disabled>Damage −25</button><button id="reset" disabled>Reset to 35</button><button id="finish" disabled>Advance 1 second</button><button id="dispose" disabled>Dispose demo</button></div><label><input id="reduce" type="checkbox"> Reduce motion (also respects OS preference)</label><pre id="report">Loading runtime and export…</pre><p>The health value changes immediately. Particles are decorative and sit behind the bar. Holding a frame is a test control; disposal removes the canvas and disables controls. Reload to restart.</p><script type="module" src="./main.js"></script></html>

main.js

import {Application, Container, Graphics} from 'pixi.js';
import {PixiVfxRenderer, createPixiVfx2dProjection} from 'nixie-fx/pixi';
import {loadVfxExportBundle} from 'nixie-fx/export';
const report=document.querySelector('#report'),stage=document.querySelector('#stage');
try {
 const app=new Application(); await app.init({width:560,height:300,resolution:1,background:'#102020',preference:'webgl',antialias:true});app.ticker.stop();stage.append(app.canvas);
 app.canvas.setAttribute('role','img');app.canvas.setAttribute('aria-label','Green healing particles behind a health bar');
 async function json(path){const r=await fetch(path);if(!r.ok)throw Error(`Load failed: ${path}`);return r.json();}
 const manifest=await json('./vfx/manifest.json');
 const effectsByPath=Object.fromEntries(await Promise.all(manifest.effects.map(async e=>[e.path,await json('./vfx/'+e.path)])));
 const bundle=loadVfxExportBundle({manifest,effectsByPath},{requiredBackend:'pixi2d',requiredEffectIds:['healing-glow']});
 const effect=bundle.effectsById.get('healing-glow');if(effect.assets.length)throw Error('This fixture requires an assetless effect.');
 const layer=new Container();app.stage.addChild(layer);
 const runtime=new PixiVfxRenderer({parent:layer,projection:createPixiVfx2dProjection({pixelsPerUnit:100,yAxis:'down'})});
 const pulse=runtime.createEffect(effect,{autoStart:false});
 const bar=new Graphics();app.stage.addChild(bar);
 const reduce=document.querySelector('#reduce'),pref=matchMedia('(prefers-reduced-motion: reduce)'),value=document.querySelector('#health');
 let health=35,running=false,t=0,last=0,raf=0,disposed=false;
 function draw(){bar.clear().roundRect(60,140,440,30,8).fill(0x304343);if(health>0)bar.roundRect(63,143,434*health/100,24,6).fill(0x57dc8b);app.renderer.render(app.stage);value.textContent=`Health ${health} / 100`;value.setAttribute('aria-valuenow',health);report.textContent=`PixiJS export: ${effect.support.backends.pixi2d.status} · active ${pulse.stats.activeParticles} · visible ${pulse.stats.visibleParticles} · t=${t.toFixed(2)} s · seed 61`;} 
 function stop(){running=false;pulse.stop();t=0;}
 function start(hold=false){stop();if(reduce.checked||pref.matches){draw();return;}pulse.reset({position:[2.8,1.55,0],seed:61});if(hold){for(let i=0;i<24;i++)runtime.update(1/120);t=.2;}else{running=true;last=performance.now();}draw();}
 document.querySelector('#heal').onclick=()=>{health=Math.min(100,health+25);start();};
 document.querySelector('#hold').onclick=()=>{health=Math.min(100,health+25);start(true);};
 document.querySelector('#damage').onclick=()=>{health=Math.max(0,health-25);stop();draw();};
 document.querySelector('#reset').onclick=()=>{health=35;stop();draw();};
 document.querySelector('#finish').onclick=()=>{running=false;for(let i=0;i<120;i++)runtime.update(1/120);t+=1;draw();};
 function motion(){stop();draw();}reduce.addEventListener('change',motion);pref.addEventListener('change',motion);
 function dispose(){if(disposed)return;disposed=true;running=false;cancelAnimationFrame(raf);reduce.removeEventListener('change',motion);pref.removeEventListener('change',motion);window.removeEventListener('pagehide',dispose);runtime.destroy();app.destroy(true,{children:true});for(const b of document.querySelectorAll('button'))b.disabled=true;reduce.disabled=true;report.textContent='Disposed: RAF cancelled, runtime and Pixi application destroyed.';}
 document.querySelector('#dispose').onclick=dispose;window.addEventListener('pagehide',dispose);
 function frame(now){if(disposed)return;if(running){const dt=Math.min((now-last)/1000,.05);runtime.update(dt);t+=dt;if(t>.8)running=false;draw();}last=now;raf=requestAnimationFrame(frame);}raf=requestAnimationFrame(frame);
 for(const b of document.querySelectorAll('button'))b.disabled=false;draw();
}catch(e){report.textContent=e.message;console.error(e);}

Export a shield-ready cue from a NixieFX editor project to Three.js

PatilRB — Tue, 13 Oct 2026 10:42:32 +0000

Disclosure: I prepared this tutorial with AI assistance for a NixieFX marketing assignment. The screenshots are genuine desktop browser captures of the runtime example. The project is constructed with the package API; I am not presenting an editor-interface walkthrough.

A small shield-ready cue is a useful way to examine the boundary between an authoring project and a game scene. With the NixieFX VFX editor, the question I want to answer is concrete: can I validate an editor-compatible project, export it, load the export in Three.js, and hold repeatable frames for review?

The example below creates 48 cyan particles on a circle. They rise and fade during one short burst. A thin ground ring and grid belong to the Three.js host scene. They make movement easier to judge; they are not exported particles. There is no bloom, collision, lighting, or mesh-particle integration in this example.

The project-to-runtime contract

The flow is editor-compatible project → validation → export manifest and effect JSON → Three.js renderer. I use the package API to create the project file and the particle definition, then let the CLI validate and export them. This keeps the example reproducible without asking readers to match a sequence of editor clicks.

For the format and runtime integration, see the NixieFX VFX editor runtime documentation.

The export loader requires the three3d backend and the shield-ready effect ID. Those checks prevent an accidental change in the exported contract from silently loading the wrong effect. I also check the renderer's support report before creating the runtime instance. A successful load alone does not establish that every authored feature is supported by the chosen renderer.

1. Install the pinned packages

Use Node.js 20.19+ or 22.12+ and a browser with WebGL. Create an empty folder and add these files. The package versions match this test; pinning them makes subsequent changes easier to isolate.

npm init -y
npm pkg set type=module
npm install --save-exact nixie-fx@0.1.20 three@0.185.1
npm install --save-dev --save-exact vite@7.1.9

2. Create, validate, and export the cue

Save this as create-cue.mjs. It writes an editor-compatible project under authoring/, creates the effect, runs validation and export, and copies the exported bundle into Vite's public directory. Run the command from the folder containing the script.

The continuous emission rate is zero. One burst emits 48 particles at time zero, with a 0.9-second particle lifetime. Looping is disabled. The circle has no radial thickness, and each particle receives a small horizontal drift plus an upward velocity. These choices make the early and late frames visibly different without adding another emitter.

import { mkdir, writeFile, cp } from 'node:fs/promises';
import { execFileSync } from 'node:child_process';
import { createDefaultParticleEffect, createConstantParticleScalar as value, normalizeParticleEffect } from 'nixie-fx';
import { normalizeEditorProjectFile } from 'nixie-fx/project';
const date='2026-10-13T00:00:00.000Z';
await mkdir('authoring',{recursive:true});
const project=normalizeEditorProjectFile({app:'vfx-editor',kind:'project',version:1,id:'n028-shield-ready',name:'Shield ready cue',createdAt:date,updatedAt:date,settings:{effectDataPath:'.',outputPath:'out/vfx',assetRootPath:'.',allowExternalOutput:false}});
await writeFile('authoring/vfx-editor.prj',JSON.stringify(project,null,2));
const cue=createDefaultParticleEffect('shield-ready','Shield ready');
cue.targetProfile='three-world-3d';cue.timeline.duration=1.15;cue.timeline.loop.enabled=false;
const ring=cue.emitters[0];ring.name='Rising ring sparks';ring.maxParticles=48;ring.duration=0.05;ring.loop=false;
ring.spawn.shape='circle';ring.spawn.radius=0.75;ring.spawn.radiusValue=value(0.75);ring.spawn.radiusThickness=0;
ring.spawn.rate=0;ring.spawn.rateValue=value(0);ring.spawn.bursts=[{time:0,count:48,cycles:1,interval:0,probability:1}];
ring.modules.velocity=true;ring.initializeParticle.velocity.mode='vector';ring.initializeParticle.velocity.min=[-0.18,0.7,-0.18];ring.initializeParticle.velocity.max=[0.18,1.6,0.18];
ring.initializeParticle.lifetime=value(0.9);ring.initializeParticle.size=value(0.075);ring.billboard.sizeValue=value(0.075);ring.billboard.softness=0.65;
ring.initializeParticle.color.color=[0.15,0.8,1,1];ring.initializeParticle.color.intensity=value(1);ring.initializeParticle.color.intensity.editorMin=0;ring.initializeParticle.color.intensity.editorMax=16;
ring.modules.color=true;ring.color.gradient.alphaStops=[{position:0,alpha:1},{position:0.5,alpha:0.7},{position:1,alpha:0}];
ring.render.blend='additive';ring.render.shading='unlit';ring.render.depthTest=false;ring.render.depthWrite=false;ring.render.depthInk=false;
await writeFile('authoring/shield-ready.json',JSON.stringify(normalizeParticleEffect(cue),null,2));
const cli=new URL('./node_modules/nixie-fx/dist/cli.js',import.meta.url).pathname;
execFileSync(process.execPath,[cli,'validate','./authoring'],{stdio:'inherit'});
execFileSync(process.execPath,[cli,'export','./authoring'],{stdio:'inherit'});
await mkdir('public/vfx',{recursive:true});await cp('authoring/out/vfx','public/vfx',{recursive:true});

node create-cue.mjs

In the tested project, validation returned 0 errors and 0 warnings, and export produced one effect. Keep that output visible when adapting the example: it is a check on this exact configuration, not a blanket guarantee for a different effect.

3. Consume the export in Three.js

Save this as main.js. The code reads the manifest and effect JSON rather than directly importing the authoring file. This tests the exported boundary that a runtime integration actually consumes.

The effect has no external file assets. The explicit asset check is intentional: adding a texture later also creates asset-loading work. Removing the guard without implementing that work would hide an incomplete integration.

import * as THREE from 'three';
import { loadVfxExportBundle } from 'nixie-fx/export';
import { ThreeVfxRenderer } from 'nixie-fx/three';
async function json(path){const r=await fetch(path);if(!r.ok)throw Error(`Could not load ${path}`);return r.json();}
async function start(){
  const manifest=await json('./vfx/manifest.json');
  const effectsByPath=Object.fromEntries(await Promise.all(manifest.effects.map(async item=>[item.path,await json(`./vfx/${item.path}`)])));
  const bundle=loadVfxExportBundle({manifest,effectsByPath},{requiredBackend:'three3d',requiredEffectIds:['shield-ready']});
  const effect=bundle.effectsById.get('shield-ready');if(effect.assets.length)throw Error('This cue expects procedural particles without file assets.');
  const scene=new THREE.Scene();scene.background=new THREE.Color('#081522');
  const camera=new THREE.PerspectiveCamera(45,640/390,0.1,30);camera.position.set(3,2.7,4);camera.lookAt(0,0.5,0);
  const view=new THREE.WebGLRenderer({antialias:true});view.setPixelRatio(1);view.setSize(640,390);document.querySelector('#stage').append(view.domElement);
  view.domElement.setAttribute('role','img');view.domElement.setAttribute('aria-label','A cyan shield-ready particle ring rising above a marked ground circle');
  const grid=new THREE.GridHelper(5,20,0x29445e,0x142c42);scene.add(grid);
  const mark=new THREE.Mesh(new THREE.TorusGeometry(0.75,0.014,8,64),new THREE.MeshBasicMaterial({color:0x69a9c1}));mark.rotation.x=Math.PI/2;mark.position.y=0.01;scene.add(mark);
  const vfx=new ThreeVfxRenderer({scene,camera});const support=vfx.getSupport(effect);if(support.status!=='supported')throw Error('Review the runtime support report.');
  const cue=vfx.createEffect(effect,{autoStart:false,position:[0,0,0],seed:31});
  const status=document.querySelector('#status');const metrics=document.querySelector('#metrics');const reduce=document.querySelector('#reduce');const preference=matchMedia('(prefers-reduced-motion: reduce)');
  let running=false,time=0.2,last=performance.now();
  function draw(){view.render(scene,camera);metrics.textContent=`t=${time.toFixed(2)} s · seed 31 · active ${cue.stats.activeParticles} · visible ${cue.stats.visibleParticles} · support ${support.status}`;}
  function hold(seconds){running=false;time=seconds;cue.seek(seconds);cue.pause();status.textContent='Held review frame.';draw();}
  document.querySelector('#early').onclick=()=>hold(0.2);document.querySelector('#late').onclick=()=>hold(0.65);
  document.querySelector('#replay').onclick=()=>{if(reduce.checked||preference.matches){hold(0.2);status.textContent='Reduced motion: static review frame.';return;}cue.restart();cue.play();time=0;last=performance.now();running=true;status.textContent='Playing the cue once.';};
  function motionChanged(){if(reduce.checked||preference.matches)hold(0.2);}
  reduce.onchange=motionChanged;preference.addEventListener('change',motionChanged);
  view.setAnimationLoop(now=>{const dt=Math.min((now-last)/1000,0.05);last=now;if(running){time+=dt;vfx.update(dt);if(time>=1.15){running=false;cue.pause();status.textContent='Cue finished.';}draw();}});
  for(const id of ['early','late','replay'])document.querySelector('#'+id).disabled=false;hold(0.2);
  window.addEventListener('pagehide',()=>{view.setAnimationLoop(null);preference.removeEventListener('change',motionChanged);vfx.destroy();grid.geometry.dispose();for(const m of (Array.isArray(grid.material)?grid.material:[grid.material]))m.dispose();mark.geometry.dispose();mark.material.dispose();view.dispose();},{once:true});
}
start().catch(error=>{document.querySelector('#status').textContent=error.message;console.error(error);});

The seed is fixed at 31. seek() followed by pause() gives a held review frame, while restart() and play() replay the cue. During playback the host updates the VFX renderer and then draws the Three.js scene. A seed and a time are useful comparison inputs; they are not a claim that every renderer or future package version will produce identical pixels.

4. Add the page and run it

Save this as index.html. The initial frame is static, the controls are disabled until loading succeeds, and replay respects both the checkbox and the system reduced-motion preference. Keyboard users can reach the native buttons and checkbox.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>NixieFX editor export · shield-ready cue</title>
<style>*{box-sizing:border-box}body{margin:0;background:#06101c;color:#e3f0ff;font:16px/1.6 system-ui}main{max-width:850px;margin:26px auto;padding:24px}h1{font-size:34px;line-height:1.15}p{color:#aac3da}#stage{border:1px solid #305475;border-radius:15px;overflow:hidden}canvas{width:100%;height:auto;display:block}.controls{display:flex;flex-wrap:wrap;gap:12px;align-items:center;margin-top:18px}button{border:1px solid #67e8f9;border-radius:8px;background:#67e8f9;color:#073844;font:inherit;padding:10px 17px;font-weight:650;cursor:pointer}button:focus-visible,input:focus-visible{outline:3px solid #fbbf24;outline-offset:4px}label{display:flex;align-items:center;gap:7px}input{width:19px;height:19px}#metrics{background:#102438;padding:12px;border-radius:8px;color:#99e4f3}small{color:#80a2c2}</style>
</head>
<body>
<main>
<small>N-028 · AUTHORING → EXPORT → RUNTIME</small>
<h1>Review a shield-ready cue from an editor project</h1>
<p>NixieFX VFX editor-compatible project, validated export bundle, and a Three.js consumer. The project was constructed with the package API; this is a runtime capture, not a screenshot of the editor UI.</p>
<div id="stage">
</div>
<div class="controls">
<button id="early" disabled>Hold 0.20 s</button>
<button id="late" disabled>Hold 0.65 s</button>
<button id="replay" disabled>Replay once</button>
<label>
<input id="reduce" type="checkbox">Reduce motion</label>
</div>
<p id="status" role="status" aria-live="polite">Loading…</p>
<p id="metrics">Runtime checks pending.</p>
<p>The cyan particles rise from one circular emitter. The thin ground ring and grid are host-scene geometry for orientation. There is no lighting, bloom pass, collision, or prepared mesh-particle integration in this example.</p>
<small>48 particles · 0.9 s particle lifetime · seed 31. Genuine browser verification; mobile performance not measured. AI assistance used for a NixieFX marketing assignment.</small>
</main>
<script type="module" src="./main.js">
</script>
</body>
</html>

npx vite --host 127.0.0.1

Open the local URL printed by Vite. Serve the files over HTTP: a file:// page is not the intended way to fetch this bundle. If loading fails, the status line shows the error instead of presenting an apparently working empty canvas.

Two frames from the running example

At 0.20 seconds, seed 31, the runtime reported 48 active and 48 visible particles and a supported renderer result. The particles are close enough to the ground marker to make the circular origin legible.

At 0.65 seconds, the same seed still reported 48 active and 48 visible particles. The rising particles have moved and faded. Holding both frames makes the visual difference easier to inspect than repeatedly trying to stop an animation by eye.

I also checked reduced-motion replay: with the option enabled, Replay once kept the static review frame. The screenshots above show the runtime, and the marker and grid are host geometry.

What this verifies, and what to check next

This example verifies one validated export and one Three.js consumer on the tested desktop browser. It does not measure mobile performance, frame rate, or cross-engine parity. There is no PixiJS or Babylon.js implementation in this tutorial.

If you adapt the cue, review the validation output, exported effect ID, required backend, support report, asset requirements, and the two held frames. Then test it inside the actual game camera and rendering setup. Those checks turn a visually promising authoring result into a small, inspectable runtime integration.

Before you hand an AI task to a teammate, check these three gates

PatilRB — Tue, 13 Oct 2026 07:38:42 +0000

A teammate has time to supervise a coding agent. Your backlog has an unfinished task. That does not automatically make the task a good handoff.

The missing piece is often eligibility: can that person access the right material, understand a bounded outcome, and give the result to someone who can judge it?

Here is a small worksheet for AI task handoff for teams. It separates requirements that must pass from scores that help prioritize eligible work.

The worksheet is a proposed process. The five-person startup and tasks below are illustrative, not reported customer results.

Start with three gates

Before scoring a task, answer these questions:

Gate	What must be written down	What makes it fail
Access	The runner can use the required repository, tools, and approved data through their own authorized access.	The task requires another person's login, inaccessible files, or data the runner may not handle.
Scope	One concrete outcome, explicit boundaries, and observable acceptance criteria.	“Improve onboarding,” an unknown dependency, or changes without a defined stopping point.
Review	A named reviewer who understands the outcome and has agreed to review it.	Nobody can verify the work, or review is assumed to happen eventually.

An unanswered gate stays pending. A failed gate rejects the handoff until the underlying issue changes.

Do not award enough points elsewhere to compensate for missing authorization or a missing reviewer.

Score only tasks that pass

Use four dimensions, each scored from zero to two:

Dimension	0	1	2
Context readiness	Important context missing	Some questions remain	Reproduction, references, and constraints supplied
Verification	Mostly subjective	Manual checks defined	Repeatable checks and expected outcomes defined
Change containment	Broad dependencies	Several connected areas	Narrow change with explicit exclusions
Runner readiness	Cannot supervise this work	Needs scheduled assistance	Can explain, supervise, and stop the task

For this example, six out of eight makes a task a candidate. This threshold is a team choice, not a validated predictor of success.

A candidate still needs the runner to accept the work. Having spare tool allowance does not establish available attention or competence.

Work through a five-person example

Imagine this team:

Priya: backend engineer and task author.
Leo: full-stack engineer and proposed runner.
Maya: QA engineer and reviewer.
Sam: designer.
Noor: founder and product lead.

Priya has three overflow tasks:

Task	Gates	Score	Decision
Add a regression test for a documented CSV parsing bug using synthetic fixtures	All pass	8/8	Candidate for Leo
Investigate a customer export available only through Priya's private access	Access fails	Not scored	Hold until an approved source and access path exist
“Improve the onboarding experience”	Scope and review fail	Not scored	Rewrite the task before assigning it

The worksheet selects a bounded regression-test task. It does not prove that the task will succeed or that Leo's tools can finish it within a particular allowance.

Write the handoff before assigning it

A reusable brief can be plain YAML:

task: Reject malformed CSV rows without losing valid rows

author: Priya
runner: Leo
reviewer: Maya

access:
  repository: Runner's existing authorized repository access
  data: Synthetic CSV fixtures only
  tools: Runner's own authorized tools

outcome:
  - Reproduce the documented parsing failure
  - Add a regression test
  - Make the smallest required parser change

out_of_scope:
  - Production exports
  - Database migrations
  - Parser API redesign
  - Deployment

acceptance:
  - Malformed rows produce the documented error
  - Valid fixtures preserve their expected parsed values
  - Relevant existing tests pass

stop_if:
  - Real customer data becomes necessary
  - The fix requires an API or schema change
  - A required dependency or permission is missing

delivery:
  - Proposed patch
  - Commands run and actual results
  - Remaining uncertainty

review:
  - Maya checks the reproduction and acceptance criteria
  - Acceptance does not authorize deployment

Replace every illustrative detail with the actual repository, reproduction, and expected behavior before use.

Keep preparation, execution, and acceptance separate

Priya prepares the task and chooses what context may be shared. Leo executes it with his own authorized tools, supervises the agent, and stops when the brief no longer applies. Maya judges the evidence against the acceptance criteria.

Delivery means that a result is available for review. It does not mean accepted, merged, or deployed.

The background to this distinction is described in Wagglet's article on using unused Claude Code and Codex capacity. The transferable unit is a prepared task; accounts and credentials stay with their owners.

For an initial pilot, record preparation time, review time, rejected handoffs, rework, and accepted outcomes. Keep failed attempts in the record. Otherwise, a worksheet intended to reduce coordination can quietly become another dashboard to optimize.

Disclosure: This article was prepared with AI assistance. I work at Rockbite, which makes Wagglet.

Building Agent-Ready VFX Workflows for Web Game Teams

PatilRB — Fri, 02 Oct 2026 08:24:25 +0000

Visual effects are an awkward part of an AI-assisted development workflow.

A coding agent can modify TypeScript, update tests, and refactor a component because the inputs and outputs are visible in the repository. VFX work often looks different: editor state, binary assets, renderer-specific settings, and visual decisions that cannot be judged from a diff alone.

So simply giving an agent access to a particle editor is not enough.

For agent ready VFX tools to be genuinely useful, the workflow needs four things:

source files an agent can inspect and edit;
deterministic validation before anything reaches the game;
an explicit build or export step;
human visual review before the result is accepted.

Here is what that can look like in a PixiJS project.

1. Keep the authoring source in the repository

Start with a dedicated VFX project structure:

vfx/
├── vfx-editor.prj
├── particle-data/
│   └── effects/
├── assets/
└── out/
    └── vfx/

The important separation is between authoring files and runtime files.

The effect source lives under particle-data/effects/. The game should consume the generated out/vfx bundle instead.

That gives an AI agent something concrete to modify while keeping a build boundary between authored content and what actually ships.

For NixieFX specifically, effects are stored as JSON and exported into a bundle containing a manifest, compiled effect definitions, and any referenced assets. The broader runtime and backend behavior is documented in the NixieFX editor and runtime reference.

2. Create a minimal project

Install the runtime alongside PixiJS:

npm install nixie-fx pixi.js

Create a vfx directory:

mkdir -p vfx/particle-data/effects
mkdir -p vfx/assets

Then add vfx/vfx-editor.prj:

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

Now scaffold an effect for the PixiJS backend:

npx nixie-fx effect create \
  --project ./vfx \
  --name "Agent Burst" \
  --profile pixi-ui-2d

This gives the workflow an important property: the agent does not need to invent an entire particle-effect schema from memory.

It starts from a valid effect and modifies a known source file.

3. Make validation part of the agent loop

The workflow should not be:

prompt -> edit -> ship

It should be:

prompt
  ↓
edit effect JSON
  ↓
validate
  ↓
fix errors
  ↓
export
  ↓
visual review
  ↓
accept

Run validation after each meaningful change:

npx nixie-fx validate ./vfx

Validation is useful because it gives both humans and agents a machine-readable boundary.

A visual effect can still look bad while being technically valid, but basic structural and backend problems should not require somebody to discover them manually inside a running game.

You can also make validation part of the normal project scripts:


json
{
  "scripts": {
    "vfx:check": "nixie-fx validate ./vfx

The biggest problem is how to share Codex and Claude tokens without giving someone my password

PatilRB — Thu, 01 Oct 2026 14:18:32 +0000

I work in operations, so I'm always paying attention to whats being used - and how. And an issue that I kept seeing is we're paying good money (and a lot of it) for AI subscriptions and some people are using it really well... then there's people like me who use it mostly for reviewing my texts and writing scripts for financial stuff.

The first time our data analyst asked me for my Codex password, I gave it knowing I have authentication turned on. Then a week later one of our developers wanted it, and all of a sudden half the office knew my AI software passwords and were begging for me to authenticate them for them to use my tokens. Sure, I could have made an API key, sure I could have upgraded their already expensive AI subscriptions, but instead we started thinking about what we can do to share something in the safest way possible.
At the same time with budget cuts, we started thinking about project management software for AI agents, without the HUGE costs and we came to one decision.

Move the task, not the account passwords

This way the capacity is distributed. Not only do we now see that developers that were consistenly working overtime now going home after they finish their 8 hours, but everyone in the office is working and enjoying it.

So since people already have access to the repository, we just moved who completes the task, instead of who has the password.

Check out more here: https://wagglet.com/blog/use-unused-claude-code-codex-capacity

_Disclosure: I work at Rockbite which made Wagglet :D _

Tap-to-move is harder than it looks

PatilRB — Wed, 26 Aug 2026 08:57:50 +0000

Tap-to-move is the first input scheme most 3D web games implement and the first place they get subtly wrong. Not broken — wrong in ways that feel like the game is cheap.

The naive version is four lines and it mostly works:

canvas.addEventListener('pointerdown', e => {
  const ndc = toNDC(e.clientX, e.clientY);
  raycaster.setFromCamera(ndc, camera);
  const hit = raycaster.intersectObject(ground)[0];
  if (hit) player.target.copy(hit.point);
});

Here is what that misses, roughly in the order you'll discover it.

Normalised device coordinates need the canvas, not the window

clientX is relative to the viewport. The raycaster wants coordinates relative to the canvas, in the range −1 to 1, with y flipped. If your canvas is inset, letterboxed, or sits below a header, using window dimensions puts every tap at a small offset from where the player aimed — and it will feel like input lag rather than a mapping error.

const r = canvas.getBoundingClientRect();
const x = ((e.clientX - r.left) / r.width) * 2 - 1;
const y = -((e.clientY - r.top) / r.height) * 2 + 1;

Recompute the rect on resize and on orientation change, or cache it and invalidate — reading it per tap is fine, reading it per frame is not.

Raycast a plane, not the ground mesh

Intersecting the visible ground works until the ground has holes, decorative geometry, or a mesh whose collider does not match its silhouette. Then taps near edges do nothing, which reads as unresponsiveness.

Raycast a mathematical plane at the gameplay height instead. It always hits, it costs nothing, and it decouples input from art.

`pointerdown`, and only pointer events

Not mousedown plus a touch path bolted on later. pointerdown covers mouse, touch and pen in one code path. Also set touch-action: none on the canvas, or mobile browsers will helpfully scroll and pinch-zoom your game while the player tries to play it.

Move with delta time, and check the unit

const step = speed * dt;              // dt in SECONDS
if (player.position.distanceTo(target) > step) {
  player.position.addScaledVector(dir, step);
} else {
  player.position.copy(target);       // snap, or you oscillate forever
}

Two traps in four lines. THREE.Clock.getDelta() gives seconds; a raw requestAnimationFrame timestamp gives milliseconds, and passing the wrong one produces motion that is wrong by a factor of 1000 without erroring. And omitting the snap leaves the player jittering around the target forever, because it can never land exactly.

The part that makes it feel good

Everything above makes tap-to-move correct. What makes it feel deliberate is the acknowledgement: a small burst at the tap point, fired on pointerdown, before the character has moved at all.

That single effect does more for perceived responsiveness than any amount of movement tuning, because it answers the player's real question — did it hear me? — in the same frame as the input.

This tutorial goes end to end on the mobile-first version: renderer with a capped pixel ratio, scene and camera, the loop, pointer input, and a tap-burst effect wired into the same per-frame update.

What I'd tell someone starting today

Write the input layer yourself and get the mapping right, because it is small and everything else sits on top of it. Then borrow the feedback layer, because hand-rolling a particle system teaches you about object pooling rather than about your game.