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

package/dist/runtime/adapter/coordinator-bridge.d.ts

@@ -1,92 +0,0 @@
-/**
- * Coordinator bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Unlike the DOM / framework-error bridges (which translate
- * **outputs** into I/O), the coordinator bridge is an **input source**:
- * it listens to a `ToolkitCoordinator` and feeds the resulting events
- * into the core via the `dispatchCoreInput` callback supplied by the
- * adapter.
- *
- * Responsibilities:
- *   1. **Framework-error subscription.** When the coordinator reports
- *      a framework error through its bus, dispatch a
- *      `{ kind: "framework-error" }` core input. Listener isolation
- *      matches `FrameworkErrorBus`: a throwing bridge handler is
- *      caught and `console.warn`-logged so the original fan-out is
- *      not interrupted.
- *
- *   2. **Section-controller resolution.** When the host calls
- *      `resolveSectionController({ ... })`, the bridge invokes
- *      `coordinator.getOrCreateSectionController({ ... })` and, on
- *      successful resolution, dispatches
- *      `{ kind: "section-controller-resolved" }` to the core. Init
- *      tokens guard against late resolutions overwriting a more
- *      recent cohort (mirrors `SectionRuntimeEngine.initialize`'s
- *      `activeInitToken` pattern).
- *
- *   3. **Disposal.** On `dispose()`, the bridge unsubscribes from the
- *      framework-error bus and (if the engine owns the section
- *      controller for the cohort) calls
- *      `coordinator.disposeSectionController({ ... })`. It does
- *      **not** dispose the coordinator itself — the coordinator's
- *      lifetime is owned by the toolkit CE / host, not by the engine.
- *
- * Disposal is idempotent: calling `dispose()` twice is a no-op.
- *
- * The bridge **must not** import `svelte`.
- */
-import type { SectionControllerHandle } from "../../services/section-controller-types.js";
-import type { CohortKey } from "../core/cohort.js";
-import type { SectionEngineInput } from "../core/engine-input.js";
-/**
- * Subset of the `ToolkitCoordinator` surface the bridge consumes. Kept
- * structural so tests can pass a fake without pulling the full
- * coordinator.
- */
-export interface CoordinatorPort {
-    subscribeFrameworkErrors(listener: (model: import("../../services/framework-error.js").FrameworkErrorModel) => void): () => void;
-    getOrCreateSectionController(args: {
-        sectionId: string;
-        attemptId?: string;
-        input?: unknown;
-        updateExisting?: boolean;
-        createDefaultController: () => SectionControllerHandle | Promise<SectionControllerHandle>;
-    }): Promise<SectionControllerHandle>;
-    disposeSectionController(args: {
-        sectionId: string;
-        attemptId?: string;
-    }): Promise<void>;
-}
-export interface ResolveSectionControllerArgs {
-    cohort: CohortKey;
-    assessmentId: string;
-    view: string;
-    section: unknown;
-    createDefaultController: () => SectionControllerHandle | Promise<SectionControllerHandle>;
-    /**
-     * Optional callback invoked when the controller resolves and on
-     * every controller `subscribe` event. The kernel uses this to keep
-     * its composition snapshot in sync with the controller's view.
-     *
-     * The bridge is responsible for unsubscribing on dispose / cohort
-     * change so a stale controller doesn't keep emitting after rollover.
-     */
-    onCompositionChanged?: (composition: unknown) => void;
-    /**
-     * Optional callback invoked once with the resolved controller handle
-     * the moment it is available. Lets the host keep a reference for
-     * direct method calls (e.g. `navigateToItem`, `applySession`)
-     * without re-querying the coordinator.
-     */
-    onControllerResolved?: (controller: SectionControllerHandle) => void;
-}
-export interface CoordinatorBridgeOptions {
-    coordinator: CoordinatorPort;
-    dispatchCoreInput: (input: SectionEngineInput) => void;
-}
-export interface CoordinatorBridgeHandle {
-    resolveSectionController(args: ResolveSectionControllerArgs): Promise<void>;
-    dispose(): Promise<void>;
-}
-export declare function createCoordinatorBridge(options: CoordinatorBridgeOptions): CoordinatorBridgeHandle;

