@adobe/data-ai 0.9.84 → 0.9.87

package/skills/build-systems/SKILL.md

@@ -5,6 +5,9 @@ input: feature
 output: feature
 ---
 
+Skip if this feature doesn't contain or require systems.
+Most games that use a canvas will use systems but most applications will not.
+
 Create `ecs/system-database/system-database.ts`: `Database.Plugin.create({ extends:
 Database.Plugin.combine(ComputedDatabase.plugin, scheduler), systems })` where the `systems`
 map is declared **inline** (see `features/ecs/systems.md` — inline is required for `db` to be
@@ -14,9 +17,6 @@ per-frame body helpers).
 - A system is a `SystemDeclaration`: `{ create, schedule?: { before?, after?, during? } }`.
   `create(db)` runs once (capture queries / index handles / closures); the returned function
   advances the world one tick. Return `void` for an init-only system (seeding entities).
-- The step math lives in `data/`; each system reads store rows, calls the pure `data/` step,
-  writes back — via `db.store` (writable) for hot per-row work, or `db.transactions.*` for
-  discrete events. Iterate archetypes per `archetypes.md` (tail→head when destroying rows).
 - Order under `schedule` (mirror the `data/` step's internal sequence); drive the loop by
   combining `scheduler` (rAF), gated by the `schedulerState` resource.
 

package/skills/graph-execute/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: graph-execute
+description: executes a graph of steps
+input: piped function calls
+---
+
+The input is a set of piped function calls where each call is represented by a slash skill invocation.
+
+Each step must be completed independently before moving on to the next.
+
+The output of each phase is generally either a returned result or written to the file system. You can pass some context including any previous result to the next phase, but you must never read the subsequent phases in advance.
+
+Call each of these phases in a subagent so that they are not even aware that future phases will take place.

package/.claude/rules/archetypes.md

@@ -1,60 +0,0 @@
----
-description: Authoring rules for ECS systems that iterate archetype rows.
-globs: "**/*.ts"
----
-
-# Archetypes — iteration rules
-
-## Express selection in the query, not the loop
-
-`queryArchetypes(include, { exclude })` accepts both required and excluded
-component lists. Use them. Don't query a wider set and then skip rows or
-archetypes with an `if`.
-
-```ts
-// ❌ post-filter
-for (const arch of db.store.queryArchetypes(["position", "rotation"])) {
-    if (arch.components.has("_worldMatrix")) continue;
-    ...
-}
-
-// ✅ declarative
-for (const arch of db.store.queryArchetypes(
-    ["position", "rotation"],
-    { exclude: ["_worldMatrix"] },
-)) {
-    ...
-}
-```
-
-## When every row migrates out, iterate tail → head
-
-Archetypes are densely packed. Removing or migrating a row that isn't the
-last one triggers a hole-fill: the tail row is moved into the gap.
-Iterating `0 → rowCount-1` while migrating every row pays this cost on
-every iteration. Iterating `rowCount-1 → 0` means each removal is from
-the tail — no shift, indices ahead of the cursor stay valid.
-
-```ts
-// ❌ shifts the tail into every hole, and the snapshot allocation is
-//    only there to survive the shifts.
-const ids = [...];
-for (let i = 0; i < arch.rowCount; i++) ids[i] = arch.columns.id.get(i);
-for (const id of ids) db.store.update(id, { _worldMatrix: Mat4x4.identity });
-
-// ✅ no shifts, no allocation
-for (let i = arch.rowCount - 1; i >= 0; i--) {
-    db.store.update(arch.columns.id.get(i), { _worldMatrix: Mat4x4.identity });
-}
-```
-
-If only *some* rows migrate (filter inside the loop), snapshot the ids
-you'll touch — forward iteration is fine because rows you don't touch
-stay put.
-
-## Don't snapshot what the query already filters
-
-A snapshot of "all entity ids in this archetype right now" is only
-needed when forward iteration would invalidate. Reverse iteration
-removes the need; an `exclude` clause removes the need to look at rows
-that don't qualify in the first place.