cabloy 5.1.60 → 5.1.62

package/cabloy-docs/frontend/zova-vs-vue3-comparison.md

@@ -0,0 +1,308 @@
+# Zova vs Vue 3 Comparison
+
+This page compares **Zova’s frontend programming model** with the **default mental model many developers bring from Vue 3**.
+
+The goal is not to argue that one replaces the other.
+
+The goal is to explain two things clearly:
+
+1. **Zova still stands on top of Vue 3 runtime and reactivity foundations**
+2. **Zova deliberately changes the preferred authoring surface, architectural center, and code-organization habits built on top of those foundations**
+
+Use this page together with:
+
+- [Reading Zova for Vue Developers](/frontend/reading-zova-for-vue-developers)
+- [Zova Reactivity Under the Hood](/frontend/zova-reactivity-under-the-hood)
+- [Zova Source Reading Map](/frontend/zova-source-reading-map)
+
+## Why this page exists
+
+A Vue developer can look at Zova code and ask questions like these:
+
+- why is this state a plain class field instead of a `ref`?
+- why is derived state wired in `__init__` instead of declared in `setup()`?
+- why does route state appear on the controller instance instead of being pulled through `useRoute()`?
+- why does the page grow into controller/render/style/service beans instead of only more composables and child components?
+
+Those questions are reasonable.
+
+This page answers them by comparing the two programming models across a few stable architectural dimensions.
+
+## The shortest accurate summary
+
+If you only want the shortest answer, use this one:
+
+> Vue 3 usually presents reactivity as explicit local primitives and composition-oriented setup logic, while Zova presents reactivity through framework-managed bean instances and controller-oriented architecture.
+
+Under the surface, Zova still uses Vue runtime/reactivity capabilities.
+
+The big difference is the **business-facing programming model**.
+
+## Side-by-side comparison table
+
+| Dimension | Zova | Vue 3 default mental model |
+| --- | --- | --- |
+| Reactive host | controller or bean instance | local `ref` / `reactive` values inside `setup()` |
+| Derived state | `$computed()` often assigned to instance fields | `computed()` usually assigned to local variables |
+| Main wiring surface | `__init__` and bean lifecycle | `setup()` and composition hooks |
+| Route state access | page-controller surface such as `$route`, `$params`, `$query` | composables such as `useRoute()` |
+| Sharing model | IoC containers and bean scopes unify more sharing patterns | composables, props/emits, `provide/inject`, and store layers often coexist |
+| Render organization | controller-oriented; render can stay in controller or move to render beans | component-oriented; template/render/setup stay the obvious center |
+| Growth path | split into controller, render, style, service, model, or other beans | split into composables, child components, and store or helper layers |
+| Architectural emphasis | explicit object roles, scope ownership, and runtime-managed surfaces | flexible local composition with more developer-managed assembly |
+
+## 1. Reactive host
+
+### Zova
+
+Zova often makes the controller or bean instance the visible reactive surface.
+
+That is why code can look like:
+
+```typescript
+count: number = 0;
+
+increment() {
+  this.count++;
+}
+```
+
+The important idea is not only shorter syntax.
+
+The important idea is that the framework is making the bean instance itself the business-facing state host.
+
+### Vue 3
+
+The default Vue mental model usually starts with explicit primitives:
+
+```typescript
+const count = ref(0);
+
+function increment() {
+  count.value++;
+}
+```
+
+### Comparison takeaway
+
+- Vue 3 teaches you to build reactivity from visible primitives
+- Zova teaches you to work on top of a framework-managed reactive object
+
+## 2. Derived state
+
+### Zova
+
+Derived state often looks like instance wiring:
+
+```typescript
+protected async __init__() {
+  this.count2 = this.$computed(() => {
+    return `=== ${this.count} ===`;
+  });
+}
+```
+
+This makes derived state feel like part of object initialization and lifecycle wiring.
+
+### Vue 3
+
+Derived state often looks like local reactive declaration:
+
+```typescript
+const count2 = computed(() => `=== ${count.value} ===`);
+```
+
+### Comparison takeaway
+
+- Vue 3 presents derived state as a local reactive value
+- Zova often presents it as an instance-level property of a controller or bean
+
+## 3. Main wiring surface
+
+### Zova
+
+Zova concentrates many setup concerns inside bean lifecycle methods such as:
+
+- `__init__`
+- `__dispose__`
+
+That is where you often wire:
+
+- computed values
+- watchers
+- derived state
+- lifecycle cleanup
+
+### Vue 3
+
+Vue 3 usually treats `setup()` as the main assembly point, then uses composition hooks around it.
+
+### Comparison takeaway
+
+- Vue 3 is more obviously composition-function-centered
+- Zova is more obviously lifecycle-and-object-centered
+
+## 4. Route state access
+
+### Zova
+
+For page controllers, route-aware state is often part of the controller surface:
+
+- `$route`
+- `$params`
+- `$query`
+
+This keeps route-aware page logic close to the page controller itself.
+
+### Vue 3
+
+Vue code more often pulls route state through:
+
+- `useRoute()`
+- `useRouter()`
+
+### Comparison takeaway
+
+- Vue 3 usually pulls route state into local composition code
+- Zova usually pushes route-aware state into the page-controller surface
+
+## 5. Sharing model
+
+### Zova
+
+Zova uses IoC as a larger frontend architectural answer, not only as a small dependency-injection convenience.
+
+That means questions often become:
+
+- which bean owns this behavior?
+- which scope should this bean live in?
+- should this be resolved through injection or lookup?
+
+### Vue 3
+
+Vue projects often combine several distinct sharing tools depending on the team and codebase:
+
+- props and emits
+- composables
+- `provide/inject`
+- store layers
+
+### Comparison takeaway
+
+- Vue 3 gives a flexible base that can lead to multiple sharing styles in one codebase
+- Zova tries to unify more of those patterns through bean and scope architecture
+
+## 6. Render organization
+
+### Zova
+
+Zova treats render as part of a controller-oriented architecture.
+
+A page can:
+
+- render directly inside the controller
+- later split render into a dedicated render bean
+- also split style into a style bean
+- later move additional state or behavior into service beans
+
+### Vue 3
+
+Vue usually treats the component itself as the natural render center:
+
+- template
+- render function
+- `setup()` locals feeding the component render
+
+### Comparison takeaway
+
+- Vue 3 makes the component the obvious render center
+- Zova makes the page or component controller architecture the larger center
+
+## 7. Growth path as complexity increases
+
+### Zova
+
+A common Zova growth path is:
+
+1. start with one page controller
+2. split render into a render bean
+3. split style into a style bean
+4. extract state or logic into service or model beans when ownership becomes clearer
+
+### Vue 3
+
+A common Vue growth path is:
+
+1. start with one component
+2. extract composables
+3. add child components
+4. introduce or extend store ownership where needed
+
+### Comparison takeaway
+
+- Vue 3 complexity growth often feels more composition-first
+- Zova complexity growth often feels more role-and-boundary-first
+
+## 8. Code-reading experience
+
+### Zova
+
+When reading Zova, you often ask:
+
+- which bean am I looking at?
+- is this a page, component, service, model, render, or style role?
+- what scope owns this bean?
+- what runtime surface is being injected or refreshed onto it?
+
+### Vue 3
+
+When reading Vue, you often ask:
+
+- what lives in `setup()`?
+- which composables are being used?
+- which local refs/computeds feed the render?
+- where does state ownership move to a store or parent component?
+
+### Comparison takeaway
+
+The reading rhythm itself changes.
+
+That is why a Vue expert can still feel unfamiliar inside Zova at first even though the lower-level reactive runtime is related.
+
+## What is the same underneath
+
+Despite all the differences above, a few important foundations are still shared:
+
+- Vue reactivity still matters underneath
+- dependency tracking still matters underneath
+- recomputation and rerender still matter underneath
+- component runtime behavior still matters underneath
+
+So the comparison is **not**:
+
+- Zova versus Vue runtime
+
+It is mostly:
+
+- Zova’s architectural authoring model versus Vue’s default authoring habits
+
+## When to prefer this comparison page
+
+Use this page when:
+
+- you already know Vue and want a clean translation layer into Zova
+- you want one page that summarizes the biggest architectural differences quickly
+- you need to explain to another developer why Zova code should not be auto-refactored back toward generic Vue patterns
+
+If you want the next level of detail after this page, continue with:
+
+- [Zova Reactivity Under the Hood](/frontend/zova-reactivity-under-the-hood)
+- [Zova Source Reading Map](/frontend/zova-source-reading-map)
+
+## Final takeaway
+
+The most important comparison insight is simple:
+
+> Vue 3 usually teaches explicit reactive primitives first and architectural composition second. Zova keeps the Vue runtime foundation but teaches explicit architectural roles first and hides more of the reactive primitive management behind framework-managed controller and bean surfaces.
+
+Once that shift is clear, Zova code becomes much easier to read on its own terms.