package/dist/runtime/adapter/coordinator-bridge.js

@@ -1,126 +0,0 @@
-/**
- * Coordinator bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Unlike the DOM / framework-error bridges (which translate
- * **outputs** into I/O), the coordinator bridge is an **input source**:
- * it listens to a `ToolkitCoordinator` and feeds the resulting events
- * into the core via the `dispatchCoreInput` callback supplied by the
- * adapter.
- *
- * Responsibilities:
- *   1. **Framework-error subscription.** When the coordinator reports
- *      a framework error through its bus, dispatch a
- *      `{ kind: "framework-error" }` core input. Listener isolation
- *      matches `FrameworkErrorBus`: a throwing bridge handler is
- *      caught and `console.warn`-logged so the original fan-out is
- *      not interrupted.
- *
- *   2. **Section-controller resolution.** When the host calls
- *      `resolveSectionController({ ... })`, the bridge invokes
- *      `coordinator.getOrCreateSectionController({ ... })` and, on
- *      successful resolution, dispatches
- *      `{ kind: "section-controller-resolved" }` to the core. Init
- *      tokens guard against late resolutions overwriting a more
- *      recent cohort (mirrors `SectionRuntimeEngine.initialize`'s
- *      `activeInitToken` pattern).
- *
- *   3. **Disposal.** On `dispose()`, the bridge unsubscribes from the
- *      framework-error bus and (if the engine owns the section
- *      controller for the cohort) calls
- *      `coordinator.disposeSectionController({ ... })`. It does
- *      **not** dispose the coordinator itself — the coordinator's
- *      lifetime is owned by the toolkit CE / host, not by the engine.
- *
- * Disposal is idempotent: calling `dispose()` twice is a no-op.
- *
- * The bridge **must not** import `svelte`.
- */
-export function createCoordinatorBridge(options) {
-    const { coordinator, dispatchCoreInput } = options;
-    let activeInitToken = 0;
-    let activeCohort = null;
-    let unsubscribeController = null;
-    let disposed = false;
-    const unsubscribeFrameworkErrors = coordinator.subscribeFrameworkErrors((model) => {
-        try {
-            dispatchCoreInput({ kind: "framework-error", error: model });
-        }
-        catch (error) {
-            console.warn("[CoordinatorBridge] framework-error dispatch failed:", error);
-        }
-    });
-    function detachControllerSubscription() {
-        if (!unsubscribeController)
-            return;
-        try {
-            unsubscribeController();
-        }
-        catch (error) {
-            console.warn("[CoordinatorBridge] controller unsubscribe failed:", error);
-        }
-        unsubscribeController = null;
-    }
-    async function resolveSectionController(args) {
-        if (disposed)
-            return;
-        activeInitToken += 1;
-        const token = activeInitToken;
-        activeCohort = args.cohort;
-        const controller = await coordinator.getOrCreateSectionController({
-            sectionId: args.cohort.sectionId,
-            attemptId: args.cohort.attemptId || undefined,
-            input: {
-                section: args.section,
-                sectionId: args.cohort.sectionId,
-                assessmentId: args.assessmentId,
-                view: args.view,
-            },
-            updateExisting: true,
-            createDefaultController: args.createDefaultController,
-        });
-        // Drop late resolutions — a cohort change or dispose may have
-        // rolled the token forward while we awaited the coordinator.
-        if (token !== activeInitToken || disposed)
-            return;
-        detachControllerSubscription();
-        args.onControllerResolved?.(controller);
-        const getCompositionModel = controller.getCompositionModel;
-        args.onCompositionChanged?.(getCompositionModel?.());
-        if (typeof controller.subscribe === "function") {
-            unsubscribeController = controller.subscribe((_event) => {
-                if (token !== activeInitToken || disposed)
-                    return;
-                args.onCompositionChanged?.(getCompositionModel?.());
-            });
-        }
-        dispatchCoreInput({ kind: "section-controller-resolved" });
-    }
-    async function dispose() {
-        if (disposed)
-            return;
-        disposed = true;
-        activeInitToken += 1;
-        detachControllerSubscription();
-        try {
-            unsubscribeFrameworkErrors();
-        }
-        catch (error) {
-            console.warn("[CoordinatorBridge] framework-error unsubscribe failed:", error);
-        }
-        const cohort = activeCohort;
-        activeCohort = null;
-        if (cohort) {
-            try {
-                await coordinator.disposeSectionController({
-                    sectionId: cohort.sectionId,
-                    attemptId: cohort.attemptId || undefined,
-                });
-            }
-            catch (error) {
-                console.warn("[CoordinatorBridge] section-controller dispose failed:", error);
-            }
-        }
-    }
-    return { resolveSectionController, dispose };
-}

