@adobe/ecs 0.1.0 → 0.2.1

package/src/implementation/world/out-of-band.ts

@@ -0,0 +1,61 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
+import { errorOfFailure, type Failure } from './failures.js';
+
+/**
+ * Raises an error out of band: through the platform's `reportError` where it has one, as browsers and their workers
+ * do, so it's logged and dispatched as an `error` event; otherwise thrown from a task of its own, an uncaught
+ * exception, as in node. Read each time, so a test can stand in for it.
+ */
+export const raise = (error: Error): void => {
+    const report: unknown = Reflect.get(globalThis, "reportError");
+    if (typeof report === "function") Reflect.apply(report, globalThis, [error]);
+    else setTimeout(() => { throw error; }, 0);
+};
+
+/**
+ * Failures no run rejects with, raised out of band: once per subject, a system, finalizer, index or GPU work, while
+ * it keeps failing. The world tells it what recovered: a system or finalizer that ran without failing, an index a
+ * tick found no conflict in, GPU work whose scopes gave no error. Once closed, as its world is disposed, it raises
+ * nothing more. With nothing reported, what the world asks of it costs a size check.
+ */
+export const createOutOfBand = () => {
+    /** Subjects reported and not known to have recovered, by the kind of their failure. */
+    const reported = new Map<object, Failure["kind"]>();
+    let closed = false;
+
+    /** Raises a failure, unless its subject is reported already or this is closed. */
+    const report = (failure: Failure): void => {
+        if (closed || reported.has(failure.subject)) return;
+        reported.set(failure.subject, failure.kind);
+        raise(errorOfFailure(failure));
+    };
+
+    return {
+        report,
+        reportAll: (failures: readonly Failure[] | null): void => {
+            if (failures !== null) for (let k = 0; k < failures.length; k++) report(failures[k]);
+        },
+        /** How many subjects are reported, still failing as far as it knows. */
+        size: (): number => reported.size,
+        has: (subject: object): boolean => reported.has(subject),
+        /** Whether a subject of this kind is reported. */
+        reports: (kind: Failure["kind"]): boolean => {
+            for (const each of reported.values()) if (each === kind) return true;
+            return false;
+        },
+        /** `subject` ran without failing, so its next failure is reported. */
+        recovered: (subject: object): void => {
+            if (reported.size !== 0) reported.delete(subject);
+        },
+        /** Indexes reported that none of `failures` names recovered, as a tick found no conflict in them. */
+        indexesRecovered: (failures: readonly Failure[]): void => {
+            for (const [subject, kind] of reported) if (kind === "index" && !failures.some(failure => failure.subject === subject)) reported.delete(subject);
+        },
+        close: (): void => {
+            closed = true;
+            reported.clear();
+        },
+    };
+};
+
+export type OutOfBand = ReturnType<typeof createOutOfBand>;

package/src/implementation/world/outcomes.test-helper.ts

@@ -0,0 +1,138 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
+import type { Input } from "../../interface/system/input.js";
+import type { System } from "../../interface/system/system.js";
+import type { World } from "../../interface/world/world.js";
+import { recorderOf, type Outcome } from "./create.js";
+import type { Failure, Warning } from "./failures.js";
+
+/** What a run went through, as data: what failed, the labels of the systems it skipped, what it dropped, its warnings. */
+export type Reported = {
+    readonly failures: readonly Failure[];
+    readonly skipped: readonly string[];
+    readonly dropped: number;
+    readonly warnings: readonly Warning[];
+};
+
+/** What a run or tick ran, and where. */
+export type Ran = Pick<Outcome, "systems" | "workers" | "joined" | "main" | "gpu">;
+
+const reportedOf = ({ failures, skipped, dropped, warnings }: Outcome): Reported => ({ failures, skipped: skipped.map(system => system.name), dropped, warnings });
+
+/**
+ * Runs a system on a world `createWorld` made, and gives what the run went through, whether it resolved or rejected,
+ * with what it resolved to or rejected with; rejects as the run does when it failed before its systems ran.
+ */
+export const runOutcome = async <I, R>(world: World, system: System<I, R>, ...input: Input<NoInfer<I>>): Promise<{ readonly outcome: Outcome; readonly value: R | undefined; readonly error: unknown }> => {
+    recorderOf(world);
+    return outcomeOf(world, world.run(system, ...input));
+};
+
+/**
+ * What a run went through, by the promise its `run` returned, whether it resolved or rejected, with what it resolved to
+ * or rejected with; rejects as the run does when it failed before its systems ran. Its world must have been recording
+ * outcomes (`recorderOf`) before it was run.
+ */
+export const outcomeOf = async <R>(world: World, running: Promise<R>): Promise<{ readonly outcome: Outcome; readonly value: R | undefined; readonly error: unknown }> => {
+    const record = recorderOf(world).runs.get(running);
+    if (record === undefined) {
+        // Rejected before it was queued, or queued before its world recorded outcomes.
+        await running;
+        throw new Error("The run was queued before its world recorded outcomes.");
+    }
+    let value: R | undefined = undefined;
+    let error: unknown = undefined;
+    let rejected = false;
+    try {
+        value = await running;
+    }
+    catch (thrown) {
+        rejected = true;
+        error = thrown;
+    }
+    if (record.outcome === null) throw rejected ? error : new Error("The run gave no outcome.");
+    return { outcome: record.outcome, value, error };
+};
+
+/** What a run went through, by its promise, as `runReported` gives it. */
+export const reportOf = async (world: World, running: Promise<unknown>): Promise<Reported> => reportedOf((await outcomeOf(world, running)).outcome);
+
+/** Runs a system, then gives what its run went through. */
+export const runReported = async <I, R>(world: World, system: System<I, R>, ...input: Input<NoInfer<I>>): Promise<Reported> =>
+    reportedOf((await runOutcome(world, system, ...input)).outcome);
+
+/** Runs a system, then gives what its run ran, and where. */
+export const runRan = async <I, R>(world: World, system: System<I, R>, ...input: Input<NoInfer<I>>): Promise<Ran> => {
+    const { systems, workers, joined, main, gpu } = (await runOutcome(world, system, ...input)).outcome;
+    return { systems, workers, joined, main, gpu };
+};
+
+/** What every run on a world's thread goes through from now on, joined threads' included, in the order they settle. */
+export const followRuns = (world: World): Reported[] => {
+    const seen: Reported[] = [];
+    recorderOf(world).each.push(outcome => seen.push(reportedOf(outcome)));
+    return seen;
+};
+
+/**
+ * Follows a world's ticks: `seen` lists each tick's report once its tails are done, and `until` resolves with the
+ * first one a test passes, once one does.
+ */
+export const followTicks = (world: World) => {
+    const seen: Reported[] = [];
+    const waiting: (() => void)[] = [];
+    const listener = (outcome: Outcome): void => {
+        seen.push(reportedOf(outcome));
+        for (const wake of waiting.splice(0)) wake();
+    };
+    const { ticks } = recorderOf(world);
+    ticks.push(listener);
+    const until = async (test: (report: Reported) => boolean): Promise<Reported> => {
+        for (;;) {
+            const found = seen.find(test);
+            if (found !== undefined) return found;
+            await new Promise<void>(resolve => waiting.push(resolve));
+        }
+    };
+    return {
+        seen, until, stop: () => {
+            const at = ticks.indexOf(listener);
+            if (at >= 0) ticks.splice(at, 1);
+        },
+    };
+};
+
+/**
+ * Stands in for the platform's `reportError` until disposed, so what worlds report out of band is collected in
+ * `errors` rather than raised: `until` resolves once one a test passes is.
+ */
+export const catchOutOfBand = () => {
+    const errors: Error[] = [];
+    const waiting: (() => void)[] = [];
+    const had = Object.hasOwn(globalThis, "reportError");
+    const previous: unknown = Reflect.get(globalThis, "reportError");
+    Reflect.set(globalThis, "reportError", (error: Error) => {
+        errors.push(error);
+        for (const wake of waiting.splice(0)) wake();
+    });
+    const until = async (test: (error: Error) => boolean): Promise<Error> => {
+        for (;;) {
+            const found = errors.find(test);
+            if (found !== undefined) return found;
+            await new Promise<void>(resolve => waiting.push(resolve));
+        }
+    };
+    return {
+        errors,
+        until,
+        /** Resolves once `count` errors were reported. */
+        count: async (count: number): Promise<void> => {
+            while (errors.length < count) await new Promise<void>(resolve => waiting.push(resolve));
+        },
+        /** The messages of what was reported. */
+        messages: (): string[] => errors.map(error => error.message),
+        [Symbol.dispose]: (): void => {
+            if (had) Reflect.set(globalThis, "reportError", previous);
+            else Reflect.deleteProperty(globalThis, "reportError");
+        },
+    };
+};

