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

package/dist/policy/core/engine-context.d.ts

@@ -1,29 +0,0 @@
-/**
- * Svelte context key for the tool policy engine (M8 PR 1).
- *
- * Components inside an assessment toolkit subtree consume the engine
- * through Svelte's native `getContext(TOOL_POLICY_ENGINE_KEY)`. The
- * canonical provider is the `ToolkitCoordinator` wiring (M8 PR 2):
- * the toolkit CE constructs a `ToolPolicyEngine`, attaches it to the
- * coordinator, and exposes it to descendants via
- * `setContext(TOOL_POLICY_ENGINE_KEY, engine)`.
- *
- * Mirrors the M7 `SECTION_RUNTIME_ENGINE_KEY` pattern. As with the
- * runtime engine, 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.
- *
- * **No cross-CE bridge.** Unlike the runtime engine, there is no
- * `connectToolPolicyEngineHostContext` helper — see M8 design Q8.
- * Every CE in the tree gets its engine from its own coordinator
- * (the toolkit element). This avoids subscription-bridge overhead
- * for a function-style engine that hosts can simply re-call after
- * an input swap.
- *
- * **Stability.** This export is part of the stable `policy/engine`
- * surface; renaming or replacing the symbol is a major breaking
- * change.
- */
-import type { ToolPolicyEngine } from "./ToolPolicyEngine.js";
-export declare const TOOL_POLICY_ENGINE_KEY: unique symbol;
-export type ToolPolicyEngineContext = ToolPolicyEngine;

package/dist/policy/core/engine-context.js

@@ -1,27 +0,0 @@
-/**
- * Svelte context key for the tool policy engine (M8 PR 1).
- *
- * Components inside an assessment toolkit subtree consume the engine
- * through Svelte's native `getContext(TOOL_POLICY_ENGINE_KEY)`. The
- * canonical provider is the `ToolkitCoordinator` wiring (M8 PR 2):
- * the toolkit CE constructs a `ToolPolicyEngine`, attaches it to the
- * coordinator, and exposes it to descendants via
- * `setContext(TOOL_POLICY_ENGINE_KEY, engine)`.
- *
- * Mirrors the M7 `SECTION_RUNTIME_ENGINE_KEY` pattern. As with the
- * runtime engine, 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.
- *
- * **No cross-CE bridge.** Unlike the runtime engine, there is no
- * `connectToolPolicyEngineHostContext` helper — see M8 design Q8.
- * Every CE in the tree gets its engine from its own coordinator
- * (the toolkit element). This avoids subscription-bridge overhead
- * for a function-style engine that hosts can simply re-call after
- * an input swap.
- *
- * **Stability.** This export is part of the stable `policy/engine`
- * surface; renaming or replacing the symbol is a major breaking
- * change.
- */
-export const TOOL_POLICY_ENGINE_KEY = Symbol("@pie-players/tool-policy-engine");

package/dist/policy/core/policy-source-tag.d.ts

@@ -1,31 +0,0 @@
-/**
- * Policy source tag — attribution for `ToolPolicyEntry.sources`.
- *
- * The engine attaches a `PolicySourceTag` to every `ToolPolicyEntry` it
- * emits, capturing every step from `compose-decision.ts` that contributed
- * to the entry being kept (or, in the case of `required-tool-blocked`,
- * the step that surfaced the conflict).
- *
- * Tag vocabulary maps onto the six composition steps in
- * `m8-design.md` § 3:
- *
- *   1. Membership filter   → `"placement"`
- *   2. Provider veto       → `"provider"` (negative; only present when
- *                                            the entry survived a
- *                                            non-`enabled: false` check)
- *   3. Host whitelist      → `"policy"`
- *   4. Host blocklist      → `"policy"` (negative)
- *   5. PNP/profile gates   → `"pnp.${rule}"` (e.g. `"pnp.pnp-support"`,
- *                                              `"pnp.item-requirement"`)
- *   6. Custom PolicySources → `"custom.${source.id}"`
- *
- * Negative tags do not appear on surviving entries — they are reflected
- * only in `ToolPolicyProvenance` decisions. The tag union therefore
- * tracks contributors that *kept* a tool, not contributors that
- * *removed* one. Diagnostic surfacing of removals is the
- * provenance/diagnostic channel's job.
- */
-export type PnpPolicySourceRule = "district-block" | "test-admin-override" | "item-restriction" | "item-requirement" | "district-requirement" | "pnp-support" | "pnp-prohibited";
-export type PnpPolicySourceTag = `pnp.${PnpPolicySourceRule}`;
-export type CustomPolicySourceTag = `custom.${string}`;
-export type PolicySourceTag = "placement" | "policy" | "provider" | PnpPolicySourceTag | CustomPolicySourceTag;