package/dist/runtime/adapter/framework-error-bridge.d.ts

@@ -1,36 +0,0 @@
-/**
- * Framework-error bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Routes `framework-error` engine outputs into a `FrameworkErrorBus`
- * (write side: `FrameworkErrorReporter`). The bus is the single
- * fan-out point shared with the toolkit CE's banner, the coordinator's
- * canonical `onFrameworkError` lifecycle hook, and any direct host
- * subscribers via `subscribeFrameworkErrors`. See
- * `packages/assessment-toolkit/src/services/framework-error-bus.ts`
- * for the full bus contract.
- *
- * **Why a separate bridge.** The dom-event-bridge dispatches the
- * `framework-error` DOM event on the host. The framework-error-bridge
- * routes the same model into the in-process bus so listeners that
- * subscribe via `coordinator.subscribeFrameworkErrors(...)` see the
- * same fan-out with byte-identical payloads. Splitting the
- * responsibilities lets a host opt out of either side (DOM-only or
- * bus-only) without re-implementing the other.
- *
- * **Bus ownership.** The bridge does not construct the bus; the
- * adapter receives one externally so the toolkit CE can keep sharing
- * its bus with the coordinator (matching today's
- * `PieAssessmentToolkit.svelte` lifetime model). This avoids the
- * "second bus" pitfall — a dual-bus topology would silently fragment
- * fan-out.
- */
-import type { FrameworkErrorReporter } from "../../services/framework-error-bus.js";
-import type { SectionEngineOutput } from "../core/engine-output.js";
-export interface FrameworkErrorBridgeOptions {
-    bus: FrameworkErrorReporter;
-}
-export interface FrameworkErrorBridgeHandle {
-    dispatch(output: SectionEngineOutput): void;
-}
-export declare function createFrameworkErrorBridge(options: FrameworkErrorBridgeOptions): FrameworkErrorBridgeHandle;

package/dist/runtime/adapter/framework-error-bridge.js

@@ -1,46 +0,0 @@
-/**
- * Framework-error bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Routes `framework-error` engine outputs into a `FrameworkErrorBus`
- * (write side: `FrameworkErrorReporter`). The bus is the single
- * fan-out point shared with the toolkit CE's banner, the coordinator's
- * canonical `onFrameworkError` lifecycle hook, and any direct host
- * subscribers via `subscribeFrameworkErrors`. See
- * `packages/assessment-toolkit/src/services/framework-error-bus.ts`
- * for the full bus contract.
- *
- * **Why a separate bridge.** The dom-event-bridge dispatches the
- * `framework-error` DOM event on the host. The framework-error-bridge
- * routes the same model into the in-process bus so listeners that
- * subscribe via `coordinator.subscribeFrameworkErrors(...)` see the
- * same fan-out with byte-identical payloads. Splitting the
- * responsibilities lets a host opt out of either side (DOM-only or
- * bus-only) without re-implementing the other.
- *
- * **Bus ownership.** The bridge does not construct the bus; the
- * adapter receives one externally so the toolkit CE can keep sharing
- * its bus with the coordinator (matching today's
- * `PieAssessmentToolkit.svelte` lifetime model). This avoids the
- * "second bus" pitfall — a dual-bus topology would silently fragment
- * fan-out.
- */
-export function createFrameworkErrorBridge(options) {
-    const { bus } = options;
-    function dispatch(output) {
-        switch (output.kind) {
-            case "framework-error":
-                bus.reportFrameworkError(output.error);
-                return;
-            case "stage-change":
-            case "loading-complete":
-                return;
-            default: {
-                const exhaustive = output;
-                void exhaustive;
-                return;
-            }
-        }
-    }
-    return { dispatch };
-}

