@adobe/data-ai 0.10.32 → 0.10.34

package/.claude/rules/README.md

@@ -13,13 +13,13 @@ holds just enough to understand that folder; each child gets its own file:
 
 ```
 global/               # always-on conventions — deliberately repo-wide globs
-  namespace.md  cohesion.md  type-casts.md  function-references.md  react.md
+  typespace.md  cohesion.md  type-casts.md  function-references.md  react.md
 features/
   index.md            # the layering as a whole: data → services → spec | ecs → ui → app
   data/
     index.md          # pure Data declarations
     values.md  components.md  resources.md  entities.md
-  services/index.md   # service namespaces: interface, create, createFake
+  services/index.md   # service TypeSpaces: interface, create, createFake
   spec/index.md       # the State spec: actions, derivations, cases (test tier)
   ecs/
     index.md          # the layered database plugins + MainService

package/.claude/rules/data-modelling.md

@@ -19,7 +19,7 @@ discriminated unions.
 // types/http-method/http-method.ts — the hand-authored type owns the member identity
 export type HttpMethod = "GET" | "POST" | "PUT" | "DELETE";
 // (a schema.ts, if/when a runtime boundary needs one, is written to match this
-//  type and pinned to it — see global/namespace.md and features/data/index.md)
+//  type and pinned to it — see global/typespace.md and features/data/index.md)
 
 // In an unrelated request-counter plugin:
 

package/.claude/rules/ecs.md

@@ -100,7 +100,7 @@ const particleDataPlugin = Database.Plugin.create({
 });
 ```
 
-- **Components**: per-entity data. Use schema imports (`Vec3`, `Vec4`, `F32` from `@adobe/data/math`) or type namespaces for custom shapes.
+- **Components**: per-entity data. Use schema imports (`Vec3`, `Vec4`, `F32` from `@adobe/data/math`) or TypeSpaces for custom shapes.
 - **Resources**: global state. Every resource carries a `default` (`{ ...Boolean.schema }`, or `{ default: 'dark' as ThemeColor }` to widen a literal).
 - **Archetypes**: one per entity kind. List all components that kind requires.
 

package/.claude/rules/features/data/values.md

@@ -5,7 +5,7 @@ paths:
 
 # data/values/ — Data types and pure helpers
 
-Each Data type is its own namespace folder (`global/namespace.md`): its hand-written
+Each Data type is its own TypeSpace folder (`global/typespace.md`): its hand-written
 type, its schema pinned to it, and its pure synchronous helpers.
 
 ```
@@ -30,7 +30,7 @@ data/values/player-mark/
   the wire. A type used only by the spec may have none.
 - **Helpers are synchronous and pure**, each with a sibling `*.test.ts`. They are the
   home for logic the spec and the ECS share.
-- **A helper-only namespace** (`motion`, `collision`) with no type of its own also
+- **A helper-only TypeSpace** (`motion`, `collision`) with no type of its own also
   lives here.
 - Objects of only 32-bit numeric values or sub-structs use
   `Schema.fromStructProperties` (linear-memory storage).

package/.claude/rules/features/services/index.md

@@ -8,7 +8,7 @@ paths:
 > **Legacy feature** (has `data/state/` or `services/main-service/`)? Follow `services/main-service/` instead.
 
 A service is the boundary between the feature and the outside world (generation,
-analytics, networking). Each is a namespace folder (`global/namespace.md`) holding its
+analytics, networking). Each is a TypeSpace folder (`global/typespace.md`) holding its
 interface, its implementation and a fake. Services depend only on `data/`.
 
 ```

package/.claude/rules/features/services/main-service/core-database.md

@@ -9,8 +9,8 @@ paths:
 
 A thin assembler: `Database.Plugin.create({ components?, resources?, archetypes? })`
 over the facet files, exposed through the `CoreDatabase` namespace. This is the