package/src/implementation/world/package-id.test-helper.ts

@@ -0,0 +1,9 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
+/// <reference types="node" />
+import { readFileSync } from 'node:fs';
+
+const manifest: unknown = JSON.parse(readFileSync(new URL("../../../package.json", import.meta.url), "utf8"));
+const version: unknown = typeof manifest === "object" && manifest !== null ? Reflect.get(manifest, "version") : undefined;
+
+/** The id of a binding of one of the package's own modules, as the build gives it: its name and current version first. */
+export const ownId = (path: string, binding: string): string => `@adobe/ecs@${String(version)}/${path}#${binding}`;

package/src/implementation/world/perf.md

@@ -124,6 +124,7 @@ A report for every run and tick, `Report.run` written in place and `Report.error
 - **About 125 ns a run:** two `performance.now()` calls for `elapsed`, 31 ns each, then locating the report, writing its struct and stamping it.
 - **`Report.run` is written field by field** through its layout's leaves, not the general struct writer: `run idle` 583 → 500 ns, and `run observer` 375 → 291.
 - **What a tier ran is worked out once per list of runners:** counting each runner every run took `run 50 idle` to 4.08 µs a run.
+- **A world's first 256 runs each spawn their report,** so each has a sync point applying a spawn: 3.2–5.1 µs a run in node against 1.1–1.5 µs once reports are reused, about 1 ms over a world's life. One command buffer spawns every report, 3.8–5.7 → 3.2–5.1 µs. Benchmarks timing a run after another (`after` in `perftest/benchmarks.ts`) warm up past the 256, so they time a world's steady state: the filtered `up` benchmarks timed the spawn's sync point instead, `up one root changed` 0.042 against 0.024 ms, `up filtered after a reparent` 0.028 against 0.018, `up small tree in a big world` 0.020 against 0.011.
 - **A reused report keeps its errors and takes new ones in place,** so a run with a blocking tier every tick changes no archetype, and its sync point isn't one tails wait for.
 
 Strings in shared memory, alternating against `c6bb3c83`, node, five and six rounds, medians: every touched benchmark within noise (`run idle` a mean over 20,000 runs 626–644 against 622–660 ns, `run 50 idle`, `run observer`, `loop tick idle`, `sync point one spawn`, `move 1K`, `main thread 1K`, `spawn bulk`, `despawn bulk`, `despawn one`, `add tag`, `add value`, `remote run`, `joined observer resource`, `joined observer 10K`, `handoff`, `tail prompt`, `tail late snapshot 10K`, `despawn objects 10K` 97.5 against 97.7 ns).
@@ -133,6 +134,12 @@ Strings in shared memory, alternating against `c6bb3c83`, node, five and six rou
 - **Records up to 512 bytes are carved from slabs** by power-of-two size class: `string write 10K joined` 142 → 127 ns against the arena's blocks, whose size class costs a `Math.log2` per record.
 - **A removed row lets go only of its archetype's string storages,** listed once per archetype: `despawn objects 10K` 104 → 97.7 ns against a check of every storage.
 
+A joined thread's finalizers reading its object resources from its mirror, alternating against `998738a3`, node, three rounds: `despawn objects 10K` 98.2–102 against 99.6–103 ns, within noise. The mirror's archetype holding the resource entity is found once per group of stops that reads one, kept and checked before it's searched for again.
+
+A joined thread's finalizers reading string resources from copies in the stop list, once per group, alternating against `13eb6d6f`, node, six rounds, medians, on a machine busy elsewhere: all within noise. New `despawn objects 10K string resource`, the despawn benchmark's finalizer reading a string resource too, 95.5 ns a despawn against 99.5 reading the live record (the benchmark run on the old build); `despawn objects 10K` 98.0 against 97.2 ns, `string write 10K joined` 129 against 129 ns, `joined observer strings 10K` 478 against 500 µs a tick. Finalizers reading no string resource copy nothing and the group holds no extra bytes.
+
+Their linear resources copied into the stop list too, once per group, alternating against `92b823c9`, node, six rounds, medians, on a machine busy elsewhere: all within noise. New `despawn objects 10K linear resource`, the finalizer reading a number and a vec3 resource too, 99.5 ns a despawn against 99.1 reading them where they are (the benchmark run on the old build); `despawn objects 10K` 100.5 against 101.0 ns, `despawn objects 10K string resource` 98.4 against 99.3 ns, `joined observer 10K` 584 against 567 µs a tick, a path this doesn't touch, its rounds spread 500–754 µs.
+
 Sync points waiting only for tails that read the world's memory, against `c21e8e1e`, node: `tail late snapshot 10K` 474–484 → 9.0–9.5 ns a row copied, against 8.9 for `e3c30aa1` measured beside it (its record 8.2), and in chromium 450 → 6.0 ns (its record 5.0, one or two 5 µs timer steps); within noise in both: `tail prompt`, `tail overlap`, `tail overlap waiting`. Since every run spawns its report, until 256 are, almost every sync point has something to apply, and each one settled every tail, so the run waited out the whole body of the benchmark's 4 ms tail ahead of the late one, whose head it had claimed.
 - **A tail reading only its own thread's objects isn't settled at a sync point,** having nothing there a sync point writes: 474 → 12.8 ns.
 - **The benchmark times the run alone,** reading its report after: 12.8 → 9.0 ns. Reading it through `runReported` timed a second run as well.
@@ -142,6 +149,86 @@ GPU copies uploading only the chunks CPU writes changed, against `a4eef10e`, chr
 - **An upload writes each run of adjacent chunks stamped since its last upload** or holding rows a sync point appended or disturbed, clamped to the row count; a column with GPU writes the CPU hasn't read back writes only those rows. A whole-column stamp (`columnChanged`) uploads nothing: only GPU kernels make one, and their writes are on the GPU already.
 - **A WASM kernel's column addresses are kept per load as well as per archetype version:** a kernel loaded again to stamp a component that already kept ticks went on passing the muted column's address, 0, and wrote its stamps over the entity table there.
 
+Render systems with `order`, against `9daaa3f8`, chromium, three runs each: new `gpu ordered render unchanged 50K`, 50K shapes and images, two archetypes interleaved in depth, drawn as one table in a sorted index's order with nothing changed, 0.030–0.036 ms a run, against 0.045–0.049 ms for the same 50K drawn without `order` as two tables, which writes both tables' records each run. New `gpu ordered render one key 50K`, a target system moving one item to another depth and then the ordered draw, 0.268–0.294 ms a run, against 0.042–0.050 ms unordered: listing the 50K entries in order costs 0.167–0.175 ms (3.4 ns an entry) and writing the 200 KB block 0.067–0.070 ms, timed inside the run.
+- **The order block is listed and written only when the index's entries changed or moved rows,** by the index's `changed` tick and a `moved` tick its refresh stamps when it relocates an entry with its key unchanged, or when the matches grew; the tables block only when a column's address changed; the record only when one of its four words did. An unchanged run writes nothing to the queue and allocates nothing: the table, its `bind`, the tables list and the context are reused.
+- **An entry is one u32:** the matching archetype's slot in the high bits, as few as the matches need and at least one, and its row in the rest, so the shader masks by the record's shift.
+
+A 2D editor's first tick after loading a document, against `826c45ad`, node, alternating, three rounds: new `editor load tick 50K` 31.4–33.2 → 20.0–20.4 ms, and `up load` 221–223 → 182–186 ms; within noise: `up depth 10`, `up depth 1000`, `up after a spawn`, `up filtered after churn`, `up filtered after a reparent`, `up small tree in a big world`, `index rebuild 1M main`, `order run 100K`, `order filtered 100K 1%`, `children lookup`, `sorted range 1M`, `sorted page 100K`. The benchmark spawns 50,201 nodes depth first, a document, 200 groups, two subgroups in each and 124 shapes and images in each subgroup, after a first tick over the empty world, then times the next tick: two `up` row systems with `changed` filters writing a position and an opacity, a layout looking up each group's children through a hash index on the parent, and a paint system run in a sorted index's paint order. Before, each system's part of the tick, run alone after the load: the position `up` 13.1 ms, the opacity `up` 10.4, the layout 2.45 (its index's build), the paint 5.43 (its index's build and 50K ordered rows). Of the opacity `up`'s profile, building the tree 22%, marking every row as passing the filters (`changedRows`, `mark`, clearing the marks) 25%, building the order 19%, listing the marked rows from it 10%, and the body 20%. After: 6.4, 4.4, 2.15 and 4.4 ms.
+- **A filtered run after its tree was built again runs the whole order,** as an unfiltered one does, since every row passes then: the tick 32 → 25.1 ms, the position `up` 13.1 → 8.5 and the opacity `up` 10.4 → 7.1. Marking 50K rows, each in a bucket of its depth, and scanning the order for the marks cost as much as the run. A later sparse run is cold for it: `up one root changed` 28 → 33 µs a run over the benchmark's 100 rounds, the marking path no longer warmed by a first full pass, and 14 µs either way after 1,000 rounds.
+- **The tree's build reads each archetype's parent column once,** rather than finding the archetype, column and layout for every entity: the opacity `up` 5.35 → 4.5 ms.
+- **The build sets every level in one walk per entity,** up to a root or an entity already set and back down, rather than settling the entities as journaled changes do, which walk each one's children again: the opacity `up` 4.77 → 4.49 ms.
+- **An order build's scratch is shared by every `up` of a thread:** the second system reuses the first one's arrays rather than allocating its own, 13 of them 50K entries each: the tick 20.6 → 20.0 ms, medians of five rounds.
+- **A sorted index's rebuild skips the sort when its entries are in key order already,** as a load in document order lists them, checked in one pass that stops at the first pair out of order: the paint 5.6–5.8 → 5.1–5.3 ms.
+- **A main-thread system run in an index's order binds its row in place when the archetype changes,** rather than looking the shared row up again, which happens at every row when archetypes interleave in the order: the paint 4.85 → 4.5 ms.
+
+Long hash buckets left unsorted until read by position, against `1ff6c206`, node, alternating, medians of five: new `bucket move 1K/10K/100K length`, one entity moved between the two buckets of an index on a boolean and a run reading both lengths, as toggling a todo is, 9.0 → 5.7, 63.9 → 5.5 and 418 → 5.6 µs a move (two runs' fixed cost included); new `bucket move … in order`, the run reading each bucket's first ten rows, 9.4 → 6.8, 65.2 → 12.7 and 416 → 68.9 µs. Within noise: `index refresh 1M 1%` 159 → 152 ns, `unique lookup 1M`, `children lookup`, `grid neighbors 100K main` and `workers`, `sorted range 1M`, `sorted page 100K`, `order run 100K`, `order filtered 100K 1%`, `index idle`, the keyless and `lookup 1K entities` benchmarks, `index rebuild 1M main` and `workers` (7.74 → 8.19 ms, runs spread 7.2–8.4 both); `rekey 1M` 13.6 → 14.4 ms (+6%), its 10K buckets of 100 taking about six moves each a frame, which a batched merge did in one pass.
+- **A long bucket's change leaves a hole or joins a tail,** found by binary search over the part in entity order or by the tail position kept per entity, so moving an entity costs no shift of the bucket; its record's length counts entries, so `length` and `changed` read no order.
+- **Sorting is lazy where it can be, eager where it must be:** a list's `at` on the world's thread sorts its bucket; `writeIndexParameters` sorts every unsorted bucket before kernels, workers and joined threads read the arrays, since they read entries by position and can't write them.
+- **A sort moves 8-byte words:** shared memory copies an element at a time, a 150K-word `copyWithin` 193 µs as `Int32Array` against 25 as `Float64Array`; a shift by an odd number of words goes through a scratch, 58 µs, once it's at least 1,024 words, the two views of it it makes costing tens of nanoseconds against a microsecond's copy; a shorter one copies a word at a time and allocates nothing. `bucket move 100K in order` 222 → 68 µs; every odd shift a word at a time, 180 µs, and `bucket move 10K in order` 12.7 → 23 µs.
+- **A full unsorted bucket with holes sorts in place rather than moving its segment, and one that grows gets half its length more spare slots:** `rekey 1M` 15.5 → 14.4 ms, from relocated segments, buffer growth and compactions.
+
+Block ticks, alternating against `998738a3`, node, medians of five rounds for the filter benchmarks and three for the rest; chromium, medians of three. New benchmarks (`perftest/filters.ts`), 100K rows of one archetype after a write of one row, ten rows 10,000 apart, or every row, then eight main-thread systems or four WASM kernels filtering on `changed`, timed a run of them:
+
+| Benchmark | Before | Now |
+|---|---|---|
+| `changed one 100K`, eight systems | 34.9 µs | 5.04 µs |
+| `changed few 100K` | 421 µs | 11.5 µs |
+| `changed all 100K` | 8.49 ms | 4.69 ms |
+| `changed one 100K two filters`, the other component unwritten | 37.6 µs | 8.42 µs |
+| `changed one 100K kernels`, four WASM kernels | 5.21 µs | 4.42 µs |
+| `changed few 100K kernels` | 15.2 µs | 7.33 µs |
+| `changed all 100K kernels` | 504 µs | 420 µs |
+| `sparse changed`, 1M, 1% scattered | 354 µs | 317 µs |
+| `sparse changed clustered` | 29.3 µs | 28.0 µs |
+
+In chromium: `sparse changed main` 295 → 260 µs, `sparse changed workers` 70 → 60 µs, `changed few 100K` 115 → 5 µs, `changed one 100K two filters` 40 → 5 µs (timers step by 5 µs), `changed all 100K kernels` 485 → 395 µs. Readers of key and parent ticks: `up one root changed` 27.8 → 26.4 µs, `up filtered after churn` 54.5 → 51.4 µs, `rekey 1M` 13.6 → 12.4 ms, `read run changed` 14.5 → 13.3 µs. Writes within noise in node (`create`, `create flat`, `move`, `churn`, `retag`, `emit`, `emit main`, `reduce`, `chain`, `follow`, `spawn bulk`, `spawn bulk kernel`, `add tag`, `add value`, `add replace`, `despawn bulk`, `index refresh 1M 1%`, `sync point one spawn`, `move 1K`) and chromium (`move`, `chain`, `emit` and `spawn bulk kernel`, main and workers), and so are `run idle`, `run observer`, `index idle`, `observer idle 100`, `joined observer 10K` and `observe gpu entity factory`. Memory: a ticked storage has two block arrays, one for a constant, each 128 bytes per chunk of its capacity, so at least 128 bytes: 1.6% of its row ticks once its capacity is 1024 rows or more, and as much as them at the initial capacity of 16 rows. Each storage's layout record takes two more words.
+
+- **Every row tick's writer raises its block's tick,** one store beside the chunk's: row writes on any thread, kernels (once per call for a block every row of the call reaches, in JS and WASM), the sync point's writes, spawns and moves, swaps into removed rows, a GPU kernel's column stamp lifted onto a joined thread's rows, and joined threads' own ticks. The arrays live in the arena beside the chunk ticks, and the layout directory gives workers and joined threads their offsets.
+- **Main-thread, worker JS and joined-thread filters skip chunks, then blocks, then rows, each in a loop over one array,** and a passing range runs on by row ticks alone until a row doesn't pass; the scan was about 5 ns a row, with a branch per row on the filter count, and is now under 1 ns: `changed all 100K` 8.49 → 4.69 ms.
+- **WASM kernels find runs of passing blocks in an outer loop and run their rows in an inner one,** a chunk's passing blocks read into a mask once and each run found with `ctz`, a chunk with more than half its blocks passing taken as one run; every row pays one comparison against the run's end, where it paid a test of whether it started a chunk: `changed all 100K kernels` 504 → 420 µs.
+- **Index refreshes and `up` find changed key-part and filter rows by blocks too.**
+
+Joined threads' index lookups checking archetypes once a run, alternating against `13eb6d6f`, node, on a machine loaded by other work, medians of 9 and 11 rounds:
+- **A row a lookup gave stays bound while one count stays the same,** as on the world's thread: each flush that writes an existing archetype's record again adds one to a header word, and a joined thread's directory moves its count on once a run when the word, its mirror's archetypes (a rebuild) or its views (memory grown, keys named) changed. Before, every row read loaded its archetype's view, the mirror's entry and the record's version. `joined observer 10K` 485 → 438 µs and 480 → 417 µs a tick; `joined select 10K factory` 524 → 498 µs. Within noise: `joined observer numbers 10K`, `joined observer strings 10K` (their rows bind once per archetype a run either way), `joined observer resource` 4.7 against 4.6 µs, `unique lookup 1M` 79 against 71 ns (its generated site now checks the count, not the archetype's version), `grid neighbors 100K main` 5.94 against 5.99 µs a row.
+- **A rebuilt mirror's rows are bound again:** rows compare the view they were bound to, not only its version, so a row a lookup gave before the thread's log lapped no longer reads the objects of the mirror's old columns.
+
+Runs that wait for nothing allocate no async frame, alternating against `415c463`, node, five rounds, medians: `run idle` 500 → 291 ns, `run observer` 291 → 250, `run 50 idle` 77 → 70 ns a system, `sync point one spawn` 1,000 → 791 ns, `loop tick idle` 1.90 → 1.58 µs, `move 1K` 0.79 → 0.58 ns a row, `despawn one` 1.71 → 1.38 µs, `spawn singles` 323 → 260 ns, `bucket move 10K length` 3.4 → 2.5 µs, `handoff` 13.4 → 11.0 µs, `joined resource factory` 4.3 → 3.6 µs; every other node benchmark within noise but `run failing`, 9.95 → 10.4 µs, its body's error formatting a deeper stack. A run of a system no entity matches allocated 3.4 KB, sampled by the heap profiler, and allocates 0.44 KB: the queue's two promises and the microtasks around them.
+- **The run path is synchronous until something waits:** `perform` runs its steps as plain functions, each going on in an async function of its own only when it has a promise to wait for; `execute` and `executeTiers` run tiers with no GPU, tails, joined threads or observer posts without awaiting, and hand over to `executeFrom` at the first tier on a joined thread, index build across the pool or chunk on workers, settling resumable from where it stopped. Each async function allocated its frame on entry whether or not it awaited: 1 KB for `executeTiers`.
+- **Queuing a run makes no closure:** runs of registered systems wait in reused arrays a shared task takes from in order, and the queue's settle handler is shared.
+- **Functions returning early make no closure context:** `activate` and `prepareSync` return before the part whose closures capture their locals, which V8 allocates on entry; an empty queue isn't spliced, the run's start time is kept in a `Float64Array` rather than passed boxed, and a report's cell is found without an object.
+- **`retag` depends on how it's started:** 50 ms under `pnpm perf`, against 33.7 ms from `node scripts/perf.mjs` or `node dist/perf/run.js` with the same bundle, the base's bundle measuring 33.5–34 run directly; its record here is from `node scripts/perf.mjs`.
+
+Kernels' remainders, alternating against `63552a7`, node, five rounds: new `raise on even ticks 10K`, a WASM kernel testing `resources[clock].tick % 2`, 33.2 → 0.61 ns a row, against 0.51 for `raise 10K` without the test; new `wrap 10K`, a number column `% 1000` in every row, 34.2 → 2.39 ns. Every other kernel benchmark within noise (`move`, `move 10K`, `chain`, `reduce`, `sparse changed`, `follow`). Results stay the body's bit for bit (`precision.test.ts`).
+- **Values the same for every row that call an import are computed once a call:** the largest row-independent expressions holding `%`, `**` or a `Math` function WASM lacks go into locals before the rows. Each row called the JS import, 33 ns from WASM.
+- **A remainder by a nonzero integer literal is exact in WASM while the dividend is an integer below 2^53:** each row checks, and takes the `i64` remainder with the dividend's sign, or the import otherwise.
+
+`up` systems sharing their tree and order, alternating against `940448c`, node, five rounds: `editor load tick 50K` 20.8 → 18.0–19.0 ms (413 → 360–378 ns a node over two sessions), its two `up`s with the same `through` building one tree and one order where each built its own, about 1.5 ms each; every other `up` benchmark within noise (`up depth 10`, `up depth 1000`, `up depth 10 10K`, `up one root changed`, `up after a spawn`, the three `up filtered` ones, `up load`, `up small tree in a big world`).
+- **A thread's `up`s with the same `through` share one tree and order while they agree on every archetype:** whether it matches and whether a parent in it is readable. Each new archetype is checked against every reader, and one disagreeing leaves to build its own. The tree reads the journal once for all, telling each filtered reader the entities whose parents changed, which its next filtered run marks and a whole pass drops; a reader holding more than a journal's worth drops them and runs every row next. Each keeps its own marks and lists. Within noise of that, against `198cb74`: `editor load tick 50K`, `up filtered 4K, 250 moving a frame`, `run idle`, `run observer`, `loop tick idle`, the `up filtered` ones.
+
+The journal keeping its newer half when full, alternating against `45ce602`, node, five rounds: new `up filtered 4K, 250 moving a frame` 110 → 97 µs a frame. It dropped every entry once full, within a sync point too, so readers current at the last one, `up` trees and indexes, built again every four to five frames there, and a filtered `up` then ran every row; a test counts the rows it runs. Within noise: `index refresh 1M 1%`, `rekey 1M`, `keyless refresh 1M 1%`, `keyless spawn 1M 1%`, `bucket move 10K length`, `up filtered after churn`, `up one root changed`, `churn`, `editor load tick 50K`, `order filtered 100K 1%`.
+
+`transfer` in chromium varies with the bitmaps it moves, not the ECS: of its ten batches of ten transfers, each 1024 by 1024 bitmap and 1 MB buffer, a batch takes about 0.8 ms or about 2 ms, in either order, so the sum of ten ran 13.3–21.6 ms over six runs; with 1 by 1 bitmaps the batches are unimodal (medians 0.42–0.64 ms) and new `transfer small bitmaps`, the fastest of 40 batches for 100 transfers, ran 2.65–3.3 ms after its first run. Waiting 30 ms before each batch made both modes slower, cores clocking down while idle, and warming the threads with four tiny transfers first left the two modes as they were.
+
+`index rebuild 1M workers` had measured the world's thread alone, 27–29 ms in node and chromium, since its pool-starting kernel matched no row and the pool now starts only for kernels over rows enough for workers; its kernel runs over the 1M keyed rows instead: 6.6–7.0 ms in node and 7.9 ms in chromium, as recorded before.
+
+Runs without reports, alternating against `225fd64`, node, three rounds each, the fastest run: `run idle` 291 → 208 ns, `run observer` 208–250 → 125, `run failing` 10.3 → 6.7–6.9 µs, `loop tick idle` 1.60–1.65 → 1.47–1.54 µs a tick; within noise: `run 50 idle`, `read run`, `read run observer`, `read run changed`. The fastest run steps by 42 ns there, so a mean of 200K runs, three rounds: `run idle` 365–371 → 274–277 ns, `run observer` 300–317 → 212–215.
+- **A run spawns, writes and stamps nothing of its own,** and reads no clock: no entity per run, no `Report.run` struct, no `elapsed`, no errors added or removed between runs, and no wait for tails before a tick's observer systems.
+- **A failing run builds its Error once its sync point and observer pass are done,** from failures gathered as data, and rejects; nothing is queued for a sync point of its own.
+- **The queue chains a promise of its own, which never rejects,** a failure carried as a value, and gives each run a second promise, which nothing in the queue handles, so a failing run nobody awaits is an unhandled rejection whatever follows it. Making each run's promise the queue's tail, one promise a run, was 25–35 ns faster (`run idle` 247–256 ns and `run observer` 187–194, means of 200K runs, against 282–288 and 221–224 now; `loop tick idle` 1.49–1.52 µs against 1.56–1.59), but the next run's handler swallowed a failing run nobody awaited: correctness outranks the cost, which a later measurement put at 42 ns on `run idle`. A queue settling each run through `Promise.withResolvers` cost more again: 295–312 and 232–252 ns.
+
+Shared components and `where`, against `12e366d`, node: the whole suite three times on each, then the key benchmarks alternating, five rounds; every one within noise (fastest runs, before → after): `run idle` 208 → 208 ns, `run 50 idle` 68.3–69.2 → 68.3–70.8 ns a system, `run observer` 125 → 125 ns, `loop tick idle` 1.55–1.66 → 1.48–1.57 µs, `move 1K` 0.50–0.54 → 0.50–0.54 ns a row, `churn` 16.0–16.6 → 16.0–16.6 ns, `spawn singles` 240–250 → 240–250 ns, `spawn bulk` 25.3–25.7 → 25.3–25.7 ns, `sync point one spawn` 667–750 → 708 ns, `add tag` 93.6–95.7 → 94.4–96.8 ns, `remove tag` 70.0–71.0 → 70.0–71.2 ns, `index idle` 9.4–9.7 → 9.2–9.8 ns, `index refresh 1M 1%` 144–149 → 142–150 ns, `unique lookup 1M` 44.7–46.5 → 44.2–47.1 ns, `sorted range 1M` 656–662 → 656–679 ns, `keyless index idle` 7.0–7.3 → 7.0–8.0 ns, `move` 0.36–0.38 → 0.36–0.38 ns, `chain` 0.256–0.264 → 0.256–0.264 ns, `with 100K kernel` 0.49–0.51 → 0.50 ns, `changed one 100K kernels` 1.07–1.20 → 1.10–1.23 µs, `struct replace kernel main` 61.6–65.0 → 63.8–66.2 ns, `editor load tick 50K` 361–386 → 351–370 ns a node, `remote run` 8.8–11.9 → 9.0–11.9 µs, `handoff` 10.9–12.2 → 10.4–12.3 µs, `fused tiers` 6.5–7.4 → 6.4–6.9 µs, `joined observer resource` 3.4–4.2 → 3.3–3.7 µs, `joined observer 10K` 0.41–0.48 → 0.42–0.48 ms, `tail prompt` 16.6–17.9 → 16.6–17.7 µs, `observer idle 100` 76–85 → 83–86 ns. In chromium, three suites alternating with the baseline's, every benchmark within its noise (such as `move workers` 0.06 → 0.06 ns a row, `loop tick idle` 3.90 → 4.04 µs with 3.2% noise, `tail prompt` 22.5 → 21.3 µs). Worlds and archetypes without shared components look archetypes up, take their edges and bind rows as before: the world's `sharing` flag and each component's entry in `State.shared` stand in front of everything new.
+- **A shared value read in a row costs what a column's does:** `shared read 100K` 4.04–4.10 ns a row against 4.24–4.27 for `column read 100K`, the value bound with the row once per archetype. In a kernel it's a parameter of each call: `shared read 100K kernel` 0.40–0.41 against 0.50 for `column read 100K kernel`, one column fewer to stream.
+- **Spawning with a shared constant:** `spawn bulk shared`, one spawner reused, 17.3–18.1 ns a spawn against 33.3–34.3 for `spawn bulk plain`, whose cell is a column; `spawn singles shared`, its spawner found by its constants each call, 313–323 ns against 229 for `spawn singles plain`: about 90 ns a call to find the spawner, a tuple's leaves walked through a tree of its stored leaves (`shared.ts`) and each constant in turn through the shape's tree of spawners, with no text built.
+- **`where` over 1K cells,** 3 × 3 of them in view: `where 1K cells still` 0.49 ns a cell, 0.5 µs a run with nothing evaluated; `where 1K cells moving`, every predicate evaluated again as the camera moves each run, 18.7–19.0 ns a cell, each predicate's resources read once per evaluation.
+- **Many small archetypes:** `small archetypes 1K`, 10K rows over 1K archetypes of one cell each, 7.26–7.43 ns a row against 3.46–3.49 for `one archetype 10K`: about 39 ns an archetype, binding its row and walking its filters, which a shared component's values multiply.
+
+Review fixes to shared components and `where`, node, alternating against the commit before each, medians of four to six rounds:
+- **Arrivals precise** (`arrivals.ts`): a system with `where` and change filters reads a ring of the moves since its last run, each archetype moved into owing the point of the one its rows came from, where every arrival made the archetype count from the oldest point of all matches, found by a scan of them. New `where changed 1K cells drifting in view`, every cell in view, 1% of 10K rows moving to the next cell before each run: 123.6 → 69.2 ns a cell; `where changed 1K cells drifting`, 3 × 3 cells in view, 2.0 → 2.8 ns a cell, the ring's 102 entries a run read, about 7 ns each, and cells moved into from culled ones scanned since that one's point; `changed 1K cells drifting`, without `where`, 52.3 → 52.0. `where 1K cells still` and `moving` within noise.
+- **`commands.spawn` takes its constants as a second parameter,** where a rest parameter allocated an array every call: `create` (1M spawns, no shared components) +4.1% → +1.4–1.8% against `12e366d`, within the ±2% the suite moves from session to session; bisected over the shared components' commits, no other step stood out. `joined observer 10K` and `tail prompt` within noise in node (+0.3%, +1.2%, rounds spreading 5–20%) and in chromium (+1.7% over 237–360 µs, −9%), eight rounds against `12e366d`.
+- **On the GPU, a shared f32 value** read and stored, an integer leaf, and one product, sum or difference of f32s are the body's bit for bit; longer arithmetic rounds each step in f32 where JS rounds once at the store: `value * scale / 3 + scale * scale` over scales 0.1, 1.7 and −3.3 differs by at most 1.65e-7 of its largest term, up to 14 ULPs of a result near cancellation (`shared-gpu.browser.test.ts`, bound 2^-21).
+- **A spawner's guard** against a component given in both calls, one check of each constant's key a spawn: `spawn singles shared` 323 → 323 ns, `spawn bulk shared` 18.0 → 18.1 ns.
+- **Reclaiming** (`reclaim.ts`): an entity walking one cell a run made an archetype, an interned value, a batch and spawner levels per cell, for good: after 20K cells 20,002 archetypes, 185 MB of heap and 9.1 MB of arena, and `one row after 100K cells walked`, a system over one row, 2.76 ms a run against 250 ns before the walk. Reclaimed and reused, after 100K cells: 11 archetypes, 9 values, 9 batches, 18 spawner levels, heap 29.7–29.9 MB from 1K cells on, arena 71,616 B throughout; `one row after 100K cells walked` 250 ns; `walk to a new cell` 10.3 → 2.8 µs a run. Waiting out empty sync points (`emptyFor`), `circle 8 cells`, round 8 cells, each emptied 7 sync points: 2.67–2.69 µs a run at 1, 2 and 4, reclaiming and reusing one archetype a run, 1.00 at 8 and 16, reclaiming nothing; `walk to a new cell` 2.69–2.73 µs at 1 to 4, 2.81 at 8, 3.06 at 16, scanning more candidates; `flicker between 2 cells` 958 ns at all, against 916 before reclaiming, the sync point's scan of its emptied archetypes. 8, so a cell left for up to 7 sync points keeps its archetype. Edges cached to an archetype of shared values are kept on it to clear, but a batch's archetype is checked by its generation instead: an edge object per spawned archetype, allocated between archetypes and their storages, made `where 1K cells moving` 10% slower, its 1K predicates walking archetypes spread over more memory; checked, +1.8%. Worlds without shared components, five rounds against the commit before: within noise (`run idle` 208 → 208 ns, `run observer` 125 → 125, `loop tick idle`, `move 1K`, `main thread 1K`, `sync point one spawn` 708 → 708, `create` +0.5%, `create flat`, `spawn bulk`, `despawn one`, `churn`, `add value`, `remote run`, `joined observer resource`, `joined observer 10K`, `handoff`, `tail prompt` +0.5% over eight rounds, `log replay`, `read run`); `run 50 idle` was +5% a system until the run's check for reclaimed archetypes kept the scan for new ones apart, out of what its runner inlines: 71.2 → 71.2 ns.
+
 ## Where the gains came from
 
 Step figures marked (vitest) are from the node vitest lane: read them as relative.
@@ -150,10 +237,14 @@ Step figures marked (vitest) are from the node vitest lane: read them as relativ
 - Commands as parallel typed arrays, a reusable typed plan, and cached archetype edges: create 198 → 68 ms, churn 22 → 10 ms, retag 24 → 11.7 ms, emit 7.3 → 3.1 ms (vitest).
 - `Object.keys` instead of `for…in`, and buffers reused across runs: small gains.
 - Allocation-free kernel commands (`begin`/`value`/`component`/`spawn`): emit 3.2 → 1.98 ms (vitest).
+- Kernel commands write the buffer themselves, not through `pushCommand` and `pushComponent`: once V8 reoptimized a
+  kernel, the second call stayed a call and boxed each entity, a double past 2^32. `despawn bulk kernel` 4.60 → 4.12 ms;
+  `despawn bulk` compiled 4.55 ms against 4.32 as written before, 4.10 after.
 - Inline value writes instead of closures, an 8-shape spawn cache, edges indexed by component id, archetypes grown once per sync point: create 38 → 27.6 ms.
 
 **Change filters.**
 - Chunk ticks, the newest tick per 1024 rows, so filters skip unchanged chunks: clustered sparse to ~0.09 ms.
+- Block ticks, the newest tick per 64 rows, so filters skip a changed chunk's unchanged blocks: eight systems finding one changed row of 100K 34.9 → 5.04 µs (above).
 - Filters inside WASM kernels, one call per archetype instead of one per passing range: uniform sparse 3.5 → 1.15 ms, clustered to 0.02 ms.
 
 **Lookups.**
@@ -192,7 +283,7 @@ Step figures marked (vitest) are from the node vitest lane: read them as relativ
 **Tails.** A tail's snapshot is laid out for the rows it found passing and copied a run of consecutive rows at a time, its entities and each linear read one `set` each, its positions, archetypes and rows written in place, and tags marked only for a tail that writes objects: `tail late snapshot 10K` 29.8 → 6.7 ns a row in node, from a row at a time through a scratch list, whose tag pass alone cost 3.3 ns a row for a tail that writes nothing. The copy is what lets the world's work after its writer overlap a late tail: `tail overlap` 2.53 ms a tick against 4.70 for `tail overlap waiting` in node (below).
 
 **Indexes.** Node numbers, `pnpm perf`.
-- Keeping one current costs nothing while its entities rest: a refresh checks its journal position and its key parts' last writes, which systems' writes and sync points' values mark per component, `index idle` 9 ns an index. Moving 1% of 1M entities to other keys, `index refresh 1M 1%`, 4.3 → 1.56 ms: rows listed with their archetype and row, without marks when one key part's scan is all a refresh reads, short buckets' operations applied as they come and long ones merged once, ordered by a counting sort by bucket; a refresh whose changed chunks' rows pass an eighth counts the rows' own ticks before building again, so a few writes spread over every chunk patch: `rekey 1M`, 1M particles 6% of which cross into another cell a frame, 46.9 → 14.1 ms, against 4.8 ms for the same frame without the index.
+- Keeping one current costs nothing while its entities rest: a refresh checks its journal position and its key parts' last writes, which systems' writes and sync points' values mark per component, `index idle` 9 ns an index. Moving 1% of 1M entities to other keys, `index refresh 1M 1%`, 4.3 → 1.56 ms: rows listed with their archetype and row, without marks when one key part's scan is all a refresh reads, short buckets' operations applied as they come and long ones left unsorted; a refresh whose changed chunks' rows pass an eighth counts the rows' own ticks before building again, so a few writes spread over every chunk patch: `rekey 1M`, 1M particles 6% of which cross into another cell a frame, 46.9 → 14.1 ms, against 4.8 ms for the same frame without the index.
 - Lookups: a call site's encoding, hash and probe generated for its shape and the index's layout, buckets as records of hash, segment and key beside two-word slots of hash and bucket, and a row bound only when its archetype changed: `unique lookup 1M` 86 → 45–50 ns. A microbenchmark of the same probes over the same table reads 29 ns sequential and 85 random a lookup; an identity hash for integer keys is under "Tried and not kept". `children lookup` 32 ns a child, `grid neighbors 100K main` 10.5 µs a row of 27 probes.
 - Sorted ranges: a search over a compact array of each block's last key and entity, comparing words only for keys of words, and `at` walking blocks through a cursor: `sorted range 1M` 1.08 → 0.76 µs a range of ten; `sorted page 100K` 22 µs a change against 1.12 ms for `select page 100K`.
 - Kernels: probes in straight-line WASM over the index's arrays, `grid neighbors 100K workers` 179 ns a row across nine workers.
@@ -210,9 +301,11 @@ Step figures marked (vitest) are from the node vitest lane: read them as relativ
 **Main thread.** Row getters chosen once, and tuple reads and writes in one loop: 50 systems 3.2 → 1.63 ms (vitest).
 - Accessor rows each get their own prototype. Built from `{}`, every row after the first that defines an accessor with another getter went to V8 dictionary properties. One row per set of reads and writes, shared across systems and archetypes and rebound per pass, so a body sees one shape; f32-lane tuples read as array literals, and scalars and f32 lanes written directly. Resource cells in a context are resolved once per run. On node: 50 systems 1.1 → 0.45 ms, churn 55 → 32 ms, retag 74 → 59 ms; 50 distinct bodies over three row shapes 1.75 → 0.53 ms; two writing systems over 100K 19.5 → 1.9 ms; 20 systems reading a resource per row 1.26 → 0.22 ms.
 
+**f64 lanes for kernels computing at the body's precision.** A kernel compiled without `kernel: true` computes in f64, as its body does, so it can't use f32 lanes. Across rows it runs f64x2 lanes instead: each f32 pair loaded with `load64_zero` and promoted, each operation the f64 one, demoted only on store, so results are the body's bit for bit (`wasm.test.ts`, `precision.test.ts`). Medians of five, node, against one row at a time in f64 and against `kernel: true`'s f32 lanes: `move` 0.399 → 0.177 ms (f32 lanes 0.090), `chain` 6.48 → 3.70 ms (1.55), `move 10K` 16.2 → 7.7 µs (4.5). Filtered kernels and reductions run a row at a time in both, so `sparse changed` and `reduce` are unchanged; a padded vec3's elements aren't whole vectors, so it does too.
+
 ## GPU particles
 
-The sample (`pnpm sample`, which opens `/particles/`) draws the visible and enabled quarter of the perf particles as points, wrapping positions in the vertex shader, and moves them with the perf `move` kernel: on the GPU (`?mode=gpu`, positions never come back), on workers with the positions uploaded for drawing each frame (`?mode=cpu`), or not at all (`?mode=static`). Headless chromium on Apple silicon at 60 fps, 10 s per sample after warmup, CPU time per frame by process from `ps`, main-thread task time from the DevTools protocol. Four rounds at 1M (250K drawn), two at 4M (1M drawn):
+The sample (`pnpm dev`, the GPU Particles tab, or `/particles/` alone) draws the visible and enabled quarter of the perf particles as points, wrapping positions in the vertex shader, and moves them with the perf `move` kernel: on the GPU (`?mode=gpu`, positions never come back), on workers with the positions uploaded for drawing each frame (`?mode=cpu`), or not at all (`?mode=static`). Headless chromium on Apple silicon at 60 fps, 10 s per sample after warmup, CPU time per frame by process from `ps`, main-thread task time from the DevTools protocol. Four rounds at 1M (250K drawn), two at 4M (1M drawn):
 
 | Per frame, ms | draw only | CPU move + upload | GPU move |
 |---|---|---|---|
@@ -250,6 +343,22 @@ move, chromium, by worker count and entity count (a quarter of the entities move
 
 ## Tried and not kept
 
+- **Shared components' runs through one loop with `where`'s,** the run list a match list or `where`'s passing one: `run 50 idle` 68.3–69.2 → 75.8–79.2 ns a system, the run's closure grown past what V8 inlines. Kept: `where`'s loop apart from the plain one, which runs as before: 68.3–70.8. Worth revisiting if the two loops grow apart in what they do.
+- **A shared value read through its storage's layout on every row,** `layout.kind === "constant" ? layout.value : …`, so copies of rows across archetypes could hold values by row: `shared read 100K` 5.37 ns a row against 4.20 for `column read 100K`. Kept: the value bound into the row's slot once per archetype, 4.04–4.10, and snapshots and stop lists bound a run of one archetype's rows at a time, each archetype its own copy.
+- **Interning every shared value by its canonical text,** a tuple of numbers included: `spawn singles shared` 604 ns a spawn against 229 for `spawn singles plain`, the text built and the value checked against its schema for every spawner looked up. Kept: tuples of numbers found through a tree of their stored leaves, 313–323. Worth revisiting for structs and strings once a workload looks up spawners of them often.
+- **`where`'s predicates reading resources through a system's context,** each read copying a struct out: `where 1K cells moving` 25.9 ns a cell against 18.7–19.0 reading each once per evaluation.
+
+- **Checking every row and render body's return through a function call,** to fail a system whose body returned a
+  promise: `churn` 15.9 → 18.6–19.2 ns a row, a call per row. Kept instead: the call only for a body that returned
+  something, after an inline `!== undefined`, which measured the same as no check (`churn` 15.8–16.3 ns against
+  15.8–16.2). Worth revisiting only if bodies commonly return values.
+
+- **Lists made at runtime finding their shape through a `WeakMap` by list, or through a record of their own beside the
+  index property:** with `Archetype.create` gone, `spawn sixteen archetypes`, whose lists are built by `Array.from`,
+  took 9.8 ms and 6.9 ms against 3.96 with them indexed by hand; a microbenchmark gave 43 ns a lookup for the second
+  property against 5.4 for an index. The record now lives in the index property itself, 12 ns checked: 4.37 ms, the
+  rest the check of the list's keys that a list made at runtime needs, since it may change. Worth revisiting if a way
+  to know a runtime list is unchanged without reading its keys appears.
 - **Observer posts without allocating per post** (a reused list of chosen posts, no closure for posting, the block's cleared words a constant list, settling over reused scratch rather than a copy of the posts): `joined observer resource` 7.2–7.6 µs a tick against 6.4–8.3 without, `joined observer 10K` 0.52–0.69 ms against 0.51–0.76, within noise. Worth revisiting once posting shows in a profile of a world with many observer systems on joined threads.
 - **Observer factories: a count or selection with `where` tracked through an index without a key,** every row read through `at` and tested after any change: `count 1M changed factory` 23.2 ms; a sorted index on the `where` key, each entry looking up its range, takes 42 µs. Kept for selections with a page and no `order`, which stop at the page's end in entity order.
 - **Observer factories: descending pages finding each run of equal keys by galloping back from its last row,** three reads of most rows: `select page 100K factory` 23 µs a change; reading each row once, holding a run until its key changes, 16 µs.
@@ -285,6 +394,10 @@ move, chromium, by worker count and entity count (a quarter of the entities move
 - **Copying drained columns into fresh, exactly sized arrays:** planning 2.60 → 2.45 ms in chromium, but the copies cost more than that.
 - **The main thread claiming pieces too:** no gain; workers that wake late are slow at first, so the main thread does about what it would alone.
 - **A loop per main-thread system** (eval or emitted by the plugin): 5–10% on top of fast-property rows; a micro-benchmark of 50 systems with one loop literal each measured 16%. The tuple each `row[component]` read allocates stays, and it costs more than the shared call site. Worth revisiting with compiled main-thread bodies, where reads become column loads.
+- **A WASM kernel testing block starts in its one row loop,** a block's tick checked at each row that starts one, inside which a chunk's start checks the chunk's: `changed all 100K kernels` 504 → 576 µs, from a branch taken every 64 rows that the predictor misses, where the chunk test it replaced was taken every 1024. Checking blocks only at the eight-row SIMD checks, every eighth of them, still cost 7% in a microbenchmark of one kernel over 100K rows that all changed. The outer loop over runs of blocks takes it to 420 µs.
+- **Every run of passing blocks as its own run in WASM,** however many of a chunk's blocks pass: 1% of 100K rows changed, scattered, one filter, in a microbenchmark, 31 µs against 24 µs for chunks alone, since a run's end costs more than the eight-row checks spend on a block between two runs. Taking a chunk with more than half its blocks passing as one run measured 23.9 µs, more than a quarter 23.9 µs and more than three quarters 32 µs; one changed row 0.21–0.25 µs against 0.33 for chunks alone at each.
+- **Blocks of 32 rows:** against 64, eight systems finding one row of 100K 4.75 against 4.92 µs and ten rows 10.2 against 11.5 µs, but `sparse changed` 421 against 294 µs, a WASM kernel's chunk of 32 blocks with 1% of rows changed having fewer than half passing, so its many runs each pay their end; and twice the memory. Worth revisiting if one-row changes dominate real filters on main-thread systems and WASM finds runs another way.
+- **Several filters scanned filter by filter,** each array's next newer tick found in a loop of its own and the earliest taken, in a microbenchmark of three filters: one change of 10K rows 0.40 against 0.39 µs, 1% of 10K 32.3 against 28.8 µs, 100K rows with nothing changed 0.18 against 0.38 µs. Mixed, so the filters are tested together at each index. Worth revisiting if systems filtering on several components over large archetypes that rarely change show in a profile.
 - **Removing a sync point's rows after all its entries, each archetype's from the highest,** so every row that stays moves at most once: churn 1M +13%, retag +6%. Sorting, the map of rows and a second pass over scattered rows cost more than the copies saved, and copying cells is only about 12% of retag; planning, the system's body and per-entry work make up the rest. Worth revisiting only with column-major moves per pair of archetypes, where removals are batched too.
 - **Unrolled f32 lane writers for staged spawns:** create 1M −5% for 30 more lines. Profiles attribute the caller's tuple allocations to the writer, which inflates it. Worth revisiting if spawns stop allocating tuples.
 - **Faster value-object spawns** (`create flat dynamic`): `Object.keys` and the caller's own spreads dominate, on a path the plugin already avoids for literal keys. Worth revisiting only if spawns from data objects matter to real workloads.
@@ -337,20 +450,27 @@ move, chromium, by worker count and entity count (a quarter of the entities move
 - **Reading a patch's keys, hashes and buckets ahead in batches of 64,** so their misses overlap: `index refresh 1M 1%` 165 → 173 ns and `rekey 1M` 14.7 → 23.7 ms. A move in cache costs the same, so there was little latency to hide.
 - **A list's pool in three banks, its first, last and middle positions,** for hash lists too: `grid neighbors 100K main` 3.63 → 3.84 µs a row from choosing the bank in `at`. Only sorted lists keep a second pool for their last positions.
 - **Making a pool's rows for every position a list holds:** a 100K-row sorted list made 100K rows for a page of 20; rows are made ahead for the first and last 256 positions only.
+- **The tree's build linking parents over locals,** rather than through `link`: the opacity `up` 4.44–4.65 against 4.55–4.76 ms, about 2%, within noise.
+- **An index rebuild listing its entities in one loop over locals,** rather than a closure per entity: `index rebuild 1M main` 28.3–30 against 28.7–34.7 ms, and the editor's layout 2.33–2.84 against 2.35–2.56 ms, no gain.
+- **Binding a row without making a slot object per component:** the editor's paint 5.02–5.06 against 4.99–5.07 ms, no gain; V8 removes the allocation.
+- **Unsorted buckets sorted once their holes and tail passed a quarter of their entries,** rather than when full: `rekey 1M` 15.5 ms against 14.4, sorting buckets of 100 every few frames that nothing reads by position. A bucket at least 256 long before it's left unsorted, shorter ones shifted: 14.8 ms, no better. Merging a long tail an entry at a time rather than by a binary search and a move per tail entry: no measurable difference at `rekey 1M`, 15.4–16.7 ms against 15.4–15.8 then; worth revisiting where tails of thousands are sorted.
+- **Moves of 4-byte words over shared memory,** `copyWithin` on the entries' `Int32Array`: `bucket move 100K in order` 222 µs against 68 with 8-byte words; closing holes by scanning the whole bucket rather than stopping at the last, 245 µs.
+- **Presizing a hash index's table for a rebuild,** measured rather than tried: the editor's 601 parents rehash and place their buckets in 0.2 of 34 ms of profile, since a table is sized for the buckets it last held. Worth revisiting for a first build of an index with as many keys as entities.
+- **Rebuilding an `up` tree from scratch for a large journal range,** rather than patching it: `editor load tick 50K` 20.3 against 20.8 ms, within noise, since building and patching both cost about 30 ns an entity. Worth revisiting if patching gets dearer per entity than a build.
 
 ## Next
 
 - `grid neighbors 100K main`, 3.66 µs a row against about 1.6 µs for the kernel on one worker: each neighbor costs about 10 ns in loads of the list's state, the pool and the row's slots; rows whose values carry their index and views as their own fields would save a few of them.
 - Index refreshes, 141 ns a moved entity: two ordered bucket edits and a probe, in cache.
+- `editor load tick 50K`, 18 ms: the shared tree's build and its order's take about 1.5 ms each, 30 ns an entity, spread over linking, settling levels and grouping; the `up` bodies through accessor rows take about 2 ms a system, the 50K ordered paint rows about 2 ms, and each index's rebuild about 1.5 ms, 28 ns an entity listing and encoding its key.
 
 - `loop tick add remove`, a new system each tick: about 2 µs more a tick since indexes (above), in `System.create` and `add`, as more garbage; the paths a run of an existing system takes measure as before.
 - Index rebuilds across the pool: `index rebuild 1M workers` 6.7 ms, nine workers 4.3× one, every phase scattering or gathering by partition; an estimated 2–3 ms if the scatters reached memory bandwidth. Rebuilds are rare, a refresh moving more than an eighth of an index.
 - Single-tier runs on workers: workers asleep at the start of a run take 60–135 µs to see the task, and 2–4 of 9 find nothing left to claim.
 - Idle cores clock down: after 5 ms idle, even the main thread runs move 2–4× slower per frame, and keeping one other core busy removes most of it, at 10M too. That's the OS's power policy, not something dispatch can avoid without spending power.
 - Emit and other command-heavy kernels: the sync point dominates.
-- Kernels taking `%` of an f64: a conditional on `resources[clock].tick % 2` costs about 33 ns a row in node, 10K rows 333 µs against 8.5 µs without it.
 - Replaying the move log: `log replay` takes 24 ns a move in node and 36.5 ns in chromium, two entries each, against about 1 ns to move the bytes; the cost is the per-entry dispatch and the scattered rows a swap reads.
 - Ordered selections recomputed every tick: `joined observer 10K` spends most of its 0.4–0.5 ms a tick sorting 10K entities.
-- `joined observer 10K`, back to back: lookups read the rows in place, so the world's writer waits for each run the thread claimed, about 1.07 ms, in 1,451 of 3,000 ticks; the thread's run is about 60% the benchmark's own sort, and of the rest `at` through the index without a key (14%) and a load of the archetype's version per row (12%), which a check of versions once a post would save.
+- `joined observer 10K`, back to back: lookups read the rows in place, so the world's writer waits for each run the thread claimed, about 1.07 ms, in 1,451 of 3,000 ticks; the thread's run is mostly the benchmark's own sort, and of the rest `at` through the index without a key.
 - A tail's body reading from a snapshot ran slower in one case: a loop counted down from an unbounded integer resource (an f64) took 13.6 ms against 11.2 in place over 10,000 rows of 200 steps, in node, while counted as an i32 it took 10.8 against 11.2; deopts didn't account for it.
 - Main-thread spawns reserving in blocks too: `spawn bulk` still takes one atomic add per spawn. Finalizers spawn during the sync point, after it materializes the run's reservations, so a world's block would have to end before each materialization.

package/src/implementation/world/plan.ts

@@ -1,3 +1,4 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
 /**
  * A sync point's plan: each touched entity's net change, as reusable parallel arrays rather than an object per entity.
  * `to` is where it ends up; its values are command ranges, applied in issue order so later values win. Each world has

package/src/implementation/world/platforms.test-helper.ts

@@ -1,3 +1,4 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
 /// <reference types="node" />
 import type { ToWorker } from './protocol.js';
 import { browserPort, nodePort, platformWorkers, type WorkerPlatform, type WorkerPort } from './worker-platform.js';

package/src/implementation/world/pool-size.cases.ts

@@ -1,3 +1,4 @@
+// © 2026 Adobe. MIT License. See /LICENSE for details.
 import { describe, expect, it } from "vitest";
 import type * as Fixture from "./pool-size.fixture.js";
 
@@ -11,7 +12,26 @@ export const poolSizeCases = (load: () => Promise<typeof Fixture>) => describe("
     });
     it("honors a number, and null again gives the platform's choice", async () => {
         const fixture = await load();
-        expect((await fixture.resized(1, [null])).started).toEqual([1, 1 + fixture.platformCount()]);
+        // The platform's choice starts a pool of its own unless it's the size the pool already is.
+        const platform = fixture.platformCount();
+        expect((await fixture.resized(1, [null])).started).toEqual([1, platform === 1 ? 1 : 1 + platform]);
+    });
+    it("starts the pool only once a kernel has rows enough for workers", async () => {
+        const fixture = await load();
+        const { started, values } = await fixture.whenWarranted();
+        expect(started).toEqual([0, fixture.platformCount()]);
+        expect(values).toEqual([0, 4, 8, 12]);
+    });
+    it("starts no pool for rows no kernel runs over", async () => {
+        expect(await (await load()).unmatched()).toBe(0);
+    });
+    it("reports a kernel that fails to load on workers as the pool starts, and runs it here from then on", async () => {
+        const fixture = await load();
+        const { failures, loads, values } = await fixture.failedLoad();
+        expect(failures[0]).toEqual([expect.stringMatching(/^The kernel pool's workers failed: .*no kernel here/)]);
+        expect(failures[1]).toEqual([]);
+        expect(loads[1]).toBe(loads[0]);
+        expect(values).toEqual([0, 4, 8, 12]);
     });
     it("sizes the kernel pool at the next sync point, with the same results", async () => {
         const fixture = await load();