package/dist/runtime/adapter/instrumentation-bridge.d.ts

@@ -1,31 +0,0 @@
-/**
- * Instrumentation bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Forwards every `SectionEngineOutput` to an optional observability
- * hook the host injects (telemetry, debug logger, e2e probe). The
- * bridge is intentionally thin: it does not buffer, transform, or
- * filter. Hosts that need a different shape can run their own subscriber
- * via the adapter's public `subscribe(...)` channel.
- *
- * **Why a dedicated bridge instead of a generic subscriber.** The
- * subscriber-fanout channel is host-shaped — listeners receive batched
- * arrays of outputs per `core.dispatch` call so they can reason about
- * "what happened in this transition." The instrumentation hook is
- * per-output: telemetry pipelines want one record per stage change,
- * one record per readiness flip, etc. Splitting the channels keeps
- * both shapes ergonomic.
- *
- * The bridge **must not** import `svelte` per the M7 layering
- * constraint.
- */
-import type { SectionEngineOutput } from "../core/engine-output.js";
-export type InstrumentationHook = (output: SectionEngineOutput) => void;
-export interface InstrumentationBridgeOptions {
-    hook?: InstrumentationHook;
-}
-export interface InstrumentationBridgeHandle {
-    dispatch(output: SectionEngineOutput): void;
-    setHook(hook: InstrumentationHook | undefined): void;
-}
-export declare function createInstrumentationBridge(options?: InstrumentationBridgeOptions): InstrumentationBridgeHandle;

package/dist/runtime/adapter/instrumentation-bridge.js

@@ -1,38 +0,0 @@
-/**
- * Instrumentation bridge for the section runtime engine adapter (M7 —
- * Variant C, layered).
- *
- * Forwards every `SectionEngineOutput` to an optional observability
- * hook the host injects (telemetry, debug logger, e2e probe). The
- * bridge is intentionally thin: it does not buffer, transform, or
- * filter. Hosts that need a different shape can run their own subscriber
- * via the adapter's public `subscribe(...)` channel.
- *
- * **Why a dedicated bridge instead of a generic subscriber.** The
- * subscriber-fanout channel is host-shaped — listeners receive batched
- * arrays of outputs per `core.dispatch` call so they can reason about
- * "what happened in this transition." The instrumentation hook is
- * per-output: telemetry pipelines want one record per stage change,
- * one record per readiness flip, etc. Splitting the channels keeps
- * both shapes ergonomic.
- *
- * The bridge **must not** import `svelte` per the M7 layering
- * constraint.
- */
-export function createInstrumentationBridge(options = {}) {
-    let hook = options.hook;
-    function dispatch(output) {
-        if (!hook)
-            return;
-        try {
-            hook(output);
-        }
-        catch (error) {
-            console.warn("[InstrumentationBridge] hook failed:", error);
-        }
-    }
-    function setHook(next) {
-        hook = next;
-    }
-    return { dispatch, setHook };
-}

package/dist/runtime/core/engine-stage-derivation.d.ts