-single-file namespace form (one value export — `plugin` — everything else a type;
-see `global/namespace.md`).
+single-file TypeSpace form (one value export — `plugin` — everything else a type;
+see `global/typespace.md`).
 
 ```ts
 import { Database, type Store } from "@adobe/data/ecs";

package/.claude/rules/features/services/main-service/index.md

@@ -96,7 +96,7 @@ drift-guard (see `archetypes.md`).
 ## Layered composition (behaviour)
 
 Above the schema, behaviour is a chain of `Database.Plugin`s, each its own
-**namespace folder** — `<layer>-database/` holding the eponymous
+**TypeSpace folder** — `<layer>-database/` holding the eponymous
 `<layer>-database.ts` (the plugin, which `extends` the previous layer) plus the
 facet folder it adds. **Name each layer for the facet it adds — never for the
 feature or app.** A feature creates only the layers it uses:
@@ -128,7 +128,7 @@ export namespace IndexDatabase {
 computed / action / system). Consumers — `ui/`, the app entry, `services/main-service/conformance/`
 — need the *whole* feature database but must not name that layer, or adding or
 dropping a layer rewrites them all. Alias it once from the **folder-eponymous
-`main-service.ts`** (per `global/namespace.md`, a folder's primary export lives in
+`main-service.ts`** (per `global/typespace.md`, a folder's primary export lives in
 its same-named file), as a namespace so consumers reach `MainService.plugin` /
 `MainService.Store`:
 

package/.claude/rules/global/{namespace.md → typespace.md}

@@ -3,9 +3,13 @@ paths:
   - '**/*.ts'
 ---
 
-# Type namespace pattern
+# TypeSpace pattern
 
-Single import surface per type: `<type-name>/<type-name>.ts`. Schema in `-schema.ts`, namespace re-export from `public.js`. Types live in
+**TypeSpace** = a type plus its functions, schema and constants, exposed under one name. The type and the namespace-like value share
+the name (`Point` is the type, `Point.add` is a function), implemented with `export * as <Name> from './public.js'`. It is **not** a
+TypeScript `namespace` declaration, and not a generic grouping of code.
+
+Single import surface per type: `<type-name>/<type-name>.ts`. Schema in `-schema.ts`, TypeSpace re-export from `public.js`. Types live in
 the `types/` layer. **In a feature**, Data types live in `features/<name>/data/values/<type>/` with the schema in `schema.ts`
 (`features/data/values.md`).
 
@@ -37,18 +41,18 @@ patterns (e.g., inline `export namespace` in shared files) that do not conform
   `schema.ts` inside the folder), named `schema` (not `<type-name>Schema`), and is **written to match the hand-authored type and pinned
   to it** with `Assert<Equal<Schema.ToType<typeof schema>, <TypeName>>>` — never the other way around. `Schema.ToType` appears only in
   that assertion, never as the exported type.
-- Export namespace: `export * as <type-name> from "./public.js"`
+- Export the TypeSpace: `export * as <type-name> from "./public.js"`
 - In public.ts, re-export every public constant file
 - Filenames map deterministically to single export:
   - `foo.ts` → `export type Foo = ...`
   - `do-bar.ts` → `export function doBar() { }`
   - DO NOT append other suffixes like `-type` etc.
-- Function files: name by purpose only (e.g., `add.ts`, `sub.ts`). **Do not prefix** with the type name — the folder provides the namespace
+- Function files: name by purpose only (e.g., `add.ts`, `sub.ts`). **Do not prefix** with the type name — the folder provides the TypeSpace
   context.
 
 ## Constants file
 
-Constants are the **one exception** to one-declaration-per-file. A namespace folder MAY have a single `constants.ts` exporting several
+Constants are the **one exception** to one-declaration-per-file. A TypeSpace folder MAY have a single `constants.ts` exporting several
 plain `const` literals (no functions, no types), re-exported through `public.ts` so callers reach them as `<TypeName>.<constant>`:
 
 ```ts
@@ -68,17 +72,19 @@ literal, it is a function and does not belong in `constants.ts`.
 
 ## Anti-patterns (do not copy)
 
-- **`export namespace <TypeName> { ... }`** — Use `export * as <TypeName> from "./public.js"` instead.
+- **`export namespace <TypeName> { ... }` containing values** — Use `export * as <TypeName> from "./public.js"` instead; the standard pattern keeps
+  every member tree-shakeable and an inline namespace does not. An inline namespace that contains **only types** is allowed (it has no runtime
+  existence).
 - **Prefixing function files with the type name** (e.g., `vec2-add.ts`) — Use `add.ts`; the folder provides context.
 - **Importing from `public.js` or `-schema.js`** outside the type folder — Consumers must import only from `<type-name>/<type-name>.ts`.
-- **A generic `functions/` folder for helpers** — a helper lives on the namespace of the type it most closely relates to (or, for a single caller, as a private declaration in that caller); never a typeless `functions/` bucket.
+- **A generic `functions/` folder for helpers** — a helper lives on the TypeSpace of the type it most closely relates to (or, for a single caller, as a private declaration in that caller); never a typeless `functions/` bucket.
 
 ## Consumers
 
 **Never:**
 
-- Import from `public.js` outside the type namespace folder
-- Import from `<type-name>-schema.js` outside the type namespace folder
+- Import from `public.js` outside the TypeSpace folder
+- Import from `<type-name>-schema.js` outside the TypeSpace folder
 
 **Do:**
 
@@ -117,7 +123,7 @@ export const length = ({ x, y }: Point) => Math.hypot(x, y);
 export const add = ({ x: x1, y: y1 }: Point, { x: x2, y: y2 }: Point): Point => ({ x: x1 + x2, y: y1 + y2 });
 ```
 
-After applying the namespace pattern:
+After applying the TypeSpace pattern:
 
 ```ts
 // src/types/point/point.ts
@@ -140,14 +146,14 @@ export const add = ({ x: x1, y: y1 }: Point, { x: x2, y: y2 }: Point): Point =>
 1. **Follow this rule** — Do not copy patterns from existing code; apply this standard.
 2. Identify constants in the current file.
 3. Extract them into the standard pattern.
