@ecopages/core 0.2.0-alpha.9 → 0.2.1

package/src/route-renderer/GRAPH.md

@@ -1,6 +1,6 @@
 # Rendering Logic Graph
 
-This document maps the end-to-end rendering logic in core, including request-time rendering, explicit route rendering, static generation, and marker graph orchestration.
+This document maps the end-to-end rendering logic in core, including request-time rendering, explicit route rendering, static generation, and deferred boundary orchestration.
 
 ## Design Principles
 
@@ -12,16 +12,14 @@ These diagrams are based on a few architectural assumptions that seem important
   Adapters and route matchers decide which renderer to use; once selected, the integration renderer owns the page render pipeline.
 - **Data resolution should happen before HTML transformation.**
   Static props, metadata, dependency processing, and route assets are all upstream of final HTML injection.
-- **Marker graph orchestration should be a post-render reconciliation step.**
-  The initial integration render may emit deferred component markers; those are resolved after the first HTML pass, not during route matching.
-- **Marker emission is integration-defined boundary behavior.**
-  Markers are emitted when the active render boundary policy decides a component boundary must be deferred. If no `eco-marker` tokens are emitted, the marker graph stage is skipped entirely.
-- **The marker pipeline remains generic after emission.**
-  Once markers exist, core resolves them generically through marker graph extraction, integration renderer dispatch, asset collection, and HTML replacement. The current built-in React integration is one concrete consumer of that mechanism.
+- **Deferred boundary orchestration should stay renderer-owned.**
+  The initial integration render is responsible for handing foreign boundaries back to their owning renderer before final route HTML is returned.
+- **Foreign boundary ownership is renderer-defined behavior.**
+  If a renderer cannot resolve a foreign boundary inside its own runtime, route execution now treats any leftover unresolved boundary artifact HTML as an error instead of attempting any route-level fallback.
 - **Caching policy is authoritative at the page layer.**
   Middleware, locals, and response reuse all depend on the effective page cache strategy.
 - **Asset emission should converge into one injection stage.**
-  Route-level assets, integration assets, page-root component assets, and marker-generated assets all end up in the HTML transformer.
+  Route-level assets, integration assets, page-root component assets, and renderer-owned boundary assets all end up in the HTML transformer.
 
 ## Entry Points
 
@@ -143,7 +141,7 @@ flowchart TD
 
 ### 4.2 Main execute flow via `RenderExecutionService`
 
-Important nuance: this phase does not always run marker graph resolution. It only does that when the first render pass actually produced `eco-marker` placeholders. In practice today, that usually means a non-React renderer crossed into React component rendering and deferred those nodes for the second pass.
+Important nuance: this phase does not resolve mixed-integration boundaries itself anymore. Renderer-owned runtimes must finish that work before route finalization. If unresolved boundary artifact HTML survives to this phase, route execution fails fast.
 
 ```mermaid
 flowchart TD
@@ -151,19 +149,14 @@ flowchart TD
   B --> C[prepareRenderOptions]
   C --> D[runWithComponentRenderContext then render]
   D --> E[normalize response body to renderedHtml]
-  E --> F[merge captured and explicit componentGraphContext]
-  F --> G{contains eco marker token?}
-  G -- Yes --> H[resolveMarkerGraphHtml]
-  G -- No --> I[skip graph resolution]
-  H --> J[HtmlTransformerService dedupeProcessedAssets]
-  J --> K[merge marker assets into transformer deps]
-  I --> L{root attributes attachable?}
-  K --> L
-  L -- Yes --> M[HtmlTransformerService applyAttributesToFirstBodyElement]
-  L -- No --> N[leave html unchanged]
-  M --> O[htmlTransformer transform]
-  N --> O
-  O --> P[return body stream and cache strategy]
+  E --> F{contains unresolved boundary artifact html?}
+  F -- Yes --> G[throw unresolved boundary error]
+  F -- No --> H{root attributes attachable?}
+  H -- Yes --> I[HtmlTransformerService applyAttributesToFirstBodyElement]
+  H -- No --> J[leave html unchanged]
+  I --> K[htmlTransformer transform]
+  J --> K
+  K --> L[return body stream and cache strategy]
 ```
 
 ### 4.3 Render preparation responsibilities
@@ -189,7 +182,7 @@ flowchart LR
 flowchart LR
   A[IntegrationRenderer] --> B[RenderPreparationService]
   A --> C[RenderExecutionService]
