@cynodia/axiom 0.8.1-alpha.1 → 0.8.2-alpha.1

package/docs/ACTIONS_TRANSACTIONS.md

@@ -1,6 +1,6 @@
 # Actions and transactions
 
-Axiom 0.8.1-alpha.1. An action is behavior expressed as data, executed as a transaction.
+Axiom 0.8.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.8.1-alpha.1. The machine-facing interface. Agents query semantics and apply
+Axiom 0.8.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.8.1-alpha.1. Compressed operational contract. Read this plus the `.d.ts`
+Axiom 0.8.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:
@@ -31,7 +31,7 @@ One canonical term per concept. These are not interchangeable.
 ## Graph construction
 
 ```ts
-const graph = new ApplicationGraph(id, name);      // version defaults to '0.8.0'
+const graph = new ApplicationGraph(id, name);      // version defaults to '0.8.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
@@ -496,6 +496,22 @@ if (!result.ok) {
 warnings never make a graph invalid. 72 codes in `VALIDATION_CODES`, grouped in
 [`VALIDATION.md`](VALIDATION.md).
 
+**`validateGraph(graph)` with no options is target-neutral by design** (spec 8.2 §2-4): a
+graph is never rejected for a renderer or trigger runtime nobody named. This means a bare
+`validateGraph(graph).valid === true` does **not** by itself guarantee the graph is
+executable by the browser client — a UI node kind no renderer implements, or a
+client-authority trigger kind the browser trigger runtime does not execute
+(`CLIENT_TRIGGER_UNSUPPORTED`), both validate silently under the no-options call. Use
+`validateForBrowser(graph)` (`@cynodia/axiom-compiler`) for a validate-only check against
+real browser capabilities, or call `compileToIR(graph)` directly — it applies those same
+capabilities and throws `GraphValidationError` on exactly what `validateForBrowser` would
+report as an error. See [Renderability](#renderability) below for the parallel UI-kind gate.
+
+```ts
+validateGraph(graph).valid;          // target-neutral: accepts every UI kind and trigger kind
+validateForBrowser(graph).valid;     // browser-real: same as compileToIR's validation step
+```
+
 ## Agent API
 
 ```ts
@@ -638,7 +654,7 @@ event.
 agent.listIntegrations() / agent.listIntegrationOperations(id?);
 agent.getActionsUsingIntegration(id) / agent.getEffectsForAction(actionId);
 agent.getTriggersForAction(actionId) / agent.getTimedTriggers();
-agent.getActionsTriggeredByEvent(eventId) / agent.getWebhookEvents();
+agent.getActionsTriggeredByEvent(eventId) / agent.getTriggeredEvents();  // graph-static: has a bound trigger, not "was delivered"
 agent.getExternalDependencies();   // { integrations, operations } — the deployment manifest
 agent.getSystemOnlyActions() / agent.getTriggersTargetingClientOnlyActions();
 agent.isClientInvocable(actionId) / agent.isSystemOnly(actionId);
@@ -647,12 +663,24 @@ agent.isClientInvocable(actionId) / agent.isSystemOnly(actionId);
 Portable artifacts, for a runtime written in another language:
 
 ```
-@cynodia/axiom-server/conformance                     the fixture manifest
+@cynodia/axiom-server/conformance                     the fixture manifest (fixture.format, below)
 @cynodia/axiom-server/conformance/<name>.json         one fixture, pure data
-@cynodia/axiom-server/schema/server-ir.v1.schema.json JSON Schema for the IR
+@cynodia/axiom-server/schema/server-ir.v1.schema.json JSON Schema for axiom.server.v1 (frozen)
+@cynodia/axiom-server/schema/server-ir.v2.schema.json JSON Schema for axiom.server.v2
+@cynodia/axiom-server/schema/server-ir.v3.schema.json JSON Schema for axiom.server.v3
+@cynodia/axiom-server/schema/server-ir.v4.schema.json JSON Schema for axiom.server.v4 (latest)
 @cynodia/axiom-server/schema/protocol.v1.schema.json  JSON Schema for the protocol
 ```
 
