@pie-players/pie-assessment-toolkit 0.3.73 → 0.3.75

package/dist/runtime/core/SectionEngineCore.d.ts

@@ -1,12 +1,12 @@
 /**
- * Section runtime engine — pure core (M7 — Variant C, layered).
+ * Section runtime engine — pure core.
  *
  * `SectionEngineCore` is a thin object oriented wrapper over the pure
  * `transition()` function. It owns the current `SectionEngineState`,
  * applies inputs serially, and fans out the resulting
  * `SectionEngineOutput[]` to subscribers. There is no DOM, Svelte,
  * coordinator, or timing dependency in this module — all I/O lives in
- * the adapter layer (PR 2).
+ * the adapter layer.
  *
  * Lifetime model:
  *   - One instance per cohort logical lifetime. Cohort changes happen

package/dist/runtime/core/SectionEngineCore.js

@@ -1,12 +1,12 @@
 /**
- * Section runtime engine — pure core (M7 — Variant C, layered).
+ * Section runtime engine — pure core.
  *
  * `SectionEngineCore` is a thin object oriented wrapper over the pure
  * `transition()` function. It owns the current `SectionEngineState`,
  * applies inputs serially, and fans out the resulting
  * `SectionEngineOutput[]` to subscribers. There is no DOM, Svelte,
  * coordinator, or timing dependency in this module — all I/O lives in
- * the adapter layer (PR 2).
+ * the adapter layer.
  *
  * Lifetime model:
  *   - One instance per cohort logical lifetime. Cohort changes happen

package/dist/runtime/core/cohort.d.ts

@@ -1,5 +1,5 @@
 /**
- * Cohort identity for the section runtime engine (M7).
+ * Cohort identity for the section runtime engine.
  *
  * One cohort is the tuple `(sectionId, attemptId)` for the section the
  * host is currently rendering. Stage progression, readiness latches, and

package/dist/runtime/core/cohort.js

@@ -1,5 +1,5 @@
 /**
- * Cohort identity for the section runtime engine (M7).
+ * Cohort identity for the section runtime engine.
  *
  * One cohort is the tuple `(sectionId, attemptId)` for the section the
  * host is currently rendering. Stage progression, readiness latches, and

package/dist/runtime/core/engine-input.d.ts

@@ -1,24 +1,22 @@
 /**
- * Section runtime engine inputs (M7 — Variant C, layered core).
+ * Section runtime engine inputs.
  *
- * Inputs are the discriminated union of events the adapter (PR 2) feeds
- * into the pure transition function (`engine-transition.ts`). The shape
- * is closed: every field is plain data so the transition can be tested
- * without any DOM, Svelte, or coordinator wiring.
+ * Inputs are the closed union of events the adapter feeds into the pure
+ * transition function (`engine-transition.ts`). Every field is plain data, so
+ * the transition is testable without DOM, Svelte, or coordinator wiring.
  *
  * Adapter→core boundary contract:
- *   - The adapter never mutates engine state directly. It always
- *     constructs an input and calls `core.dispatch(input)`.
- *   - Inputs are total: an unhandled `kind` is a programming error
- *     (the transition uses `assertNever` exhaustiveness).
- *   - Inputs carry only data, never live host references that would
- *     pin lifetime. Coordinator and controller handles live in the
- *     adapter; the core only sees readiness signals derived from them.
+ *   - The adapter never mutates engine state directly. It constructs an input
+ *     and calls `core.dispatch(input)`.
+ *   - The transition switch is exhaustive over `kind`: a new input kind that
+ *     it does not handle fails to type-check.
+ *   - Inputs carry no live host references. Coordinator and controller handles
+ *     live in the adapter; the core sees only readiness signals derived from
+ *     them.
  */
 import type { CohortKey } from "./cohort.js";
 import type { EffectiveRuntime, RuntimeInputs } from "./engine-resolver.js";
 import type { EngineReadinessSignals } from "./engine-readiness.js";