-  A --> D[MarkerGraphResolver]
+  A --> D[QueuedBoundaryRuntimeService]
   A --> F[PageModuleLoaderService]
   A --> G[DependencyResolverService]
   A --> H[HtmlTransformerService]
@@ -197,32 +190,32 @@ flowchart LR
   B --> F
   B --> G
   B --> H
-  C --> D
   C --> H
+  D --> H
 ```
 
-## 5) Marker Emission + Graph Resolution
+## 5) Boundary Tokens And Renderer-Owned Resolution
 
-This part is architecturally interesting because it introduces a second render stage. The first pass captures boundaries; the second pass resolves them in dependency order.
+This part is architecturally interesting because boundaries can still emit temporary transport tokens, but renderer-owned runtimes are now responsible for resolving foreign descendants before final route HTML is returned.
 
 If this feels complex, the simplest mental model is:
 
 - first pass: render everything that can be rendered safely right now
-- when a boundary cannot be rendered safely in the current integration pass, emit a placeholder marker instead
-- second pass: revisit those placeholders and render them using the correct integration renderer
-- final pass: merge any emitted assets and perform the normal HTML transformation
+- when a renderer supports mixed boundaries, hand foreign descendants back to the owning renderer inside that renderer's runtime
+- if literal `<eco-marker>` boundary artifact HTML survives to route finalization, treat it as a failure instead of attempting any route-level fallback
+- final pass: merge emitted assets and perform the normal HTML transformation
 
-In the current implementation, this marker path exists to defer React subtrees that cannot be rendered inline during the active non-React integration pass.
+In the current implementation, renderer-owned runtimes use internal boundary tokens for queued nested handoff. Literal `<eco-marker>` markup remains only as a route-level failure signal when unresolved boundary artifacts escape renderer-owned resolution.
 
-Important clarification: not every integration automatically goes through this stage. The marker pipeline is conditional.
+Important clarification: not every integration automatically goes through this stage. Boundary queueing is conditional.
 
-- If the first render pass returns plain HTML with no `eco-marker` tokens, rendering continues directly to post-processing and HTML transformation.
-- If the first render pass emits `eco-marker` tokens, the marker graph is built and resolved before the final HTML rewrite.
-- In the current implementation, marker emission is triggered when the active render pass boundary policy decides that entering React should be deferred. The policy is injected through component render context, and the React integration currently opts into that deferred behavior.
+- If a render pass stays inside one integration, rendering continues directly to post-processing and HTML transformation.
+- If a renderer can resolve foreign descendants inline, the boundary runtime returns resolved HTML immediately.
+- If a renderer needs token-based nested handoff, it queues renderer-owned transport tokens and resolves them before returning final HTML.
 
 ### Why this exists
 
-The marker pipeline exists because some component boundaries cannot always be rendered eagerly inside the current integration pass.
+Renderer-owned boundary queueing exists because some component boundaries cannot always be rendered eagerly inside the current integration pass.
 
 Typical reasons include:
 
@@ -231,62 +224,45 @@ Typical reasons include:
 - the parent render needs to preserve ordering and slots before the child subtree is resolved
 - the child render may emit its own assets or root attributes that must be merged back into the final document
 
-So the first pass captures a stable placeholder plus serialized render context, and the second pass resolves those placeholders using the correct integration renderer.
-
-Responsibility split:
-
-- core resolves the deferred marker mechanically: graph shape, refs, slot relationships, and target renderer lookup
-- the selected integration renderer resolves the actual component render once it receives `component`, `props`, and optional `children`
+So the first pass either returns resolved renderer-owned output immediately or emits a renderer-local transport token that is resolved before the enclosing renderer returns its final HTML.
 
 Another way to say it:
 
-- a marker is a promise that says "this subtree will be rendered later by another renderer"
-- the marker stores just enough information to make that later render deterministic
-- the graph exists so nested deferred boundaries resolve from leaves to parents, preserving child insertion order and slot structure
+- a boundary token says "this subtree belongs to another renderer, but the current renderer still owns the overall render pass"
+- the token stores just enough information to make that later renderer-owned handoff deterministic
+- the queue exists so nested foreign boundaries resolve from leaves to parents while preserving child insertion order and emitted assets
 
-### 5.1 Marker emission in `eco.component` factory
+### 5.1 Boundary interception in `eco.component` factory
 
-The key rule here today is: markers are not a general-purpose placeholder for every component. During an active component render pass, `eco.component` asks the current render boundary context whether the next boundary should be deferred. When the answer is defer, it captures props/refs/slot links and returns an `eco-marker` token instead of rendering the component immediately.
+The key rule here today is: boundaries are resolved by the owning renderer, not by a shared core fallback. During an active component render pass, `eco.component` asks the current render boundary context whether the next boundary should render inline or be resolved by a foreign renderer runtime.
 
-For the current built-in integrations, this is how non-React renders defer React subtrees until the marker resolution pass.
+For the current built-in integrations, this is how non-owning renderers hand foreign subtrees back to the owning runtime without relying on a shared core fallback.
 
 ```mermaid
 flowchart TD
   A[eco component render] --> B[getComponentRenderContext]
