@aventara/core 0.1.0-pilot.3 → 0.1.0-pilot.4

package/dist/transactions/transaction-request.d.ts

@@ -4,25 +4,23 @@ type TransactionRequestBase = {
     readonly requestId: string;
     readonly plan: unknown;
 };
+/** An in-process transaction request, run under the Application Contract. */
 export type ApplicationTransactionRequest = TransactionRequestBase & {
     readonly scope: "application";
     readonly protocol?: never;
     readonly transport?: never;
 };
+/** A remote transaction request, run under the Client Contract. */
 export type ClientTransactionRequest = TransactionRequestBase & {
     readonly scope: "client";
     readonly protocol: ClientProtocolIdentity;
     readonly transport?: PipelineTransportContext;
 };
+/** One transaction request, as `framework.executeTransaction` takes it. */
 export type FrameworkTransactionRequest = ApplicationTransactionRequest | ClientTransactionRequest;
 /**
  * The origin one plan operation runs under: its own layer's Contract, its own
  * pipelines, and — for a client step — the protocol identity it is accepted with.
- * The untyped seam derives every operation's origin from the request; the typed
- * runner states one per handle.
- *
- * Internal to the transaction runtime, and deliberately not a member of the
- * request: the public seam's request cannot smuggle a per-operation origin.
  */
 export type TransactionOperationOrigin = Pick<ApplicationTransactionRequest, "scope"> | Pick<ClientTransactionRequest, "scope" | "protocol" | "transport">;
 export {};

package/dist/transactions/transaction-response.d.ts

@@ -1,17 +1,15 @@
 import type { OperationFailureResponse } from "../runtime/operation-response.js";
-/**
- * A committed plan: each operation's final `data`, in plan order.
- *
- * `T` mirrors `OperationResponse<T>`: the untyped seam (`executeTransaction`)
- * answers the default `readonly unknown[]`, and the typed runner
- * (`framework.transaction`) supplies the per-position tuple its handles derive.
- */
+/** A committed plan: each operation's final `data`, in plan order. */
 export type TransactionCommittedResponse<T = readonly unknown[]> = {
     readonly data: T;
     readonly code: "A1009";
     readonly cause: null;
 };
+/** What a transaction answers: committed (`A1009`) or a failure. */
 export type TransactionResponse = TransactionCommittedResponse | OperationFailureResponse;
+/** Builds the committed response. */
 export declare function transactionCommitted(results: readonly unknown[]): TransactionCommittedResponse;
+/** Builds the failure response of a plan step, naming the step in `cause.operation`. */
 export declare function transactionOperationFailure(failure: OperationFailureResponse, operation: number): OperationFailureResponse;
+/** Builds the `A3002` response for a transaction that itself failed. */
 export declare function transactionInfrastructureFailure(operation?: number): OperationFailureResponse;

package/dist/transactions/transaction-runtime.d.ts

@@ -13,8 +13,8 @@ import type { TransactionResponse } from "./transaction-response.js";
  */
 export type FrameworkTransactionExecutor = (request: FrameworkTransactionRequest, diagnostics: TransactionDiagnosticsChannel, origins?: readonly TransactionOperationOrigin[]) => Promise<TransactionResponse>;
 /**
- * Validates a whole plan through the Framework Validation Layer, then runs it
- * inside exactly one Adapter transaction. Guards, pipes, hooks and interceptors of
- * every plan operation run while the provider transaction is open.
+ * Validates a whole plan through the Framework Validation Layer, then runs it inside
+ * exactly one Adapter transaction. Guards, pipes, hooks and interceptors of every plan
+ * operation run while the provider transaction is open.
  */
 export declare function createTransactionRuntime<M extends AdapterModel>(dependencies: OperationRuntimeDependencies<M>): FrameworkTransactionExecutor;

package/dist/transactions/transaction-slot-path-error.d.ts

@@ -1,22 +1,12 @@
 /**
- * The ways a transaction slot path can fail to name a member of the argument view
- * it is written into. Every slot path was collected from an argument view by the
- * plan validator, so any of these is a framework defect rather than a caller
- * error; the violation is the only thing that tells them apart, so it is
- * structured data rather than message text.
- *
- * - `slot-prefix`: the path does not begin `["operations", <this operation>,
- *   "args", <member>]`, or the view itself is not an object.
- * - `absent-member`: a segment names no own member of its container.
- * - `non-object-ancestor`: a segment descends through a non-object value.
+ * The ways a transaction slot path can fail to name a member of its argument
+ * view. Each is a framework defect, not a caller error.
  */
 export type TransactionSlotPathViolation = "slot-prefix" | "absent-member" | "non-object-ancestor";
 /**
- * The framework-owned failure thrown when a slot path does not name a member of
- * the argument view. It never reaches the wire: inside a plan's transaction
- * callback it becomes that operation's `A3000`, during validation the totality
- * guard's `A3000`. It reaches a diagnostics sink as the raw `error`, where the
- * violation discriminates the three defects.
+ * Thrown internally when a slot path does not name a member of its argument
+ * view; the caller receives `A3000`, and the diagnostics sink receives this
+ * error.
  */
 export declare class TransactionSlotPathError extends Error {
     readonly violation: TransactionSlotPathViolation;

package/dist/transactions/transaction-slot-writer.d.ts

@@ -1,18 +1,8 @@
 /**
  * The one owner of writing a value at a transaction slot path. Validation installs
- * framework-owned `$ref` control snapshots through it and execution installs
- * resolved final data through it, so both argument views are produced by the same
- * ancestor-cloning walker.
- *
- * Slot paths are collected once, from the validated semantic argument view.
- * Validation then writes them into two views: that semantic view, where the path
- * is known to name a member, and the raw wire view
- * (`operation.request.arguments`), where the same path is asserted rather than
- * established. It holds there because a slot names a scalar leaf key inside
- * top-level mutation data and Framework Validation Layer normalization preserves
- * that `data`-leaf key structure. A path that does not name a member of the view
- * being written is therefore a framework defect either way, and fails loudly
- * rather than being skipped.
+ * framework-owned `$ref` control snapshots through it and execution installs resolved
+ * final data through it, so both argument views are produced by the same ancestor-
+ * cloning walker.
  */
 type Path = readonly (string | number)[];
 /** One value to install at a full transaction slot path. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aventara/core",
-  "version": "0.1.0-pilot.3",
+  "version": "0.1.0-pilot.4",
   "license": "SEE LICENSE IN LICENSE",
   "description": "Core runtime, contract compiler, and extension APIs for Aventara.",
   "type": "module",