updated skills

plugins/document-navigator/docs/gaming/games/ecs/README.md

@@ -88,4 +88,3 @@ bun run docs:check --filter=@suaveplan/ecs
 ## License
 
 MIT © Suaveplan Team
-

plugins/document-navigator/docs/gaming/games/ecs/src/observability/otel.md

@@ -58,7 +58,7 @@ const snapshots = await /* meterProvider */;
 
 ## Implementation Notes
 
-- The meter is resolved at module load via `metrics.getMeter("@suaveplan/ecs")`. The OTel API guarantees a stable meter reference: when a real SDK is later registered, *previously created* instruments continue to emit through the new provider. This is the documented "no-op-then-bind" pattern.
+- The meter is resolved at module load via `metrics.getMeter("@suaveplan/ecs")`. The OTel API guarantees a stable meter reference: when a real SDK is later registered, _previously created_ instruments continue to emit through the new provider. This is the documented "no-op-then-bind" pattern.
 - The histogram unit is `"ms"`, matching `performance.now()`. The world records the wall-clock difference between the start and end of `execute(dt)`.
 - Counter attributes are keyed by `op`, not by code-path, so dashboards can sum spawn + despawn as a single series or split per-op trivially.
 - Tests should reset the in-memory exporter between cases (`testInMemoryMetricExporter.reset()`) to avoid cross-test bleed; the package's `world.spec-conformance.test.ts` does this in an `afterEach` hook.

plugins/document-navigator/docs/gaming/games/ecs/src/schema/schema.md

@@ -13,7 +13,7 @@ The optional Zod validator opts the descriptor into runtime validation: `World.a
 ## Features
 
 - Deep-freeze on the descriptor and its `defaults` — strict-mode mutation throws.
-- Defaults are *copied* on construction, so caller mutations after `defineComponent` don't leak into the descriptor.
+- Defaults are _copied_ on construction, so caller mutations after `defineComponent` don't leak into the descriptor.
 - Optional `schema?: z.ZodType<T>` validator threaded through to the world's validation step.
 - specific addition over upstream's `defineComponent` — upstream lacked the Zod hook.
 
@@ -61,5 +61,5 @@ world.addComponent(entity, Health, { current: -1, max: 100 });
 
 - The defaults clone is shallow (`{ ...defaults }`). For nested mutable references, callers should freeze deeply themselves before passing in. The component schema is identity-stable, but interior mutability of a passed reference is out of scope.
 - The schema property is added conditionally (omitted from the object when not supplied) so JSON serialisation of a descriptor produces a clean two-key shape when no validator is supplied.
-- Validation is *not* applied at registration — only at component-add / component-set boundaries. This keeps the registry decoupled from Zod and means a schema can be retrofitted onto an existing component without rewiring registration.
+- Validation is _not_ applied at registration — only at component-add / component-set boundaries. This keeps the registry decoupled from Zod and means a schema can be retrofitted onto an existing component without rewiring registration.
 - The factory does not generate IDs; the registry assigns those on first registration via `World.registerComponent` or implicitly during `addComponent`.

plugins/document-navigator/docs/gaming/games/ecs/src/system/system.md

@@ -6,7 +6,7 @@ _(no submodules)_
 
 ## Purpose
 
-A *system* is the unit of behaviour in an ECS — a function that runs over every entity matching a query and mutates component state. `defineSystem` is the factory that fills in sensible defaults (`phase: "update"`, `priority: 0`, `enabled: true`) and produces a frozen `SystemDefinition`. `SystemScheduler` is the world's internal sorted registry: it orders systems by phase then priority, lazily resorting only when the set changes.
+A _system_ is the unit of behaviour in an ECS — a function that runs over every entity matching a query and mutates component state. `defineSystem` is the factory that fills in sensible defaults (`phase: "update"`, `priority: 0`, `enabled: true`) and produces a frozen `SystemDefinition`. `SystemScheduler` is the world's internal sorted registry: it orders systems by phase then priority, lazily resorting only when the set changes.
 
 Phase ordering is fixed at `preUpdate → update → postUpdate → render`, mirroring the canonical game-loop pipeline. Priority breaks ties within a phase, lowest first.