-  B --> C[boundaryContext decideBoundaryRender]
-  C --> D{decision is defer?}
-  D -- No --> E[render component content immediately]
-  D -- Yes --> F[create nodeId + propsRef]
-  F --> G[store props in propsByRef]
-  G --> H{children include eco-marker tokens?}
-  H -- Yes --> I[create slotRef and slotChildrenByRef links]
-  H -- No --> J[no slot links]
-  I --> K[createComponentMarker]
-  J --> K
-  K --> L[return eco marker token]
+  B --> C[boundaryRuntime interceptBoundarySync]
+  C --> D{resolved foreign boundary?}
+  D -- No --> E[render component content inline]
+  D -- Yes --> F[return renderer-owned resolved html]
 ```
 
-### 5.2 Marker graph execution
+### 5.2 Queued boundary execution
 
-Once markers exist in the HTML, the second pass is integration-agnostic at execution time. Each marker carries its target integration name, so the resolver can ask the right renderer to render that specific node. Even though marker emission is currently React-focused, the resolution phase itself is generic and works off the marker payload plus renderer lookup.
+When string-first renderers queue foreign boundaries, the base renderer helper resolves queued boundary tokens directly against the shared queue service. That pass is intentionally narrow: it only resolves queued boundary tokens that the owning renderer emitted as transport artifacts for that string runtime.
 
-This means the marker itself is not interpreted by the integration renderer. Core interprets the marker and reconstructs render input; the integration renderer only performs the final component render.
+This means boundary tokens are no longer a general component-boundary contract. Core only resolves queued boundary payloads that already belong to a renderer-owned string boundary workflow.
 
 ```mermaid
 flowchart TD
