@pie-players/pie-assessment-toolkit 0.3.63 → 0.3.65

package/dist/policy/core/feature-decision.d.ts

@@ -0,0 +1,57 @@
+/**
+ * Feature policy decisions — eligibility for policy-addressable capabilities
+ * that are not toolbar tools.
+ *
+ * "Tool" in this codebase means *policy-addressable capability*, not "gadget on
+ * a toolbar" (see `docs/tools-and-accomodations/architecture.md`). Most such
+ * capabilities render as toolbar surfaces, so the engine's main answer is a
+ * placement-scoped `ToolPolicyDecision`. Some do not: a signed alternate renders
+ * as its own region and is never placed on a toolbar, so asking
+ * `decide({ level: "item", ... })` about it would answer the wrong question —
+ * it would be absent because it is not in `tools.placement.item`, not because
+ * policy said no.
+ *
+ * A feature decision answers only the eligibility half: *did policy grant this
+ * feature id?* Whether the capability has anything to show is a separate,
+ * independent check owned by its renderer — for signing, whether a matching
+ * catalog card exists. Both are required; neither implies the other.
+ */
+import type { PnpPolicyResult } from "../sources/PnpPolicySource.js";
+import type { PnpPolicySourceRule } from "./policy-source-tag.js";
+import type { ToolPolicyResolutionDecision, ToolPolicySourceType } from "./provenance.js";
+export interface FeaturePolicyDecision {
+    /** The PNP/AfA support id that was evaluated (e.g. `"signLanguage"`). */
+    featureId: string;
+    /**
+     * `true` only when policy explicitly granted the feature at one of the six
+     * precedence levels. A feature nobody configured is **not** available —
+     * accommodations require a documented need, so silence means no.
+     */
+    granted: boolean;
+    action: ToolPolicyResolutionDecision["action"];
+    /** Which precedence rule produced the verdict. */
+    rule: PnpPolicySourceRule;
+    precedence: 1 | 2 | 3 | 4 | 5 | 6;
+    sourceType: ToolPolicySourceType;
+    /** Human-readable explanation, suitable for a policy debugger. */
+    reason: string;
+    /**
+     * `true` when the grant is a mandate (item or district `requiredTools`)
+     * rather than a student-profile support.
+     */
+    required: boolean;
+    /**
+     * Feature parameters resolved from item `toolParameters` then assessment
+     * `toolConfigs`, keyed by the feature id. The seam a later configurable
+     * presentation would hang on; no vocabulary is defined yet.
+     */
+    parameters?: unknown;
+}
+/**
+ * Interpret a single-feature `PnpPolicySource.resolveFeature(...)` result.
+ *
+ * `resolveFeature` evaluates exactly one support id, so the result carries
+ * exactly one decision and at most one flags entry — no mapped-tool-id
+ * bookkeeping is needed to read it back out.
+ */
+export declare function interpretFeatureResult(featureId: string, result: PnpPolicyResult): FeaturePolicyDecision;

package/dist/policy/core/feature-decision.js

@@ -0,0 +1,40 @@
+/**
+ * Feature policy decisions — eligibility for policy-addressable capabilities
+ * that are not toolbar tools.
+ *
+ * "Tool" in this codebase means *policy-addressable capability*, not "gadget on
+ * a toolbar" (see `docs/tools-and-accomodations/architecture.md`). Most such
+ * capabilities render as toolbar surfaces, so the engine's main answer is a
+ * placement-scoped `ToolPolicyDecision`. Some do not: a signed alternate renders
+ * as its own region and is never placed on a toolbar, so asking
+ * `decide({ level: "item", ... })` about it would answer the wrong question —
+ * it would be absent because it is not in `tools.placement.item`, not because
+ * policy said no.
+ *
+ * A feature decision answers only the eligibility half: *did policy grant this
+ * feature id?* Whether the capability has anything to show is a separate,
+ * independent check owned by its renderer — for signing, whether a matching
+ * catalog card exists. Both are required; neither implies the other.
+ */
+/**
+ * Interpret a single-feature `PnpPolicySource.resolveFeature(...)` result.
+ *
+ * `resolveFeature` evaluates exactly one support id, so the result carries
+ * exactly one decision and at most one flags entry — no mapped-tool-id
+ * bookkeeping is needed to read it back out.
+ */
+export function interpretFeatureResult(featureId, result) {
+    const decision = result.decisions[0];
+    const flags = Array.from(result.perToolFlags.values())[0];
+    return {
+        featureId,
+        granted: decision?.action === "enable",
+        action: decision?.action ?? "skip",
+        rule: decision?.rule ?? "pnp-support",
+        precedence: decision?.precedence ?? 6,
+        sourceType: decision?.sourceType ?? "system",
+        reason: decision?.reason ?? `Feature "${featureId}" not configured`,
+        required: Boolean(flags?.required),
+        parameters: flags?.settings,
+    };
+}

