cabloy 5.1.60 → 5.1.62

package/cabloy-docs/frontend/zova-source-reading-map.md

@@ -0,0 +1,421 @@
+# Zova Source Reading Map
+
+This page is a practical map for contributors and AI workflows that need to read Zova source code efficiently.
+
+It does not try to teach every subsystem from scratch. Instead, it answers a narrower question:
+
+> when I need to understand one kind of Zova frontend behavior, which files should I read first, and in what order?
+
+Use this page together with the architectural guides:
+
+- [Foundation](/frontend/foundation)
+- [Design Principles](/frontend/design-principles)
+- [IoC and Beans](/frontend/ioc-and-beans)
+- [Reading Zova for Vue Developers](/frontend/reading-zova-for-vue-developers)
+- [Frontend Source Reading Roadmap](/frontend/frontend-source-reading-roadmap)
+- [Zova Reactivity Under the Hood](/frontend/zova-reactivity-under-the-hood)
+
+## Why this page exists
+
+In a framework-sized codebase, source reading usually becomes slow for one reason:
+
+- you can already find _a_ relevant file
+- but you do not yet know the shortest path to the _next_ file
+
+Zova especially benefits from a reading map because several layers cooperate at once:
+
+- public wrappers and generated surfaces
+- controller or bean authoring surfaces
+- container and lifecycle runtime
+- route or SSR integration
+- module and suite boundaries
+
+This page gives a starting sequence for each major topic so readers can move from public surface to runtime layer without drifting.
+
+## How to use this page
+
+For each topic below:
+
+1. start with the public guide to refresh the architectural intent
+2. read the first source file to identify the public surface
+3. continue into the next runtime file only if you still need the implementation detail
+4. stop as soon as you have enough information for the task
+
+The goal is not to read the entire framework every time. The goal is to choose the shortest accurate path.
+
+## 1. Page controller and page reactivity
+
+Use this path when you are asking questions like:
+
+- why does a plain page-controller field update the UI?
+- where do `$params` and `$query` come from?
+- how does page render enter the runtime?
+
+### Read the docs first
+
+- [Page Guide](/frontend/page-guide)
+- [Reading Zova for Vue Developers](/frontend/reading-zova-for-vue-developers)
+- [Zova Reactivity Under the Hood](/frontend/zova-reactivity-under-the-hood)
+
+### Then read source in this order
+
+1. `zova/src/suite/a-demo/modules/demo-basic/src/page/state/controller.tsx`
+2. `zova/packages-zova/zova-core/src/composables/useController.ts`
+3. `zova/packages-zova/zova-core/src/bean/beanContainer.ts`
+4. `zova/packages-zova/zova-core/src/bean/beanBase.ts`
+5. `zova/packages-zova/zova-core/src/bean/beanControllerPageBase.ts`
+6. `zova/packages-zova/zova-core/src/core/context/component.ts`
+7. `zova/src/suite-vendor/a-zova/modules/a-router/src/monkey.ts`
+
+### What each file clarifies
+
+- `controller.tsx` shows the public authoring pattern
+- `useController.ts` shows controller creation and load timing
+- `beanContainer.ts` shows when beans become reactive and context-managed
+- `beanBase.ts` shows helper wrappers such as `$computed` and `$watch`
+- `beanControllerPageBase.ts` shows page-controller data-refresh hooks
+- `component.ts` shows controller-oriented render redirection
+- `a-router/src/monkey.ts` shows how route-aware state is pushed onto the controller
+
+## 2. Component controller and component wrapper behavior
+
+Use this path when you are asking questions like:
+
+- how do Z-prefixed wrapper components fit into the runtime?
+- how does `controllerRef` expose the controller instance?
+- how do component controllers differ from page controllers?
+
+### Read the docs first
+
+- [Component Guide](/frontend/component-guide)
+- [IoC and Beans](/frontend/ioc-and-beans)
+- [Reading Zova for Vue Developers](/frontend/reading-zova-for-vue-developers)
+
+### Then read source in this order
+
+1. a representative component metadata wrapper under `src/.metadata/component/*.ts`
+2. `zova/packages-zova/zova-core/src/composables/useController.ts`
+3. `zova/packages-zova/zova-core/src/bean/beanControllerBase.ts`
+4. `zova/packages-zova/zova-core/src/core/context/component.ts`
+5. the component controller source you are actually analyzing
+
+### What each file clarifies
+
+- metadata wrapper files show how the public component wrapper enters `useController(...)`
+- `useController.ts` shows how component-local controller data is prepared
+- `beanControllerBase.ts` shows component-controller data refresh rules such as props updates
+- `component.ts` shows how render is patched toward controller/render beans
+- the concrete component controller shows the public authoring pattern for the case you care about
+
+## 3. Bean lifecycle, instance scope, and helper APIs
+
+Use this path when you are asking questions like:
+
+- where should reactive setup happen?
+- what is the role of `__init__` and `__dispose__`?
+- how are helpers such as `$watch`, `$toRef`, or `$customRef` exposed?
+
+### Read the docs first
+
+- [IoC and Beans](/frontend/ioc-and-beans)
+- [Design Principles](/frontend/design-principles)
+
+### Then read source in this order
+
+1. `zova/packages-zova/zova-core/src/bean/beanBase.ts`
+2. `zova/packages-zova/zova-core/src/bean/beanBaseSimple.ts`
+3. `zova/packages-zova/zova-core/src/bean/beanContainer.ts`
+4. `zova/packages-zova/zova-core/src/core/context/util.ts`
+
+### What each file clarifies
+
+- `beanBase.ts` shows the main helper surface available to beans
+- `beanBaseSimple.ts` shows the lower-level bean identity/base surface
+- `beanContainer.ts` shows init, inject, and dispose flow
+- `context/util.ts` shows how instance scope is applied around framework operations
+
+## 4. Page routing, params, query, and layout-oriented route behavior
+
+Use this path when you are asking questions like:
+
+- where are typed params/query resolved?
+- how does a route record connect to a page wrapper?
+- where should route-aware page changes be debugged?
+
+### Read the docs first
+
+- [Page Route Guide](/frontend/page-route-guide)
+- [A-Router Guide](/frontend/a-router-guide)
+- [Zova Router Under the Hood](/frontend/zova-router-under-the-hood)
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- [Page Params Guide](/frontend/page-params-guide)
+- [Page Query Guide](/frontend/page-query-guide)
+- [Navigation Guards Guide](/frontend/navigation-guards-guide)
+
+### Then read source in this order
+
+1. the page `routes.ts` file for the module you care about
+2. `zova/src/suite-vendor/a-zova/modules/a-router/src/monkey.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-router/src/lib/utils.ts`
+4. the relevant route schema metadata or module page schema source
+5. `zova/packages-zova/zova-core/src/bean/beanControllerPageBase.ts`
+
+### What each file clarifies
+
+- route files show the public route declaration surface
+- `monkey.ts` shows controller data prepare/init/update behavior
+- route utils show how current/page route resolution is derived
+- route schema sources show typed parsing behavior for params and query
+- `beanControllerPageBase.ts` shows the page-controller refresh hook surface
+
+### When to continue into routed hosts
+
+If your next question becomes any of these:
+
+- why this route lands in one shell host rather than another
+- where keep-alive participation is decided after route resolution
+- where `tabKey` / `componentKey` are derived for routed pages
+- how the active layout consumes routed-host state
+
+then continue immediately with:
+
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- section 5 on this page for the compact source-reading path
+
+## 5. Router-view hosts, routertabs, and routerstack
+
+Use this path when you are asking questions like:
+
+- why does one routed page use an empty host while another behaves like a tabbed workbench?
+- where do `tabKey`, `componentKey`, and keep-alive inclusion actually come from?
+- how do `routerViewTabs` and `routerViewStack` differ at runtime?
+- which layout files are the real consumers of routed-host behavior?
+
+### Read the docs first
+
+- [Page Route Guide](/frontend/page-route-guide)
+- [Zova Router Under the Hood](/frontend/zova-router-under-the-hood)
+- [Router View Hosts Guide](/frontend/router-view-hosts-guide)
+- [Router Tabs Introduction](/frontend/router-tabs-introduction)
+- [Router Tabs Overview](/frontend/router-tabs-overview)
+- [Router Tabs Mechanism](/frontend/router-tabs-mechanism)
+- [Router Tabs vs Stack](/frontend/router-tabs-vs-stack)
+- [Router Stack Guide](/frontend/router-stack-guide)
+
+### Then read source in 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-router/src/component/routerViewEmpty/controller.tsx`
+3. `zova/src/suite-vendor/a-zova/modules/a-routertabs/src/component/routerViewTabs/controller.tsx`
+4. `zova/src/suite-vendor/a-zova/modules/a-routertabs/src/model/tabs.ts`
+5. `zova/src/suite-vendor/a-zova/modules/a-routerstack/src/component/routerViewStack/controller.tsx`
+6. `zova/src/suite-vendor/a-zova/modules/a-routerstack/src/model/stack.ts`
+7. the active layout controller/render pair that consumes the host you care about
+
+### What each file clarifies
+
+- `routerViewBase.tsx` shows the shared host contract for routed-page render, keep-alive, and host callbacks
+- `routerViewEmpty/controller.tsx` shows the minimal routed host without the richer tabs/stack model
+- `routerViewTabs/controller.tsx` shows the controller-facing tabs host entrypoint
+- `model/tabs.ts` shows workspace grouping, tab-item state, page-meta updates, and keep-alive inclusion
+
+If your next question becomes specifically about task-level title, dirty state, or form-scene presentation after the routed item is already open, continue with [Page Meta Guide](/frontend/page-meta-guide).
+
+- `routerViewStack/controller.tsx` shows the stack-host entrypoint with a smaller contract than tabs
+- `model/stack.ts` shows the fullPath-based stack identity model and recency-based pruning
+- active layout consumers show how the current shell turns host state into visible Admin or Web behavior
+
+## 6. Model state, cache-oriented state, and broader data ownership
+
+Use this path when you are asking questions like:
+
+- should this state live in a model bean?
+- how does Zova unify async and sync state categories?
+- where should I debug model-owned state instead of controller-owned state?
+
+### Read the docs first
+
+- [Model Architecture](/frontend/model-architecture)
+- [Model State Guide](/frontend/model-state-guide)
+- [Design Principles](/frontend/design-principles)
+
+### Then read source in this order
+
+1. the relevant model bean in the module you are studying
+2. `zova/src/suite-vendor/a-zova/modules/a-model/src/bean/bean.model/bean.model.useState.ts`
+3. representative built-in model beans such as router tabs or resource models
+4. nearby state-owner service/controller code that consumes the model
+
+### What each file clarifies
+
+- the local model bean shows the public business-facing ownership pattern
+- `bean.model.useState.ts` shows framework-level state helper behavior
+- built-in model beans show how the architecture is used in nontrivial cases
+- consuming code shows whether the state really belongs in the model or only uses the model result
+
+## 7. Command scene and command-bean invocation
+
+Use this path when you are asking questions like:
+
+- how does `$performCommand(...)` resolve a command bean?
+- when should an action live in a command bean instead of a page/controller method?
+- where do command names, helper bases, and generated command typing come from?
+
+### Read the docs first
+
+- [Command Scene Authoring](/frontend/command-scene-authoring)
+- [IoC and Beans](/frontend/ioc-and-beans)
+- [Frontend CLI](/frontend/cli)
+
+### Then read source in this order
+
+1. `zova/src/suite-vendor/a-zova/modules/a-command/src/lib/command.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-command/src/monkey.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-command/src/lib/performCommand.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-command/src/types/command.ts`
+5. one generated downstream metadata file such as `zova/src/suite/cabloy-basic/modules/basic-commands/src/.metadata/index.ts`
+6. representative command beans such as `command.create.tsx`, `command.delete.tsx`, `command.setValue.tsx`, or `command.log.tsx`
+
+### What each file clarifies
+
+- `command.ts` shows the public decorator surface and confirms the `sys` container scope
+- `monkey.ts` shows how `$performCommand(...)` is injected onto bean instances and how default `renderContext` data is synthesized from the host bean
+- `performCommand.ts` shows onion-name to bean resolution, sync-first then async bean loading, option merging, and command execution
+- `types/command.ts` shows the command-scene type contract, including `ICommandRecord`, `IDecoratorCommandOptions`, and `SymbolCommandResult`
+- generated downstream metadata shows the real command names and bean full names exposed by consuming modules
+- representative command beans show when to use the plain, bulk, row, or scene-sensitive command shapes
+
+## App-shell root host and `a-app`
+
+Use this path when you are asking questions like:
+
+- what is the root app host in Zova?
+- where does the routed tree first enter the app controller path?
+- where do app-wide behaviors wrap the routed content?
+- how should I read `a-app` without confusing it with routes, layouts, or SSR orchestration?
+
+### Read the docs first
+
+- [Zova App Guide](/frontend/zova-app-guide)
+- [Root Behaviors Guide](/frontend/root-behaviors-guide)
+- [App Startup Guide](/frontend/app-startup-guide)
+- [Page Route Guide](/frontend/page-route-guide)
+- [Behavior Guide](/frontend/behavior-guide)
+
+### Then read source in this order
+
+1. `zova/src/suite-vendor/a-zova/modules/a-app/src/.metadata/this.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-app/src/.metadata/index.ts`
+3. `zova/src/suite-vendor/a-zova/modules/a-app/src/.metadata/component/app.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-app/src/component/app/controller.tsx`
+5. `zova/src/suite-vendor/a-zova/modules/a-app/src/config/config.ts`
+
+### What each file clarifies
+
+- `this.ts` shows the module identity quickly
+- `.metadata/index.ts` shows the generated integration surface for controller, component, config, and scope
+- `.metadata/component/app.ts` shows the thin `ZApp` wrapper that mounts `ControllerApp` through `useController(...)`
+- `controller.tsx` shows app-level meta setup, behavior-holder initialization, and behavior-wrapped `RouterView` render
+- `config.ts` shows the root behavior injection point through `scope.config.behaviors`
+
+## 8. Behavior scene and render-time interception
+
+Use this path when you are asking questions like:
+
+- should this concern be a Behavior, a Component, or a Helper?
+- how do behaviors wrap render targets?
+- where does the behavior pipeline actually compose?
+
+### Read the docs first
+
+- [Behavior Guide](/frontend/behavior-guide)
+- [IoC and Beans](/frontend/ioc-and-beans)
+
+### Then read source in this order
+
+1. the public behavior wrapper and controller path referenced in the docs
+2. the concrete behavior bean you are studying
+3. the composer/service files used by the behavior scene
+4. any host-injected controller or bean that the behavior depends on
+
+### What each file clarifies
+
+- wrapper/controller files show the public entry into the behavior system
+- concrete behavior beans show authoring-time render interception
+- composer/service files show how behavior chains are normalized and executed
+- host dependencies show why host-scoped injection is part of the behavior design
+
+## 9. SSR runtime and hydration handoff
+
+Use this path when you are asking questions like:
+
+- is this SSR issue owned by Vona or Zova?
+- where does the frontend SSR runtime begin?
+- where should hydration-sensitive debugging start?
+
+### Read the docs first
+
+- [SSR Architecture Overview](/frontend/ssr-architecture-overview)
+- [SSR Overview](/frontend/ssr-overview)
+- [SSR Init Data](/frontend/ssr-init-data)
+- [SSR Troubleshooting Guide](/frontend/ssr-troubleshooting-guide)
+
+### Then read source in this order
+
+1. the frontend SSR site entry or generated SSR bundle entry for the affected app/site
+2. the SSR-related context/runtime files in `zova-core`
+3. the relevant page/controller/model code whose output differs between server and client
+4. if needed, the Vona SSR integration layer for the site entry and request handoff
+
+### What each file clarifies
+
+- SSR entry files show where the frontend runtime starts during SSR
+- SSR runtime/context files show how render context and state transfer are assembled
+- page/controller/model files show whether the bug is actually page-level logic
+- the Vona side shows whether the problem happens before the Zova runtime is even entered
+
+## 10. Modules, suites, and architectural placement
+
+Use this path when you are asking questions like:
+
+- where should new frontend code live?
+- does this belong in an existing module, a new module, or a different suite?
+- which source-tree boundary expresses the intended business architecture?
+
+### Read the docs first
+
+- [Modules and Suites](/frontend/modules-and-suites)
+- [Module Scope](/frontend/module-scope)
+- [Frontend Directory Structure](/reference/frontend-directory-structure)
+
+### Then read source in this order
+
+1. the nearby suite/module layout under `zova/src/suite*`
+2. the target module `package.json` and metadata if relevant
+3. representative peer modules in the same suite
+4. only then the exact controller/component/model/service file you intend to change
+
+### What each file clarifies
+
+- source-tree layout shows the real architectural neighborhood
+- module metadata shows naming, dependencies, and bundle-related declarations
+- peer modules show current placement conventions
+- the final target file then makes sense inside the correct architectural boundary
+
+## A compact reading strategy
+
+When in doubt, use this sequence:
+
+1. public guide
+2. representative example in app/module code
+3. public wrapper or controller entrypoint
+4. bean/container/runtime source
+5. integration layer such as router, behavior, model, or SSR
+
+That order usually gets you to the answer faster than starting from deep runtime files first.
+
+## Final takeaway
+
+The fastest way to read Zova source accurately is not to memorize every core file.
+
+It is to recognize which architectural topic you are in, then start from the smallest public surface that matches that topic and only descend into runtime files as needed.