-  A[resolveMarkerGraphHtml] --> B[buildComponentRefRegistry]
-  B --> C[extractComponentGraph from html and slot registry]
-  C --> D[resolveComponentGraph in reverse levels]
-  D --> E[for each marker node]
-  E --> F[resolve component by componentRef]
-  F --> G[resolve props by propsRef]
-  G --> H[stitch child html from slotRef node ids]
-  H --> I[getIntegrationRendererForName]
-  I --> J[renderer.renderComponent]
-  J --> K[collect component assets]
-  K --> L[apply root attributes to first element]
-  L --> M[replace marker token in HTML]
-  M --> N[resolved html and assets]
+  A[string boundary runtime html] --> B[find queued boundary tokens]
+  B --> C[resolve nested child tokens first]
+  C --> D[dispatch boundary to owning renderer]
+  D --> E[renderer.renderComponentBoundary]
+  E --> F[collect emitted assets]
+  F --> G[apply root attributes to first element]
+  G --> H[replace queued token in html]
+  H --> I[resolved html and merged assets]
 ```
 
 ## 6) Explicit Rendering Paths (outside FS page matching)
@@ -345,15 +321,12 @@ For someone new to the rendering system, this is probably the most useful order
 6. `integration-renderer.ts`
 7. `render-preparation.service.ts`
 8. `render-execution.service.ts`
-9. `marker-graph-resolver.ts`
+9. `queued-boundary-runtime.service.ts`
 10. `html-transformer.service.ts`
 11. `page-module-loader.ts`
 12. `dependency-resolver.ts`
-13. `component-marker.ts`
-14. `component-graph.ts`
-15. `component-graph-executor.ts`
-16. `eco.ts`
-17. `component-render-context.ts`
+13. `eco.ts`
+14. `component-render-context.ts`
 
 ## 9) Key Files
 
@@ -368,10 +341,7 @@ For someone new to the rendering system, this is probably the most useful order
 - `packages/core/src/route-renderer/orchestration/integration-renderer.ts`
 - `packages/core/src/route-renderer/orchestration/render-preparation.service.ts`
 - `packages/core/src/route-renderer/orchestration/render-execution.service.ts`
-- `packages/core/src/route-renderer/component-graph/marker-graph-resolver.ts`
-- `packages/core/src/route-renderer/component-graph/component-marker.ts`
-- `packages/core/src/route-renderer/component-graph/component-graph.ts`
-- `packages/core/src/route-renderer/component-graph/component-graph-executor.ts`
+- `packages/core/src/route-renderer/orchestration/queued-boundary-runtime.service.ts`
 - `packages/core/src/route-renderer/page-loading/page-module-loader.ts`
 - `packages/core/src/route-renderer/page-loading/dependency-resolver.ts`
 - `packages/core/src/services/module-loading/page-module-import.service.ts`

package/src/route-renderer/README.md

@@ -25,23 +25,18 @@ Framework-owned orchestration services and renderer base class:
 
 - `integration-renderer.ts`: abstract base class that coordinates end-to-end route rendering.
 - `render-preparation.service.ts`: page module/data/dependency preparation before render.
-- `render-execution.service.ts`: render capture, marker-graph resolution, and finalization.
+- `render-execution.service.ts`: render capture, unresolved boundary artifact enforcement, and finalization.
+- `queued-boundary-runtime.service.ts`: shared queued foreign-boundary runtime used directly by renderer-owned helpers, including string-first renderers.
 
 It also provides:
 
 - `renderToResponse()` contract for explicit-route rendering.
 - `renderComponent()` contract for component-level orchestration and artifact reporting.
-- marker graph resolution for nested cross-integration component boundaries.
+- deferred boundary resolution for nested cross-integration component boundaries.
 
-### `component-graph/`
+### Boundary Tokens
 
-Component marker contracts and graph resolution:
-
-- `createComponentMarker()` for canonical `<eco-marker ...></eco-marker>` generation.
-- `parseComponentMarkers()` for marker extraction from rendered HTML.
-- node collection by marker id.
-- parent/child edges from slot reference registry.
-- topological levels for bottom-up execution.
+Renderer-owned runtimes may emit internal boundary tokens while they resolve foreign descendants before returning final HTML. If literal `<eco-marker ...></eco-marker>` markup survives to route finalization, it is treated as an unresolved boundary artifact rather than a normal transport mechanism.
 
 ### `page-loading/`
 
@@ -61,7 +56,7 @@ Builds processed assets from component dependency declarations:
 
 Default behavior:
 
-- marker-graph component orchestration + component render artifacts.
+- renderer-owned component-boundary orchestration + component render artifacts.
 - global lazy trigger map + global injector bootstrap.
 
 Global injector lifecycle notes:
@@ -87,12 +82,10 @@ Current base orchestration behavior:
 - Merges returned `assets` into processed dependencies.
 - Applies returned `rootAttributes` to the first element under `<body>`.
 
-When rendered output contains `eco-marker` nodes:
+When rendered output still contains unresolved boundary artifact HTML:
 
-- builds marker graph using `componentGraphContext` (`propsByRef`, `slotChildrenByRef`) from integration-specific page module exports.
-- resolves markers bottom-up through integration-specific `renderComponent()` calls.
-- fails fast when marker component refs or props refs are missing.
-- merges marker-rendered assets back into the dependency pipeline with deduplication.
+- route execution now fails fast instead of attempting any route-level unresolved-boundary fallback.
+- renderer-owned boundary runtimes are responsible for resolving foreign nested components before final route HTML is returned.
 
 This enables island-style hydration assets (for example React/Lit/Kita integration outputs) to be emitted through the normal dependency injection pipeline.
 
@@ -115,8 +108,9 @@ This enables island-style hydration assets (for example React/Lit/Kita integrati
 6. HTML transformer injects head/body dependencies.
 7. Route result returns body + metadata + cache strategy.
 
-## Notes for Future Work
+## Current Limits And Near-Term Work
+
+If you are reading this file to understand today's contract, you can stop at the output pipeline above. The items below describe areas still evolving rather than required behavior.
 
-- Expand integration-side marker emission so more nested trees are resolved through graph mode by default.
-- Add broader fixtures/e2e for deep multi-level slot graphs.
-- Add optional batching by integration per graph level to reduce repeated renderer invocations.
+- Deep multi-level mixed-integration trees now rely on renderer-owned boundary runtimes rather than a shared post-render graph resolver.
+- Each renderer still decides how to hand off foreign boundaries, so specialized runtimes remain appropriate where child serialization or hydration contracts differ.

package/src/route-renderer/orchestration/component-render-context.d.ts

@@ -0,0 +1,83 @@
+import type { EcoComponent } from '../../types/public-types.js';
+/**
+ * Result returned by a renderer-owned boundary runtime.
+ *
+ * `inline` keeps rendering inside the current integration. `resolved` returns a
+ * renderer-owned value immediately, which can be final HTML or a renderer-local
+ * transport token for later queue resolution.
+ */
+export type ComponentBoundaryInterceptionResult = {
+    kind: 'inline';
+} | {
+    kind: 'resolved';
+    value: unknown;
+};
+/**
+ * Boundary metadata passed into the active renderer-owned runtime.
+ */
+export type ComponentBoundaryInterceptionInput = {
+    currentIntegration: string;
+    targetIntegration?: string;
+    component: EcoComponent;
+    props: Record<string, unknown>;
+};
+/**
+ * Narrow renderer-owned boundary runtime injected into one active render
+ * context.
+ *
+ * Integrations implement this contract when foreign boundaries must be handed
+ * off inside the renderer instead of being left for route-level reconciliation.
+ */
+export interface ComponentBoundaryRuntime {
+    interceptBoundary?(input: ComponentBoundaryInterceptionInput): ComponentBoundaryInterceptionResult | Promise<ComponentBoundaryInterceptionResult>;
+    interceptBoundarySync?(input: ComponentBoundaryInterceptionInput): ComponentBoundaryInterceptionResult;
+}
+type ComponentBoundaryRenderInput = {
+    component: EcoComponent;
+    props: Record<string, unknown>;
+    targetIntegration?: string;
+};
+/**
+ * Per-render mutable state used while applying boundary interception and lazy
+ * output wrapping.
+ */
+export type ComponentRenderContext = {
+    currentIntegration: string;
+    boundaryRuntime?: ComponentBoundaryRuntime;
+    interceptBoundary(input: ComponentBoundaryRenderInput): Promise<unknown | undefined> | unknown | undefined;
+    finalizeComponentRender<T>(component: EcoComponent, content: T): T;
+};
+/**
+ * Returns the current component render context, if one is active.
+ *
+ * @returns Active render context or `undefined` outside render execution.
+ */
+export declare function getComponentRenderContext(): ComponentRenderContext | undefined;
+/**
+ * Runs boundary interception for one component boundary.
+ *
+ * The active runtime may resolve the boundary immediately or keep it inline.
+ */
+export declare function interceptComponentBoundary(input: ComponentBoundaryRenderInput): Promise<unknown | undefined> | unknown | undefined;
+/**
+ * Applies lazy trigger or injector wrapping to completed component output.
+ *
+ * This helper works both inside render-context execution and in fallback flows
+ * where no active context exists.
+ */
+export declare function finalizeComponentRender<T>(component: EcoComponent, content: T): T;
+/**
+ * Runs render work under a fresh component render context and returns the
+ * resulting value.
+ *
+ * @param input Execution metadata for current integration and boundary policy.
+ * @param render Async render function to execute inside the context.
+ * @returns Render result value.
+ */
+export declare function runWithComponentRenderContext<T>(input: {
+    currentIntegration: string;
+    boundaryRuntime?: ComponentBoundaryRuntime;
+}, render: () => Promise<T>): Promise<{
+    value: T;
+}>;
+export {};

package/src/route-renderer/orchestration/component-render-context.js

@@ -0,0 +1,147 @@
+import { addTriggerAttribute, isThenable, wrapWithScriptsInjector } from "./render-output.utils.js";
+class ComponentRenderOutputRuntime {
+  finalizeComponentRender(component, content) {
+    const lazyTriggers = component.config?._resolvedLazyTriggers;
+    if (lazyTriggers && lazyTriggers.length > 0) {
+      return this.addTriggerToContent(content, lazyTriggers[0].triggerId);
+    }
+    const lazyGroups = component.config?._resolvedLazyScripts;
+    if (lazyGroups && lazyGroups.length > 0) {
+      return this.wrapContentWithScriptsInjector(content, lazyGroups);
+    }
+    return content;
+  }
+  addTriggerToContent(content, triggerId) {
+    if (isThenable(content)) {
+      return content.then((resolvedContent) => addTriggerAttribute(resolvedContent, triggerId));
+    }
+    return addTriggerAttribute(content, triggerId);
+  }
+  wrapContentWithScriptsInjector(content, lazyGroups) {
+    if (isThenable(content)) {
+      return content.then((resolvedContent) => wrapWithScriptsInjector(resolvedContent, lazyGroups));
+    }
+    return wrapWithScriptsInjector(content, lazyGroups);
+  }
+}
+class ContextualComponentRenderRuntime extends ComponentRenderOutputRuntime {
+  context;
+  constructor(context) {
+    super();
+    this.context = context;
+  }
+  applyBoundaryInterceptionResult(result) {
+    if (result.kind === "resolved") {
+      return result.value;
+    }
+    return void 0;
+  }
+  /**
+   * Resolves one boundary interception through the active runtime.
+   *
+   * The runtime may choose inline rendering or immediate resolved output.
+   */
+  interceptBoundary(input) {
+    const boundaryRuntimeInput = {
+      currentIntegration: this.context.currentIntegration,
+      targetIntegration: input.targetIntegration,
+      component: input.component,
+      props: input.props
+    };
+    const asyncInterception = this.context.boundaryRuntime?.interceptBoundary?.(boundaryRuntimeInput);
+    if (asyncInterception !== void 0) {
+      if (isThenable(asyncInterception)) {
+        return asyncInterception.then((result) => this.applyBoundaryInterceptionResult(result));
+      }
+      return this.applyBoundaryInterceptionResult(asyncInterception);
+    }
+    const syncInterception = this.context.boundaryRuntime?.interceptBoundarySync?.(boundaryRuntimeInput);
+    if (syncInterception === void 0) {
+      return void 0;
+    }
+    return this.applyBoundaryInterceptionResult(syncInterception);
+  }
+}
+const GLOBAL_COMPONENT_RENDER_CONTEXT_STATE_KEY = "__ECOPAGES_COMPONENT_RENDER_CONTEXT_STATE__";
+function getSharedContextScope() {
+  const globalProcess = globalThis.process;
+  if (globalProcess && typeof globalProcess === "object") {
+    return globalProcess;
+  }
+  return globalThis;
+}
+function getComponentRenderContextState() {
+  const sharedScope = getSharedContextScope();
+  sharedScope[GLOBAL_COMPONENT_RENDER_CONTEXT_STATE_KEY] ??= {
+    contextStack: [],
+    nodeContextStorage: null,
+    nodeContextStorageLoader: null
+  };
+  return sharedScope[GLOBAL_COMPONENT_RENDER_CONTEXT_STATE_KEY];
+}
+async function getContextStorage() {
+  const state = getComponentRenderContextState();
+  if (state.nodeContextStorage) {
+    return state.nodeContextStorage;
+  }
+  if (state.nodeContextStorageLoader) {
+    return state.nodeContextStorageLoader;
+  }
+  state.nodeContextStorageLoader = import("node:async_hooks").then((module) => {
+    const storage = new module.AsyncLocalStorage();
+    state.nodeContextStorage = {
+      getStore: () => storage.getStore(),
+      run: (store, callback) => storage.run(store, callback)
+    };
+    return state.nodeContextStorage;
+  }).catch(() => {
+    state.nodeContextStorage = null;
+    return null;
+  }).finally(() => {
+    state.nodeContextStorageLoader = null;
+  });
+  return state.nodeContextStorageLoader;
+}
+function getComponentRenderContext() {
+  const state = getComponentRenderContextState();
+  return state.nodeContextStorage?.getStore() ?? state.contextStack[state.contextStack.length - 1];
+}
+const componentRenderOutputRuntime = new ComponentRenderOutputRuntime();
+function interceptComponentBoundary(input) {
+  return getComponentRenderContext()?.interceptBoundary(input);
+}
+function finalizeComponentRender(component, content) {
+  const renderContext = getComponentRenderContext();
+  return renderContext?.finalizeComponentRender(component, content) ?? componentRenderOutputRuntime.finalizeComponentRender(component, content);
+}
+async function runWithComponentRenderContext(input, render) {
+  const context = {
+    currentIntegration: input.currentIntegration,
+    boundaryRuntime: input.boundaryRuntime
+  };
+  const runtime = new ContextualComponentRenderRuntime(context);
+  context.interceptBoundary = (deferredInput) => runtime.interceptBoundary(deferredInput);
+  context.finalizeComponentRender = (component, content) => runtime.finalizeComponentRender(component, content);
+  const storage = await getContextStorage();
+  let value;
+  if (storage) {
+    value = await storage.run(context, render);
+  } else {
+    const state = getComponentRenderContextState();
+    state.contextStack.push(context);
+    try {
+      value = await render();
+    } finally {
+      state.contextStack.pop();
+    }
+  }
+  return {
+    value
+  };
+}
+export {
+  finalizeComponentRender,
+  getComponentRenderContext,
+  interceptComponentBoundary,
+  runWithComponentRenderContext
+};