cabloy 5.1.61 → 5.1.62

package/cabloy-docs/frontend/generated-contract-consumption-debug-checklist.md

@@ -0,0 +1,190 @@
+# Generated Contract Consumption Debug Checklist
+
+This page is a symptom-first diagnostic companion for one narrow frontend question:
+
+> when generated contract consumption still looks wrong, which frontend consumer layer should I inspect next?
+
+Use this page together with:
+
+- [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)
+- [Generated Contract Consumption: List Branch](/frontend/generated-contract-consumption-list-branch)
+- [Generated Contract Consumption: Entry Branch](/frontend/generated-contract-consumption-entry-branch)
+- [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook)
+- [OpenAPI Runtime Under the Hood](/frontend/a-openapi-under-the-hood)
+- [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+
+> [!TIP]
+> **Generated-contract diagnosis path**
+>
+> 1. **[Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)** — understand the family and choose the branch
+> 2. **[Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook)** — prove what should be true after a change
+> 3. **[Generated Contract Consumption Debug Checklist](/frontend/generated-contract-consumption-debug-checklist)** — use this page when the result is already wrong and you need the first failing layer
+>
+> **You are here:** step 3.
+> **Previous recommended pages:** [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen) and [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook).
+
+## Why this page exists
+
+The current frontend generated-contract family already gives you:
+
+- a conceptual hub
+- list and entry branch pages
+- a proof-oriented verify playbook
+
+What was still missing was one symptom-first page.
+
+This page fills that gap.
+
+It is not another generation page and not another branch specimen. It is the checklist for isolating the first failing consumer-side layer.
+
+## Shared symptom: contract surface missing or stale
+
+Start here when the problem looks earlier than either list or entry runtime.
+
+Primary anchors:
+
+- `zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts`
+- optional direct schema consumer: `zova/src/suite/a-home/modules/home-passport/src/model/passport.ts`
+
+What to inspect first:
+
+- does the expected generated schema surface exist at all?
+- do the expected API/schema methods still exist on the module-level schema bean?
+- if the issue is clearly that the generated contract itself never refreshed, stop and hand off to the bridge/regeneration docs instead of debugging consumer pages
+
+## Shared symptom: owner boundary wrong or stale
+
+Start here when the contract surface looks present but consumption still feels wrong across both branches.
+
+Primary anchor:
+
+- `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+
+What to inspect:
+
+- does the thin semantic model still delegate to the stable resource owner?
+- did the module accidentally grow a competing second owner for the same contract slice?
+- do custom methods such as `summary()` or `deleteForce()` still point at the intended owner-backed consumer path?
+
+If this layer is wrong, do not continue into list or entry runtime yet.
+
+## List branch symptoms
+
+Only enter this branch when the issue is clearly list-page oriented.
+
+Primary anchors:
+
+- `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/resource/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+
+Typical failures to classify:
+
+### A. List page renders blank or wrong blocks
+
+Check:
+
+- whether the route shell resolves the expected `resource`
+- whether `schemaRow?.rest?.blocks` is actually present
+- whether the page is stopping before deeper runtime blocks can render
+
+### B. `schemaRow`, `schemaFilter`, or query state mismatch
+
+Check:
+
+- whether the owner still exposes the expected schema surfaces
+- whether `select(query)` is still the active data path
+- whether `basic-page:blockPage` is still the deeper list runtime owner
+
+### C. List route shell looks right but visible behavior is still stale
+
+At this point, you may need to hand off to:
+
+- [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+
+## Entry branch symptoms
+
+Only enter this branch when the issue is clearly entry-page oriented.
+
+Primary anchors:
+
+- `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/entry/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockPageEntry/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockForm/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockToolbarRow/controller.tsx`
+
+Typical failures to classify:
+
+### A. Entry page shows missing data or missing form schema
+
+Check:
+
+- whether `resource`, `id`, and `formScene` resolve correctly
+- whether owner-level `formMeta`, `formSchema`, and `formData` still load where expected
+- whether the shell is failing before deeper page-entry blocks can render
+
+### B. Wrong `formScene` or wrong toolbar visibility
+
+Check:
+
+- whether the route shell derived the intended `formScene`
+- whether `blockToolbarRow` still consumes the expected host context
+- whether this is really a narrower action-visibility/form-scene issue rather than a full contract-consumption issue
+
+### C. Submit or page-meta behavior looks out of sync
+
+Check:
+
+- whether `blockForm` still feeds submit/change callbacks back into the shared page-entry owner
+- whether the deeper entry runtime still owns page-meta updates rather than scattered local code
+
+If this layer is still unclear, hand off to:
+
+- [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive)
+- [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+
+## Classify the failure last
+
+Only after the branch-local checks should you classify the problem as:
+
+- bridge/generation issue
+- deeper owner/runtime issue
+- list-branch issue
+- entry-branch issue
+
+A practical rule is:
+
+> do not start from the deepest runtime layer until the shared contract surface and the stable owner boundary already look correct.
+
+## What this page does not re-explain
+
+This page deliberately does **not** re-teach:
+
+- frontend OpenAPI generation/setup -> see [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- the broader server-data abstraction ladder -> see [Server Data](/frontend/server-data)
+- lower `a-openapi` runtime internals -> see [OpenAPI Runtime Under the Hood](/frontend/a-openapi-under-the-hood)
+- `ModelResource` internals -> see [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+- deeper list runtime -> see [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- deeper entry runtime -> see [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive)
+
+Its job is only to help you isolate the first failing frontend consumer layer.
+
+## Where to read next
+
+- If you need the family overview first, return to [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen).
+- If you need the list or entry branch specimen first, continue with [Generated Contract Consumption: List Branch](/frontend/generated-contract-consumption-list-branch) or [Generated Contract Consumption: Entry Branch](/frontend/generated-contract-consumption-entry-branch).
+- If you want the proof-oriented layer-by-layer workflow first, continue with [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook).
+- If the generated surface itself is missing or stale, hand off to [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk) and [OpenAPI SDK Guide](/frontend/openapi-sdk-guide).
+- If the issue is clearly below the current boundary, descend into [OpenAPI Runtime Under the Hood](/frontend/a-openapi-under-the-hood), [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive), [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive), or [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive).
+
+## Final takeaway
+
+The cleanest way to debug generated-contract consumption is not to jump immediately into the deepest runtime files.
+
+First isolate:
+
+- whether the generated contract surface itself is present
+- whether the stable owner boundary is still correct
+- whether the failure belongs to the list or entry branch
+
+Only then descend into deeper internals if you still need them.

package/cabloy-docs/frontend/generated-contract-consumption-entry-branch.md

@@ -0,0 +1,205 @@
+# Generated Contract Consumption: Entry Branch
+
+This page is a focused specimen for one narrow frontend question:
+
+> after generated contract material has already crossed into Zova, how is that contract consumed on the entry-page branch?
+
+Use this page together with:
+
+- [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)
+- [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive)
+- [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+- [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+
+## Why this page exists
+
+The current docs already explain:
+
+- how backend-authored contract truth reaches frontend generation
+- how generated contract material is consumed in a broad sense
+- how the deeper entry runtime works internally
+
+What was still missing was one narrow page that isolates the **entry-page consumption branch** before the deeper form/page-entry runtime takes over.
+
+This page fills that gap.
+
+## The shortest accurate mental model
+
+A practical entry-branch chain looks like this:
+
+1. generated contract material already exists in frontend API/schema surfaces
+2. the current resource model keeps `ModelResource` as the stable owner
+3. the entry route shell consumes that owner through resource, `id`, and `formScene`
+4. `basic-pageentry:blockPageEntry` becomes the deeper entry runtime owner
+5. `blockForm` and `blockToolbarRow` consume that owner-owned context
+6. deeper form and page-meta runtime docs take over from there
+
+That means the entry branch is not only “render a form from schema.”
+
+It is the path from generated contract access into resource-owner and entry-page shell consumption.
+
+## Source-confirmed reading path
+
+This page is the second layer of a small source-reading chain around same-resource model facades:
+
+1. [Model Architecture](/frontend/model-architecture) for the broader role of Zova Model
+2. this page for the consumer-side handoff into the owner
+3. [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive) for the owner internals that make that handoff work
+
+Use this order:
+
+1. `zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts`
+2. `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+3. `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/entry/controller.tsx`
+4. `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockPageEntry/controller.tsx`
+5. `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockForm/controller.tsx`
+6. `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockToolbarRow/controller.tsx`
+
+That order starts from the generated schema access surface, moves into the thin module model facade, then into the resource entry shell and the deeper Basic entry runtime owner plus its concrete consumers.
+
+## Generated contract surface on the entry branch
+
+A practical current source anchor is:
+
+- `zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts`
+
+Representative source facts:
+
+- the module exposes a schema bean through `@ApiSchema()`
+- entry-related schema access is available through methods such as `create()`, `view()`, and `update()`
+- those methods call `this.$sdk.createApiSchemas(...)`
+
+This is the first consumer-facing contract surface on the entry branch.
+
+The entry-page branch does not start with local form-only logic.
+It starts with generated schema access that has already been turned into frontend-usable contract material.
+
+## Thin model facade and owner-level form helpers
+
+A practical current model specimen is:
+
+- `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+
+Representative source facts:
+
+- the module model keeps `rest-resource.model.resource` as the stable owner
+- `summary(id)` still goes through `queryItem(...)` rather than bypassing the owner
+- `deleteForce(id)` still goes through `mutationItem(...)` rather than introducing a separate mutation surface
+- custom endpoints still delegate to owner-level helpers rather than replacing the resource-owner story
+
+This is the thin-facade boundary:
+
+- the model does not become a second resource owner
+- same-resource custom actions are exposed as small named model methods
+- entry and form consumers can continue to depend on owner-level surfaces without splitting the resource story
+
+A practical rule is:
+
+> when entry-page behavior still belongs to the same resource, keep the resource owner stable and let form helpers stay owner-driven.
+
+This matters because entry pages usually depend on owner-level surfaces such as:
+
+- `formMeta`
+- `formSchema`
+- `formProvider`
+- `formData`
+- submit helpers
+
+If you want the broader model-layer explanation behind this narrow facade pattern, continue with [Model Architecture](/frontend/model-architecture).
+If you want the deeper owner internals behind `queryItem(...)`, `mutationItem(...)`, and form-derived helpers, continue with [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive).
+
+## Entry shell consumption
+
+The clearest current entry shell is:
+
+- `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/entry/controller.tsx`
+
+Representative source facts:
+
+- the page resolves `$$modelResource` from the route resource
+- it derives `formMeta` from `formScene`
+- it autoloads `this.$$modelResource.getFormApiSchemas(this.formMeta)?.sdk`
+- it derives `formSchema` from `this.$$modelResource.getFormSchema(this.formMeta)`
+
+This is the entry-shell boundary:
+
+- generated contract material has already crossed into the owner
+- the shell uses the owner to derive scene-aware form schema state
+- schema-defined blocks then take over the deeper runtime
+
+## Handoff into `basic-pageentry:blockPageEntry`
+
+The next concrete consumer is:
+
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockPageEntry/controller.tsx`
+
+Representative source facts:
+
+- it resolves the selector-backed owner
+- it computes `formMeta`, `formProvider`, `formSchema`, and `formData`
+- it uses owner-level helpers such as `getFormData(...)` and `getFormMutationSubmit(...)`
+- it pushes `pageTitle`, `pageDirty`, and `formMeta` into page meta
+
+This means the deeper entry runtime still depends on the same generated-contract and resource-owner surfaces.
+
+## `blockForm` and `blockToolbarRow` as concrete consumers
+
+Two especially clear consumer files are:
+
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockForm/controller.tsx`
+- `zova/src/suite/cabloy-basic/modules/basic-pageentry/src/component/blockToolbarRow/controller.tsx`
+
+Representative source facts from `blockForm`:
+
+- it passes owner-derived `formData`, `formSchema`, `schemaScene`, `formMeta`, and `formProvider` into `ZForm`
+- `onChanged` feeds updated data back into page meta through `$$pageEntry.setPageMeta(...)`
+
+Representative source facts from `blockToolbarRow`:
+
+- it consumes the same `$$pageEntry` context
+- it filters actions by current `formScene`
+- it combines `formScene` and permission checks before rendering the toolbar actions
+
+A practical reading takeaway is:
+
+- generated contract material becomes owner-level form surfaces first
+- the entry runtime then turns those surfaces into actual form and toolbar behavior
+
+## What this page does not re-explain
+
+This page does **not** fully re-explain:
+
+- how to configure or generate OpenAPI SDK output -> see [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- the broader generated-contract hub -> see [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)
+- the lower runtime of `$sdk` -> see [OpenAPI Runtime Under the Hood](/frontend/a-openapi-under-the-hood)
+- `ModelResource` internals -> see [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+- the deeper entry runtime and form/page-meta chain -> see [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive) and [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide)
+- the broader `rest-resource` runtime bridge -> see [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)
+
+Its job is only to show the entry-side contract-consumption handoff before deeper runtime internals take over.
+
+## Where to read next
+
+- If you want the shared consumer-side overview first, return to [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen).
+- If you want a proof-oriented layer-by-layer validation workflow, continue with [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook).
+- If the result is already wrong and you want symptom-first diagnosis, continue with [Generated Contract Consumption Debug Checklist](/frontend/generated-contract-consumption-debug-checklist).
+- If you want the deeper entry runtime internals, continue with [Resource Entry Page Deep Dive](/frontend/resource-entry-page-deep-dive).
+- If you want the broader resource/runtime shell map, continue with [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood).
+- If you want the form-scene to page-meta runtime chain, continue with [Form Scene to Page Meta Guide](/frontend/form-scene-to-page-meta-guide).
+- If you want resource-owner internals, continue with [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive).
+
+## Final takeaway
+
+The cleanest way to read generated contract consumption on the entry branch is:
+
+- generated schema/API surface
+- stable resource owner
+- entry route shell
+- deeper `basic-pageentry` runtime owner
+- form and toolbar consumers
+- deeper runtime internals only if you still need them
+
+That keeps the entry-branch consumption path visible before you descend into the heavier form/runtime details.

package/cabloy-docs/frontend/generated-contract-consumption-list-branch.md

@@ -0,0 +1,157 @@
+# Generated Contract Consumption: List Branch
+
+This page is a focused specimen for one narrow frontend question:
+
+> after generated contract material has already crossed into Zova, how is that contract consumed on the list-page branch?
+
+Use this page together with:
+
+- [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)
+- [Backend OpenAPI to Frontend SDK](/fullstack/openapi-to-sdk)
+- [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)
+- [Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map)
+- [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+
+## Why this page exists
+
+The current docs already explain:
+
+- how backend-authored contract truth reaches frontend generation
+- how generated contract material is consumed in a broad sense
+- how the deeper list runtime works internally
+
+What was still missing was one narrow page that isolates the **list-page consumption branch** before the deeper list runtime takes over.
+
+This page fills that gap.
+
+## The shortest accurate mental model
+
+A practical list-branch chain looks like this:
+
+1. generated contract material already exists in frontend API/schema surfaces
+2. the current resource model keeps `ModelResource` as the stable owner
+3. the list route shell consumes that owner through resource context
+4. `basic-page:blockPage` becomes the deeper list runtime owner
+5. deeper table, filter, and pager runtime docs take over from there
+
+That means the list branch is not only “call one API.”
+
+It is the path from generated contract access into resource-owner and list-page shell consumption.
+
+## Source-confirmed reading path
+
+Use this order:
+
+1. `zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts`
+2. `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+3. `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/resource/controller.tsx`
+4. `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+
+That order starts from the generated schema access surface, moves into the thin module model facade, then into the resource list shell and the deeper Basic list runtime owner.
+
+## Generated contract surface on the list branch
+
+A practical current source anchor is:
+
+- `zova/src/suite/a-training/modules/training-student/src/apiSchema/trainingStudent.ts`
+
+Representative source facts:
+
+- the module exposes a schema bean through `@ApiSchema()`
+- list-related schema access is available through methods such as `select()`
+- those methods call `this.$sdk.createApiSchemas(...)`
+
+This is the first consumer-facing contract surface on the list branch.
+
+The list-page branch does not start with local page-only table logic.
+It starts with generated schema access that has already been turned into frontend-usable contract material.
+
+## Thin model facade and stable owner rule
+
+A practical current model specimen is:
+
+- `zova/src/suite/a-training/modules/training-student/src/model/student.ts`
+
+Representative source facts:
+
+- the module model resolves `rest-resource.model.resource` through selector-backed access
+- custom methods such as `summary(id)` and `deleteForce(id)` still delegate to resource-owner helper surfaces
+
+A practical rule is:
+
+> when the API still belongs to the same resource, keep `ModelResource` as the stable owner and keep the module model thin.
+
+That is the rule that prevents list-page consumption from scattering contract ownership into ad hoc page code.
+
+## List shell consumption
+
+The clearest current list shell is:
+
+- `zova/src/suite-vendor/a-cabloy/modules/rest-resource/src/page/resource/controller.tsx`
+
+Representative source facts:
+
+- the page resolves `$$modelResource` from the route resource
+- `__init__()` autoloads `this.$$modelResource.apiSchemasSelect.sdk`
+- render reads `schemaRow?.rest?.blocks`
+
+This is the list-shell boundary:
+
+- generated contract material has already crossed into the owner
+- the shell uses the owner to load top-level list schema state
+- schema-defined blocks then take over the deeper runtime
+
+## Deeper handoff into `basic-page:blockPage`
+
+The next concrete consumer is:
+
+- `zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx`
+
+Representative source facts:
+
+- it resolves the selector-backed resource owner
+- it loads `this.$$modelResource.apiSchemasSelect.sdk`
+- it derives list data through `this.$$modelResource.select(this.query)`
+- it exposes `schemaFilter`, `schemaRow`, and `permissions`
+
+That means the deeper list runtime still depends on the same generated-contract and resource-owner surfaces.
+
+A practical reading takeaway is:
+
+- generated contract material becomes owner surfaces first
+- `blockPage` then becomes the shared list runtime owner for filters, paging, query state, and list data
+
+## What this page does not re-explain
+
+This page does **not** fully re-explain:
+
+- how to configure or generate OpenAPI SDK output -> see [OpenAPI SDK Guide](/frontend/openapi-sdk-guide)
+- the broader generated-contract hub -> see [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen)
+- the lower runtime of `$sdk` -> see [OpenAPI Runtime Under the Hood](/frontend/a-openapi-under-the-hood)
+- `ModelResource` internals -> see [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive)
+- the deeper list runtime and page-block chain -> see [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive)
+- the broader `rest-resource` runtime bridge -> see [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood)
+
+Its job is only to show the list-side contract-consumption handoff before deeper runtime internals take over.
+
+## Where to read next
+
+- If you want the shared consumer-side overview first, return to [Generated Contract Consumption Specimen](/frontend/generated-contract-consumption-specimen).
+- If you want a proof-oriented layer-by-layer validation workflow, continue with [Generated Contract Consumption Verify Playbook](/frontend/generated-contract-consumption-verify-playbook).
+- If the result is already wrong and you want symptom-first diagnosis, continue with [Generated Contract Consumption Debug Checklist](/frontend/generated-contract-consumption-debug-checklist).
+- If you want the deeper list runtime internals, continue with [Resource List Page Deep Dive](/frontend/resource-list-page-deep-dive).
+- If you want the broader resource/runtime shell map, continue with [Rest Resource Under the Hood](/frontend/rest-resource-under-the-hood) and [Rest Resource Source Reading Map](/frontend/rest-resource-source-reading-map).
+- If you want resource-owner internals, continue with [ModelResource Internals Deep Dive](/frontend/model-resource-internals-deep-dive).
+
+## Final takeaway
+
+The cleanest way to read generated contract consumption on the list branch is:
+
+- generated schema/API surface
+- stable resource owner
+- list route shell
+- deeper `basic-page` runtime owner
+
+That keeps the list-branch consumption path visible before you descend into the heavier runtime details.