-4. Identify all consumers of public namespaces.
+4. Identify all consumers of public TypeSpaces.
 5. Check each consumer: ensure imports use `<type-name>.ts` only, never public.js or -schema.js.
 6. Ensure unit tests exist per function file, splitting as needed.
 
 ## Single file pattern
 
 This pattern is ONLY allowed if there is only a single value export and every other export is just a type.
-As soon as there is more than one value type it MUST be promoted to the full namespace pattern.
+As soon as there is more than one value type it MUST be promoted to the full TypeSpace pattern.
 
 Example — a type merged with one value export and any number of type-only members:
 

package/.claude/rules/plugin-modelling.md

@@ -40,7 +40,7 @@ codebase grep, and "find all plugins" tooling match `**/*-plugin.ts`
 without inspecting contents.
 
 The exported constant's name depends on whether the folder also hosts a
-type namespace:
+TypeSpace:
 
 - **Pure-plugin folder** (no owned type) → export the concept name
   itself, lowercase. `node-plugin.ts` exports `node`. Import sites read

package/.claude/rules/service.md

@@ -8,7 +8,7 @@ paths:
 
 > Inside a feature, `features/services/index.md` covers the service layer; database-bound factories in `ecs/services/` follow `features/ecs/services.md`.
 
-Asynchronous data services. Live in the `services/` layer. Adhere to the namespace rule for type and function organization.
+Asynchronous data services. Live in the `services/` layer. Adhere to the TypeSpace rule for type and function organization.
 
 **Data** = readonly JSON values, `ReadonlySet`, `ReadonlyMap`, or Blobs.
 

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "adobe-data-ai",
-  "version": "0.10.32",
+  "version": "0.10.34",
   "description": "Architecture skills for @adobe/data — data-oriented modelling, archetype iteration, hot-path performance, and related conventions.",
   "author": {
     "name": "Adobe"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adobe/data-ai",
-  "version": "0.10.32",
+  "version": "0.10.34",
   "description": "Cross-agent architecture skills for @adobe/data — installable as a Claude Code plugin or copied into any Agent-Skills-compatible agent (Cursor, Codex).",
   "type": "module",
   "private": false,
@@ -29,13 +29,13 @@
     "skills"
   ],
   "peerDependencies": {
-    "@adobe/data": "0.10.32"
+    "@adobe/data": "0.10.34"
   },
   "devDependencies": {
     "typescript": "^5.8.3",
     "vitest": "^5.0.5",
     "yaml": "^2.9.1",
-    "@adobe/data": "0.10.32"
+    "@adobe/data": "0.10.34"
   },
   "license": "MIT",
   "scripts": {

package/skills/build-data/SKILL.md

@@ -10,7 +10,7 @@ Legacy feature (has `data/state/` or `services/main-service/`)? Extend it in pla
 Create the feature's `data/` layer: pure Data declarations, depending only on
 `@adobe/data` and the `data/` of features this one builds on.
 
-- `values/<type>/` — one namespace per Data type: a hand-written type, a schema pinned
+- `values/<type>/` — one TypeSpace per Data type: a hand-written type, a schema pinned
   to it (`type _Pin = Assert<Equal<Schema.ToType<typeof schema>, <Type>>>`) when
   something needs one, and pure helpers, each with a test.
 - `components/<name>.ts` — one schema per file, scope spread from `Scope`, plus an
@@ -22,4 +22,4 @@ Create the feature's `data/` layer: pure Data declarations, depending only on
 Create only the folders the feature needs. Gate: it compiles and the helper tests
 pass.
 
-The how is in the auto-loading `features/data/` rules and `global/namespace.md`.
+The how is in the auto-loading `features/data/` rules and `global/typespace.md`.

package/skills/build-services/SKILL.md

@@ -9,7 +9,7 @@ Legacy feature (has `data/state/` or `services/main-service/`)? Extend it in pla
 
 Skip if the feature talks to nothing outside itself.
 
-Create one `services/<name>-service/` namespace per service: the interface (an async
+Create one `services/<name>-service/` TypeSpace per service: the interface (an async
 data service, validated with `AsyncDataService.IsValid`), `create` (the
 implementation, or a factory that throws when the app must inject it),
 `createFake`, and `public.ts`. Add `services/services.ts` with the `Services` map when

package/skills/review/SKILL.md

@@ -9,7 +9,7 @@ output: a review — OPTIMAL, or a list of issues each tagged code | skill | rul
 Check a legacy feature (has `data/state/` or `services/main-service/`) against the legacy rules; don't flag the layout itself.
 
 Read the files under the given path and assess them against the relevant `features/`
-rules (each layer's rule and the cross-cutting rules — `namespace`, `data-modelling`,
+rules (each layer's rule and the cross-cutting rules — `typespace`, `data-modelling`,
 `type-casts`, `cohesion`, …):
 
 - **Correctness** — does it typecheck and follow the layer's required shape?