+This list is generated/tested content, not hand-maintained prose: `packages/demo/test
+/documentation.test.ts` fails if a shipped `schema/*.json` file is missing from it or a
+listed file no longer exists (spec 8.2 §43-45). `runConformanceFixture`/
+`runConformanceSuite` (`@cynodia/axiom-server`) are the public runner over that fixture
+format — see [`AUTHORITY.md`](AUTHORITY.md#conformance) for `fixture.conformance` (the
+fixture-format version) vs `fixture.serverIR.contract` (the per-fixture Server IR contract)
+vs the manifest's own `conformance`/`protocol`/`release` fields — three separate concepts,
+never conflated under one "contract" name (spec 8.2 §9-10).
+
 Boundary diagnostics: `UNKNOWN_SERVER_ACTION` `ARGUMENT_TYPE_MISMATCH` `AUTHORIZATION_DENIED`
 `INVOCATION_SOURCE_NOT_ALLOWED` `CONCURRENCY_CONFLICT` `MALFORMED_REQUEST`
 `AUTHORITY_UNREACHABLE`, plus `SERVER_STATE_WRITE` and `REMOTE_ACTION_UNAVAILABLE` on the
@@ -683,6 +711,19 @@ Capabilities describe **node-kind** support, not partial support: a renderer can
 that it draws a kind but not one of its options. Nothing in the current vocabulary needs that,
 and it is a deliberate future extension rather than an oversight.
 