@@ -1,18 +0,0 @@
-/**
- * Stage derivation for the section runtime engine (M7).
- *
- * Maps the FSM phase onto the canonical M6 stage vocabulary
- * (`composed`, `engine-ready`, `interactive`, `disposed`). The phase
- * `idle` is the engine's "no cohort yet" state and has no stage; it
- * returns `null`.
- *
- * This module exists as a one-line indirection because:
- *   - The adapter uses it to guard `pie-stage-change` emit calls.
- *   - The transition uses it (via the pure helper below) to decide
- *     when to emit `stage-change` outputs as the phase advances.
- *   - Future shape-specific stages (e.g. layout-only `paginated`) can
- *     be wired in here without rewriting callers.
- */
-import type { Stage } from "@pie-players/pie-players-shared/pie";
-import type { SectionEnginePhase } from "./engine-state.js";
-export declare function phaseToStage(phase: SectionEnginePhase): Stage | null;

package/dist/runtime/core/engine-stage-derivation.js

@@ -1,29 +0,0 @@
-/**
- * Stage derivation for the section runtime engine (M7).
- *
- * Maps the FSM phase onto the canonical M6 stage vocabulary
- * (`composed`, `engine-ready`, `interactive`, `disposed`). The phase
- * `idle` is the engine's "no cohort yet" state and has no stage; it
- * returns `null`.
- *
- * This module exists as a one-line indirection because:
- *   - The adapter uses it to guard `pie-stage-change` emit calls.
- *   - The transition uses it (via the pure helper below) to decide
- *     when to emit `stage-change` outputs as the phase advances.
- *   - Future shape-specific stages (e.g. layout-only `paginated`) can
- *     be wired in here without rewriting callers.
- */
-export function phaseToStage(phase) {
-    switch (phase) {
-        case "idle":
-            return null;
-        case "booting-section":
-            return "composed";
-        case "engine-ready":
-            return "engine-ready";
-        case "interactive":
-            return "interactive";
-        case "disposed":
-            return "disposed";
-    }
-}

package/dist/runtime/engine-context.d.ts

@@ -1,39 +0,0 @@
-/**
- * Svelte context key for the section runtime engine (M7 PR 5).
- *
- * Components inside a section player layout consume the engine through
- * Svelte's native `getContext(SECTION_RUNTIME_ENGINE_KEY)`. The kernel
- * (`SectionPlayerLayoutKernel.svelte`) is the canonical provider — it
- * constructs the engine, attaches it to the layout CE host, and exposes
- * it to descendants via `setContext(SECTION_RUNTIME_ENGINE_KEY, engine)`.
- *
- * The contract is one-directional:
- *   - Provider: the component that owns engine lifetime (kernel today;
- *     in M7 PR 6 the toolkit CE will fall back to constructing its own
- *     engine when no upstream provider is present).
- *   - Consumers: any descendant Svelte component that needs to read
- *     state, subscribe to outputs, or feed inputs (e.g. the toolkit CE
- *     reaching the engine through the wrapping kernel).
- *
- * The key is a `Symbol` so it cannot collide with userland context keys
- * and so descendants are forced to import this module rather than
- * guess a string id.
- *
- * **Stability.** This export is part of the stable runtime/engine
- * surface; renaming or replacing the symbol is a major breaking
- * change. Adding adjacent context keys (e.g. for dedicated read-only
- * snapshots) is allowed.
- */
-import type { SectionRuntimeEngine } from "./SectionRuntimeEngine.js";
-/**
- * Svelte context key under which a `SectionRuntimeEngine` instance is
- * provided to descendants.
- */
-export declare const SECTION_RUNTIME_ENGINE_KEY: unique symbol;
-/**
- * Type-level alias for the value stored under
- * `SECTION_RUNTIME_ENGINE_KEY`. Exposed as a separate alias so
- * consumers can spell the type without importing the implementing
- * class directly.
- */
-export type SectionRuntimeEngineContext = SectionRuntimeEngine;

package/dist/runtime/engine-context.js