package/cabloy-docs/frontend/zova-table-controller-render-supplement.md

@@ -0,0 +1,225 @@
+# Zova Table Controller Render Deep Dive
+
+This page is a small lower-level supplement for the Zova Table runtime.
+
+Use it when you already understand the broader table architecture and now want to inspect the controller micro-pipeline more precisely:
+
+- how `ControllerTable` boots
+- how visible columns and render functions are assembled
+- how `tableCell` render providers are normalized and resolved
+- how cell render preparation and transient-object handoff work
+
+## Why this supplement exists
+
+The existing table docs already cover the broad architecture well:
+
+- [Table Guide](/frontend/table-guide)
+- [Zova Table Under the Hood](/frontend/zova-table-under-the-hood)
+- [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+
+What those pages do not isolate directly is the controller/render micro-pipeline inside `ControllerTable`.
+
+That is the only gap this supplement fills.
+
+## The shortest accurate mental model
+
+A practical mental model is:
+
+1. `BeanControllerTableBase.$useTable(...)` owns the TanStack bridge at controller level
+2. `ControllerTable.__init__()` prepares schema properties, metadata, columns, and the table instance
+3. `_createTableMeta()` decides which properties are visible and which render function each one should use
+4. `_createColumnRender()` resolves either a `tableCell` bean-backed render path or a general render target
+5. `cellRenderPrepare()` can preload nested bean-backed renders
+6. `_cellRender()` / `_cellRenderInner()` hand off row/cell scope, fallback values, and transient `getValue(...)` state into final rendering
+
+That means the controller micro-pipeline is where schema, visibility, bean resolution, and render contexts finally converge.
+
+## Source-confirmed reading path
+
+When reading this topic, use this order:
+
+1. `zova/src/suite-vendor/a-zova/modules/a-table/src/lib/beanControllerTableBase.ts`
+2. `zova/src/suite-vendor/a-zova/modules/a-table/src/component/table/controller.tsx`
+3. `zova/src/suite-vendor/a-zova/modules/a-table/src/types/tableCell.ts`
+4. `zova/src/suite-vendor/a-zova/modules/a-table/src/types/tableColumn.ts`
+5. `zova/packages-utils/zova-jsx/src/lib/zovaJsx.ts`
+6. `zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx`
+
+That order moves from the controller/TanStack bridge, to the main controller runtime, to the render contracts, to the JSX runtime handoff, and finally to a concrete `tableCell` specimen.
+
+## `BeanControllerTableBase.$useTable(...)`
+
+The TanStack bridge lives in:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-table/src/lib/beanControllerTableBase.ts
+```
+
+The key source-confirmed behavior is:
+
+- `useVueTable(...)` is called inside `instanceScope(...)`
+- the returned table instance is `markRaw(...)`
+
+This is the first important lower-level rule:
+
+- the table instance is still controller-owned runtime
+- TanStack is the underlying table engine, but the controller remains the effective Zova runtime owner
+
+## `ControllerTable.__init__()` boot sequence
+
+The main runtime file is:
+
+```text
+zova/src/suite-vendor/a-zova/modules/a-table/src/component/table/controller.tsx
+```
+
+The source confirms this boot sequence:
+
+1. register `$$table`
+2. create the CEL environment and `ZovaJsx` instance
+3. create schema-driven properties
+4. refresh metadata
+5. watch `schema` for meta refresh
+6. create the TanStack table instance
+
+That is the core controller-level assembly path.
+
+## `_createTableMeta()` as visible-column/render assembly point
+
+Inside the same controller, `_createTableMeta()` is the clearest metadata-assembly step.
+
+It:
+
+- iterates schema-derived properties
+- builds column scope
+- builds render context
+- merges top-level column props
+- checks visibility
+- creates per-column render functions
+- stores the surviving visible properties and render map in `tableMeta`
+
+This is the most important micro-pipeline rule:
+
+- schema properties do not automatically become rendered columns
+- they are filtered and converted through controller-owned metadata assembly first
+
+## `getRenderProvider()` normalization and `_createColumnRender()`
+
+The render-resolution path also lives in `ControllerTable`.
+
+It decides whether a column render should be treated as:
+
+- text fallback
+- a general render target
+- a `tableCell` bean-backed renderer
+
+`_createColumnRender()` is the main resolution point where:
+
+- render provider is normalized
+- bean-backed providers are resolved
+- decorator options are merged
+- visibility hooks such as `checkVisible(...)` can participate
+
+This is the lower-level rule to remember:
+
+- render resolution is not only “take whatever the schema says”
+- the controller resolves and normalizes that render contract first
+
+## `cellRenderPrepare()` and nested render preloading
+
+`cellRenderPrepare()` is the preloading step for bean-backed renderers.
+
+This matters most for nested or action-heavy cells, because it lets the controller prepare the concrete `tableCell` beans before final render.
+
+A practical reading rule is:
+
+- `cellRenderPrepare()` is part of render readiness, not only a cosmetic helper
+
+A good current specimen is:
+
+- `basic-table/src/bean/tableCell.actionOperationsRow.tsx`
+
+because it prepares the nested row-action render set based on visibility.
+
+## `_cellRender()` / `_cellRenderInner()` and transient value handoff
+
+The final cell rendering path uses:
+
+- column scope
+- cell scope
+- fallback value
+- actual cell value
+- transient `getValue(...)` handoff through `ZovaJsx`
+
+This is where the lower-level scope handoff matters most.
+
+The current runtime uses the `ZovaJsx` transient-object path so cell renderers can see the active value context while still staying inside the controller-driven runtime.
+
+A practical reading rule is:
+
+- the final cell render is not only a plain function call
+- it is a scoped runtime handoff with controller-owned context
+
+## Table-cell contract in types
+
+The render contracts live in:
+
+- `a-table/src/types/tableCell.ts`
+- `a-table/src/types/tableColumn.ts`
+
+These files confirm the lower-level boundary types for:
+
+- `ITableCellRender`
+- `checkVisible(...)`
+- column scope vs cell scope
+- render contexts passed into cell renderers
+
+That makes them the right files to read when the runtime feels confusing even though the broad table docs are already understood.
+
+## Concrete specimen: operations-row tableCell
+
+A good concrete specimen is:
+
+```text
+zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx
+```
+
+This file is useful because it shows several lower-level pieces in one place:
+
+- `checkVisible(...)`
+- permission-based render filtering
+- nested render preparation
+- final action-row rendering through the table cell contract
+
+So it is the best small specimen for understanding why the micro-pipeline matters in practice.
+
+## What this page does not re-explain
+
+This supplement does **not** fully re-explain:
+
+- broad table authoring -> see [Table Guide](/frontend/table-guide)
+- full runtime architecture -> see [Zova Table Under the Hood](/frontend/zova-table-under-the-hood)
+- general file-order map -> see [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+- row/bulk permission semantics -> see [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+
+Its job is only to explain the controller/render micro-pipeline.
+
+## Where to read next
+
+Use these next steps depending on your question:
+
+- if you want the broad table runtime again, read [Zova Table Under the Hood](/frontend/zova-table-under-the-hood)
+- if you want the file-order map, read [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+- if you want row/bulk visibility behavior, read [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+- if you want the list-page runtime that feeds `ZTable`, read [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+
+## Final takeaway
+
+The most accurate way to read this lower-level table supplement is:
+
+- `BeanControllerTableBase` owns the TanStack bridge at controller scope
+- `ControllerTable` owns metadata assembly and render resolution
+- `tableCell` beans participate through explicit controller-managed resolution and scope handoff
+- `cellRenderPrepare()` and `_cellRender()` are part of the real runtime pipeline, not only helper details
+
+That is the source-confirmed controller/render micro-pipeline in the current Cabloy Basic table runtime.