-import type { FrameworkErrorModel } from "../../services/framework-error.js";
 /**
  * `initialize` is the first transition out of `idle`. It carries the
  * cohort key and the resolved runtime/tools snapshot for the cohort.
@@ -60,7 +58,8 @@ export type EngineInputCohortChange = {
  * the controller for the current cohort. Advances the phase from
  * `booting-section` → `engine-ready` (assuming `composed` is already
  * implied by `phase >= booting-section`, which the FSM treats as
- * monotonic).
+ * monotonic), and on to `interactive` when the last readiness snapshot
+ * already satisfies it.
  */
 export type EngineInputSectionControllerResolved = {
     kind: "section-controller-resolved";
@@ -68,7 +67,8 @@ export type EngineInputSectionControllerResolved = {
 /**
  * `update-readiness-signals` carries the latest readiness snapshot
  * from the host. The transition uses it to gate the move into
- * `interactive` and to decide whether to emit `loading-complete`.
+ * `interactive`, to end the chain as `failed` when `runtimeError` is set
+ * before `interactive`, and to decide whether to emit `loading-complete`.
  *
  * The full signal set is sent every time so the transition does not
  * have to reason about partial overlays.
@@ -76,7 +76,6 @@ export type EngineInputSectionControllerResolved = {
 export type EngineInputUpdateReadinessSignals = {
     kind: "update-readiness-signals";
     signals: EngineReadinessSignals;
-    loadedCount: number;
     itemCount: number;
     /**
      * Strict-mode gate. When `"strict"`, `interactive` only fires
@@ -86,26 +85,15 @@ export type EngineInputUpdateReadinessSignals = {
      */
     mode: "progressive" | "strict";
 };
-/**
- * `framework-error` is sent for every framework-error report (M3
- * canonical channel). The transition records the latest error in
- * state and emits a `framework-error` output so the adapter can fan
- * out to subscribers and the DOM event.
- */
-export type EngineInputFrameworkError = {
-    kind: "framework-error";
-    error: FrameworkErrorModel;
-};
 /**
  * `dispose` tears the engine down. Emits `disposed` for the current
- * cohort (if any) and moves to the terminal `disposed` phase. After
- * dispose the engine accepts no further inputs (the transition logs
- * a warning and is a no-op).
+ * cohort (if any) and moves to the terminal `disposed` phase. Every input
+ * after dispose is a no-op.
  */
 export type EngineInputDispose = {
     kind: "dispose";
 };
-export type SectionEngineInput = EngineInputInitialize | EngineInputUpdateRuntime | EngineInputCohortChange | EngineInputSectionControllerResolved | EngineInputUpdateReadinessSignals | EngineInputFrameworkError | EngineInputDispose;
+export type SectionEngineInput = EngineInputInitialize | EngineInputUpdateRuntime | EngineInputCohortChange | EngineInputSectionControllerResolved | EngineInputUpdateReadinessSignals | EngineInputDispose;
 /**
  * Convenience re-export so the adapter can import `RuntimeInputs`
  * from a single place when it constructs `initialize` inputs.

package/dist/runtime/core/engine-input.js

@@ -1,18 +1,17 @@
 /**
- * Section runtime engine inputs (M7 — Variant C, layered core).
+ * Section runtime engine inputs.
  *
- * Inputs are the discriminated union of events the adapter (PR 2) feeds
- * into the pure transition function (`engine-transition.ts`). The shape
- * is closed: every field is plain data so the transition can be tested
- * without any DOM, Svelte, or coordinator wiring.
+ * Inputs are the closed union of events the adapter feeds into the pure
+ * transition function (`engine-transition.ts`). Every field is plain data, so
+ * the transition is testable without DOM, Svelte, or coordinator wiring.
  *
  * Adapter→core boundary contract:
- *   - The adapter never mutates engine state directly. It always
- *     constructs an input and calls `core.dispatch(input)`.
- *   - Inputs are total: an unhandled `kind` is a programming error
- *     (the transition uses `assertNever` exhaustiveness).
- *   - Inputs carry only data, never live host references that would
- *     pin lifetime. Coordinator and controller handles live in the
- *     adapter; the core only sees readiness signals derived from them.
+ *   - The adapter never mutates engine state directly. It constructs an input
+ *     and calls `core.dispatch(input)`.
+ *   - The transition switch is exhaustive over `kind`: a new input kind that
+ *     it does not handle fails to type-check.
+ *   - Inputs carry no live host references. Coordinator and controller handles
+ *     live in the adapter; the core sees only readiness signals derived from
+ *     them.
  */
 export {};

package/dist/runtime/core/engine-output.d.ts

@@ -1,36 +1,22 @@
 /**
- * Section runtime engine outputs (M7 — Variant C, layered core).
+ * Section runtime engine outputs.
  *
- * Outputs are the closed discriminated union of effects the transition
- * function returns. The adapter (PR 2) takes the output array, walks
- * it in order, and dispatches each one to the right bridge (DOM
- * events, framework-error bus, subscriber fan-out).
+ * Outputs are the closed union of effects the transition function returns. The
+ * adapter walks each batch in order and hands it to the DOM-event bridge and the
+ * subscriber fan-out. Outputs carry only plain data, so the transition table is
+ * testable without DOM or coordinator wiring.
  *
- * Outputs carry only plain data so the transition table can be tested
- * exhaustively without any DOM or coordinator wiring.
- *
- * Adjustment A2 from the M7 implementation plan: `loading-complete`
- * is an output, **not** an FSM phase. The transition emits it from
- * the `interactive` phase when the readiness signals indicate every
- * item has finished loading. This mirrors today's
- * `pie-loading-complete` DOM event semantics.
- *
- * Readiness alias output kinds (`readiness-change`,
- * `interaction-ready`, `ready`) were removed in the broad
- * architecture review compat sweep along with their DOM-event bridge
- * event bridge. Stage and readiness changes now flow
- * through `stage-change` (with `EngineReadinessDetail` available via
- * `SectionEngineCore.getState()` / kernel `selectReadiness()`); the
- * "all items loaded" signal flows through `loading-complete` only.
+ * Framework errors are not an output. The toolkit that owns the coordinator
+ * publishes each one once, as its `framework-error` event and `onFrameworkError`
+ * hook; the engine sees an error only through the readiness signals, and a
+ * fatal one before `interactive` ends the cohort's stage chain as `failed`.
  */
 import type { Stage, StageStatus } from "@pie-players/pie-players-shared/pie";
 import type { CohortKey } from "./cohort.js";
-import type { FrameworkErrorModel } from "../../services/framework-error.js";
 /**
- * Stage transition. The adapter dispatches a `pie-stage-change` DOM
- * event with the canonical detail and forwards to subscribers /
- * coordinator. The status indicates whether the stage was entered,
- * skipped, or recorded as failed.
+ * Stage transition. The adapter dispatches it as `pie-stage-change` with the
+ * canonical detail. The status says whether the stage was entered, skipped, or
+ * recorded as failed.
  */
 export type EngineOutputStageChange = {
     kind: "stage-change";
@@ -39,23 +25,13 @@ export type EngineOutputStageChange = {
     cohort: CohortKey | null;
 };
 /**
- * Canonical `pie-loading-complete` emit (M6 D1). One-shot per cohort.
- * Fires from the `interactive` phase when loaded == items count and
- * the readiness signals satisfy `allLoadingComplete`.
+ * Canonical `pie-loading-complete`. One-shot per cohort, emitted when the
+ * readiness signals satisfy `allLoadingComplete`, so every one of `itemCount`
+ * items has loaded.
  */
 export type EngineOutputLoadingComplete = {
     kind: "loading-complete";
     cohort: CohortKey;
     itemCount: number;
-    loadedCount: number;
-};
-/**
- * Framework error fan-out. Mirrors the M3 `framework-error` DOM event
- * and the `subscribeFrameworkErrors` listener channel. Emitted on
- * every `framework-error` input.
- */
-export type EngineOutputFrameworkError = {
-    kind: "framework-error";
-    error: FrameworkErrorModel;
 };
-export type SectionEngineOutput = EngineOutputStageChange | EngineOutputLoadingComplete | EngineOutputFrameworkError;
+export type SectionEngineOutput = EngineOutputStageChange | EngineOutputLoadingComplete;

package/dist/runtime/core/engine-output.js

@@ -1,26 +1,14 @@
 /**
- * Section runtime engine outputs (M7 — Variant C, layered core).
+ * Section runtime engine outputs.
  *
- * Outputs are the closed discriminated union of effects the transition
- * function returns. The adapter (PR 2) takes the output array, walks
- * it in order, and dispatches each one to the right bridge (DOM
- * events, framework-error bus, subscriber fan-out).
+ * Outputs are the closed union of effects the transition function returns. The
+ * adapter walks each batch in order and hands it to the DOM-event bridge and the
+ * subscriber fan-out. Outputs carry only plain data, so the transition table is
+ * testable without DOM or coordinator wiring.
  *
- * Outputs carry only plain data so the transition table can be tested
- * exhaustively without any DOM or coordinator wiring.
- *
- * Adjustment A2 from the M7 implementation plan: `loading-complete`
- * is an output, **not** an FSM phase. The transition emits it from
- * the `interactive` phase when the readiness signals indicate every
- * item has finished loading. This mirrors today's
- * `pie-loading-complete` DOM event semantics.
- *
- * Readiness alias output kinds (`readiness-change`,
- * `interaction-ready`, `ready`) were removed in the broad
- * architecture review compat sweep along with their DOM-event bridge
- * event bridge. Stage and readiness changes now flow
- * through `stage-change` (with `EngineReadinessDetail` available via
- * `SectionEngineCore.getState()` / kernel `selectReadiness()`); the
- * "all items loaded" signal flows through `loading-complete` only.
+ * Framework errors are not an output. The toolkit that owns the coordinator
+ * publishes each one once, as its `framework-error` event and `onFrameworkError`
+ * hook; the engine sees an error only through the readiness signals, and a
+ * fatal one before `interactive` ends the cohort's stage chain as `failed`.
  */
 export {};

package/dist/runtime/core/engine-readiness.d.ts

@@ -1,48 +1,16 @@
 /**
- * Readiness derivation for the section runtime engine (M7).
- *
- * Canonical home of `createReadinessDetail` and `resolveReadinessPhase`.
- * As of M7 PR 7 the previous duplicates in
- * `packages/section-player/src/components/shared/section-player-readiness.ts`
- * have been deleted; section-player now consumes these helpers via
- * `@pie-players/pie-assessment-toolkit/runtime/internal`.
- *
- * Type duplication note: the public DOM-event detail aliases
- * (`SectionPlayerReadinessChangeDetail` /
- * `SectionPlayerReadinessPhase`) still live in section-player's
- * `contracts/public-events.ts` because that file is part of section-
- * player's published custom-element contract. The toolkit core defines
- * `EngineReadinessPhase` independently so it has zero section-player
- * imports. The two definitions must stay structurally identical;
- * that invariant is covered by the readiness assertions in this
- * package's tests, which mirror the section-player suite.
+ * Readiness gating for the section runtime engine: which of the host's
+ * readiness signals open `interactive` and `loading-complete` under the
+ * section's readiness mode.
  */
-/**
- * Coarse readiness phase label, derived from the four readiness
- * signals. Surfaced via the kernel's `selectReadiness()` /
- * `getSnapshot().readiness` selectors; M6 stages own the stage-level
- * transitions on `pie-stage-change` and use this phase as a
- * convenience label only. The `readiness-change` DOM
- * event that used to surface this directly was removed in the broad
- * architecture review compat sweep alongside its
- * event bridge.
- */
-export type EngineReadinessPhase = "bootstrapping" | "interaction-ready" | "loading" | "ready" | "error";
 export type EngineReadinessSignals = {
     sectionReady: boolean;
     interactionReady: boolean;
     allLoadingComplete: boolean;
     runtimeError: boolean;
 };
-export type EngineReadinessDetail = {
-    phase: EngineReadinessPhase;
+export type EngineReadinessGates = {
     interactionReady: boolean;
     allLoadingComplete: boolean;
-    reason?: string;
 };
-export declare function resolveReadinessPhase(signals: EngineReadinessSignals): EngineReadinessPhase;
-export declare function createReadinessDetail(args: {
-    mode: "progressive" | "strict";
-    signals: EngineReadinessSignals;
-    reason?: string;
-}): EngineReadinessDetail;
+export declare function resolveReadinessGates(mode: "progressive" | "strict", signals: EngineReadinessSignals): EngineReadinessGates;

package/dist/runtime/core/engine-readiness.js

@@ -1,46 +1,13 @@
 /**
- * Readiness derivation for the section runtime engine (M7).
- *
- * Canonical home of `createReadinessDetail` and `resolveReadinessPhase`.
- * As of M7 PR 7 the previous duplicates in
- * `packages/section-player/src/components/shared/section-player-readiness.ts`
- * have been deleted; section-player now consumes these helpers via
- * `@pie-players/pie-assessment-toolkit/runtime/internal`.
- *
- * Type duplication note: the public DOM-event detail aliases
- * (`SectionPlayerReadinessChangeDetail` /
- * `SectionPlayerReadinessPhase`) still live in section-player's
- * `contracts/public-events.ts` because that file is part of section-
- * player's published custom-element contract. The toolkit core defines
- * `EngineReadinessPhase` independently so it has zero section-player
- * imports. The two definitions must stay structurally identical;
- * that invariant is covered by the readiness assertions in this
- * package's tests, which mirror the section-player suite.
+ * Readiness gating for the section runtime engine: which of the host's
+ * readiness signals open `interactive` and `loading-complete` under the
+ * section's readiness mode.
  */
-export function resolveReadinessPhase(signals) {
-    if (signals.runtimeError)
-        return "error";
-    if (signals.allLoadingComplete)
-        return "ready";
-    if (signals.interactionReady)
-        return "interaction-ready";
-    if (signals.sectionReady)
-        return "loading";
-    return "bootstrapping";
-}
-export function createReadinessDetail(args) {
-    // Final ready must always be gated by section lifecycle and complete loading.
-    const finalReady = args.signals.sectionReady && args.signals.allLoadingComplete;
-    const interactionReady = args.mode === "strict" ? finalReady : args.signals.interactionReady;
-    const phase = resolveReadinessPhase({
-        ...args.signals,
-        allLoadingComplete: finalReady,
-        interactionReady,
-    });
+export function resolveReadinessGates(mode, signals) {
+    // Final ready is always gated by the section lifecycle and complete loading.
+    const allLoadingComplete = signals.sectionReady && signals.allLoadingComplete;
     return {
-        phase,
-        interactionReady,
-        allLoadingComplete: finalReady,
-        reason: args.reason,
+        interactionReady: mode === "strict" ? allLoadingComplete : signals.interactionReady,
+        allLoadingComplete,
     };
 }

package/dist/runtime/core/engine-resolver.d.ts

@@ -1,11 +1,9 @@
 /**
- * Section runtime engine resolver (M7).
+ * Section runtime engine resolver.
  *
  * Canonical home of `resolveRuntime`, `resolveToolsConfig`, and their
- * supporting helpers/types. As of M7 PR 7 the previous duplicates in
- * `packages/section-player/src/components/shared/section-player-runtime.ts`
- * have been deleted; section-player now consumes these helpers via
- * `@pie-players/pie-assessment-toolkit/runtime/internal`.
+ * supporting helpers/types; section-player consumes them through
+ * `@pie-players/pie-assessment-toolkit/runtime/engine`.
  *
  * What is NOT absorbed in this module:
  * - `resolvePlayerRuntime` stays in section-player because it depends on
@@ -18,22 +16,26 @@
  *   `packages/section-player/src/components/shared/section-player-host-runtime.ts`)
  *   hands its local implementation in.
  *
- * Runtime-owned configuration flows through `runtime.<key>`. Layout-only
- * inputs stay on the section-player host elements.
+ * Each input has one tier. `assessmentId`, the tools and player config and the
+ * `on*` callbacks arrive on `runtime`. The primitive inputs (`nds-icons`,
+ * `locale`, `tool-config-strictness`) are element attributes; the resolver takes
+ * `toolConfigStrictness` beside `runtime`.
  */
 import type { LoaderConfig } from "@pie-players/pie-players-shared/loader-config";
 import type { LoadingCompleteDetail, StageChangeDetail } from "@pie-players/pie-players-shared/pie";
 import type { FrameworkErrorModel } from "../../services/framework-error.js";
 import type { ToolConfigStrictness } from "../../services/tool-config-validation.js";
-export declare const DEFAULT_ASSESSMENT_ID = "section-demo-direct";
 export declare const DEFAULT_PLAYER_TYPE = "iife";
-export declare const DEFAULT_LAZY_INIT = true;
+export declare const DEFAULT_LAZY_INIT = false;
 export declare const DEFAULT_ISOLATION = "inherit";
 export declare const DEFAULT_ENV: Record<string, unknown>;
 export type PlayerOverrides = {
+    /** The host has already loaded the item bundles; the player loads none. */
+    hosted?: boolean;
     loaderConfig?: LoaderConfig;
     loaderOptions?: Record<string, unknown>;
-    [key: string]: unknown;
+    /** The item player's `backend` config, passed through unread. */
+    backend?: Record<string, unknown> | null;
 };
 export type FrameworkErrorHandler = (model: FrameworkErrorModel) => void;
 export type StageChangeHandler = (detail: StageChangeDetail) => void;
@@ -61,48 +63,34 @@ export type RuntimeConfig = {
     isolation?: string;
     env?: Record<string, unknown>;
     /**
-     * Presentation flag: opt-in to the vendored `<nds-icon-button>` for the
-     * toolbar tool buttons, the calculator shell controls, inline-TTS
-     * play/pause, and the section scroll-hint. NDS icons render only when
-     * this is explicitly `true`; unset/`false` keeps the plain `<button>`
-     * markup (the default). Purely visual — no engine effect.
-     */
-    ndsIcons?: boolean;
-    /**
-     * Interface locale: a BCP-47 tag naming the language the player renders its own
-     * UI in. Purely presentational — no engine effect.
-     *
-     * Distinct from content language, which describes the authored item and
-     * travels on `env`. QTI 3's implementation guide states the independence
-     * directly: a candidate may choose an interface language which may or may not
-     * also be the language of the content.
+     * Content language: a BCP-47 tag naming the language the authored content is
+     * written in, which read-aloud speaks it in and catalog lookups select
+     * alternates by. A `lang` in the content's markup wins over it. Purely
+     * presentational — no engine effect.
      *
-     * Unset renders `en-US`. POSIX (`nl_NL`) and bare (`nl`) forms both resolve.
+     * Unset reads as `en-US` wherever the markup names no language.
      */
-    locale?: string;
-    toolConfigStrictness?: ToolConfigStrictness;
+    contentLanguage?: string;
     onFrameworkError?: FrameworkErrorHandler;
+    /** Called with each `pie-stage-change` detail. */
     onStageChange?: StageChangeHandler;
+    /** Called with each `pie-loading-complete` detail. */
     onLoadingComplete?: LoadingCompleteHandler;
 };
 export type RuntimeInputs = {
-    assessmentId?: string;
-    toolConfigStrictness?: ToolConfigStrictness;
-    onFrameworkError?: FrameworkErrorHandler;
-    onStageChange?: StageChangeHandler;
-    onLoadingComplete?: LoadingCompleteHandler;
     runtime: RuntimeConfig | null;
+    toolConfigStrictness?: ToolConfigStrictness;
 };
 /**
- * Resolve the canonical `onFrameworkError` handler from the two-tier
- * surface. Precedence (highest first): `runtime.onFrameworkError`,
- * then top-level `onFrameworkError`. Layout CEs and the kernel call
- * this so every entry point converges on the same handler.
+ * The id a section runs under: the host's `section-id`, else the section's own
+ * `identifier`, else one named after the assessment. The toolkit keys the
+ * section's controller by it, and the layout kernel its stage cohort.
  */
-export declare function resolveOnFrameworkError(args: {
-    runtime: RuntimeConfig | null;
-    onFrameworkError?: FrameworkErrorHandler;
-}): FrameworkErrorHandler | undefined;
+export declare function resolveSectionId(args: {
+    sectionId?: string | null;
+    section?: unknown;
+    assessmentId?: string | null;
+}): string;
 export declare function resolveToolsConfig(args: {
     runtime: RuntimeConfig | null;
 }): {
@@ -111,20 +99,18 @@ export declare function resolveToolsConfig(args: {
     };
 };
 export declare function resolveRuntime(args: {
-    assessmentId: string;
     runtime: RuntimeConfig | null;
     effectiveToolsConfig: unknown;
     toolConfigStrictness?: ToolConfigStrictness;
-    onFrameworkError?: FrameworkErrorHandler;
-    onStageChange?: StageChangeHandler;
-    onLoadingComplete?: LoadingCompleteHandler;
 }): {
-    assessmentId: string | undefined;
     playerType: string;
     player: {
-        [key: string]: unknown;
+        /** The host has already loaded the item bundles; the player loads none. */
+        hosted?: boolean;
         loaderConfig?: LoaderConfig;
         loaderOptions?: Record<string, unknown>;
+        /** The item player's `backend` config, passed through unread. */
+        backend?: Record<string, unknown> | null;
     } | null;
     lazyInit: boolean;
     accessibility: Record<string, unknown> | null;
@@ -132,39 +118,25 @@ export declare function resolveRuntime(args: {
     createSectionController: unknown;
     isolation: string;
     env: Record<string, unknown>;
-    toolConfigStrictness: "off" | "error" | "warn";
-    onFrameworkError: FrameworkErrorHandler | undefined;
-    onStageChange: StageChangeHandler | undefined;
-    onLoadingComplete: LoadingCompleteHandler | undefined;
+    toolConfigStrictness: ToolConfigStrictness;
     tools: unknown;
+    assessmentId?: string;
     toolContextResolvers?: Record<string, unknown> | null;
     /**
-     * Presentation flag: opt-in to the vendored `<nds-icon-button>` for the
-     * toolbar tool buttons, the calculator shell controls, inline-TTS
-     * play/pause, and the section scroll-hint. NDS icons render only when
-     * this is explicitly `true`; unset/`false` keeps the plain `<button>`
-     * markup (the default). Purely visual — no engine effect.
-     */
-    ndsIcons?: boolean;
-    /**
-     * Interface locale: a BCP-47 tag naming the language the player renders its own
-     * UI in. Purely presentational — no engine effect.
+     * Content language: a BCP-47 tag naming the language the authored content is
+     * written in, which read-aloud speaks it in and catalog lookups select
+     * alternates by. A `lang` in the content's markup wins over it. Purely
+     * presentational — no engine effect.
      *
-     * Distinct from content language, which describes the authored item and
-     * travels on `env`. QTI 3's implementation guide states the independence
-     * directly: a candidate may choose an interface language which may or may not
-     * also be the language of the content.
-     *
-     * Unset renders `en-US`. POSIX (`nl_NL`) and bare (`nl`) forms both resolve.
+     * Unset reads as `en-US` wherever the markup names no language.
      */
-    locale?: string;
+    contentLanguage?: string;
+    onFrameworkError?: FrameworkErrorHandler;
+    /** Called with each `pie-stage-change` detail. */
+    onStageChange?: StageChangeHandler;
+    /** Called with each `pie-loading-complete` detail. */
+    onLoadingComplete?: LoadingCompleteHandler;
 };
-/**
- * Effective runtime returned by `resolveRuntime`. The shape is exposed
- * as `unknown` at the public boundary because consumers spread it into
- * arbitrary host props; downstream call sites narrow with the specific
- * keys they need.
- */
 export type EffectiveRuntime = ReturnType<typeof resolveRuntime>;
 /**
  * Engine-side orchestrator that powers `resolveSectionPlayerRuntimeState`