@@ -1,31 +0,0 @@
-/**
- * Svelte context key for the section runtime engine (M7 PR 5).
- *
- * Components inside a section player layout consume the engine through
- * Svelte's native `getContext(SECTION_RUNTIME_ENGINE_KEY)`. The kernel
- * (`SectionPlayerLayoutKernel.svelte`) is the canonical provider — it
- * constructs the engine, attaches it to the layout CE host, and exposes
- * it to descendants via `setContext(SECTION_RUNTIME_ENGINE_KEY, engine)`.
- *
- * The contract is one-directional:
- *   - Provider: the component that owns engine lifetime (kernel today;
- *     in M7 PR 6 the toolkit CE will fall back to constructing its own
- *     engine when no upstream provider is present).
- *   - Consumers: any descendant Svelte component that needs to read
- *     state, subscribe to outputs, or feed inputs (e.g. the toolkit CE
- *     reaching the engine through the wrapping kernel).
- *
- * The key is a `Symbol` so it cannot collide with userland context keys
- * and so descendants are forced to import this module rather than
- * guess a string id.
- *
- * **Stability.** This export is part of the stable runtime/engine
- * surface; renaming or replacing the symbol is a major breaking
- * change. Adding adjacent context keys (e.g. for dedicated read-only
- * snapshots) is allowed.
- */
-/**
- * Svelte context key under which a `SectionRuntimeEngine` instance is
- * provided to descendants.
- */
-export const SECTION_RUNTIME_ENGINE_KEY = Symbol("@pie-players/section-runtime-engine");

package/dist/runtime/internal.d.ts

@@ -1,43 +0,0 @@
-/**
- * Section runtime engine — **internal** entry point (M7 — Variant C).
- *
- * Re-exports the layered core + adapter surface for advanced hosts that
- * want to construct or inspect engines directly, and for the engine's
- * own tests / benchmarks.
- *
- * **Stability posture.** This module is **not** part of the stable
- * public API. Symbols here are subject to change between minor versions
- * with only a changeset note. Hosts that need long-term stability
- * should depend on the facade (`SectionRuntimeEngine` exported from
- * `./runtime/engine`) instead.
- *
- * The split is intentional:
- *   - `./runtime/engine` (PR 3) — narrow, stable facade for common
- *     host wiring.
- *   - `./runtime/internal` — wide, evolving surface for the kernel,
- *     adapter tests, and any host that wants to reach past the facade.
- *
- * The `runtime/engine` and `runtime/internal` package `exports` map
- * entries are added in PR 3 alongside the facade refactor.
- */
-export { SectionEngineAdapter } from "./adapter/SectionEngineAdapter.js";
-export type { SectionEngineAdapterOptions } from "./adapter/SectionEngineAdapter.js";
-export { FrameworkErrorBus, type FrameworkErrorListener, type FrameworkErrorPort, type FrameworkErrorReporter, } from "../services/framework-error-bus.js";
-export { createCoordinatorBridge, type CoordinatorBridgeHandle, type CoordinatorBridgeOptions, type CoordinatorPort, type ResolveSectionControllerArgs, } from "./adapter/coordinator-bridge.js";
-export { createDomEventBridge, type DomEventBridgeHandle, type DomEventBridgeOptions, } from "./adapter/dom-event-bridge.js";
-export { createFrameworkErrorBridge, type FrameworkErrorBridgeHandle, type FrameworkErrorBridgeOptions, } from "./adapter/framework-error-bridge.js";
-export { createInstrumentationBridge, type InstrumentationBridgeHandle, type InstrumentationBridgeOptions, type InstrumentationHook, } from "./adapter/instrumentation-bridge.js";
-export { createSubscriberFanout, type EngineOutputListener, type SubscriberFanoutHandle, } from "./adapter/subscriber-fanout.js";
-export { SectionEngineCore } from "./core/SectionEngineCore.js";
-export type { SectionEngineCoreListener } from "./core/SectionEngineCore.js";
-export { cohortKey, cohortsEqual, makeCohort, type CohortKey, } from "./core/cohort.js";
-export type { SectionEngineInput } from "./core/engine-input.js";
-export type { SectionEngineOutput } from "./core/engine-output.js";
-export type { EngineReadinessDetail, EngineReadinessPhase, EngineReadinessSignals, } from "./core/engine-readiness.js";
-export type { SectionEnginePhase, SectionEngineState, } from "./core/engine-state.js";
-export { createInitialEngineState } from "./core/engine-state.js";
-export { phaseToStage } from "./core/engine-stage-derivation.js";
-export { DEFAULT_ASSESSMENT_ID, DEFAULT_ENV, DEFAULT_ISOLATION, DEFAULT_LAZY_INIT, DEFAULT_PLAYER_TYPE, resolveOnFrameworkError, resolveRuntime, resolveSectionEngineRuntimeState, resolveToolsConfig, type EffectiveRuntime, type FrameworkErrorHandler, type LoadingCompleteHandler, type PlayerOverrides, type RuntimeConfig, type RuntimeInputs, type StageChangeHandler, } from "./core/engine-resolver.js";
-export { createReadinessDetail, resolveReadinessPhase, } from "./core/engine-readiness.js";
-export { transition } from "./core/engine-transition.js";
-export type { TransitionResult } from "./core/engine-transition.js";