package/dist/policy/engine.d.ts

@@ -21,6 +21,7 @@
  */
 export { ToolPolicyEngine, type PnpEnforcementMode, type ResolvedEngineInputs, type ToolPolicyChangeEvent, type ToolPolicyChangeListener, type ToolPolicyEngineArgs, type ToolPolicyEngineInputs, } from "./core/ToolPolicyEngine.js";
 export { TOOL_POLICY_ENGINE_KEY, type ToolPolicyEngineContext, } from "./core/engine-context.js";
+export type { FeaturePolicyDecision } from "./core/feature-decision.js";
 export type { RequiredToolBlockedDetails, ToolPolicyDecision, ToolPolicyDecisionRequest, ToolPolicyDiagnostic, ToolPolicyDiagnosticCode, ToolPolicyEntry, ToolPolicyHostGate, ToolScope, } from "./core/decision-types.js";
 export type { PolicySource, PolicySourceDecisionContext, PolicySourceProvenanceEntry, PolicySourceResult, } from "./core/PolicySource.js";
 export type { PolicySourceTag, PnpPolicySourceRule, PnpPolicySourceTag, CustomPolicySourceTag, } from "./core/policy-source-tag.js";

package/dist/policy/sources/PnpPolicySource.d.ts

@@ -88,6 +88,28 @@ export declare class PnpPolicySource {
     private readonly toolRegistry;
     constructor(toolRegistry: ToolRegistry);
     apply(args: PnpPolicyApplyArgs): PnpPolicyResult;
+    /**
+     * Evaluate exactly one PNP support id through the same six-level
+     * precedence `apply(...)` uses.
+     *
+     * This exists for **policy-addressable capabilities that are not toolbar
+     * tools** — a signed alternate rendered as its own region, for example.
+     * `apply(...)` only evaluates support ids that appear somewhere in the
+     * bound policy inputs, and it keys its result maps by *mapped tool id*, so
+     * a caller asking about one feature would have to re-derive that mapping
+     * and could collide with another support id that maps to the same tool.
+     * Evaluating one id in isolation avoids both problems: the returned result
+     * carries exactly one decision, and `decisions[0].action` is the verdict.
+     *
+     * Reusing `resolveSupport(...)` rather than re-walking the precedence rules
+     * is the point — a second copy of the six levels would drift.
+     */
+    resolveFeature(featureId: string, args: PnpPolicyApplyArgs): PnpPolicyResult;
+    /**
+     * Build the rule-evaluation context and the empty result (with its
+     * configuration-source attribution) from the bound policy inputs.
+     */
+    private prepare;
     private resolveSupport;
     /**
      * Map a QTI / PNP support id (e.g. `"calculator-basic"`) to the

package/dist/policy/sources/PnpPolicySource.js

@@ -14,6 +14,46 @@ export class PnpPolicySource {
         this.toolRegistry = toolRegistry;
     }
     apply(args) {
+        const { ctx, result } = this.prepare(args);
+        const { pnp, districtPolicy, itemSettings } = ctx;
+        const allSupports = new Set();
+        pnp?.supports?.forEach((s) => allSupports.add(s));
+        pnp?.prohibitedSupports?.forEach((s) => allSupports.add(s));
+        districtPolicy?.blockedTools?.forEach((s) => allSupports.add(s));
+        districtPolicy?.requiredTools?.forEach((s) => allSupports.add(s));
+        itemSettings?.requiredTools?.forEach((s) => allSupports.add(s));
+        itemSettings?.restrictedTools?.forEach((s) => allSupports.add(s));
+        for (const supportId of allSupports) {
+            this.resolveSupport(supportId, ctx, result);
+        }
+        return result;
+    }
+    /**
+     * Evaluate exactly one PNP support id through the same six-level
+     * precedence `apply(...)` uses.
+     *
+     * This exists for **policy-addressable capabilities that are not toolbar
+     * tools** — a signed alternate rendered as its own region, for example.
+     * `apply(...)` only evaluates support ids that appear somewhere in the
+     * bound policy inputs, and it keys its result maps by *mapped tool id*, so
+     * a caller asking about one feature would have to re-derive that mapping
+     * and could collide with another support id that maps to the same tool.
+     * Evaluating one id in isolation avoids both problems: the returned result
+     * carries exactly one decision, and `decisions[0].action` is the verdict.
+     *
+     * Reusing `resolveSupport(...)` rather than re-walking the precedence rules
+     * is the point — a second copy of the six levels would drift.
+     */
+    resolveFeature(featureId, args) {
+        const { ctx, result } = this.prepare(args);
+        this.resolveSupport(featureId, ctx, result);
+        return result;
+    }
+    /**
+     * Build the rule-evaluation context and the empty result (with its
+     * configuration-source attribution) from the bound policy inputs.
+     */
+    prepare(args) {
         const { assessment, currentItemRef } = args;
         const pnp = assessment?.personalNeedsProfile;
         const settings = assessment?.settings;
@@ -46,13 +86,6 @@ export class PnpPolicySource {
                 config: itemSettings,
             };
         }
-        const allSupports = new Set();
-        pnp?.supports?.forEach((s) => allSupports.add(s));
-        pnp?.prohibitedSupports?.forEach((s) => allSupports.add(s));
-        settings?.districtPolicy?.blockedTools?.forEach((s) => allSupports.add(s));
-        settings?.districtPolicy?.requiredTools?.forEach((s) => allSupports.add(s));
-        itemSettings?.requiredTools?.forEach((s) => allSupports.add(s));
-        itemSettings?.restrictedTools?.forEach((s) => allSupports.add(s));
         const ctx = {
             pnp,
             districtPolicy: settings?.districtPolicy,
@@ -60,10 +93,7 @@ export class PnpPolicySource {
             itemSettings,
             toolConfigs: settings?.toolConfigs,
         };
-        for (const supportId of allSupports) {
-            this.resolveSupport(supportId, ctx, result);
-        }
-        return result;
+        return { ctx, result };
     }
     resolveSupport(supportId, ctx, out) {
         // 1. District block (absolute veto)

package/dist/runtime/catalog-registration.d.ts

@@ -1,6 +1,19 @@
+/**
+ * Where accessibility catalogs live on a rendered entity, and which owner scope
+ * each one belongs to.
+ *
+ * Catalogs are placed dynamically: a shell registers what its entity carries
+ * when it mounts, and readers (TTS, the item card's media region) resolve by
+ * identifier within an owner scope. Both sides therefore have to agree on two
+ * facts — the three places catalogs can hang off an entity, and the owner
+ * context each one is filed under. This module is the only place either is
+ * decided, so a reader cannot look up a scope registration never wrote.
+ *
+ * Part of PIE Assessment Toolkit.
+ */
 import type { AccessibilityCatalog } from "@pie-players/pie-players-shared/types";
 import type { CatalogOwnerContext } from "../services/AccessibilityCatalogResolver.js";
-import type { RuntimeRegistrationDetail } from "./registration-events.js";
+import type { RuntimeRegistrationDetail, RuntimeRegistrationKind } from "./registration-events.js";
 export interface CatalogRegistrationRuntimeContext {
     assessmentId?: string;
     sectionId?: string;
@@ -9,4 +22,46 @@ export interface CatalogRegistration {
     context: CatalogOwnerContext;
     catalogs: AccessibilityCatalog[];
 }
+/** The entity shape catalogs hang off: an item, or a passage. */
+export interface CatalogSourceEntity {
+    accessibilityCatalogs?: AccessibilityCatalog[];
+    config?: {
+        extractedCatalogs?: AccessibilityCatalog[];
+        models?: Array<{
+            id?: string;
+            accessibilityCatalogs?: AccessibilityCatalog[];
+        }>;
+    };
+}
+/** Who is rendering the entity — everything owner scoping is derived from. */
+export interface CatalogOwnerIdentity {
+    kind: RuntimeRegistrationKind;
+    /** The rendered instance id. */
+    itemId: string;
+    canonicalItemId?: string;
+    assessmentId?: string;
+    sectionId?: string;
+}
+/**
+ * The owner context an entity's catalogs are registered under, and therefore the
+ * one a reader must look them up with.
+ *
+ * Exported because readers construct the lookup context themselves: the
+ * resolver matches contexts field by field, so a reader that hand-assembled its
+ * own would silently resolve nothing the day either side gained a field.
+ */
+export declare function catalogOwnerContextFor(owner: CatalogOwnerIdentity): CatalogOwnerContext;
+/**
+ * Every catalog an entity carries, paired with the owner scope it belongs in.
+ *
+ * Three places carry catalogs, and the distinction matters to resolution rather
+ * than only to bookkeeping: entity-level `accessibilityCatalogs` and
+ * extractor-generated `config.extractedCatalogs` are filed against the entity,
+ * while a model's own catalogs are filed against that model, so two models on
+ * one item can use the same catalog identifier without colliding.
+ *
+ * Passages have no models, so the walk stops after the entity-level pair.
+ */
+export declare function collectEntityCatalogRegistrations(entity: CatalogSourceEntity | null | undefined, owner: CatalogOwnerIdentity): CatalogRegistration[];
+/** Adapter for the runtime registration event a shell dispatches on mount. */
 export declare function collectCatalogRegistrations(detail: RuntimeRegistrationDetail, runtime?: CatalogRegistrationRuntimeContext): CatalogRegistration[];

package/dist/runtime/catalog-registration.js

@@ -1,53 +1,86 @@
+/**
+ * Where accessibility catalogs live on a rendered entity, and which owner scope
+ * each one belongs to.
+ *
+ * Catalogs are placed dynamically: a shell registers what its entity carries
+ * when it mounts, and readers (TTS, the item card's media region) resolve by
+ * identifier within an owner scope. Both sides therefore have to agree on two
+ * facts — the three places catalogs can hang off an entity, and the owner
+ * context each one is filed under. This module is the only place either is
+ * decided, so a reader cannot look up a scope registration never wrote.
+ *
+ * Part of PIE Assessment Toolkit.
+ */
 const hasCatalogs = (catalogs) => Array.isArray(catalogs) && catalogs.length > 0;
-export function collectCatalogRegistrations(detail, runtime = {}) {
-    const entity = detail.item;
-    if (!entity)
-        return [];
-    const registrations = [];
-    if (detail.kind === "passage") {
-        const context = {
+/**
+ * The owner context an entity's catalogs are registered under, and therefore the
+ * one a reader must look them up with.
+ *
+ * Exported because readers construct the lookup context themselves: the
+ * resolver matches contexts field by field, so a reader that hand-assembled its
+ * own would silently resolve nothing the day either side gained a field.
+ */
+export function catalogOwnerContextFor(owner) {
+    if (owner.kind === "passage") {
+        return {
             ownerKind: "passage",
-            assessmentId: runtime.assessmentId,
-            sectionId: runtime.sectionId,
-            passageId: detail.canonicalItemId || detail.itemId,
+            assessmentId: owner.assessmentId,
+            sectionId: owner.sectionId,
+            passageId: owner.canonicalItemId || owner.itemId,
         };
-        if (hasCatalogs(entity.accessibilityCatalogs)) {
-            registrations.push({ context, catalogs: entity.accessibilityCatalogs });
-        }
-        if (hasCatalogs(entity.config?.extractedCatalogs)) {
-            registrations.push({
-                context,
-                catalogs: entity.config.extractedCatalogs,
-            });
-        }
-        return registrations;
     }
-    const itemContext = {
+    return {
         ownerKind: "itemModel",
-        assessmentId: runtime.assessmentId,
-        sectionId: runtime.sectionId,
-        itemId: detail.itemId,
-        canonicalItemId: detail.canonicalItemId || detail.itemId,
+        assessmentId: owner.assessmentId,
+        sectionId: owner.sectionId,
+        itemId: owner.itemId,
+        canonicalItemId: owner.canonicalItemId || owner.itemId,
     };
+}
+/**
+ * Every catalog an entity carries, paired with the owner scope it belongs in.
+ *
+ * Three places carry catalogs, and the distinction matters to resolution rather
+ * than only to bookkeeping: entity-level `accessibilityCatalogs` and
+ * extractor-generated `config.extractedCatalogs` are filed against the entity,
+ * while a model's own catalogs are filed against that model, so two models on
+ * one item can use the same catalog identifier without colliding.
+ *
+ * Passages have no models, so the walk stops after the entity-level pair.
+ */
+export function collectEntityCatalogRegistrations(entity, owner) {
+    if (!entity)
+        return [];
+    const context = catalogOwnerContextFor(owner);
+    const registrations = [];
     if (hasCatalogs(entity.accessibilityCatalogs)) {
-        registrations.push({
-            context: itemContext,
-            catalogs: entity.accessibilityCatalogs,
-        });
+        registrations.push({ context, catalogs: entity.accessibilityCatalogs });
     }
     if (hasCatalogs(entity.config?.extractedCatalogs)) {
         registrations.push({
-            context: itemContext,
+            context,
             catalogs: entity.config.extractedCatalogs,
         });
     }
+    if (owner.kind === "passage")
+        return registrations;
     for (const model of entity.config?.models ?? []) {
         if (!hasCatalogs(model.accessibilityCatalogs))
             continue;
         registrations.push({
-            context: { ...itemContext, modelId: model.id },
+            context: { ...context, modelId: model.id },
             catalogs: model.accessibilityCatalogs,
         });
     }
     return registrations;
 }
+/** Adapter for the runtime registration event a shell dispatches on mount. */
+export function collectCatalogRegistrations(detail, runtime = {}) {
+    return collectEntityCatalogRegistrations(detail.item, {
+        kind: detail.kind,
+        itemId: detail.itemId,
+        canonicalItemId: detail.canonicalItemId,
+        assessmentId: runtime.assessmentId,
+        sectionId: runtime.sectionId,
+    });
+}

package/dist/runtime/composition-emit-scheduler.d.ts

@@ -0,0 +1,78 @@
+/**
+ * Composition emit scheduler (PIE-885).
+ *
+ * `PieAssessmentToolkit.svelte` publishes the section composition to the
+ * players through exactly one path — the `composition-changed` event — and
+ * coalesces bursts of updates behind a one-shot latch so several changes
+ * within one frame produce a single emit.
+ *
+ * That latch used to be cleared only by a `requestAnimationFrame` callback,
+ * and the frame branch was chosen whenever `window.requestAnimationFrame`
+ * merely *existed* rather than when it was known to fire. In a document that
+ * never paints the callback never ran, the latch never cleared, and no
+ * `composition-changed` was ever dispatched: the section controller held a
+ * correct view model while the player kept its initial empty composition, so
+ * every `pie-section-player` route rendered no content at all. The permanent
+ * failure was in contexts with no compositor — headless browsers, hidden or
+ * offscreen tabs, agent and CI automation harnesses. A background tab only
+ * rendered late, because its pending frame becomes due on refocus.
+ *
+ * So the frame is raced against a deadline timer instead of trusted. Whichever
+ * arrives first releases the latch and flushes, and a non-painting document
+ * degrades to a slower render rather than a permanent blank. Svelte's own
+ * `tick()` races the same two primitives for the same reason.
+ *
+ * This scheduler owns the latch and both handles, which is what makes "the
+ * latch cannot stay set after a scheduled frame is cancelled or superseded"
+ * structural rather than a discipline every call site has to keep: releasing
+ * the latch and releasing the handles is one operation in one place.
+ *
+ * Deliberately stateless across cycles. A cycle the timer wins does not switch
+ * the scheduler into a timer-preferring mode: that trades the deadline cost for
+ * a mode which never returns to frame alignment once a single frame is missed,
+ * and a slower render is the accepted outcome.
+ *
+ * NOT a public surface: internal to the toolkit and not exported from
+ * `runtime/engine.ts`. It exists as its own module so the race can be pinned in
+ * a unit test without mounting the toolkit CE — same rationale as
+ * `runtime/stage-emit-gate.ts`.
+ */
+/**
+ * How long to wait for a frame before the timer takes over.
+ *
+ * Six frames at 60fps, so on any normally painting document the frame still
+ * wins and emits stay paint-aligned. Chrome clamps timers in hidden tabs to
+ * ≥1s and can clamp harder under intensive throttling; that makes a hidden tab
+ * bounded-slow instead of blank, which is the point.
+ */
+export declare const DEFAULT_FRAME_DEADLINE_MS = 100;
+/**
+ * Timing primitives, injectable so tests can drive the race deterministically.
+ *
+ * An omitted primitive is resolved from `globalThis` at `schedule()` time
+ * rather than captured at construction: the pre-fix code also checked per
+ * emit, and a host can install a `requestAnimationFrame` shim after the
+ * toolkit is constructed. An explicit `null` opts the primitive out.
+ */
+export interface CompositionEmitSchedulerTiming {
+    requestFrame?: ((callback: () => void) => number) | null;
+    cancelFrame?: ((handle: number) => void) | null;
+    setTimer?: ((callback: () => void, delayMs: number) => unknown) | null;
+    clearTimer?: ((handle: unknown) => void) | null;
+    queueMicrotaskFn?: ((callback: () => void) => void) | null;
+    frameDeadlineMs?: number;
+}
+export interface CompositionEmitScheduler {
+    /**
+     * Arm a flush. While a cycle is pending this only replaces the stored
+     * callback — that is the coalescing guarantee: one resolution, one flush.
+     */
+    schedule(flush: () => void): void;
+    /**
+     * Abandon a pending cycle. Releases the latch and both handles together,
+     * and is idempotent.
+     */
+    cancel(): void;
+    isPending(): boolean;
+}
+export declare function createCompositionEmitScheduler(timing?: CompositionEmitSchedulerTiming): CompositionEmitScheduler;

package/dist/runtime/composition-emit-scheduler.js

@@ -0,0 +1,154 @@
+/**
+ * Composition emit scheduler (PIE-885).
+ *
+ * `PieAssessmentToolkit.svelte` publishes the section composition to the
+ * players through exactly one path — the `composition-changed` event — and
+ * coalesces bursts of updates behind a one-shot latch so several changes
+ * within one frame produce a single emit.
+ *
+ * That latch used to be cleared only by a `requestAnimationFrame` callback,
+ * and the frame branch was chosen whenever `window.requestAnimationFrame`
+ * merely *existed* rather than when it was known to fire. In a document that
+ * never paints the callback never ran, the latch never cleared, and no
+ * `composition-changed` was ever dispatched: the section controller held a
+ * correct view model while the player kept its initial empty composition, so
+ * every `pie-section-player` route rendered no content at all. The permanent
+ * failure was in contexts with no compositor — headless browsers, hidden or
+ * offscreen tabs, agent and CI automation harnesses. A background tab only
+ * rendered late, because its pending frame becomes due on refocus.
+ *
+ * So the frame is raced against a deadline timer instead of trusted. Whichever
+ * arrives first releases the latch and flushes, and a non-painting document
+ * degrades to a slower render rather than a permanent blank. Svelte's own
+ * `tick()` races the same two primitives for the same reason.
+ *
+ * This scheduler owns the latch and both handles, which is what makes "the
+ * latch cannot stay set after a scheduled frame is cancelled or superseded"
+ * structural rather than a discipline every call site has to keep: releasing
+ * the latch and releasing the handles is one operation in one place.
+ *
+ * Deliberately stateless across cycles. A cycle the timer wins does not switch
+ * the scheduler into a timer-preferring mode: that trades the deadline cost for
+ * a mode which never returns to frame alignment once a single frame is missed,
+ * and a slower render is the accepted outcome.
+ *
+ * NOT a public surface: internal to the toolkit and not exported from
+ * `runtime/engine.ts`. It exists as its own module so the race can be pinned in
+ * a unit test without mounting the toolkit CE — same rationale as
+ * `runtime/stage-emit-gate.ts`.
+ */
+/**
+ * How long to wait for a frame before the timer takes over.
+ *
+ * Six frames at 60fps, so on any normally painting document the frame still
+ * wins and emits stay paint-aligned. Chrome clamps timers in hidden tabs to
+ * ≥1s and can clamp harder under intensive throttling; that makes a hidden tab
+ * bounded-slow instead of blank, which is the point.
+ */
+export const DEFAULT_FRAME_DEADLINE_MS = 100;
+function pickFunction(override, ambient) {
+    if (typeof override === "function")
+        return override;
+    if (override === null)
+        return null;
+    return typeof ambient === "function" ? ambient : null;
+}
+export function createCompositionEmitScheduler(timing = {}) {
+    const frameDeadlineMs = timing.frameDeadlineMs ?? DEFAULT_FRAME_DEADLINE_MS;
+    let pending = false;
+    let pendingFlush = null;
+    let frameHandle = null;
+    let timerHandle = null;
+    // Kept from the arming call so a cancel is paired with the primitive that
+    // actually armed the handle.
+    let cancelFrame = null;
+    let clearTimer = null;
+    function release() {
+        pending = false;
+        if (frameHandle !== null) {
+            cancelFrame?.(frameHandle);
+            frameHandle = null;
+        }
+        if (timerHandle !== null) {
+            clearTimer?.(timerHandle);
+            timerHandle = null;
+        }
+        cancelFrame = null;
+        clearTimer = null;
+    }
+    /**
+     * Resolve one cycle. `firedFrom` names the side that arrived so its own
+     * handle is dropped rather than handed back to a cancel that has nothing
+     * left to cancel.
+     *
+     * The latch is released before the flush callback runs, so a re-entrant
+     * `schedule()` from inside the flush arms a fresh cycle instead of being
+     * swallowed. The pre-fix code cleared its latch first for the same reason.
+     */
+    function resolve(firedFrom) {
+        if (!pending)
+            return;
+        if (firedFrom === "frame")
+            frameHandle = null;
+        if (firedFrom === "timer")
+            timerHandle = null;
+        const flushNow = pendingFlush;
+        pendingFlush = null;
+        release();
+        flushNow?.();
+    }
+    function schedule(flush) {
+        pendingFlush = flush;
+        if (pending)
+            return;
+        pending = true;
+        const ambient = globalThis;
+        const requestFrame = pickFunction(timing.requestFrame, ambient.requestAnimationFrame);
+        cancelFrame = pickFunction(timing.cancelFrame, ambient.cancelAnimationFrame);
+        const setTimer = pickFunction(timing.setTimer, ambient.setTimeout);
+        clearTimer = pickFunction(timing.clearTimer, ambient.clearTimeout);
+        if (requestFrame) {
+            const handle = requestFrame(() => resolve("frame"));
+            // A primitive that calls back synchronously has already flushed and
+            // released; arming anything else would leave a stray handle behind.
+            if (!pending)
+                return;
+            frameHandle = handle;
+            // The frame is not trusted to arrive. Without a timer alongside it, a
+            // document that never paints leaves the latch set forever.
+            if (setTimer) {
+                const deadlineHandle = setTimer(() => resolve("timer"), frameDeadlineMs);
+                if (pending)
+                    timerHandle = deadlineHandle;
+            }
+            return;
+        }
+        // No frame primitive at all (SSR, non-DOM test environments). Preserve
+        // the microtask timing those hosts already had.
+        const queueMicrotaskFn = pickFunction(timing.queueMicrotaskFn, ambient.queueMicrotask);
+        if (queueMicrotaskFn) {
+            queueMicrotaskFn(() => resolve("microtask"));
+            return;
+        }
+        if (setTimer) {
+            const deadlineHandle = setTimer(() => resolve("timer"), 0);
+            if (pending)
+                timerHandle = deadlineHandle;
+            return;
+        }
+        // Nothing to defer with. A synchronous flush is strictly better than
+        // dropping the composition on the floor.
+        resolve("microtask");
+    }
+    function cancel() {
+        if (!pending)
+            return;
+        pendingFlush = null;
+        release();
+    }
+    return {
+        schedule,
+        cancel,
+        isPending: () => pending,
+    };
+}

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

@@ -120,7 +120,7 @@ export declare function resolveRuntime(args: {
     createSectionController: unknown;
     isolation: string;
     env: Record<string, unknown>;
-    toolConfigStrictness: "off" | "error" | "warn";
+    toolConfigStrictness: "off" | "warn" | "error";
     onFrameworkError: FrameworkErrorHandler | undefined;
     onStageChange: StageChangeHandler | undefined;
     onLoadingComplete: LoadingCompleteHandler | undefined;