+The same gate exists for client-authority triggers, since the browser trigger runtime
+implements no `TriggerSpec.kind` at all:
+
+```ts
+validateGraph(graph, { triggerRuntime: BROWSER_TRIGGER_CAPABILITIES });  // CLIENT_TRIGGER_UNSUPPORTED
+compileToIR(graph);                                                     // applies it by default
+```
+
+`CLIENT_TRIGGER_UNSUPPORTED`'s message states the remediation, not only the refusal: move
+the trigger's target action to server authority, or compile for a trigger runtime that
+publishes the kind (`compileToIR(graph, { triggerRuntime })`). Full model:
+[`TRIGGERS.md`](TRIGGERS.md#where-a-trigger-executes).
+
 ## Named expressions
 
 ```ts

package/docs/ANTI_PATTERNS.md

@@ -1,6 +1,6 @@
 # Anti-patterns
 
-Axiom 0.8.1-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
+Axiom 0.8.2-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
 alternative.
 
 ## 1. Field names as entity runtime keys

package/docs/AUTHORITY.md

@@ -1,6 +1,6 @@
 # Authority
 
-Axiom 0.8.1-alpha.1. How an application crosses the trust boundary.
+Axiom 0.8.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
@@ -549,6 +549,26 @@ Running them requires no part of this implementation. That is the point: the Ser
 specification plus these fixtures are the whole contract, so an independent runtime in
 another language can be held to exactly the same standard.
 
+**A public reference runner is exported for the TypeScript reference runtime itself**
+(spec 8.2 §14-16):
+
+```ts
+import { runConformanceFixture, runConformanceSuite } from '@cynodia/axiom-server';
+
+const result = await runConformanceFixture(fixtureJson);   // { name, ok, failures[] }
+```
+
+It imports only `@cynodia/axiom-server` and fixture data — no graph, no compiler, no
+builder — and reports structured pass/fail rather than throwing on an ordinary fixture
+mismatch. `packages/server/test/conformance.test.ts` runs every shipped fixture through
+this exact function, and `npm run conformance:run` (`scripts/run-conformance.mjs`) runs the
+whole suite from a standalone script using nothing but this public API and the manifest —
+the "held to the same standard by an outside caller" claim, demonstrated rather than
+asserted. The fixture **model** (`ConformanceFixture` and friends, `conformance-types.ts`)
+is deliberately kept separate from this **adapter**
+(`conformance-runner.ts`): a non-TypeScript implementation needs only the model's shape and
+the semantics on this page, never this file.
+
 Enumerate the suite from its manifest rather than by listing a directory:
 
 ```
@@ -556,12 +576,24 @@ Enumerate the suite from its manifest rather than by listing a directory:
 @cynodia/axiom-server/conformance/<name>.json → one fixture
 ```
 
-The manifest names the contracts the fixtures are written against (`axiom.conformance.v1`,
-`axiom.server.v1`, `axiom.protocol.v1`), the release, every area covered, and every fixture
-with its file. A runtime that does not implement a contract the manifest names should refuse
-the suite rather than discover the mismatch one assertion at a time. The files are plain JSON
-in a documented package directory, so a non-JavaScript consumer can read them straight out of
-the tarball without Node's module resolver.
+The manifest carries three **separate, non-overlapping** version concepts (spec 8.2 §9-10;
+do not conflate them under one "contract" name):
+
+| Field | Means |
+| --- | --- |
+| `manifest.conformance` | The **fixture-format** version (`axiom.conformance.v1`/`v2`) — the shape of the JSON documents themselves: what top-level keys a fixture may have (`invocations` vs `steps`/`externalAdapters`, and so on). |
+| `manifest.baseContract` | The **oldest** Server IR contract any fixture in this manifest may use — `axiom.server.v1`, always, since new fixtures are added without ever raising this floor. It does **not** describe what the newest fixture needs. |
+| `manifest.fixtures[].contract` | The Server IR contract **that specific fixture** requires — this is what is authoritative for what running it needs. The suite ships fixtures spanning `v1` through `v4` simultaneously, each correctly labelled. |
+| `manifest.release` | The `@cynodia/axiom` package version this snapshot of the suite shipped with — unrelated to either version above. |
+
+Before 8.2 the manifest's top-level field was named `contract` and fixed at
+`axiom.server.v1`, which read as a claim about the whole suite even after `v3`/`v4`
+fixtures were added; it is now named `baseContract` with the meaning above, precisely
+because per-fixture `contract` is what is actually authoritative. A runtime that does not
+implement a contract a fixture names should refuse that fixture rather than discover the
+mismatch mid-assertion. The files are plain JSON in a documented package directory, so a
+non-JavaScript consumer can read them straight out of the tarball without Node's module
+resolver.
 
 Every fixture is executed against the reference runtime by this repository's own test suite,
 and its expectations are exhaustive — a fixture that says which states changed must name all
@@ -573,6 +605,7 @@ of them and no others. No fixture is permitted to disagree with the shipped runt
 @cynodia/axiom-server/schema/server-ir.v1.schema.json
 @cynodia/axiom-server/schema/server-ir.v2.schema.json
 @cynodia/axiom-server/schema/server-ir.v3.schema.json
+@cynodia/axiom-server/schema/server-ir.v4.schema.json
 @cynodia/axiom-server/schema/protocol.v1.schema.json
 ```
 
@@ -592,15 +625,21 @@ page plus the conformance fixtures.
 | `axiom.server.v1` | the frozen 0.6.1 contract, below | 0.6.1 |
 | `axiom.server.v2` | the expression kinds `group` and `expression-ref`, and the `expressionDefs` they resolve against | 0.7.0 |
 | `axiom.server.v3` | integrations, integration operations, events, triggers, and the `integration-query`/`integration-effect` operation kinds | 0.8.0 |
+| `axiom.server.v4` | `ActionDef.invocation.allowedSources` invocation-source restriction, and the structured effect-outcome envelope (`effectOutcomeEntity`, `EFFECT_ID_FIELD` and its sibling reserved fields) that every effect dispatch uses from 8.1 onward | 0.8.1 |
 
-`SERVER_IR_CONTRACTS` enumerates all three. The rules:
+`SERVER_IR_CONTRACTS` enumerates all four, and is the single source of truth this table is
+tested against — `packages/demo/test/documentation.test.ts` fails if a contract in
+`SERVER_IR_CONTRACTS` has no row here, or a row here names a contract the code does not
+declare (spec 8.2 §7-8). The rules:
 
-- **A document declares the oldest contract that can carry it.** `compileToServerIR` computes the label from the vocabulary the document actually uses, so an application that uses nothing from 0.7 or 0.8 produces a byte-identical `axiom.server.v1` document, and the committed v1 conformance fixtures are unchanged.
-- **A runtime MUST refuse a contract it does not implement**, and MUST refuse a document whose vocabulary exceeds its declared contract. A v2 runtime executing a v1-labelled document that uses `group` would accept what a conforming v1 runtime elsewhere refuses, and the two would then disagree about the same file. `createAxiomServer` raises rather than executing one.
-- **A frozen contract gains nothing.** `axiom.server.v1` does not contain `group`, `expression-ref`, `expressionDefs`, an integration, a trigger, an event, or the `integration-query`/`integration-effect` operation kinds, and `server-ir.v1.schema.json` is byte-frozen. Vocabulary arrives under a new identifier or not at all.
+- **A document declares the oldest contract that can carry it.** `compileToServerIR` computes the label from the vocabulary the document actually uses, so an application that uses nothing from 0.7 or 0.8 produces a byte-identical `axiom.server.v1` document, and the committed v1 conformance fixtures are unchanged. `usesV4Semantics` computes the v4 case specifically: an action's `invocation.allowedSources` genuinely restricting the default two-source set, or any `integration-operation` with `mode: 'effect'` (since every effect dispatch uses the structured v4 envelope) — a document that merely mentions `invocation` without restricting it only needs `axiom.server.v2`, the same tier `group`/`expression-ref` occupy.
+- **A runtime MUST refuse a contract it does not implement**, and MUST refuse a document whose vocabulary exceeds its declared contract. A v2 runtime executing a v1-labelled document that uses `group` would accept what a conforming v1 runtime elsewhere refuses, and the two would then disagree about the same file. `createAxiomServer` raises rather than executing one — including refusing a document that **understates** its own contract (`understatedContract`).
+- **A frozen contract gains nothing.** `axiom.server.v1` does not contain `group`, `expression-ref`, `expressionDefs`, an integration, a trigger, an event, the `integration-query`/`integration-effect` operation kinds, `invocation`, or the structured effect-outcome envelope, and `server-ir.v1.schema.json` is byte-frozen. Vocabulary arrives under a new identifier or not at all.
+- **`axiom.server.v4` is the latest contract as of 0.8.2** (`SERVER_IR_LATEST_CONTRACT`). 0.8.2 is polish-only — documentation, effect observability timing, fixture coverage and AgentAPI aliasing — and introduces no incompatible IR vocabulary change, so no `axiom.server.v5` was created (spec 8.2 §55-56).
 
 There is one JSON Schema per contract, each generated from the runtime's own vocabulary and
-each shipped: `server-ir.v1.schema.json`, `server-ir.v2.schema.json`, `server-ir.v3.schema.json`.
+each shipped: `server-ir.v1.schema.json`, `server-ir.v2.schema.json`, `server-ir.v3.schema.json`,
+`server-ir.v4.schema.json`.
 
 **`group`.** Partitions a collection: `Collection<A>` → `Collection<Group<K, A>>`. Groups appear
 in the order their key was **first seen** in the source; members keep source order; two keys are

package/docs/CONSTRAINTS.md

@@ -1,6 +1,6 @@
 # Constraints
 
-Axiom 0.8.1-alpha.1. Two constructs, answering different questions. They are not
+Axiom 0.8.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.8.1-alpha.1. External effects are not rollback-capable state mutations. This file
+Axiom 0.8.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.
@@ -83,6 +83,18 @@ doubles it each time. The wait uses the host's own scheduling
 remaining retry policy immediately, regardless of `maxAttempts` — an adapter that always
 answers `retryable: false` never retries at all, whatever `policy` says (spec 8.1 §73).
 
+**The three states of `retryable` (spec 8.2 §38-39):**
+
+| `retryable` | Meaning | Effect on the declared policy |
+| --- | --- | --- |
+| `false` | The adapter determined a retry cannot succeed. | Stops immediately — the remaining `maxAttempts` are never spent. |
+| `true` | The adapter determined a retry may succeed. | Continues — the next attempt runs after the policy's delay. |
+| absent | The adapter could not determine retryability either way. | Continues, exactly as `true` — an unknown answer is not treated as a refusal. |
+
+`packages/server/test/effect-retry.test.ts` is the regression coverage for all three,
+including a genuine multi-attempt retry sequence with a stable `idempotencyKey` across
+every attempt.
+
 ## Effect status and observability
 
 ```ts
@@ -106,6 +118,50 @@ mutation, and mixing the two would misrepresent what actually happened (spec §7
 `report()` events cover the whole lifecycle: `effect-requested`, `effect-attempted`,
 `effect-succeeded`, `effect-failed`.
 
+**Exact status semantics (spec 8.2 §17-21):**
+
+| Status | Means |
+| --- | --- |
+| `pending` | A durable effect intent exists (committed in the outbox), but no attempt is currently executing — either dispatch has not started yet, or it is waiting between retry attempts. |
+| `running` | An adapter attempt has been started and has not yet settled. Set **before** `IntegrationAdapter.effect(...)` is called, synchronously with the durable `attempts` increment, so `effectLog()`'s public view reflects reality rather than lagging behind it. |
+| `succeeded` | An attempt returned `{ ok: true }`. Terminal. |
+| `failed` | Every attempt the retry policy allows was exhausted, or one returned `retryable: false`. Terminal. |
+
+Before 8.2, `running` existed in the type but nothing updated `AxiomServer`'s in-memory
+`effectLog()` view when an attempt actually started — a hung adapter call was
+indistinguishable from an effect nobody had dispatched yet, both showing `status: 'pending',
+attempts: 0` forever even though the adapter had genuinely been invoked. `attempts` counts
+**invocation attempts started**, not merely attempts that settled — it increments at the
+same moment `status` moves to `'running'`, before the adapter is called, so a hung attempt
+is still counted. `packages/server/test/integrations.test.ts`'s hung-effect regression is
+the test for this.
+
+**Restart semantics for a `running` effect (spec 8.2 §20).** A record persisted as
+`'running'` when the authority restarts means a previous process called the adapter and was
+never told the outcome — that attempt is unaccounted for, not spent. It is treated as
+resumable/unknown outstanding work: the resumed dispatch gets a **fresh** full retry budget
+(local attempt count restarts at zero; the persisted `attempts` total still carries forward
+honestly across the restart) rather than silently going idle at zero remaining attempts.
+Axiom never claims to know whether the old process's call actually reached the provider —
+only that at-least-once redelivery, paired with `idempotencyKey`, is what makes resuming it
+safe.
+
+**No runtime-enforced effect timeout in 0.8.2.** Unlike an `integration-query`'s
+`timeoutMs` (deadline enforced by the runtime itself — see [`INTEGRATIONS.md`](INTEGRATIONS.md#timeout)),
+a `running` effect attempt has no deadline: a non-cooperating adapter call can remain
+`running` indefinitely, and nothing in this release will time it out or reclassify it. This
+is a deliberate scope boundary, not an oversight (spec 8.2 §24) — see the note below for why.
+
+**Research note: effect timeout is deferred, not merely unbuilt (spec 8.2 §25).** A future
+effect timeout cannot safely map a timed-out attempt directly to `failed`: unlike a query,
+an effect may have genuinely reached the provider and caused the external side effect
+before the response was lost — declaring it `failed` could make an idempotent caller retry
+a side effect that already happened once, and declaring it `succeeded` could be simply
+wrong. The honest state that later work would need is something like `unknown` — distinct
+from both terminal states — but that state is deliberately **not** introduced in 0.8.2. Do
+not add a deadline just because `running` is now observable; effect timeout remains a
+distinct future design topic.
+
 ## The result reaches an action only through an event
 
 An effect's outcome is never folded back into the transaction that requested it. Instead,
@@ -146,6 +202,77 @@ dispatched value is always this entity shape.
 Both are checked against the declared `EventDef.payloadType` the same way any event is,
 so a mismatched declaration is caught rather than silently dropped.
 
+**The full envelope, field by field (spec 8.2 §31-33):**
+
+| Field | Present | Source, lifetime and stability |
+| --- | --- | --- |
+| `EFFECT_ID_FIELD` | always | The framework-generated id of this effect intent. Stable for the life of the intent (survives restart — it is what `EffectRecord.id` is keyed by), never consumer-settable. |
+| `EFFECT_INTEGRATION_ID_FIELD` | always | The `IntegrationDef.id` the operation belongs to. Graph-static. |
+| `EFFECT_OPERATION_ID_FIELD` | always | The `IntegrationOperationDef.id` invoked. Graph-static. |
+| `EFFECT_IDEMPOTENCY_KEY_FIELD` | when the `integration-effect` operation declared one | Whatever the action's `idempotencyKey` expression evaluated to at commit time. Application-controlled, and the field the framework recommends for business correlation (below). |
+| `EFFECT_CORRELATION_ID_FIELD` | when the committing action's transaction has one | See below — this is **not** a business correlation key. |
+| `EFFECT_RESULT_FIELD` | success only | The operation's own `resultType` value, unwrapped from the adapter's `IntegrationSuccess.value`. |
+| `EFFECT_CODE_FIELD` | failure only | The adapter's `IntegrationFailure.code`. |
+| `EFFECT_MESSAGE_FIELD` | failure only | The adapter's `IntegrationFailure.message` — see the security note below before copying it into state. |
+| `EFFECT_RETRYABLE_FIELD` | failure only | The adapter's `IntegrationFailure.retryable`, coerced to a boolean (`retryable === true`; both `false` and absent read as `false` here — the three-way distinction that matters for retry control flow is internal to the retry policy, not exposed on the terminal payload). |
+
+Success and failure share this one envelope family — the always-present fields plus
+`idempotencyKey`/`correlationId` when applicable — but they are **not symmetric**: success
+never carries `EFFECT_CODE_FIELD`/`EFFECT_MESSAGE_FIELD`/`EFFECT_RETRYABLE_FIELD`, and
+failure never carries `EFFECT_RESULT_FIELD`. Do not describe the two shapes as identical;
+describe them as one family with disjoint success-only and failure-only fields.
+
+**What `EFFECT_CORRELATION_ID_FIELD` actually is.** Its value is the internal Axiom
+transaction id (`Transaction.id`, formatted like `tx_<n>`) of the action's transaction that
+recorded the effect intent — the same id `RuntimeDiagnostic.transactionId` already carries
+elsewhere. Concretely:
+
+- **Source**: assigned by the runtime's own per-process transaction counter, never supplied
+  or influenced by the application or the adapter.
+- **Lifetime**: exists only as long as the process that created it is running.
+- **Uniqueness scope**: unique only within one running authority process — it is not a
+  globally unique identifier.
+- **Stable across restart?** No. The counter resets when the authority restarts, so this
+  value cannot be used to correlate an effect across a restart, or across two different
+  authority processes.
+- **Consumer-settable?** No — there is no way for a graph or an adapter to choose it.
+- **Always present?** In practice yes, since every `integration-effect` operation only ever
+  runs inside an action's transaction, and every transaction is assigned an id — but it is
+  documented as conditional (`when the committing action's transaction has one`) because
+  that is a property of the runtime's transaction model, not a graph-level guarantee this
+  document freezes.
+
+**Its string format (`tx_<n>`) is explicitly not part of the public contract** (spec 8.2
+§27) — only its semantics are: "identifies the Axiom transaction that created this effect
+intent, within this process's lifetime." A future implementation may change the format
+without that being a breaking change, as long as the semantics hold.
+
+**Business correlation guidance (spec 8.2 §28-30).** `EFFECT_CORRELATION_ID_FIELD` is an
+**internal diagnostic aid**, not a business correlation key — it identifies "which
+transaction" in this process, not "which order" or "which device" to a follow-up action.
+**Effect outcomes do not automatically carry the original operation's arguments.** An
+application that needs to correlate an outcome back to a specific business entity (which
+order this reboot was for, which customer this notification was about) should use
+`idempotencyKey` for that purpose when the value is naturally unique per business operation
+(an order id, a reservation id) — it is already carried through to both the success and
+failure envelope, application-controlled, and exists for exactly this shape of problem.
+0.8.2 deliberately does **not** add a separate `correlationKey`/`correlationValue`
+primitive: `idempotencyKey` already covers the common case cleanly, and a second field
+whose only job is to avoid a documentation inconvenience was judged not worth the added
+vocabulary (spec 8.2 §29-30). This may be revisited if a concrete use case proves
+`idempotencyKey` alone is not conceptually clean enough — none has yet.
+
+**Effect message security (spec 8.2 §33).** Framework diagnostics — anything Axiom itself
+emits as a `RuntimeDiagnostic`/`ServerDiagnostic` — are sanitized according to
+`DISCLOSABLE_DETAIL_KEYS` (see [`AUTHORITY.md`](AUTHORITY.md#diagnostics)) before crossing
+the trust boundary. `EFFECT_MESSAGE_FIELD`/`EFFECT_CODE_FIELD` are different: they are
+**application data**, populated verbatim from whatever `IntegrationFailure.message`/`.code`
+the adapter returned, and dispatched into ordinary graph state through the event pipeline
+like any other value. Once an application's own action copies an adapter's message into
+state, **that application is responsible for what the message contains** — Axiom's
+diagnostic sanitization does not reach into adapter-authored text. Never place a secret or
+credential in an adapter's `IntegrationFailure.message`.
+
 ## No automatic compensation
 
 0.8 does not implement compensation. If an effect has a semantic inverse, it is another

package/docs/EVENTS.md

@@ -1,6 +1,6 @@
 # Events
 
-Axiom 0.8.1-alpha.1. An event is a typed fact — something that happened — never work
+Axiom 0.8.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.
 
@@ -110,10 +110,20 @@ Full tables: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-e
 ## AgentAPI
 
 ```ts
-agent.getWebhookEvents();               // EventDef[] — events at least one trigger reacts to
+agent.getTriggeredEvents();             // EventDef[] — events at least one trigger reacts to
 agent.getActionsTriggeredByEvent(id);   // ActionDef[]
 ```
 
-"Which webhook can mutate `Order`?" (spec §78) is answerable by following
-`getWebhookEvents()` through `getActionsTriggeredByEvent()` to the actions it can reach,
+`getTriggeredEvents()` is a **graph-static** query — "which `EventDef`s have a `TriggerDef`
+bound to them" — not "which webhook deliveries has this server received" (spec 8.2 §34-37).
+An event it returns may be dispatched by a verified external webhook, by an effect's
+`succeededEventId`/`failedEventId`, or by any other internal source; the graph does not
+record which, so nothing here claims to. Webhook routes and deployment-level registration
+are host/deployment concerns, deliberately outside what `GraphQueries` infers.
+
+`getWebhookEvents()` is a deprecated alias, kept for backward compatibility; new code should
+call `getTriggeredEvents()`.
+
+"Which trigger-bound event can mutate `Order`?" (spec §78) is answerable by following
+`getTriggeredEvents()` through `getActionsTriggeredByEvent()` to the actions it can reach,
 without reading a single handler.

package/docs/EXPRESSIONS.md

@@ -1,6 +1,6 @@
 # Expressions
 
-Axiom 0.8.1-alpha.1. An expression describes **what value is computed**. It is a tree of
+Axiom 0.8.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.8.1-alpha.1. The `ApplicationGraph` is the authoritative representation of an
+Axiom 0.8.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.
 
@@ -25,7 +25,7 @@ edited.
 ## API
 
 ```ts
-const graph = new ApplicationGraph(id, name, version?);   // version defaults to '0.8.0'
+const graph = new ApplicationGraph(id, name, version?);   // version defaults to '0.8.2'
 
 graph.addNode<T>(node): NodeId        // generates an id if omitted; throws if it exists
 graph.getNode<T>(id): T | undefined   // deep clone

package/docs/INTEGRATIONS.md

@@ -1,6 +1,6 @@
 # Integrations
 
-Axiom 0.8.1-alpha.1. How an application declares and calls an external system, without
+Axiom 0.8.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.
 
@@ -101,6 +101,24 @@ via `AbortController`) to cancel the underlying provider call early, but this is
 optimization, never a correctness requirement: the runtime's own enforcement is what a graph
 author can rely on regardless of which adapter is registered.
 
+### A hung query delays other work, bounded by `timeoutMs` (spec 8.2 §40-42)
+
+The Axiom authority executes every invocation it runs — an ordinary client request, a
+trigger tick, an effect-outcome event dispatch — through one serialized FIFO queue
+(`AxiomServer`'s internal `serialize`, spec 8.1 §26-30). A query that hangs therefore does
+not merely block *its own* invocation: it also blocks whatever unrelated request happened
+to queue up behind it, even one that shares no state, integration or trigger with it at
+all. This is expected, not a bug to route around — it is what makes same-instant triggers
+commit one at a time identically on the deterministic and the real host.
+
+**The delay this can cause is bounded by `timeoutMs`, never indefinite.** The hung query
+itself cannot run past its declared deadline (above), so the request queued behind it is
+released as soon as that deadline fires — worst case, `timeoutMs`, not forever. Do not
+introduce concurrent query execution to remove this delay; the observed serialization is
+correct under the current authority model (spec 8.2 §41) and changing it is out of scope.
+See `'a hung query delays a genuinely unrelated queued Action, bounded by timeoutMs'`
+(`packages/server/test/timeout-and-scheduling.test.ts`) for the regression test.
+
 ## Registering an adapter
 
 ```ts

package/docs/LOCATIONS.md

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

package/docs/PRESENTATION.md

@@ -1,6 +1,6 @@
 # Presentation
 
-Axiom 0.8.1-alpha.1. Presentation is **semantic UX intent**, expressed as data on a UI
+Axiom 0.8.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/RUNTIME.md

@@ -1,6 +1,6 @@
 # Runtime
 
-Axiom 0.8.1-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
+Axiom 0.8.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.8.1-alpha.1. Runtime guarantees, stated formally. This file defines behavior; it
+Axiom 0.8.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.8.1-alpha.1. A `StateDef` is a named application value: stored, or computed from
+Axiom 0.8.2-alpha.1. A `StateDef` is a named application value: stored, or computed from
 other state.
 
 ```ts

package/docs/TRIGGERS.md

@@ -1,6 +1,6 @@
 # Triggers
 
-Axiom 0.8.1-alpha.1. A `TriggerDef` says **when** an action should be invoked, without
+Axiom 0.8.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.
@@ -69,15 +69,25 @@ triggers targeting a server-authority one, are rejected at validation
 do nothing with it.
 
 **A client-authority trigger of a kind the browser cannot execute is a validation error,
-not a silent no-op.** The browser runtime implements no trigger kind at all today
-(`BROWSER_TRIGGER_CAPABILITIES.supportedTriggerKinds` is empty), so `validateGraph`/
-`compileToIR` reject such a trigger with `CLIENT_TRIGGER_UNSUPPORTED` — the same
-capability-gate pattern `RendererCapabilities` already applies to UI node kinds. Before
-spec 8.1, the trigger validated and compiled into `ApplicationIR.triggers` and simply never
-fired, which is exactly the "publicly declared, typechecks, passes validation, has no
-defined runtime behaviour" shape the framework forbids. Compiling for a trigger runtime
-that *does* implement a kind (`compileToIR(graph, { triggerRuntime })`) accepts it. Only the
-authoritative runtime executes triggers today. See [Not in 0.8.0](AUTHORITY.md#not-in-080).
+not a silent no-op — for any call that actually names the browser's capabilities.** The
+browser runtime implements no trigger kind at all today
+(`BROWSER_TRIGGER_CAPABILITIES.supportedTriggerKinds` is empty), so `compileToIR` — which
+applies `BROWSER_TRIGGER_CAPABILITIES` by default — and `validateForBrowser` both reject
+such a trigger with `CLIENT_TRIGGER_UNSUPPORTED`, the same capability-gate pattern
+`RendererCapabilities` already applies to UI node kinds. Before spec 8.1, the trigger
+validated and compiled into `ApplicationIR.triggers` and simply never fired, which is
+exactly the "publicly declared, typechecks, passes validation, has no defined runtime
+behaviour" shape the framework forbids.
+
+**`validateGraph(graph)` with no options is target-neutral by design (spec 8.2 §2-4) and
+does not raise `CLIENT_TRIGGER_UNSUPPORTED`** — a graph is never rejected for a trigger
+runtime nobody named, exactly as it is never rejected for a renderer nobody named. A
+validate-only workflow that wants the browser-real answer without compiling calls
+`validateForBrowser(graph)` (`@cynodia/axiom-compiler`) instead of the bare call; both it
+and `compileToIR` apply the identical `BROWSER_TRIGGER_CAPABILITIES`, so they never
+disagree. Compiling for a trigger runtime that *does* implement a kind
+(`compileToIR(graph, { triggerRuntime })`) accepts it. Only the authoritative runtime
+executes triggers today. See [Not in 0.8.0](AUTHORITY.md#not-in-080).
 
 ## Interval semantics
 

package/docs/UI.md

@@ -1,6 +1,6 @@
 # UI
 
-Axiom 0.8.1-alpha.1. Eleven semantic UI node kinds describe **what exists and what it does**.
+Axiom 0.8.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.8.1-alpha.1. Validation is authoring-time structural checking. It is not the same
+Axiom 0.8.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.
 
@@ -132,7 +132,7 @@ Full model: [`INTEGRATIONS.md`](INTEGRATIONS.md), [`EFFECTS.md`](EFFECTS.md),
 | `TRIGGER_WRONG_AUTHORITY` | An `event` trigger targeting a client-authority action (only the server dispatches events), or a `route-enter`/`route-leave` trigger targeting a server-authority one (only the client router dispatches those). |
 | `TRIGGER_TARGET_SOURCE_MISMATCH` | A trigger — which always invokes with `source: 'system'` — targets an action whose `invocation.allowedSources` excludes `'system'`; the trigger could never succeed (spec 8.1 §3-9). |
 | `INVALID_INVOCATION_SOURCE` | `ActionDef.invocation.allowedSources` is present but empty — the action could never be invoked at all. |
-| `CLIENT_TRIGGER_UNSUPPORTED` | A client-authority trigger of a kind the intended trigger runtime does not execute — before 8.1 this validated and compiled anyway, and simply never fired (spec 8.1 §31-36). The browser trigger runtime executes no kind today. |
+| `CLIENT_TRIGGER_UNSUPPORTED` | A client-authority trigger of a kind the intended trigger runtime does not execute — before 8.1 this validated and compiled anyway, and simply never fired (spec 8.1 §31-36). The browser trigger runtime executes no kind today. Only raised when a `triggerRuntime` is actually named — `validateGraph(graph)` with no options is target-neutral and never raises it; `validateForBrowser(graph)`/`compileToIR(graph)` name the real browser capabilities and do (spec 8.2 §2-6). The message states the remediation: move the target action to server authority, or compile for a trigger runtime that publishes the kind. |
 
 ### UI and routing
 

package/package.json

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