package/dist/runtime/internal.js

@@ -1,45 +0,0 @@
-/**
- * Section runtime engine — **internal** entry point (M7 — Variant C).
- *
- * Re-exports the layered core + adapter surface for advanced hosts that
- * want to construct or inspect engines directly, and for the engine's
- * own tests / benchmarks.
- *
- * **Stability posture.** This module is **not** part of the stable
- * public API. Symbols here are subject to change between minor versions
- * with only a changeset note. Hosts that need long-term stability
- * should depend on the facade (`SectionRuntimeEngine` exported from
- * `./runtime/engine`) instead.
- *
- * The split is intentional:
- *   - `./runtime/engine` (PR 3) — narrow, stable facade for common
- *     host wiring.
- *   - `./runtime/internal` — wide, evolving surface for the kernel,
- *     adapter tests, and any host that wants to reach past the facade.
- *
- * The `runtime/engine` and `runtime/internal` package `exports` map
- * entries are added in PR 3 alongside the facade refactor.
- */
-export { SectionEngineAdapter } from "./adapter/SectionEngineAdapter.js";
-// `FrameworkErrorBus` is the package-internal multi-subscriber bus the
-// engine adapter consumes via the `FrameworkErrorReporter` write port.
-// It is re-exported here (alongside the read/write ports) so advanced
-// hosts that construct an engine instance directly — including the M7
-// PR 5 section-player kernel — can wire a bus without reaching into a
-// deep relative path. The class itself remains "package-internal" in
-// posture (the doc comment on the class explains why); this export is
-// a deliberate, advanced-host escape hatch on the evolving
-// `runtime/internal` surface, never on the stable facade.
-export { FrameworkErrorBus, } from "../services/framework-error-bus.js";
-export { createCoordinatorBridge, } from "./adapter/coordinator-bridge.js";
-export { createDomEventBridge, } from "./adapter/dom-event-bridge.js";
-export { createFrameworkErrorBridge, } from "./adapter/framework-error-bridge.js";
-export { createInstrumentationBridge, } from "./adapter/instrumentation-bridge.js";
-export { createSubscriberFanout, } from "./adapter/subscriber-fanout.js";
-export { SectionEngineCore } from "./core/SectionEngineCore.js";
-export { cohortKey, cohortsEqual, makeCohort, } from "./core/cohort.js";
-export { createInitialEngineState } from "./core/engine-state.js";
-export { phaseToStage } from "./core/engine-stage-derivation.js";
-export { DEFAULT_ASSESSMENT_ID, DEFAULT_ENV, DEFAULT_ISOLATION, DEFAULT_LAZY_INIT, DEFAULT_PLAYER_TYPE, resolveOnFrameworkError, resolveRuntime, resolveSectionEngineRuntimeState, resolveToolsConfig, } from "./core/engine-resolver.js";
-export { createReadinessDetail, resolveReadinessPhase, } from "./core/engine-readiness.js";
-export { transition } from "./core/engine-transition.js";

package/dist/runtime/section-runtime-engine-host-context.d.ts

