@cynodia/axiom 0.11.0-alpha.1 → 0.11.2-alpha.1

package/README.md

@@ -33,7 +33,7 @@ Shorter forms of the same routing: [`AGENTS.md`](AGENTS.md) and [`llms.txt`](llm
 at this package's root.
 
 **Status: experimental / alpha.** The API may change between alpha releases. The
-documentation in `docs/` describes this exact version, `0.11.0-alpha.1`.
+documentation in `docs/` describes this exact version, `0.11.2-alpha.1`.
 
 ## Installation
 
@@ -47,7 +47,7 @@ Every release of this project is a pre-release and npm's `latest` tag points at
 plain command above installs the current version. **There is no `alpha` dist-tag** — the tag
 was removed once it stopped tracking releases, and `npm install @cynodia/axiom@alpha` now
 fails with a 404. Pin the exact version instead when one is needed:
-`npm install @cynodia/axiom@0.11.0-alpha.1`.
+`npm install @cynodia/axiom@0.11.2-alpha.1`.
 
 These are ES modules compiled to ES2022; import them with `import`, not `require`. There is
 no published Axiom CLI. `@cynodia/axiom-server`'s SQLite persistence adapter additionally
@@ -70,7 +70,7 @@ reports its absence rather than failing at import.
 | `Theme` | Translation of presentation intent into visual design. |
 | Renderer | Platform-specific materialization. Not part of the graph. |
 | `StateDef.authority` | Who may commit a value: the client, or the server. The one declaration the split follows from. |
-| `ServerIR` | The half an authority executes. Portable JSON, frozen as `axiom.server.v1`. |
+| `ServerIR` | The half an authority executes. Portable JSON. `axiom.server.v1` is frozen; the current contract is `axiom.server.v7`, computed from the document's vocabulary. |
 | Semantic protocol | What a client may ask for: named actions with arguments, never mutation programs. |
 | `PersistenceAdapter` | Where a decided value survives. Not part of the semantics. |
 

package/docs/ACTIONS_TRANSACTIONS.md

@@ -1,6 +1,6 @@
 # Actions and transactions
 
-Axiom 0.11.0-alpha.1. An action is behavior expressed as data, executed as a transaction.
+Axiom 0.11.2-alpha.1. An action is behavior expressed as data, executed as a transaction.
 
 ```ts
 {

package/docs/AGENT_API.md

@@ -1,6 +1,6 @@
 # Agent API
 
-Axiom 0.11.0-alpha.1. The machine-facing interface. Agents query semantics and apply
+Axiom 0.11.2-alpha.1. The machine-facing interface. Agents query semantics and apply
 structural transformations; they never edit generated code.
 
 ```ts

package/docs/AGENT_REFERENCE.md

@@ -1,6 +1,6 @@
 # Agent reference
 
-Axiom 0.11.0-alpha.1. Compressed operational contract. Read this plus the `.d.ts`
+Axiom 0.11.2-alpha.1. Compressed operational contract. Read this plus the `.d.ts`
 declarations before authoring or modifying an Axiom application.
 
 Formal guarantees: [`SEMANTIC_CONTRACT.md`](SEMANTIC_CONTRACT.md). Mistakes that compile:
@@ -65,7 +65,7 @@ One canonical term per concept. These are not interchangeable.
 ## Graph construction
 
 ```ts
-const graph = new ApplicationGraph(id, name);      // version defaults to '0.11.0'
+const graph = new ApplicationGraph(id, name);      // version defaults to '0.11.2'
 graph.addNode<StateDef>({ id, kind: 'state', ... }); // returns NodeId; throws if id exists
 graph.getNode<StateDef>(id);                        // deep clone, or undefined
 graph.updateNode(node);                             // write a modified node back
@@ -603,7 +603,7 @@ authoring an application that crosses the trust boundary.
 10. **FORM SUBMIT** — a declared submit button invokes with its own arguments, clicked or submitted.
 11. **IDEMPOTENCY** — a generated request id is unique across runtime instances; records are scoped by principal.
 12. **CHANGES** — `changes` names every observable state whose value moved, and no others.
-13. **PORTABILITY** — `axiom.server.v1` is frozen and language-independent.
+13. **PORTABILITY** — `axiom.server.v1` is frozen and language-independent. It is not the *current* contract: a document declares the oldest contract that carries its vocabulary; `axiom.server.v7` is current (migrations, schema identity).
 14. **INTEGRATION** — external systems are accessed through typed integration operations.
 15. **QUERY** — an external query is explicit action/trigger execution, never a pure `Expression`.
 16. **EFFECT** — external effects are not rollback-capable state mutations.
@@ -947,8 +947,12 @@ Providers: `createMemoryRowStore` + `createMemoryMigrationStore` (deterministic
 `runMigrationConformanceFixture` over the `axiom.conformance.v5` fixtures in
 `conformance/migrations/`.
 
-CLI (private): `axiom schema status` / `schema diff --against=<prev>` / `migrate plan
---from=N` / `migrate --sqlite=<path> --approve=op,op` / `migrate status --sqlite=<path>`.
+There is **no published Axiom CLI**. Every schema/migration operation is a public library
+function — `inspectSchema`, `diffSchema`, `explainSchemaDiff`, `migrationImpact` (from
+`@cynodia/axiom-agent-api`); `planMigration`, `explainMigration`, `executeMigration`,
+`getMigrationStatus` (from `@cynodia/axiom-server`). A host builds its own command around
+them. (The Axiom repository has a private, unpublished CLI over the same functions for
+maintainer use.)
 
 Diagnostics: `SCHEMA_MIGRATION_REQUIRED` `SCHEMA_INCOMPATIBLE` `MIGRATION_IN_PROGRESS`
 `MIGRATION_STATE_CORRUPTED` `MIGRATION_PATH_NOT_FOUND` `MIGRATION_APPROVAL_REQUIRED`

package/docs/ANTI_PATTERNS.md

@@ -1,6 +1,6 @@
 # Anti-patterns
 
-Axiom 0.11.0-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
+Axiom 0.11.2-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
 alternative.
 
 ## 1. Field names as entity runtime keys
@@ -631,7 +631,7 @@ is never "the operator approved data loss."
 if (pkg.version === persisted.axiomVersion) startNormally();
 ```
 
-`@cynodia/axiom` `0.11.0`, `axiom.server.v7`, and `graph.schemaVersion` `14` are unrelated.
+`@cynodia/axiom` `0.11.2`, `axiom.server.v7`, and `graph.schemaVersion` `14` are unrelated.
 Compare `schemaFingerprint(graph)` and `graph.schemaVersion` against what the provider
 durably recorded — which is exactly what the startup gate does.
 

package/docs/AUTHORITY.md

@@ -1,6 +1,6 @@
 # Authority
 
-Axiom 0.11.0-alpha.1. How an application crosses the trust boundary.
+Axiom 0.11.2-alpha.1. How an application crosses the trust boundary.
 
 Until 0.5.x an Axiom application executed locally. 0.6 adds an **authority**: a generic
 runtime that owns state, decides mutations and persists them. The same semantic graph
@@ -509,8 +509,10 @@ does for a local failure.
 | `MIGRATION_VALIDATION_FAILED` | Post-migration validation found persisted data that does not satisfy the target semantic schema (spec11 §37). |
 | `MIGRATION_CHECKPOINT_INVALID` | A resume was attempted from a checkpoint that does not match the current plan or schema fingerprint. |
 | `MIGRATION_FINGERPRINT_MISMATCH` | The persisted schema fingerprint does not match the origin of the resolved migration path — the stored data is not the shape the chain expects. |
-| `MIGRATION_NOT_AUTHORIZED` | The caller is not the host-controlled migration principal. Naming a migration id over the client protocol does nothing (spec11 §73, §74). |
+| `MIGRATION_NOT_AUTHORIZED` | The caller is not the host-minted migration capability. Naming a migration id over the client protocol does nothing; an object built with the capability's visible fields (or a spread copy of a real one) is rejected — authorization is by provenance, not shape (spec11 §73-74, spec11.1 §15-17). |
 | `MIGRATION_FAILED` | A migration failed for a reason with no more specific code; the target schema version was not committed and the recovery state is defined. |
+| `SCHEMA_IDENTITY_REQUIRED` | The provider's persisted metadata declares a semantic schema version, but the application graph declares none — so compatibility cannot be established. The gate fails closed rather than assuming the unversioned graph is safely compatible with schema 1 (spec11.1 §7). |
+| `SCHEMA_METADATA_REQUIRED` | The application graph declares semantic schema evolution (a `schemaVersion` past 1, or any `MigrationDef`), but `createAxiomServer` was given no `migrationMetadata` store, so the startup gate could not run. Startup is refused rather than silently assuming compatibility (spec11.1 §8). |
 
 **Migration execution is host-controlled.** `executeMigration()` is a standalone function,
 not a `ServerRequest` branch — there is no path from a client through the semantic protocol

package/docs/CONSTRAINTS.md

@@ -1,6 +1,6 @@
 # Constraints
 
-Axiom 0.11.0-alpha.1. Two constructs, answering different questions. They are not
+Axiom 0.11.2-alpha.1. Two constructs, answering different questions. They are not
 interchangeable.
 
 | | Question | Sees |

package/docs/EFFECTS.md

@@ -1,6 +1,6 @@
 # Effects
 
-Axiom 0.11.0-alpha.1. External effects are not rollback-capable state mutations. This file
+Axiom 0.11.2-alpha.1. External effects are not rollback-capable state mutations. This file
 is the delivery model; [`AUTHORITY.md`](AUTHORITY.md#external-effects) is the load-bearing
 statement of why, and [`INTEGRATIONS.md`](INTEGRATIONS.md) is the operation vocabulary this
 builds on.

package/docs/EVENTS.md

@@ -1,6 +1,6 @@
 # Events
 
-Axiom 0.11.0-alpha.1. An event is a typed fact — something that happened — never work
+Axiom 0.11.2-alpha.1. An event is a typed fact — something that happened — never work
 itself. [`AUTHORITY.md`](AUTHORITY.md#external-events) is the load-bearing statement;
 this file is the vocabulary and the webhook delivery mechanism. A **subscription** is the
 other way an external fact becomes an `EventDef` payload — see

package/docs/EXPRESSIONS.md

@@ -1,6 +1,6 @@
 # Expressions
 
-Axiom 0.11.0-alpha.1. An expression describes **what value is computed**. It is a tree of
+Axiom 0.11.2-alpha.1. An expression describes **what value is computed**. It is a tree of
 plain data, never source text and never a callback. Evaluation is pure: an expression MUST
 NOT change state.
 

package/docs/GRAPH_MODEL.md

@@ -1,6 +1,6 @@
 # Graph model
 
-Axiom 0.11.0-alpha.1. The `ApplicationGraph` is the authoritative representation of an
+Axiom 0.11.2-alpha.1. The `ApplicationGraph` is the authoritative representation of an
 application. Everything else — the IR, the page, the DOM — is derived from it and is never
 edited.
 

package/docs/INTEGRATIONS.md

@@ -1,6 +1,6 @@
 # Integrations
 
-Axiom 0.11.0-alpha.1. How an application declares and calls an external system, without
+Axiom 0.11.2-alpha.1. How an application declares and calls an external system, without
 embedding a transport, an SDK or a secret in the graph. The authority boundary this
 depends on is [`AUTHORITY.md`](AUTHORITY.md#external-systems); this file is the vocabulary.
 

package/docs/LOCATIONS.md

@@ -1,6 +1,6 @@
 # Locations
 
-Axiom 0.11.0-alpha.1.
+Axiom 0.11.2-alpha.1.
 
 ```text
 Expression = a value

package/docs/MIGRATIONS.md

@@ -1,6 +1,6 @@
 # Schema evolution & semantic migrations
 
-Axiom 0.11.0-alpha.1. The operational contract for evolving a deployed application's
+Axiom 0.11.2-alpha.1. The operational contract for evolving a deployed application's
 semantic model and its persisted canonical data over time — adding a required field,
 splitting one field into two, removing an obsolete one, migrating millions of
 provider-backed rows — **without** an application-authored SQL migration, an ORM migration,
@@ -9,15 +9,17 @@ a migration callback, a repository script, or a manual schema-version check.
 > The graph owns the meaning of the change. The migration model owns the transition between
 > semantic versions. The provider owns the physical execution.
 
-Full research and rationale: `reports/AXIOM_0_11_MIGRATION_RESEARCH.md`.
-Implementation report: `reports/AXIOM_0_11_IMPLEMENTATION_REPORT.md`.
+The design rationale, the architecture research and the implementation reports are
+maintainer artifacts in the Axiom repository (`reports/`); they are not shipped in the npm
+tarball. This document plus the `.d.ts` declarations, the `axiom.server.v7` schema and the
+`axiom.conformance.v5` fixtures are the complete consumer contract.
 
 ---
 
 ## Semantic schema identity
 
 An application has a **semantic schema version** — `graph.schemaVersion`, a monotonic
-integer, default `1`. It is a distinct concept from the npm package version (`0.11.0`) and
+integer, default `1`. It is a distinct concept from the npm package version (`0.11.2`) and
 from the Server IR contract (`axiom.server.v7`). A `MigrationDef` chain connects consecutive
 integers.
 
@@ -65,7 +67,7 @@ does not silently skip a semantic transition.
 | `populate-field` | `entityId`, `fieldId`, `value` (expression) | migration-required |
 | `transform-field` | `entityId`, `fieldId`, `fromType`, `toType`, `expression` | migration-required; narrowing → destructive |
 | `transform-record` | `entityId`, `produce` (an `object` expression), `removesFields?`, `addsFields?` | migration-required; discards info → destructive |
-| `add-relationship` | `relationship` | compatible / migration-required (required) |
+| `add-relationship` | `relationship` | compatible (metadata; no per-row rewrite) |
 | `remove-relationship` | `relationshipId` | compatible (metadata only) |
 
 Split and merge are **not** dedicated primitives: both are `transform-record` with
@@ -117,13 +119,35 @@ The **safe type-change set** is small: an identical type, a widening to `optiona
 same inner type, and enum membership growth. Everything else is `migration-required` at
 best and `destructive` if narrowing.
 
-`migrationCoversDiff(diff, operations)` proves the migration chain accounts for exactly the
+`migrationCoversDiff(diff, operations)` proves a set of operations accounts for exactly the
 data-affecting part of the diff: every `migration-required` / `destructive` entry has a
 matching operation, and no operation describes a change the graphs do not contain.
 
+**Coverage is scoped to the semantic transition being evaluated** (spec11.1 §22-24), not to
+the whole chain. `migrationImpact(previous, next)` picks the operations by the version gap:
+
+- `next.schemaVersion === previous.schemaVersion + 1` → `coverageMode: 'step'`. Coverage is
+  evaluated against exactly the `N → N+1` migration's operations. This is authoritative and
+  agrees with `migrationCoversDiff` and `validateGraph`; historical operations from earlier
+  migrations in `next` do **not** count as unmatched.
+- more than one version apart → `coverageMode: 'chain'`. A single endpoint diff has no
+  ordinary per-step coverage, so `covered` reports only whether a complete migration chain
+  connects the two versions; `steps[]` lists the migrations that would run.
+- same version, or a downgrade → `coverageMode: 'none'`.
+
+`covered: false` is never an unexplained boolean — the result carries `uncovered`,
+`unmatched` and `steps`.
+
 `AgentAPI` surface: `inspectSchema()`, `diffSchema(previous)`, `migrationImpact(previous)`
-(§57 — the diff, coverage, `dataLossPossible`, and which queries / actions / read policies /
-constraints / UI nodes reference a changed field), and `explainSchemaDiff(diff)`.
+(§57 — the diff, coverage + `coverageMode`/`uncovered`/`unmatched`/`steps`,
+`dataLossPossible`, and which queries / actions / read policies / constraints / UI nodes
+reference a changed field), and `explainSchemaDiff(diff)`. These agree with runtime and
+compiler validation on whether a valid migration step covers its semantic diff (spec11.1 §26).
+
+**`RelationshipDef.required`.** There is no public relationship-requiredness authoring
+concept in 0.11.x. The fingerprint projection reserves a `required` slot for relationships
+that is **always `false`**, so that adding the capability in a future minor need not bump
+`SCHEMA_FINGERPRINT_VERSION` (an existing graph, unable to set it, fingerprints identically).
 
 ---
 
@@ -153,8 +177,17 @@ executeMigration({
 
 - **Migration execution is host-controlled.** `executeMigration` is a standalone function,
   not a `ServerRequest` branch — there is no path from a client through the semantic
-  protocol that runs a migration. It requires a `MigrationPrincipal` minted by the host with
-  `migrationAuthority(grantedBy)`; a call without one is `MIGRATION_NOT_AUTHORIZED`.
+  protocol that runs a migration, and no `migrate` / `execute-migration` request kind. It
+  requires a `MigrationPrincipal` minted by the host with `migrationAuthority(grantedBy)`; a
+  call without one is `MIGRATION_NOT_AUTHORIZED`.
+- **Migration authority is opaque, and authorization is by provenance, not shape.** The
+  object `migrationAuthority()` returns is frozen and registered in a process-private
+  registry. Constructing an object with the same visible fields —
+  `{ kind: 'axiom.migration-authority', grantedBy: 'operator' }` — or a spread copy of a
+  real one — `{ ...migrationAuthority('operator') }` — does **not** recreate authority and
+  is rejected. `grantedBy` is a descriptive audit label, not the source of authorization.
+  The capability is process-local and is never serialized; durability lives in the
+  `MigrationMetadataStore`, the lease and the checkpoints.
 - **"A migration exists" is not "the operator approved data loss."** Every destructive
   operation id MUST appear in `approveDestructive`, or the migration is refused
   (`MIGRATION_APPROVAL_REQUIRED`) with **zero writes** and the schema version unchanged.
@@ -186,19 +219,44 @@ checkpoint, and an `idle` / `in-progress` / `checkpointed` phase.
 
 ## The startup gate
 
-When a document declares a semantic schema version and `createAxiomServer` is given
-`migrationMetadata`, `start()` runs a compatibility check. **There is no hopeful startup.**
+**There is no hopeful startup, and `compatible` never means "not checked".** A
+machine-readable `compatible` verdict means compatibility was *actually established* against
+the provider's durable record.
 
-| Verdict | Outcome |
-| --- | --- |
-| **compatible** | stored `(version, fingerprint)` match — start normally |
-| **fresh** | no stored metadata — stamp the provider and start |
-| **migration-required** | stored version `<` required, a chain exists — `start()` throws `SCHEMA_MIGRATION_REQUIRED` |
-| **migration-in-progress** | a migration lock is held — `start()` throws `MIGRATION_IN_PROGRESS` |
-| **incompatible** | stored version `>` required (`SCHEMA_INCOMPATIBLE`), or no chain (`MIGRATION_PATH_NOT_FOUND`) — `start()` throws |
-| **corrupted** | same version, different fingerprint (`MIGRATION_FINGERPRINT_MISMATCH`), or data present with no metadata — `start()` throws |
+### What must be configured
 
-`server.schemaGate()` returns the verdict without starting.
+- A graph that **declares semantic schema evolution** — a `schemaVersion` past `1`, or any
+  `MigrationDef` — MUST be given a `migrationMetadata` store. `createAxiomServer({ ir })`
+  with no store, for such a graph, refuses `start()` with `SCHEMA_METADATA_REQUIRED`: the
+  gate could not run, so serving is not permitted.
+- A graph that declares **no** semantic schema identity does not need a store. If one is
+  supplied and it records a versioned schema, the mismatch is still caught (below).
+
+### Verdicts
+
+`start()` proceeds only on `compatible`, `fresh` or `not-applicable`; every other verdict
+throws with its diagnostic code. `server.schemaGate()` returns the verdict without starting.
+
+| Verdict | Meaning | `start()` |
+| --- | --- | --- |
+| **compatible** | stored `(version, fingerprint)` were compared and match | proceeds |
+| **fresh** | the graph declares a schema, the provider has no metadata, and no persisted data exists — the provider is stamped at the graph's version | proceeds |
+| **not-applicable** | the graph declares no schema identity and there is no versioned persistence to protect — the gate genuinely does not apply | proceeds |
+| **migration-required** | stored version `<` required and a complete chain exists — `SCHEMA_MIGRATION_REQUIRED` | refused |
+| **migration-in-progress** | a migration lock is held — `MIGRATION_IN_PROGRESS` | refused |
+| **incompatible** | stored version `>` required (`SCHEMA_INCOMPATIBLE`), or no chain to it (`MIGRATION_PATH_NOT_FOUND`) | refused |
+| **corrupted** | same version, wrong fingerprint (`MIGRATION_FINGERPRINT_MISMATCH`); or persisted data present with no metadata and a schema-evolving graph (`MIGRATION_STATE_CORRUPTED`) | refused |
+| **schema-identity-required** | the provider records a schema version but the graph declares none — compatibility cannot be established (`SCHEMA_IDENTITY_REQUIRED`) | refused |
+| **schema-metadata-required** | the graph declares schema evolution but no metadata store was supplied (`SCHEMA_METADATA_REQUIRED`) | refused |
+
+### `fresh` ≠ `compatible` ≠ `not-applicable`
+
+`fresh` is a new database for a schema-evolving application — it initializes to the graph's
+declared schema through the documented fresh-start path, with no migration from imaginary
+history. `not-applicable` is an application with no persisted semantic schema to protect —
+often a trivial in-memory program. Neither is `compatible`, which means an actual match was
+verified. An unversioned graph pointed at an existing versioned provider is
+`schema-identity-required`, never any of the three.
 
 **Serving during a migration.** While a migration lock is held, the authority refuses every
 request with `MIGRATION_IN_PROGRESS`. Once the lock clears, if the persisted schema still
@@ -222,6 +280,31 @@ cursor minted under one schema is `QUERY_CURSOR_INVALID` after a migration chang
 - A resume against a checkpoint from a different plan is refused
   (`MIGRATION_CHECKPOINT_INVALID`).
 
+**Concurrent-migrator outcomes are semantic, not physical.** When two processes run the
+same required migration against the same database — including two independent OS processes
+sharing one SQLite file — each `executeMigration` result MUST be one of:
+
+| Result | Meaning |
+| --- | --- |
+| `run.phase === 'completed'`, `alreadyAtTarget === false` | this process performed the transition — exactly one process in a race does |
+| `run.alreadyAtTarget === true` | a competitor completed the whole transition first; nothing to do |
+| `MIGRATION_IN_PROGRESS` | a competitor holds the migration lease |
+
+A competing runner never re-executes the transition: the transform runs exactly once, the
+history gains exactly one entry per step, and the schema version advances once. A losing
+process performs no migration data work and does not touch the active owner's checkpoint.
+
+**The provider absorbs physical contention.** SQLite's single-writer file lock
+(`SQLITE_BUSY` / `SQLITE_LOCKED`) is reconciled to the outcomes above inside the provider —
+a short bounded busy wait, then an ownership re-check. A consumer does **not** catch
+SQLite-native lock errors around `executeMigration`, `getMigrationStatus`, `schemaGate()`
+or ordinary requests, and does **not** write its own busy-retry loop; that is provider
+responsibility. `createSqliteMigrationStore` / `createSqliteRowStore` accept an optional
+`busyTimeoutMs` (default 2000) that tunes only the physical wait — it is not
+migration-ownership configuration and correctness never depends on it. If contention
+genuinely cannot be explained by a migration owner, the result is `MIGRATION_FAILED` with
+the physical cause retained for the operator, never a masked `MIGRATION_IN_PROGRESS`.
+
 ---
 
 ## Providers
@@ -241,6 +324,23 @@ migration is refused **before any write** (`MIGRATION_PROVIDER_UNSUPPORTED`).
 **No application-authored SQL.** The memory and SQLite providers must derive semantically
 equivalent target data from the same fixture.
 
+### Where the rows come from
+
+A migration operates on persistence the host already has — a production SQLite file, a
+Postgres database. `MigrationRowStore` deliberately has **no insert operation**: seeding
+data is not a migration step. For tests, bootstrap and the conformance runner, the
+reference stores accept pre-existing rows through their own constructors:
+
+```ts
+createMemoryRowStore(dataset)                                  // dataset: Map<entityId, Row[]>
+await createSqliteRowStore({ location, ir, seed })             // seed: Record<entityId, Row[]>
+```
+
+The `seed` is source-shape data; the SQLite store reconciles it to the columns the seed
+carries so the database genuinely starts at the *source* schema and the migration's own
+`ALTER TABLE`s move it to the target. `seed` is a constructor convenience, not part of the
+migration model.
+
 ---
 
 ## Portable conformance — `axiom.conformance.v5`

package/docs/PRESENTATION.md

@@ -1,6 +1,6 @@
 # Presentation
 
-Axiom 0.11.0-alpha.1. Presentation is **semantic UX intent**, expressed as data on a UI
+Axiom 0.11.2-alpha.1. Presentation is **semantic UX intent**, expressed as data on a UI
 node. It names roles, tokens and device classes. It never names a colour, a length, a media
 query or a CSS property.
 

package/docs/QUERIES.md

@@ -1,6 +1,6 @@
 # Semantic data access & the query layer
 
-Axiom 0.11.0-alpha.1. The operational contract for demand-driven reads over authoritative
+Axiom 0.11.2-alpha.1. The operational contract for demand-driven reads over authoritative
 data that is too large to materialize as a `StateDef` — 500,000 orders, 5,000,000 order
 lines, years of audit rows. `axiom.server.v6`.
 

package/docs/RUNTIME.md

@@ -1,6 +1,6 @@
 # Runtime
 
-Axiom 0.11.0-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
+Axiom 0.11.2-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
 contains no knowledge of any application.
 
 ## Constructing

package/docs/SEMANTIC_CONTRACT.md

@@ -1,6 +1,6 @@
 # Semantic contract
 
-Axiom 0.11.0-alpha.1. Runtime guarantees, stated formally. This file defines behavior; it
+Axiom 0.11.2-alpha.1. Runtime guarantees, stated formally. This file defines behavior; it
 does not teach. Where this file and any specification in `../specs/` disagree, this file
 describes the implementation and is authoritative.
 

package/docs/STATE.md

@@ -1,6 +1,6 @@
 # State
 
-Axiom 0.11.0-alpha.1. A `StateDef` is a named application value: stored, or computed from
+Axiom 0.11.2-alpha.1. A `StateDef` is a named application value: stored, or computed from
 other state.
 
 ```ts

package/docs/STORAGE.md

@@ -1,6 +1,6 @@
 # Storage and blobs
 
-Axiom 0.11.0-alpha.1. How an application stores, references, serves and deletes binary data —
+Axiom 0.11.2-alpha.1. How an application stores, references, serves and deletes binary data —
 an attachment, a document, a photograph, a diagnostic log — with no filesystem path, no
 upload route and no download route anywhere in it.
 

package/docs/SUBSCRIPTIONS.md

@@ -1,6 +1,6 @@
 # Subscriptions
 
-Axiom 0.11.0-alpha.1. How an application receives a stream of external events — an MQTT
+Axiom 0.11.2-alpha.1. How an application receives a stream of external events — an MQTT
 topic, a WebSocket feed, a queue consumer, a filesystem watcher, a serial port — without a
 client, a socket or a callback anywhere in the graph.
 

package/docs/TRIGGERS.md

@@ -1,6 +1,6 @@
 # Triggers
 
-Axiom 0.11.0-alpha.1. A `TriggerDef` says **when** an action should be invoked, without
+Axiom 0.11.2-alpha.1. A `TriggerDef` says **when** an action should be invoked, without
 embedding callback code. `docs/AUTHORITY.md`
 [§ Triggers](AUTHORITY.md#triggers) is the load-bearing statement of the execution model;
 this file is the vocabulary.

package/docs/UI.md

@@ -1,6 +1,6 @@
 # UI
 
-Axiom 0.11.0-alpha.1. Eleven semantic UI node kinds describe **what exists and what it does**.
+Axiom 0.11.2-alpha.1. Eleven semantic UI node kinds describe **what exists and what it does**.
 How it looks is [presentation](PRESENTATION.md).
 
 All eleven share `UIBase`:

package/docs/VALIDATION.md

@@ -1,6 +1,6 @@
 # Validation
 
-Axiom 0.11.0-alpha.1. Validation is authoring-time structural checking. It is not the same
+Axiom 0.11.2-alpha.1. Validation is authoring-time structural checking. It is not the same
 as runtime constraint evaluation — see [`CONSTRAINTS.md`](CONSTRAINTS.md) for the four
 layers of correctness.
 

package/llms.txt

@@ -1,6 +1,6 @@
 # Axiom
 
-> AI-native semantic application framework, version 0.11.0-alpha.1. An Axiom application is a
+> AI-native semantic application framework, version 0.11.2-alpha.1. An Axiom application is a
 > typed semantic graph — state, behavior, constraints, UI structure, presentation and
 > authority as structured data — executed by generic runtimes. The JavaScript, HTML and CSS
 > that reach a browser are compiler output and are never authored or edited. The primary

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cynodia/axiom",
-  "version": "0.11.0-alpha.1",
+  "version": "0.11.2-alpha.1",
   "description": "AI-native semantic web application framework.",
   "license": "MIT",
   "author": "AskTech AS",
@@ -34,10 +34,10 @@
     }
   },
   "dependencies": {
-    "@cynodia/axiom-core": "0.11.0-alpha.1",
-    "@cynodia/axiom-runtime": "0.11.0-alpha.1",
-    "@cynodia/axiom-compiler": "0.11.0-alpha.1",
-    "@cynodia/axiom-agent-api": "0.11.0-alpha.1"
+    "@cynodia/axiom-core": "0.11.2-alpha.1",
+    "@cynodia/axiom-runtime": "0.11.2-alpha.1",
+    "@cynodia/axiom-compiler": "0.11.2-alpha.1",
+    "@cynodia/axiom-agent-api": "0.11.2-alpha.1"
   },
   "scripts": {
     "build": "tsc -b tsconfig.json"