@ecopages/core 0.2.0-alpha.12 → 0.2.0-alpha.14

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-owning renderer crossed into a React or Lit component boundary 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 still intentionally selective, 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,15 +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:
 
-- the first pass still renders from the page root downward and emits markers only for deferred boundaries.
-- each marker carries the target integration name plus the component, props, and optional slot references needed to reconstruct that subtree.
-- builds marker graph using `componentGraphContext` (`propsByRef`, `slotChildrenByRef`) from integration-specific page module exports, including nested deferred child markers captured inside serialized `children` props.
-- resolves markers bottom-up through integration-specific `renderComponent()` calls.
-- core decodes markers and selects the target renderer; the integration renderer only performs the reconstructed component render.
-- 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.
 
@@ -122,6 +112,5 @@ This enables island-style hydration assets (for example React/Lit/Kita integrati
 
 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.
 
-- Deep multi-level slot graphs now have dedicated unit, orchestration, and kitchen-sink coverage, and built-in marker emission covers the cross-integration React and Lit boundaries exercised by the current test matrix.
-- Integration-side marker emission is still conservative, so not every nested cross-integration tree resolves through graph mode by default.
-- Graph execution still resolves nodes one boundary at a time; batching by integration per level remains a possible follow-up if repeated renderer calls become a measurable cost.
+- 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

@@ -1,99 +1,52 @@
 import type { EcoComponent } from '../../types/public-types.js';
-import type { MarkerNodeId } from '../component-graph/component-marker.js';
 /**
- * Outcome returned by boundary policy during one component render pass.
+ * Result returned by a renderer-owned boundary runtime.
  *
- * - `inline`: render the target component immediately in the current pass
- * - `defer`: emit an `eco-marker` and resolve it during the marker graph phase
+ * `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 BoundaryRenderMode = 'inline' | 'defer';
+export type ComponentBoundaryInterceptionResult = {
+    kind: 'inline';
+} | {
+    kind: 'resolved';
+    value: unknown;
+};
 /**
- * Input provided to boundary policy when a component boundary is reached.
- *
- * This keeps `eco.component()` decoupled from concrete integration/plugin
- * objects while still giving policy enough information to decide whether the
- * boundary should render immediately or be deferred.
+ * Boundary metadata passed into the active renderer-owned runtime.
  */
-export type BoundaryRenderDecisionInput = {
+export type ComponentBoundaryInterceptionInput = {
     currentIntegration: string;
     targetIntegration?: string;
     component: EcoComponent;
+    props: Record<string, unknown>;
 };
 /**
- * Narrow render-pass facade used by `eco.component()` for boundary decisions.
- *
- * The boundary context is intentionally small so component rendering can remain
- * unaware of integration registries, plugin instances, or renderer lifecycles.
- */
-export type ComponentRenderBoundaryContext = {
-    /**
-     * Decides whether the next component boundary should render inline or defer to
-     * the marker graph stage.
-     *
-     * @param input Boundary metadata for the current render pass.
-     * @returns Boundary rendering mode for the target component.
-     */
-    decideBoundaryRender(input: BoundaryRenderDecisionInput): BoundaryRenderMode;
-};
-/**
- * Integration-owned hook for serializing framework-specific deferred child payloads.
- *
- * Core handles primitive values, generic template transport shapes, and node-like
- * objects directly. Integrations can provide this callback to teach the boundary
- * runtime about richer payloads such as framework template sentinels that should
- * survive marker deferral as HTML rather than as opaque objects.
- *
- * Returning `undefined` tells core that the value is not recognized by the
- * integration-specific serializer.
- */
-type DeferredValueSerializer = (value: unknown, serializeValue: (value: unknown) => string | undefined) => string | undefined;
-/**
- * Minimal boundary payload needed to emit one deferred marker.
+ * Narrow renderer-owned boundary runtime injected into one active render
+ * context.
  *
- * The props object is captured into the graph context so the later marker-graph
- * resolution pass can reconstruct the original component invocation outside the
- * current integration's render stack.
+ * Integrations implement this contract when foreign boundaries must be handed
+ * off inside the renderer instead of being left for route-level reconciliation.
  */
-type DeferredBoundaryRenderInput = {
+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 collecting marker graph references.
- *
- * Counters generate deterministic ids within one render execution.
+ * Per-render mutable state used while applying boundary interception and lazy
+ * output wrapping.
  */
 export type ComponentRenderContext = {
     currentIntegration: string;
-    boundaryContext: ComponentRenderBoundaryContext;
-    /** Optional integration-owned serializer for richer deferred child payloads. */
-    serializeDeferredValue?: DeferredValueSerializer;
-    /** Monotonic counter for stable marker node ids within one render pass. */
-    nextNodeId: number;
-    /** Monotonic counter for stable props references within one render pass. */
-    nextPropsRefId: number;
-    /** Monotonic counter for stable slot references within one render pass. */
-    nextSlotRefId: number;
-    /** Captured props for deferred boundaries, keyed by `propsRef`. */
-    propsByRef: Record<string, Record<string, unknown>>;
-    /** Nested child marker ids keyed by the parent boundary slot reference. */
-    slotChildrenByRef: Record<string, MarkerNodeId[]>;
-    tryRenderDeferredBoundary<E>(input: DeferredBoundaryRenderInput): E | undefined;
+    boundaryRuntime?: ComponentBoundaryRuntime;
+    interceptBoundary(input: ComponentBoundaryRenderInput): Promise<unknown | undefined> | unknown | undefined;
     finalizeComponentRender<T>(component: EcoComponent, content: T): T;
 };
-/**
- * Serializable graph context captured from one render execution.
- *
- * This payload is merged with explicit page-module graph context before marker
- * resolution in the route renderer.
- */
-export type ComponentGraphContext = {
-    /** Deferred boundary props keyed by marker `propsRef`. */
-    propsByRef: Record<string, Record<string, unknown>>;
-    /** Nested child marker ids keyed by marker `slotRef`. */
-    slotChildrenByRef: Record<string, MarkerNodeId[]>;
-};
 /**
  * Returns the current component render context, if one is active.
  *
@@ -101,12 +54,11 @@ export type ComponentGraphContext = {
  */
 export declare function getComponentRenderContext(): ComponentRenderContext | undefined;
 /**
- * Attempts to replace one component boundary with an `eco-marker` placeholder.
+ * Runs boundary interception for one component boundary.
  *
- * Outside an active render context this is a no-op and returns `undefined`, which
- * lets the caller render inline instead.
+ * The active runtime may resolve the boundary immediately or keep it inline.
  */
-export declare function tryRenderDeferredBoundary<E>(input: DeferredBoundaryRenderInput): E | undefined;
+export declare function interceptComponentBoundary(input: ComponentBoundaryRenderInput): Promise<unknown | undefined> | unknown | undefined;
 /**
  * Applies lazy trigger or injector wrapping to completed component output.
  *
@@ -115,20 +67,17 @@ export declare function tryRenderDeferredBoundary<E>(input: DeferredBoundaryRend
  */
 export declare function finalizeComponentRender<T>(component: EcoComponent, content: T): T;
 /**
- * Runs render work under a fresh component render context and returns both:
- * - the render result value
- * - captured graph reference maps for downstream marker resolution
+ * 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 and captured graph context maps.
+ * @returns Render result value.
  */
 export declare function runWithComponentRenderContext<T>(input: {
     currentIntegration: string;
-    boundaryContext: ComponentRenderBoundaryContext;
-    serializeDeferredValue?: DeferredValueSerializer;
+    boundaryRuntime?: ComponentBoundaryRuntime;
 }, render: () => Promise<T>): Promise<{
     value: T;
-    graphContext: ComponentGraphContext;
 }>;
 export {};