cabloy 5.1.60 → 5.1.62

package/cabloy-docs/frontend/root-behaviors-guide.md

@@ -0,0 +1,282 @@
+# Root Behaviors Guide
+
+This guide explains app-wide root behaviors in Zova through the current public Cabloy Basic source.
+
+Use this page when you want to understand:
+
+- what root behaviors are responsible for
+- where root behavior configuration is injected
+- how the routed tree is wrapped from the app host
+- how `BeanBehaviorsHolder`, `BehaviorRoot`, and `ServiceComposer` cooperate
+- what kinds of concerns belong at root behavior scope
+- where root behaviors stop and routing or routed-host behavior begins
+
+## Why this page exists
+
+Several existing docs already explain important parts of the story:
+
+- [Behavior Guide](/frontend/behavior-guide) explains generic Behavior concepts and authoring
+- [Zova App Guide](/frontend/zova-app-guide) explains `a-app` as the root app host
+- [A-Router Guide](/frontend/a-router-guide) explains the router runtime boundary
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide) explains routed-page host ownership
+- [Zova Source Reading Map](/frontend/zova-source-reading-map) explains compact reading paths
+
+What those pages do not isolate directly is the end-to-end app-wide behavior flow.
+
+That is the gap this page fills.
+
+In the current Basic source, root behaviors are not just “some behaviors used near the app.” They are the app-scope composition layer that wraps the routed tree from the root host, using behavior declarations from `scope.config.behaviors` and routing them through the behavior composition engine.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. `a-app` exposes the root behavior injection point through `scope.config.behaviors`
+2. `ControllerApp.__init__()` initializes `BeanBehaviorsHolder`
+3. the holder builds a synthetic root behavior declaration for `a-behavior:root`
+4. `BehaviorRoot` creates an inner composer for the declared app-wide behaviors
+5. `ServiceComposer` normalizes and loads the behavior stack
+6. `ControllerApp.render()` renders the routed tree through that composed root wrapper
+7. the routed content continues into router and host layers only after the root behavior chain has already wrapped it
+
+That means root behaviors are the app-wide render-time composition layer around the routed tree.
+
+This page starts where [Zova App Guide](/frontend/zova-app-guide) stops: the app host is already established, and the remaining question is how app-wide behavior composition works behind that host boundary.
+
+## What root behaviors are
+
+In the current Basic source, root behaviors are mainly these five things:
+
+- an **app-scope behavior declaration surface** through `scope.config.behaviors`
+- a **root behavior holder** through `BeanBehaviorsHolder`
+- a **synthetic root wrapper** through `a-behavior:root` / `BehaviorRoot`
+- a **behavior composition pipeline** through `ServiceComposer`
+- a **render-time wrapper around the routed tree** rather than around one page or one component only
+
+This is why root behaviors are best understood as part of the app host layer, not only as a generic behavior-scene feature.
+
+## What root behaviors are not
+
+It is equally important to avoid over-assigning responsibilities to root behaviors.
+
+Root behaviors do **not** themselves own:
+
+- the generic explanation of `@Behavior()` authoring
+- route registration or route-state injection
+- routed-host ownership such as tabs, stack, or keep-alive semantics
+- page-local render concerns that do not need app scope
+- standalone business state ownership that should live in a service or model bean
+
+So when you read this topic, read it as **app-wide render-time composition around routed content**, not as a replacement for routing, hosts, or generic behavior authoring.
+
+## The core source-reading path
+
+When reading root behaviors, use this order:
+
+1. `zova/src/suite-vendor/a-zova/modules/a-app/src/component/app/controller.tsx`
+2. `zova/src/suite-vendor/a-zova/modules/a-app/src/config/config.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/types/behavior.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/lib/useBehavior.ts`
+5. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/lib/behavior.ts`
+6. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/bean/bean.behaviorBase.ts`
+7. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/bean/bean.behaviorsHolder.ts`
+8. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/bean/behavior.root_.ts`
+9. `zova/src/suite-vendor/a-zova/modules/a-behavior/src/service/composer.ts`
+
+That order moves from root app host, to injection point, to declaration surface, to authoring helpers, to base contract, to root bridge, to synthetic root wrapper, and finally to the composition engine.
+
+## What each source file clarifies
+
+### `a-app/src/component/app/controller.tsx`
+
+This is the root app controller.
+
+Its root-behavior jobs are:
+
+- initialize `BeanBehaviorsHolder`
+- read app-wide behavior declarations from `scope.config.behaviors`
+- render `<RouterView />` through the behavior holder
+
+This file is the clearest proof that root behaviors wrap the routed tree from the app host.
+
+### `a-app/src/config/config.ts`
+
+This file is the root behavior injection point.
+
+It exposes:
+
+- `behaviors`
+
+That matters because it shows root behaviors are configured through the app module config surface instead of being hard-coded directly into the root controller.
+
+### `a-behavior/src/types/behavior.ts`
+
+This file is the behavior declaration and type contract.
+
+It defines:
+
+- `IBehaviorTag`
+- `IBehaviorItem`
+- `IBehaviors`
+- behavior-scene type registration
+- behavior-related JSX / HTML attribute surfaces
+
+This is the file to read when you want to understand what a behavior declaration looks like before runtime composition begins.
+
+### `a-behavior/src/lib/useBehavior.ts`
+
+This file exposes the public declaration helpers:
+
+- `$UseBehavior(...)`
+- `$UseBehaviorTag(...)`
+
+These helpers matter because root behavior composition starts from behavior declarations, not from manual wiring of raw behavior instances.
+
+### `a-behavior/src/lib/behavior.ts`
+
+This file defines the public `@Behavior()` decorator.
+
+That matters because root behaviors still use the same behavior scene as other behavior beans. They are not a separate special-purpose scene. What makes them special is their app-scope host position.
+
+### `a-behavior/src/bean/bean.behaviorBase.ts`
+
+This is the base behavior contract.
+
+It shows that a behavior bean can:
+
+- keep behavior options as `$options`
+- use host-scoped injections such as `$$beanBehavior` and `$$behaviorTag`
+- create a nested composer
+- default to `next()` pass-through when it does not need extra wrapping
+
+This file is the best place to confirm that a behavior is a bean-scene render interceptor, not just a free helper.
+
+### `a-behavior/src/bean/bean.behaviorsHolder.ts`
+
+This file is the bridge from app-level config to the actual behavior composition pipeline.
+
+Its main jobs are:
+
+- accept root holder options
+- store the host behavior tag
+- create a composer from a synthetic `a-behavior:root` declaration
+- watch reactive behavior sources and reload the composer when declarations change
+- remove behavior-only props before rendering
+- render the final chain around the default vnode, which in the app root is the routed tree
+
+This is the most important implementation file for understanding root behaviors end to end.
+
+### `a-behavior/src/bean/behavior.root_.ts`
+
+This file defines the synthetic root behavior.
+
+Its main jobs are:
+
+- create an inner composer from the declared root behaviors
+- reload that inner composer when root behavior options change
+- delegate render to the inner composer
+
+This matters because the root behavior chain is not composed directly on the app controller. It is composed through a stable synthetic root layer.
+
+### `a-behavior/src/service/composer.ts`
+
+This file is the behavior composition engine.
+
+Its main jobs are:
+
+- normalize behavior declarations into onion items
+- load onion slices from the behavior scene
+- reuse existing behavior instances when possible
+- update options when reused instances change
+- dispose removed behavior instances
+- build the final composed render chain
+
+This is the file to read when your next question is not only “where are root behaviors declared?” but “how does the app-wide behavior stack actually become a render pipeline?”.
+
+## Runtime flow from root config to wrapped routed tree
+
+The shortest practical runtime flow is:
+
+1. `a-app` exposes `scope.config.behaviors`
+2. `ControllerApp.__init__()` calls `BeanBehaviorsHolder.initialize(...)`
+3. the holder stores the behavior tag for the current host
+4. the holder creates a synthetic root declaration for `a-behavior:root`
+5. `BehaviorRoot` creates an inner composer from the declared behaviors
+6. `ServiceComposer` normalizes, loads, reuses, and composes behavior slices
+7. `ControllerApp.render()` returns the routed tree through the composed root wrapper
+8. individual root behaviors may call `next()` and then append app-wide UI around that routed output
+
+This explains why root behaviors are best described as app-scope wrapping around routed content rather than as page-local behavior selection.
+
+## What belongs in a root behavior
+
+Root behavior is a good fit when the concern should surround the routed tree as a whole.
+
+Typical fits include:
+
+- app-wide overlays or modal layers
+- app-shell wrappers that should apply around all routed content
+- global render-time concerns that depend on app-level service state
+- app-wide UI composition that should remain configurable instead of being copied into page code
+
+A practical rule is:
+
+- if the concern belongs around the routed tree, consider a root behavior
+- if the concern belongs only around one component or one page, keep it at component/page scope instead
+
+## Service-owned state and root behavior rendering
+
+A common root-behavior pattern is:
+
+- a service owns mutable UI state
+- the root behavior reads that state
+- the root behavior calls `next()` and then renders extra app-wide UI around the routed output
+
+This keeps state ownership and render wrapping separate:
+
+- services own state and actions
+- root behaviors own render-time composition around the app tree
+
+That separation usually produces cleaner app-shell code than forcing global overlay logic directly into unrelated pages.
+
+## Where root behaviors stop and other docs begin
+
+A useful boundary rule is:
+
+- **Behavior Guide** owns generic Behavior concepts and authoring
+- **Zova App Guide** owns the root app host boundary
+- **Root Behaviors Guide** owns app-wide behavior composition around the routed tree
+- **A-Router Guide** owns route registration and route-state injection
+- **Router View Hosts Guide** owns page-instance hosting, keep-alive, and empty/tabs/stack behavior
+
+So if your next question is:
+
+- “how do I author a behavior bean?” continue with [Behavior Guide](/frontend/behavior-guide)
+- “how does the app host mount the routed tree?” continue with [Zova App Guide](/frontend/zova-app-guide)
+- “how do routes become operational?” continue with [A-Router Guide](/frontend/a-router-guide)
+- “which host owns the routed page instance now?” continue with [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+
+## Read together with
+
+Use this page together with:
+
+- [Behavior Guide](/frontend/behavior-guide)
+- [Zova App Guide](/frontend/zova-app-guide)
+- [A-Router Guide](/frontend/a-router-guide)
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- [Zova Source Reading Map](/frontend/zova-source-reading-map)
+
+## Final takeaway
+
+The most accurate way to read root behaviors in Zova is not as a generic “global wrapper” shortcut and not as a routing feature.
+
+Read them as the app-scope behavior composition layer that:
+
+- starts from `scope.config.behaviors`
+- is initialized by the root app controller
+- is bridged by `BeanBehaviorsHolder`
+- is stabilized through `BehaviorRoot`
+- is executed through `ServiceComposer`
+- wraps the routed tree before control continues into routing and host layers
+
+That is the source-confirmed role of root behaviors in the current Basic frontend architecture.

package/cabloy-docs/frontend/route-alias-guide.md

@@ -59,3 +59,9 @@ When changing user-facing routes, ask:
 3. is the page params-aware, meaning the name-based alias path is the correct layer?
 
 That helps avoid breaking modular routing semantics.
+
+## Where to read next
+
+- If you want the broader public routing surface first, continue with [Page Route Guide](/frontend/page-route-guide).
+- If the alias decision depends on route metadata or shell behavior, continue with [Page Meta Guide](/frontend/page-meta-guide).
+- If you want the deeper routing runtime after the public surface is clear, descend into [Zova Router Under the Hood](/frontend/zova-router-under-the-hood).

package/cabloy-docs/frontend/router-stack-guide.md

@@ -0,0 +1,229 @@
+# Router Stack Guide
+
+This guide explains the Router Stack host in Zova through the current public Cabloy Basic source.
+
+Use this page when you want to understand:
+
+- what `routerViewStack` is responsible for
+- how stack hosting differs from Router Tabs
+- where `ControllerRouterViewStack` stops and `ModelStack` begins
+- how stack identity, pruning, and keep-alive work
+- why stack should be read as a routed-host primitive rather than as a workbench-tabs model
+
+## Why this page exists
+
+The existing router docs already explain several nearby layers:
+
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide) explains the shared routed-host layer
+- [Router Tabs Introduction](/frontend/router-tabs-introduction) and the rest of the tabs series explain the workbench-tabs branch
+- [A-Router Guide](/frontend/a-router-guide) explains the router runtime boundary before routed-host ownership begins
+
+What those pages do not isolate directly is the stack branch as a first-class host concept.
+
+That is the gap this page fills.
+
+In the current public Basic source, Router Stack is a framework-level routed-host primitive. It is smaller than the tabs model, uses a linear fullPath-keyed identity model, and does not add tabs-style workbench or page-meta semantics.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. the route has already become operational in `a-router`
+2. `routerViewStack` receives the routed page through the shared host contract
+3. `ControllerRouterViewStack` forwards host events into `ModelStack`
+4. `ModelStack` treats each route visit as a linear stack item keyed by `fullPath`
+5. `ModelStack` maintains stack contents, recency pruning, and keep-alive inclusion
+6. the host renders routed instances through the shared `BeanRouterViewBase` / `KeepAlive` contract
+
+That means Router Stack is best understood as a linear routed-cache host, not as a workbench/grouped-tabs host.
+
+## What Router Stack is
+
+In the current Basic source, Router Stack is mainly these four things:
+
+- a **shared routed-host specialization** built on `BeanRouterViewBase`
+- a **thin controller adapter** through `ControllerRouterViewStack`
+- a **linear stack state owner** through `ModelStack`
+- a **fullPath-keyed keep-alive and pruning model** for routed instances
+
+Those roles are enough to make it a distinct routed-host strategy, even though its implementation is much smaller than the tabs branch.
+
+## What Router Stack is not
+
+It is equally important to avoid over-assigning responsibilities to Router Stack.
+
+Router Stack does **not** itself own:
+
+- route registration or route-state injection
+- business workspace grouping
+- two-level tab semantics
+- tabs-style page-meta coordination
+- Admin/Web tabs layout behavior
+
+So when you read Router Stack, read it as a compact routed-host strategy after route resolution, not as the owner of the broader routing model and not as a smaller copy of Router Tabs.
+
+## The core source-reading path
+
+When reading Router Stack, use this order:
+
+1. `zova/src/suite-vendor/a-zova/modules/a-router/src/lib/routerViewBase.tsx`
+2. `zova/src/suite-vendor/a-zova/modules/a-routerstack/src/component/routerViewStack/controller.tsx`
+3. `zova/src/suite-vendor/a-zova/modules/a-routerstack/src/model/stack.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-routerstack/src/types/stack.ts`
+
+That order moves from the shared host contract, to the stack host adapter, to the real stack owner, and finally to the stack model shape.
+
+## What each source file clarifies
+
+### `a-router/src/lib/routerViewBase.tsx`
+
+This is the shared routed-host contract.
+
+Its main jobs are:
+
+- register the host with `$router`
+- receive routed output through `RouterView`
+- wrap routed instances in `KeepAlive`
+- assign vnode identity from host-prepared route meta
+- inject the current page route into the hosted vnode
+
+This file matters because Router Stack is not a standalone host system. It is a specialization built on this shared contract.
+
+### `a-routerstack/src/component/routerViewStack/controller.tsx`
+
+This is the Router Stack host controller.
+
+Its main jobs are very small and explicit:
+
+- inject `$$modelStack`
+- forward `backRoute(...)`
+- forward `forwardRoute(...)`
+- delegate `prepareRouteMeta(...)`
+- delegate `getKeepAliveInclude()`
+
+That is the key source-confirmed boundary:
+
+- the controller is a thin adapter
+- the real stack semantics live in `ModelStack`
+
+Unlike the tabs controller, the stack controller does **not** override `setPageMeta(...)`.
+
+### `a-routerstack/src/model/stack.ts`
+
+This is the real stack owner.
+
+Its main jobs are:
+
+- keep the linear stack in `tabs`
+- track `keepAliveInclude`
+- add or update routed stack items on forward navigation
+- delete stack items on back navigation
+- prune the stack by recency when `max` is bounded
+- prepare routed identity from `route.fullPath`
+
+This file is the source of truth for what “stack” really means in the framework.
+
+### `a-routerstack/src/types/stack.ts`
+
+This file defines the compact stack model shape.
+
+It confirms that the stack branch is much smaller than the tabs branch:
+
+- `ModelStackOptionsBase`
+- `RouteTabTransient`
+- `RouteTab`
+
+There is no tabs-style `items` structure or richer tab info contract here.
+
+## Stack identity model
+
+The most important stack rule is in `ModelStack.prepareRouteMeta(...)`.
+
+It returns:
+
+- `tabKey = route.fullPath`
+- `componentKey = route.fullPath`
+- `fullPath = route.fullPath`
+
+That means Router Stack collapses routed identity into one linear per-visit key.
+
+This is very different from Router Tabs, where:
+
+- `tabKey` is business/workspace grouping identity
+- `componentKey` is page-instance identity inside that grouping
+
+In Router Stack, one route visit is one stack identity.
+
+## Keep-alive and pruning behavior
+
+Router Stack still participates in keep-alive through the shared host layer, but its inclusion model is simple:
+
+- `keepAliveInclude` is derived from the current stack contents
+- each stack item contributes its own key
+- pruning removes older entries when the configured max is exceeded
+
+The pruning rule is recency-based, not workspace-based.
+
+That means Router Stack behaves more like a bounded linear routed cache than like a persistent workbench model.
+
+## Forward and back behavior
+
+The stack host reacts to route flow in a compact way:
+
+- `forwardRoute(route)` prepares the stack route meta and adds/updates the stack entry
+- `backRoute(route)` removes the matching `fullPath` entry
+
+This is another important semantic difference from tabs:
+
+- tabs maintain grouped workspace state and page-meta-aware items
+- stack mainly tracks linear routed presence
+
+## Current Cabloy Basic boundary
+
+In the current public Basic source:
+
+- Router Stack exists as a real framework primitive
+- the currently visible public Basic shell is centered on Router Tabs
+- Router Stack should therefore be read as an available routed-host strategy, not as the main visible Basic shell pattern
+
+This keeps the docs source-confirmed without overstating current public usage.
+
+## Where Router Stack stops and other docs begin
+
+A useful boundary rule is:
+
+- [A-Router Guide](/frontend/a-router-guide) owns route registration and route-state injection before host ownership begins
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide) owns the shared host layer and the first tabs/stack distinction
+- this page owns the Stack branch specifically
+- the existing Router Tabs pages own the workbench-tabs branch
+
+So if your next question is:
+
+- “how do routes become operational?” go back to [A-Router Guide](/frontend/a-router-guide)
+- “what is the shared host contract?” go to [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- “how does the workbench-tabs model work?” go to [Router Tabs Mechanism](/frontend/router-tabs-mechanism)
+
+## Read together with
+
+Use this page together with:
+
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- [Router Tabs Introduction](/frontend/router-tabs-introduction)
+- [Router Tabs Mechanism](/frontend/router-tabs-mechanism)
+- [Router Tabs vs Stack](/frontend/router-tabs-vs-stack)
+- [A-Router Guide](/frontend/a-router-guide)
+- [Zova Source Reading Map](/frontend/zova-source-reading-map)
+
+## Final takeaway
+
+The most accurate way to read Router Stack is not as “tabs, but simpler” and not as a replacement for the broader router runtime.
+
+Read it as the stack-oriented routed-host primitive that:
+
+- builds on the shared `BeanRouterViewBase` host contract
+- delegates host behavior through `ControllerRouterViewStack`
+- owns linear fullPath-keyed routed presence through `ModelStack`
+- participates in keep-alive and recency pruning
+- stays smaller than the Router Tabs workbench model
+
+That is the source-confirmed role of Router Stack in the current Basic frontend architecture.

package/cabloy-docs/frontend/router-tabs-introduction.md

@@ -2,10 +2,12 @@
 
 This guide is the landing page for the router-tabs documentation set in Zova within the Cabloy monorepo.
 
-Use it to understand what the router-tabs mechanism is, which questions each companion document answers, and what order to read them in.
+Use it to understand what the router-tabs mechanism is, how it fits into the broader routed-host layer, which questions each companion document answers, and what order to read them in.
 
 ## What router tabs are
 
+Router tabs are one routed-host strategy built on top of the shared Zova router-view host layer.
+
 Router tabs provide a workbench-style navigation model for frontend layouts that need more than a simple route-transition model.
 
 In the current Cabloy Basic source, the mechanism supports:
@@ -34,6 +36,8 @@ This document explains:
 
 Read [Router Tabs Mechanism](/frontend/router-tabs-mechanism).
 
+If your real question is whether this should be modeled as tabs at all, compare it first with [Router Tabs vs Stack](/frontend/router-tabs-vs-stack), then read [Router Stack Guide](/frontend/router-stack-guide) if the stack branch is a better fit.
+
 This document explains:
 
 - the shared state model
@@ -41,6 +45,8 @@ This document explains:
 - page metadata, keep-alive, cache, and pruning behavior
 - the relationship between the shared model and concrete layouts
 
+For authoring-focused page metadata usage, continue with [Page Meta Guide](/frontend/page-meta-guide).
+
 ### How should I author route meta for this?
 
 Read [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook).
@@ -64,6 +70,21 @@ This document explains:
 - how Web reuses the same model with a different shell style
 - why layout-specific UI should not be confused with shared mechanism semantics
 
+## Router ecosystem map
+
+Use this compact map when you want the shortest accurate document order for Zova routing and routed-shell behavior.
+
+| If your question is mainly about                                                            | Read this next                                                               | Then continue with                                                                                                                                                                                          |
+| ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| route records, shell/layout choice, and the public route surface                            | [Page Route Guide](/frontend/page-route-guide)                               | [Route Alias Guide](/frontend/route-alias-guide), [Navigation Guards Guide](/frontend/navigation-guards-guide)                                                                                              |
+| route registration, startup, lazy loading, and controller route-state injection             | [Zova Router Under the Hood](/frontend/zova-router-under-the-hood)           | [Router View Hosts Guide](/frontend/router-view-hosts-guide)                                                                                                                                                |
+| why one routed page behaves like an empty shell while another behaves like a workbench host | [Router View Hosts Guide](/frontend/router-view-hosts-guide)                 | this page, then [Router Tabs Mechanism](/frontend/router-tabs-mechanism)                                                                                                                                    |
+| the business meaning of router tabs                                                         | [Router Tabs Overview](/frontend/router-tabs-overview)                       | [Router Tabs Admin and Web Comparison](/frontend/router-tabs-admin-web-comparison)                                                                                                                          |
+| how the tabs model works in code                                                            | [Router Tabs Mechanism](/frontend/router-tabs-mechanism)                     | [Page Meta Guide](/frontend/page-meta-guide), [Router Tabs Layout Integration](/frontend/router-tabs-layout-integration), then [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook) |
+| how the current Basic layouts turn the shared tabs model into a visible shell               | [Router Tabs Layout Integration](/frontend/router-tabs-layout-integration)   | [Router Tabs Admin and Web Comparison](/frontend/router-tabs-admin-web-comparison)                                                                                                                          |
+| how to intentionally author `tabKey`, `componentKey`, and `keepAlive`                       | [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook) | [Zova Source Reading Map](/frontend/zova-source-reading-map)                                                                                                                                                |
+| which files to read first for a targeted source dive                                        | [Zova Source Reading Map](/frontend/zova-source-reading-map)                 | the branch that matches your current question                                                                                                                                                               |
+
 ## Recommended reading paths
 
 ### Product or architecture perspective
@@ -79,8 +100,9 @@ Recommended order:
 Recommended order:
 
 1. [Router Tabs Mechanism](/frontend/router-tabs-mechanism)
-2. [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook)
-3. [Router Tabs Admin and Web Comparison](/frontend/router-tabs-admin-web-comparison)
+2. [Router Tabs Layout Integration](/frontend/router-tabs-layout-integration)
+3. [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook)
+4. [Router Tabs Admin and Web Comparison](/frontend/router-tabs-admin-web-comparison)
 
 ### Maintenance and refactor perspective
 
@@ -100,6 +122,7 @@ For internal design boundaries, maintenance invariants, and refactor safety rule
 
 ## See also
 
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
 - [Router Tabs Overview](/frontend/router-tabs-overview)
 - [Router Tabs Mechanism](/frontend/router-tabs-mechanism)
 - [Router Tabs Route Meta Cookbook](/frontend/router-tabs-route-meta-cookbook)