package/dist/policy/core/policy-source-tag.js

@@ -1,28 +0,0 @@
-/**
- * Policy source tag — attribution for `ToolPolicyEntry.sources`.
- *
- * The engine attaches a `PolicySourceTag` to every `ToolPolicyEntry` it
- * emits, capturing every step from `compose-decision.ts` that contributed
- * to the entry being kept (or, in the case of `required-tool-blocked`,
- * the step that surfaced the conflict).
- *
- * Tag vocabulary maps onto the six composition steps in
- * `m8-design.md` § 3:
- *
- *   1. Membership filter   → `"placement"`
- *   2. Provider veto       → `"provider"` (negative; only present when
- *                                            the entry survived a
- *                                            non-`enabled: false` check)
- *   3. Host whitelist      → `"policy"`
- *   4. Host blocklist      → `"policy"` (negative)
- *   5. PNP/profile gates   → `"pnp.${rule}"` (e.g. `"pnp.pnp-support"`,
- *                                              `"pnp.item-requirement"`)
- *   6. Custom PolicySources → `"custom.${source.id}"`
- *
- * Negative tags do not appear on surviving entries — they are reflected
- * only in `ToolPolicyProvenance` decisions. The tag union therefore
- * tracks contributors that *kept* a tool, not contributors that
- * *removed* one. Diagnostic surfacing of removals is the
- * provenance/diagnostic channel's job.
- */
-export {};

package/dist/policy/internal.d.ts

@@ -1,25 +0,0 @@
-/**
- * Tool policy engine — **internal** entry point (M8 PR 1).
- *
- * Re-exports the composition pipeline, the PNP policy source, and the
- * provenance builder for advanced hosts that want to drive the engine
- * components directly, and for the engine's own tests.
- *
- * **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 (`ToolPolicyEngine` exported
- * from `./policy/engine`) instead.
- *
- * The split is intentional:
- *   - `./policy/engine`   — narrow, stable facade for common host
- *                           wiring and Svelte context.
- *   - `./policy/internal` — wide, evolving surface for the
- *                           composition pipeline, PNP policy source, and
- *                           any host that wants to reach past the
- *                           facade.
- */
-export { composeDecision, type ComposeDecisionInputs, } from "./core/compose-decision.js";
-export { PnpPolicySource, type PnpPolicyApplyArgs, type PnpPolicyDecisionEvent, type PnpPolicyResult, type PnpPolicyToolFlags, } from "./sources/PnpPolicySource.js";
-export { ToolPolicyProvenanceBuilder } from "./core/provenance.js";
-export { assessmentHasPnpPolicyInputs, itemRefHasPnpPolicyInputs, resolveDefaultPnpEnforcement, } from "./core/pnp-policy-inputs.js";

package/dist/policy/internal.js

@@ -1,25 +0,0 @@
-/**
- * Tool policy engine — **internal** entry point (M8 PR 1).
- *
- * Re-exports the composition pipeline, the PNP policy source, and the
- * provenance builder for advanced hosts that want to drive the engine
- * components directly, and for the engine's own tests.
- *
- * **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 (`ToolPolicyEngine` exported
- * from `./policy/engine`) instead.
- *
- * The split is intentional:
- *   - `./policy/engine`   — narrow, stable facade for common host
- *                           wiring and Svelte context.
- *   - `./policy/internal` — wide, evolving surface for the
- *                           composition pipeline, PNP policy source, and
- *                           any host that wants to reach past the
- *                           facade.
- */
-export { composeDecision, } from "./core/compose-decision.js";
-export { PnpPolicySource, } from "./sources/PnpPolicySource.js";
-export { ToolPolicyProvenanceBuilder } from "./core/provenance.js";
-export { assessmentHasPnpPolicyInputs, itemRefHasPnpPolicyInputs, resolveDefaultPnpEnforcement, } from "./core/pnp-policy-inputs.js";

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");