@@ -1,80 +0,0 @@
-/**
- * Cross-Custom-Element context for the section runtime engine (M7 PR 6).
- *
- * The toolkit CE renders inside its own Shadow DOM, so Svelte's native
- * `setContext`/`getContext` (used by `engine-context.ts`) cannot bridge
- * the kernel-provided engine reference to the toolkit's component tree.
- * This module exposes a `@pie-players/pie-context` based context that
- * does cross the CE boundary via DOM events:
- *
- *   - The kernel (`SectionPlayerLayoutKernel.svelte`) installs a
- *     `ContextProvider` for `sectionRuntimeEngineHostContext` on its
- *     `host` (the layout CE). The provider value carries a narrow
- *     lifecycle handle for the engine owned by that kernel mount.
- *   - The toolkit CE installs a `ContextConsumer` on its own host. When
- *     wrapped by a section player layout, the consumer resolves to the
- *     kernel's lifecycle handle and suppresses its standalone lifecycle
- *     DOM emits in favor of the section-player host. Controller-side
- *     calls (`register`, `handleContent*`, `initialize`, etc.) remain
- *     owned by the toolkit's locally-constructed engine. When
- *     standalone, no host provider responds and the toolkit keeps using
- *     its standalone lifecycle path.
- *
- * The two engine-context surfaces (`SECTION_RUNTIME_ENGINE_KEY` and
- * this one) are deliberately distinct:
- *   - `SECTION_RUNTIME_ENGINE_KEY` (Svelte context) stays scoped to a
- *     single component tree (kernel + descendants in the same shadow
- *     root) and is the right hook for in-tree consumers.
- *   - `sectionRuntimeEngineHostContext` (DOM-event context) is the
- *     bridge for cross-CE consumers and only carries data that is safe
- *     to share across CE boundaries (a stable lifecycle handle).
- *
- * **Stability.** This export is part of the stable runtime/engine
- * surface; the symbol identity and value shape are part of the
- * cross-CE contract. Renaming or replacing the symbol is a major
- * breaking change. Adding optional fields to the value shape is
- * allowed; required fields are not.
- */
-/**
- * Narrow cross-CE handle published by section-player. Deliberately omits
- * controller-facing methods (`initialize`, `register`, `handleContent*`,
- * etc.) so the package seam cannot grow an accidental controller contract.
- */
-export interface SectionRuntimeLifecycleHandle {
-    getRuntimeId(): string;
-}
-/**
- * Value shape published by the kernel and consumed by the wrapped
- * toolkit CE. Carries only the lifecycle handle today; if more cross-CE
- * shared runtime state is needed later, fields can be added here
- * additively.
- */
-export interface SectionRuntimeEngineHostContextValue {
-    engine: SectionRuntimeLifecycleHandle;
-}
-/**
- * `pie-context` context key for the cross-CE engine bridge. Uses a
- * `Symbol.for(...)` registry key so providers and consumers in
- * separately-bundled CEs see the same identity.
- */
-export declare const sectionRuntimeEngineHostContext: {
-    __context__: SectionRuntimeEngineHostContextValue;
-};
-export type SectionRuntimeEngineHostContextListener = (value: SectionRuntimeEngineHostContextValue) => void;
-/**
- * Connect a DOM host to the cross-CE engine context with the same
- * provider-retry semantics used elsewhere in the toolkit (initial
- * synchronous request + `context-provider` re-request + 50 ms polling
- * fallback up to 200 attempts ≈ 10 s).
- *
- * The retry mirrors the existing
- * `connectAssessmentToolkitHostRuntimeContext` infrastructure so the
- * timing characteristics of cross-CE handshakes stay consistent across
- * the toolkit's contexts.
- *
- * Returns a cleanup function that disconnects the consumer and clears
- * the retry interval. Standalone toolkits naturally exhaust the retry
- * window without ever resolving and continue using their local
- * engine — that is by design and is not an error.
- */
-export declare function connectSectionRuntimeEngineHostContext(host: HTMLElement, onValue: SectionRuntimeEngineHostContextListener): () => void;