package/cabloy-docs/fullstack/backend-metadata-to-frontend-table-actions-debug-checklist.md

@@ -0,0 +1,245 @@
+# Backend Metadata to Frontend Table Actions Debug Checklist
+
+This page is a symptom-first verify/debug companion for one narrow fullstack question:
+
+> when a visible Student row action is wrong, stale, hidden, or missing, which layer should I check next?
+
+Use this page together with:
+
+- [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
+- [Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map)
+- [Contract Loop Playbook](/fullstack/contract-loop-playbook)
+- [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+- [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+
+> [!TIP]
+> **Mixed-chain diagnosis path**
+>
+> 1. **[Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)** — understand the mixed chain conceptually
+> 2. **[Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map)** — trace the Student row-action chain in file order
+> 3. **[Backend Metadata to Frontend Table Actions Debug Checklist](/fullstack/backend-metadata-to-frontend-table-actions-debug-checklist)** — verify which layer is wrong when the visible action still fails
+>
+> **You are here:** step 3.
+> **Previous recommended pages:** [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions) and [Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map).
+
+## Why this page exists
+
+The current docs already explain the mixed chain in two useful ways:
+
+- conceptually, through the mixed-chain explainer page
+- structurally, through the mixed-chain source-reading map
+
+What was still missing was one page that starts from symptoms.
+
+This page fills that gap.
+
+It is not another contract-loop overview and not another table-runtime deep dive. It is a practical checklist for debugging one Student row-action chain.
+
+## Fastest mental model for diagnosis
+
+A visible row action can fail at several different layers:
+
+1. backend row metadata may not point to the intended action resource
+2. custom backend action semantics may not have refreshed the generated frontend contract surface
+3. the frontend action resource may be missing or stale
+4. the page block/runtime handoff may not be feeding the right row schema into `ZTable`
+5. the table runtime may finally be filtering or resolving the action differently than expected
+
+The fastest debugging strategy is:
+
+> check the earliest possible source of truth first, and only descend into deeper runtime layers when the earlier layers already look correct.
+
+## Debugging checklist by layer
+
+### 1. Check the backend row metadata first
+
+Start here when:
+
+- the action is missing entirely
+- the wrong action appears in the operations column
+- the custom action is not present in the backend contract surface at all
+
+Primary source anchor:
+
+- `vona/src/suite/a-training/modules/training-student/src/dto/studentSelectResItem.tsx`
+
+What to confirm:
+
+- the row metadata still uses the intended `ZovaRender.cell(...)` identity
+- nested `ZovaRender.tableActionRow(...)` entries include the expected action names
+- custom actions such as `training-student:actionSummary` or `training-student:actionDeleteForce` are still present where expected
+
+If this layer is wrong, stop here and fix the metadata truth first.
+
+### 2. Check the forward-generated contract only when custom action semantics changed
+
+Only do this when the visible action depends on a changed backend endpoint such as:
+
+- `summary/:id`
+- `deleteForce/:id`
+
+Primary source anchors:
+
+- `vona/src/suite/a-training/modules/training-student/src/controller/student.ts`
+- `zova/src/suite/a-training/modules/training-student/cli/openapi.config.ts`
+- `zova/src/suite/a-training/modules/training-student/src/api/trainingStudent.ts`
+- `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+
+What to confirm:
+
+- the backend controller still exposes the intended custom endpoint
+- the frontend module OpenAPI config still owns the expected operation slice
+- the generated frontend API surface still contains the expected typed method
+- the thin model facade still delegates to the correct generated API path while keeping the existing resource-owner story intact
+
+If the endpoint changed but the generated contract did not refresh, the issue is not the visible action resource yet.
+It is a forward-chain regeneration problem.
+
+### 3. Check that the frontend action resource exists and matches the metadata identity
+
+Start here when:
+
+- backend metadata looks correct
+- generated contract also looks correct
+- but the visible action still does not render or behaves like the wrong action implementation
+
+Primary source anchors:
+
+- `zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionSummary.tsx`
+- `zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionDeleteForce.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx`
+
+What to confirm:
+
+- the expected custom or built-in action bean exists
+- the resource identity in backend metadata still matches the frontend bean identity
+- the custom action bean is still thin and delegates to the right model or command path
+- `actionOperationsRow` is still able to include and render the child action resources
+
+### 4. Check the page handoff into the list/table runtime
+
+Start here when:
+
+- backend metadata and action resources both look correct
+- but the list page still does not expose the action as expected
+
+Primary source anchors:
+
+- `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockTable/controller.tsx`
+
+What to confirm:
+
+- `schemaRow` is still exposed from the stable resource owner
+- `permissions` are still flowing through the shared page runtime
+- `blockTable` is still bridging the expected `schemaRow`, `data`, and `tableScope` into `ZTable`
+
+If this layer is wrong, the problem is in the page/runtime handoff, not in the action bean itself.
+
+### 5. Only then check final table/runtime resolution
+
+Go here last when:
+
+- metadata truth is correct
+- generated contract is correct
+- action resources exist
+- page block handoff also looks correct
+- but the action still renders incorrectly
+
+Primary final-runtime anchor:
+
+- `zova/src/suite-vendor/a-zova/modules/a-table/src/component/table/controller.tsx`
+
+At this point, switch from contract debugging into deeper table-runtime debugging.
+
+For the broader table runtime reading path, continue with [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map).
+
+## How to classify the failure
+
+### Visible action missing entirely
+
+Most likely checks, in order:
+
+1. backend row metadata truth
+2. frontend action resource identity exists
+3. page block/schema handoff
+
+### Visible action exists but uses stale behavior
+
+Most likely checks, in order:
+
+1. if custom semantics changed, inspect the forward-generated contract path
+2. distinguish generated-output drift from local dependency drift
+3. then confirm the action bean still delegates to the expected model/API path
+
+### Visible action exists but wrong permissions or visibility
+
+This is often a narrower visibility problem rather than a full mixed-chain problem.
+
+When that is the real issue, continue with [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide).
+
+### Visible action exists but wrong runtime/render resolution
+
+Treat this as the deepest layer.
+
+Only go here after upstream contract, generation, action-resource, and page handoff checks already pass.
+
+## Generated-output drift vs local dependency drift
+
+A useful distinction is:
+
+### Generated-output drift
+
+This is the problem when:
+
+- the custom backend contract changed
+- but the generated frontend API/model surface was not refreshed correctly
+
+Typical response:
+
+1. confirm backend contract truth first
+2. refresh the generated frontend contract surface
+3. verify the generated output itself before debugging the visible action
+
+### Local dependency drift
+
+This is the problem when:
+
+- the generated output already contains the expected action contract or types
+- but local consumers still behave as if the old version is installed
+
+Typical response:
+
+1. stop editing source truth
+2. prove the generated handoff is already correct
+3. rerun the normal sync flow
+4. only then repair local install state if needed
+
+For the broader drift vocabulary, continue with [Contract Loop Playbook](/fullstack/contract-loop-playbook).
+
+## What this page does not re-explain
+
+This page deliberately does **not** re-teach:
+
+- generic contract-loop direction and drift theory -> see [Contract Loop Playbook](/fullstack/contract-loop-playbook)
+- the conceptual mixed-chain story -> see [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
+- the file-order mixed-chain path -> see [Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map)
+- table-action permission semantics in depth -> see [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+- deep table runtime internals -> see [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+
+Its job is only to tell you which layer to verify next when the visible Student row action still fails.
+
+## Where to read next
+
+- If you need the conceptual mixed-chain explanation first, return to [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions).
+- If you need the file-order path first, continue with [Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map).
+- If you want a proof-oriented layer-by-layer validation workflow after making a change, continue with [Backend Metadata to Frontend Table Actions Verify Playbook](/fullstack/backend-metadata-to-frontend-table-actions-verify-playbook).
+- If the issue is really visibility/permission logic, continue with [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide).
+- If the mixed-chain layer itself now looks correct and you want the frontend consumer-side diagnosis family, continue with [Generated Contract Consumption Debug Checklist](/frontend/generated-contract-consumption-debug-checklist).
+- If the issue becomes deep table-runtime resolution, descend into [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map).
+
+## Final takeaway
+
+The cleanest way to debug a visible Student row action is not to start from the deepest table runtime file.
+
+Start from backend row metadata truth, then only move into generated contract follow-up, action resource existence, page handoff, and final runtime resolution as needed.

package/cabloy-docs/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map.md

@@ -0,0 +1,139 @@
+# Backend Metadata to Frontend Table Actions Source Reading Map
+
+This page is a practical source-reading companion for one narrow fullstack question:
+
+> if I need to trace one Student row-action chain across backend metadata, generated contract follow-up, and frontend action resources, which files should I open first, and in what order?
+
+Use this page together with:
+
+- [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+- [TableCell Authoring Cookbook](/frontend/table-cell-cookbook)
+- [Table + Resource CRUD Cookbook](/frontend/table-resource-crud-cookbook)
+- [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+
+> [!TIP]
+> **Mixed-chain reading path**
+>
+> 1. **[Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)** — understand the mixed contract chain conceptually
+> 2. **[Backend Metadata to Frontend Table Actions Source Reading Map](/fullstack/backend-metadata-to-frontend-table-actions-source-reading-map)** — trace the same Student row-action chain in file order
+>
+> **You are here:** step 2.
+> **Previous recommended page:** [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions).
+
+## Why this page exists
+
+The current mixed-chain explainer page already answers the conceptual question well:
+
+- backend metadata chooses frontend action resources
+- generated API/model follow-up can join that same thread when custom actions need backend endpoints
+- the visible row action is only the last step of the chain
+
+What it does not isolate directly is the shortest source-order path through one real Student row-action thread.
+
+This page fills that gap.
+
+It is a file-order map, not another runtime explainer.
+
+## How to use this page
+
+For the two paths below:
+
+1. start with the conceptual mixed-chain page first
+2. read the first source file to identify the current source of truth
+3. follow the handoff only until you can answer the question you actually have
+4. stop before you drift into deeper table/runtime internals unless they are really needed
+
+## 1. Built-in row-action chain
+
+Use this path when your question is about:
+
+- how one built-in row action becomes visible
+- how `actionOperationsRow` composes visible child actions
+- where backend metadata stops and frontend action resources start
+
+### Read the docs first
+
+- [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
+- [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+- [TableCell Authoring Cookbook](/frontend/table-cell-cookbook)
+
+### Then read source in this order
+
+1. `vona/src/suite/a-training/modules/training-student/src/dto/studentSelectResItem.tsx`
+2. `zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx`
+3. `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+4. `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockTable/controller.tsx`
+
+### What each file clarifies
+
+- `studentSelectResItem.tsx` shows the backend-owned row DTO metadata that chooses `basic-table:actionOperationsRow` and the visible child actions inside it
+- `tableCell.actionOperationsRow.tsx` shows how the frontend runtime filters those child actions by permission and renders them through nested action resources
+- `blockPage/controller.tsx` shows how `schemaRow`, `permissions`, and list data are exposed from the stable resource owner into the page runtime
+- `blockTable/controller.tsx` shows the bridge from page runtime into `ZTable`
+
+## 2. Custom action chain with generated contract follow-up
+
+Use this path when your question is about:
+
+- how a custom row action such as `summary` or `deleteForce` joins the mixed chain
+- where the forward-generated API/model path enters
+- how the visible action stays thin while backend truth and resource ownership remain coherent
+
+### Read the docs first
+
+- [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+
+### Then read source in this order
+
+1. `vona/src/suite/a-training/modules/training-student/src/controller/student.ts`
+2. `vona/src/suite/a-training/modules/training-student/src/dto/studentSelectResItem.tsx`
+3. `zova/src/suite/a-training/modules/training-student/cli/openapi.config.ts`
+4. `zova/src/suite/a-training/modules/training-student/src/api/trainingStudent.ts`
+5. `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+6. `zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionSummary.tsx`
+7. `zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionDeleteForce.tsx`
+8. optional downstream handoff:
+   - `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+   - `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockTable/controller.tsx`
+
+### What each file clarifies
+
+- `controller/student.ts` shows the backend source truth for custom endpoints such as `summary/:id` and `deleteForce/:id`
+- `studentSelectResItem.tsx` shows the backend row metadata that inserts the custom row actions into the operations column
+- `openapi.config.ts` shows the frontend module ownership rule for generated OpenAPI operations
+- `api/trainingStudent.ts` shows the generated typed API surface that the frontend can consume
+- `model/student.ts` shows the thin semantic facade over the stable resource owner
+- `tableCell.actionSummary.tsx` shows a visible action that stays thin and delegates summary behavior into the model/API path
+- `tableCell.actionDeleteForce.tsx` shows the same pattern for force-delete behavior
+- `blockPage` and `blockTable` are only needed when the question becomes “how does the list runtime carry that row schema into visible table output?”
+
+## What this page does not re-explain
+
+This page deliberately does **not** re-teach:
+
+- generic table runtime internals -> see [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map)
+- CRUD list-page assembly -> see [Table + Resource CRUD Cookbook](/frontend/table-resource-crud-cookbook)
+- row/bulk permission filtering semantics -> see [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide)
+- the pure forward bridge -> see [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- the pure reverse bridge -> see [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend)
+
+Its job is only to provide the shortest file-order path through one mixed Student row-action chain.
+
+## Where to read next
+
+- If you need the conceptual mixed-chain explanation first, return to [Backend Metadata to Frontend Table Actions](/fullstack/backend-metadata-to-frontend-table-actions).
+- If you now want to prove the Student row-action chain end-to-end after a change, continue with [Backend Metadata to Frontend Table Actions Verify Playbook](/fullstack/backend-metadata-to-frontend-table-actions-verify-playbook).
+- If the visible Student row action is still wrong after you understand the file-order path, continue with [Backend Metadata to Frontend Table Actions Debug Checklist](/fullstack/backend-metadata-to-frontend-table-actions-debug-checklist).
+- If your next question is purely forward-chain, continue with [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk).
+- If your next question is purely reverse-chain, continue with [Frontend Metadata Back to Backend](/fullstack/frontend-metadata-to-backend).
+- If your next question becomes table-runtime specific, continue with [Zova Table Source Reading Map](/frontend/zova-table-source-reading-map) and [Table Action Visibility and Permission Flow Guide](/frontend/table-action-visibility-permission-flow-guide).
+
+## Final takeaway
+
+The cleanest way to read a mixed Student row-action chain is not to jump directly into either the backend bridge docs or the deepest table runtime files.
+
+Start from the backend row metadata that chooses the visible action resources, then follow the custom forward-generated path only when the action semantics actually require new backend endpoints.