@hinen/pro-element-plus 1.7.17 → 1.8.1

package/dist/skills/building-form-workflows/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: building-form-workflows
+description: Use when you need to route a schema-driven or business-form workflow into the right Form* wrappers, FormItem semantics, and field-specific using-* skills.
+---
+
+# Building form workflows
+
+## Overview
+
+Use this skill as the **form-workflow router** for the package.
+
+Its job is to move from business-form requirements — labels, rules, wrapper semantics, and field value shapes — into the correct `using-form-*` skills, while keeping `FormItem` and `FormFields` as the shared mental model.
+
+## Use it when
+
+Use this skill when several of these are true:
+
+- you are composing a business form from the `FormFields` family
+- you need consistent label, validation, and wrapper behavior across many inputs
+- you need to pick the right wrapped field for each piece of data
+- you need a routing layer before opening several field-specific `using-form-*` skills
+
+Strong signals this skill applies:
+
+- admin edit forms
+- settings forms
+- schema-driven business forms
+- mixed forms using text, number, select, and specialized field wrappers together
+
+## Prefer something else when
+
+- you are building a search page rather than a general business form  
+  → use `../building-query-pages/SKILL.md`
+- you already know the exact wrapped field or direct component you need  
+  → open the matching `using-form-*` or `using-*` skill directly
+- you only need to pick among top-level workflow families  
+  → use `../choosing-components/SKILL.md`
+
+## Decision guide
+
+Use `building-form-workflows` if the answer is yes for **two or more** of these:
+
+- Are you still choosing among several `Form*` wrapper types?
+- Do label, validation, and wrapper semantics need to stay consistent across many fields?
+- Do you need a field-type routing layer before opening concrete component skills?
+- Is the workflow primarily about create, edit, or settings forms rather than query plus results pages?
+
+If not, go straight to the narrowest known component or use the query-page router instead.
+
+## Recommended path
+
+1. Start with the data shape and validation rules.
+2. Use `../using-form-item/SKILL.md` to lock in wrapper semantics.
+3. Use `../using-form-fields/SKILL.md` to see the full wrapper family.
+4. Choose the narrowest `using-form-*` skill that matches each field’s value semantics.
+5. If the same field patterns must also power a search page, hand off to `../building-query-pages/SKILL.md` and `../using-query-form/SKILL.md`.
+
+## Common mistakes
+
+- choosing wrapped fields by visual similarity instead of stored value semantics
+- skipping `FormItem` and `FormFields` and jumping straight into one concrete wrapper without confirming the family pattern
+- stretching one wrapper to cover unrelated input behavior
+- treating business forms and query pages as the same workflow when the page shape is actually different
+
+## Related skills
+
+- Top-level router: `../choosing-components/SKILL.md`
+- Query-page router: `../building-query-pages/SKILL.md`
+- Wrapper-family overview: `../using-form-fields/SKILL.md`
+- Base wrapper semantics: `../using-form-item/SKILL.md`
+
+## References
+
+- Workflow: `./references/workflow.md`
+- Field selection: `./references/field-selection.md`
+- Examples: `./references/examples.md`
+- Gotchas: `./references/gotchas.md`

package/dist/skills/building-form-workflows/references/examples.md

@@ -0,0 +1,47 @@
+# Form-workflow examples
+
+## 1. Business edit form
+
+Start with `../../using-form-item/SKILL.md` and `../../using-form-fields/SKILL.md`, then move into the concrete `using-form-*` skills for each field.
+
+Minimal pattern:
+
+```vue
+<FormText label="Name" prop="name" />
+<FormNumber label="Order" prop="order" />
+<FormSelect label="Status" prop="status" :options="statusOptions" />
+```
+
+Why this fits:
+
+- the workflow is create/edit rather than filter-plus-results
+- wrapper semantics should stay consistent across many fields
+- the narrow `using-form-*` skills decide each field after the workflow is clear
+
+## 2. Mixed field settings form
+
+Use this router when the form mixes text, number, select, boolean, and specialized wrappers but should still share one wrapper model.
+
+Minimal pattern:
+
+```vue
+<FormText label="Title" prop="title" />
+<FormNumber label="Retry Count" prop="retryCount" />
+<FormSelect label="Mode" prop="mode" :value-enum="modeEnum" />
+```
+
+Why this fits:
+
+- the form mixes value shapes
+- wrapper consistency matters more than raw component freedom
+- the family router stays useful before the field set fully stabilizes
+
+## 3. Same field semantics later reused in search
+
+Use this workflow first for field semantics, then hand off to `../building-query-pages/SKILL.md` when the same concepts need a query-page shell.
+
+Typical route:
+
+- define the business-form field meaning first
+- pick the matching `using-form-*` skills
+- later map the same field concepts into `QueryForm` or `DataTable` only when the page shape becomes filter-plus-results

package/dist/skills/building-form-workflows/references/field-selection.md

@@ -0,0 +1,16 @@
+# Field selection
+
+Use this grid as the **canonical business-form field map** when the workflow is create, edit, or settings oriented rather than filter plus results.
+
+Choose fields by stored value semantics first, then refine the UX inside the destination skill.
+
+- Free text, passwords, or textarea-like values → `../../using-form-text/SKILL.md`
+- Numbers with min, max, step, or precision → `../../using-form-number/SKILL.md`
+- Local or enum-backed choice sets in a wrapped field → `../../using-form-select/SKILL.md`
+- Visible checkbox or radio lists inside the wrapper family → `../../using-form-checkbox-group/SKILL.md`, `../../using-form-radio-group/SKILL.md`
+- True binary toggles → `../../using-form-switch/SKILL.md`
+- Hierarchical values → `../../using-form-cascade-select/SKILL.md`, `../../using-form-tree-select/SKILL.md`
+- Date-like or time-like values → `../../using-form-date-picker/SKILL.md`, `../../using-form-time-picker/SKILL.md`
+- Tag collection, rating, or suggestion-driven text → `../../using-form-tag-input/SKILL.md`, `../../using-form-rate/SKILL.md`, `../../using-form-autocomplete/SKILL.md`
+
+If the same field semantics must also power a search surface, keep this grid as the base mapping and then layer query-specific rules from `../../building-query-pages/references/field-selection.md` on top.

package/dist/skills/building-form-workflows/references/gotchas.md

@@ -0,0 +1,10 @@
+# Form-workflow gotchas
+
+- This skill routes field semantics, not page shells  
+  If the page also owns search results and pagination, use `../building-query-pages/SKILL.md`.
+
+- `FormItem` and `FormFields` are foundation skills, not optional detours  
+  They define the wrapper model the concrete `using-form-*` skills build on.
+
+- Do not force one wrapper to cover unrelated value types  
+  Pick the narrowest matching `using-form-*` skill for each field.

package/dist/skills/building-form-workflows/references/workflow.md

@@ -0,0 +1,21 @@
+# Form-workflow checklist
+
+Use this checklist when the workflow is primarily **create, edit, or settings oriented**.
+
+If the page is mainly about filters plus results, pagination, or query-state coordination, switch to `../../building-query-pages/SKILL.md` instead of stretching this workflow.
+
+1. Lock in the wrapper contract first with `../../using-form-item/SKILL.md`.
+   - Confirm labels, `prop`, rules, required state, and wrapper-level tooltip/error behavior before choosing field components.
+2. Use `../../using-form-fields/SKILL.md` to decide whether you are still picking from the wrapper family or already know the exact wrapped field.
+3. Map each business field to the correct wrapped skill with `./field-selection.md`.
+   - Choose by stored value semantics, not by visual similarity.
+   - Only open the narrowest `using-form-*` skill after the field family is clear.
+4. Keep one clear source of truth for defaults, labels, validation rules, and option data.
+   - Do not let similar fields drift into different wrapper choices without a data-shape reason.
+5. Reuse the same field semantics in `../../using-query-form/SKILL.md` only when the same business concepts also appear in a search surface.
+   - Reuse the field intent.
+   - Do not treat query forms and business forms as the same page workflow.
+6. Hand off to `../../building-query-pages/SKILL.md` when the page also owns result rendering, pagination, refresh, or shared table-state decisions.
+7. Recheck edge cases before finalizing.
+   - Use `./gotchas.md` for common routing mistakes.
+   - Use `./examples.md` when you need scenario-shaped guidance rather than another field list.

package/dist/skills/building-modal-workflows/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: building-modal-workflows
+description: Use when you need to route an overlay workflow into Modal or Drawer while keeping footer behavior, close handling, and embedded content choices consistent.
+---
+
+# Building modal workflows
+
+## Overview
+
+Use this skill as the **overlay-workflow router** for the package.
+
+Its job is to decide whether an interaction should be a centered modal or an edge-attached drawer, then hand off to the right overlay skill while keeping footer semantics and close behavior aligned.
+
+## Use it when
+
+Use this skill when several of these are true:
+
+- you need an overlay that owns confirm and cancel actions
+- you are choosing between a centered dialog and a side-panel flow
+- you want to keep async submit and default footer behavior consistent
+- the shell choice is still open even though you know the interaction belongs in an overlay
+
+Strong signals this skill applies:
+
+- confirm dialogs
+- compact record editors
+- side-panel editors
+- review and approve overlays
+
+## Prefer something else when
+
+- you already know the exact overlay shell  
+  → open `../using-modal/SKILL.md` or `../using-drawer/SKILL.md` directly
+- the main decision is the content inside the overlay rather than the overlay shell itself  
+  → use `../building-form-workflows/SKILL.md` or `../building-query-pages/SKILL.md` for the inner flow
+- you are still choosing among top-level workflow families  
+  → use `../choosing-components/SKILL.md`
+
+## Decision guide
+
+Use `building-modal-workflows` if the answer is yes for **two or more** of these:
+
+- Is the interaction definitely an overlay but the shell is still undecided?
+- Do centered modal versus side drawer tradeoffs matter to the UX?
+- Should confirm and cancel behavior stay aligned with the package defaults?
+- Will choosing the right shell reduce custom overlay scaffolding?
+
+If not, go straight to the narrowest known overlay skill or back up to the top-level router.
+
+## Recommended path
+
+1. Choose the shell:
+   - compact, centered overlay → `../using-modal/SKILL.md`
+   - roomier, side-panel flow → `../using-drawer/SKILL.md`
+2. Decide whether the built-in footer is enough.
+3. Wire business-side close handling explicitly even when confirm and cancel buttons are generated for you.
+4. If the overlay hosts a form, hand off to `../building-form-workflows/SKILL.md` for field and wrapper decisions.
+5. If the overlay hosts a list or query flow, hand off to `../building-query-pages/SKILL.md` for the inner page logic.
+
+## Common mistakes
+
+- choosing `Modal` or `Drawer` by habit instead of by content shape and context needs
+- replacing the built-in footer before confirming whether the default action model already fits
+- assuming confirm or cancel events automatically close the overlay
+- deciding the shell without considering whether the inner content is a form flow or a query flow
+
+## Related skills
+
+- Top-level router: `../choosing-components/SKILL.md`
+- Centered overlay shell: `../using-modal/SKILL.md`
+- Side-panel overlay shell: `../using-drawer/SKILL.md`
+- Form content router: `../building-form-workflows/SKILL.md`
+- Query content router: `../building-query-pages/SKILL.md`
+
+## References
+
+- Workflow: `./references/workflow.md`
+- Examples: `./references/examples.md`
+- Gotchas: `./references/gotchas.md`

package/dist/skills/building-modal-workflows/references/examples.md

@@ -0,0 +1,104 @@
+# Overlay examples
+
+## 1. Short confirmation
+
+Prefer `../../using-modal/SKILL.md` when the body is brief and the main job is confirming or editing one small entity.
+
+Minimal pattern:
+
+```vue
+<Modal
+  :model-value="visible"
+  title="Delete User"
+  @cancel="visible = false"
+  @ok="handleDelete"
+>
+  <p>Confirm deletion?</p>
+</Modal>
+```
+
+Typical fit:
+
+- destructive confirmation with a few explanatory lines
+- one-step approval dialog
+- tiny editor where the main action is still confirm or cancel
+
+## 2. Side-panel editor
+
+Prefer `../../using-drawer/SKILL.md` when the content is longer, stacked vertically, or feels better as a right-side task flow.
+
+Minimal pattern:
+
+```vue
+<Drawer
+  :model-value="visible"
+  title="Edit Project"
+  @cancel="visible = false"
+  @ok="handleSave"
+>
+  <ProjectForm />
+</Drawer>
+```
+
+Typical fit:
+
+- multi-section editor
+- detail review with supporting context
+- workflow that should stay visually attached to the page
+
+## 3. Overlay with form content
+
+Choose the shell here first, then hand off to `../building-form-workflows/SKILL.md` for the field and wrapper plan inside the overlay.
+
+Typical route:
+
+- compact editor → `Modal` + business-form workflow
+- roomier editor → `Drawer` + business-form workflow
+
+Typical fit:
+
+- quick record edit in a modal
+- richer create or edit flow in a drawer
+
+The overlay router chooses the shell; the form router chooses the inner field and wrapper plan.
+
+## 4. Overlay with query or list content
+
+Use `../building-query-pages/SKILL.md` when the overlay body is not a simple editor, but a filter-plus-results or review list surface.
+
+Typical route:
+
+- choose `Modal` or `Drawer` for the shell
+- then use `QueryForm` or `DataTable` as the inner page/list shell
+
+Typical fit:
+
+- select-from-list drawer
+- review history modal with filters
+- side panel that combines search criteria and result rows
+
+In these cases, the overlay skill chooses the shell first and the query-page router owns the inner list logic.
+
+## 5. Close-handling pattern
+
+Built-in footer actions do not close the overlay by themselves.
+
+Minimal pattern:
+
+```vue
+<Modal
+  :model-value="visible"
+  @update:model-value="visible = $event"
+  @cancel="visible = false"
+  @ok="handleSubmit"
+/>
+```
+
+Minimum handoff pattern:
+
+- visibility stays in feature state
+- `update:modelValue` mirrors shell visibility changes
+- `cancel` usually closes immediately
+- `ok` runs business logic and only closes when that logic decides to
+
+For concrete shell-level examples, use the minimal patterns in `../../using-modal/SKILL.md` or `../../using-drawer/SKILL.md`.

package/dist/skills/building-modal-workflows/references/gotchas.md

@@ -0,0 +1,19 @@
+# Overlay-workflow gotchas
+
+- This skill chooses shells, not inner fields  
+  Once the shell is clear, move into the form or query router for the overlay content itself.
+
+- Modal versus Drawer is a UX decision, not just a size choice  
+  Centered interruption and edge-attached task flow communicate different product intent.
+
+- Built-in footer actions still need business-side close logic  
+  Do not assume generated confirm and cancel buttons manage visibility by themselves.
+
+- Do not choose `Modal` or `Drawer` by habit  
+  Pick the shell by content shape and surrounding context, not by whichever overlay component feels more familiar.
+
+- Visibility control and action handling are separate concerns  
+  `modelValue` decides whether the shell is open. `ok` and `cancel` are workflow events. Treating them as the same thing leads to fragile close behavior.
+
+- Do not pick the shell without checking the body workflow  
+  A form-heavy editor and a filter-plus-results surface can both live in overlays, but they should hand off to different inner routers after the shell choice is made.

package/dist/skills/building-modal-workflows/references/workflow.md

@@ -0,0 +1,17 @@
+# Overlay workflow
+
+1. Choose the shell.
+   - `../../using-modal/SKILL.md` for centered overlays with built-in size presets.
+   - `../../using-drawer/SKILL.md` for side panels with the same confirm and cancel pattern.
+2. Decide what kind of content the overlay is hosting.
+   - focused form or editor flow → `../building-form-workflows/SKILL.md`
+   - query, list, or review surface with results → `../building-query-pages/SKILL.md`
+3. Decide whether the built-in footer is enough.
+   - keep it when confirm and cancel are still the real action model
+   - replace it only when the body owns a genuinely different action layout
+4. Wire business-side close handling explicitly even when confirm and cancel buttons are generated for you.
+   - closing still belongs in your feature logic
+   - use the downstream `using-modal` or `using-drawer` examples for the concrete `update:modelValue`, `cancel`, and `ok` pattern
+5. Recheck whether the shell still matches the content shape.
+   - compact interruption → stay with `Modal`
+   - roomier task flow or richer side context → stay with `Drawer`

package/dist/skills/building-query-pages/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: building-query-pages
+description: Use when you need to route a filter or admin-style list workflow into QueryForm, DataTable, ConfigProvider, and the correct field-level using-* skills.
+---
+
+# Building query pages
+
+## Overview
+
+Use this skill as the **query-page router** for the package.
+
+Its job is to decide whether a page stops at collecting filters or should own the full search-plus-results shell, then hand off to the correct `using-*` skills for fields, table shell, and shared table-state presentation.
+
+## Use it when
+
+Use this skill when several of these are true:
+
+- you are building a search form plus result list page
+- the page needs pagination, refresh, or query-state coordination
+- you need to decide whether `QueryForm` alone is enough or the page should promote to `DataTable`
+- you need a routing layer before choosing field-level `using-form-*` or `using-data-select` skills
+
+Strong signals this skill applies:
+
+- admin search pages
+- list pages with filters and result grids
+- report pages with standard filter shells
+- multiple related tables sharing empty or error treatment
+
+## Prefer something else when
+
+- you are building a general business form rather than a filter plus results flow  
+  → use `../building-form-workflows/SKILL.md`
+- you already know the exact page shell you need  
+  → open `../using-query-form/SKILL.md`, `../using-data-table/SKILL.md`, or `../using-config-provider/SKILL.md` directly
+- you are still choosing among top-level workflow families  
+  → use `../choosing-components/SKILL.md`
+
+## Decision guide
+
+Use `building-query-pages` if the answer is yes for **two or more** of these:
+
+- Does the page involve filters or search criteria?
+- Does the same surface also need result rows, pagination, or refresh?
+- Do query-field choices need to route into the standardized field skills?
+- Should shared empty or error treatment across tables be part of the page decision?
+
+If not, go straight to `using-query-form`, `using-data-table`, or the form-workflow router.
+
+## Recommended path
+
+1. Define the fields users actually need to search on.
+2. Choose the page shell:
+   - filters only → `../using-query-form/SKILL.md`
+   - filters plus results, pagination, refresh → `../using-data-table/SKILL.md`
+3. Map each query field to the correct field skill using the query-page field grid.
+4. Keep one clear source of truth for labels, defaults, placeholders, and option data.
+5. Add `../using-config-provider/SKILL.md` only when multiple tables should share empty or error UI.
+6. If the underlying field semantics are still unclear, hand off to `../building-form-workflows/SKILL.md` for wrapper-family routing.
+
+## Common mistakes
+
+- treating query pages like ordinary business forms when the page shell really needs query-plus-results behavior
+- picking `QueryForm` and `DataTable` before deciding whether the page actually owns results
+- duplicating field semantics between page-level filters and broader form-wrapper rules instead of sharing them
+- introducing `ConfigProvider` for one local table when the customization should stay local
+
+## Related skills
+
+- Top-level router: `../choosing-components/SKILL.md`
+- Form-workflow router for shared field semantics: `../building-form-workflows/SKILL.md`
+- Standalone filter shell: `../using-query-form/SKILL.md`
+- Query-plus-results shell: `../using-data-table/SKILL.md`
+- Shared table empty and error rendering: `../using-config-provider/SKILL.md`
+
+## References
+
+- Workflow: `./references/workflow.md`
+- Field selection: `./references/field-selection.md`
+- Examples: `./references/examples.md`
+- Gotchas: `./references/gotchas.md`

package/dist/skills/building-query-pages/references/examples.md

@@ -0,0 +1,64 @@
+# Query-page examples
+
+## 1. Small filter panel
+
+Use `../../using-query-form/SKILL.md` when the page just collects filters for another component or request flow.
+
+Minimal pattern:
+
+```vue
+<QueryForm :items="items" @search="handleSearch" @reset="handleReset" />
+```
+
+Why this fits:
+
+- the page owns filters but not a standard result table shell
+- search state still benefits from schema-driven query controls
+
+## 2. Standard search table page
+
+Use `../../using-data-table/SKILL.md` when the page owns filtering, loading, pagination, and result rendering together.
+
+Minimal pattern:
+
+```vue
+<DataTable :columns="columns" :query-fn="queryFn" />
+```
+
+Why this fits:
+
+- one shell owns query, fetch, pagination, and rendering
+- columns define both field and row behavior
+
+## 3. Shared table shell
+
+Wrap the feature with `../../using-config-provider/SKILL.md` when several tables should share the same empty and error presentation.
+
+Minimal pattern:
+
+```vue
+<ConfigProvider>
+  <DataTable :columns="userColumns" :query-fn="userQuery" />
+  <DataTable :columns="roleColumns" :query-fn="roleQuery" />
+</ConfigProvider>
+```
+
+Use this when the shared fallback rendering belongs to the feature subtree rather than one list.
+
+## 4. Shared field semantics with business forms
+
+If the query filters reuse the same field semantics as broader business forms, route through `../building-form-workflows/SKILL.md` before finalizing the field choices.
+
+Typical route:
+
+- define the field meaning in the business-form workflow first
+- reuse that field meaning in `QueryForm` or `DataTable` only after the page is confirmed to be filter-plus-results
+
+## 5. Query page inside an overlay
+
+If the body is still a filter-plus-results workflow but should live in a temporary shell, route through `../building-modal-workflows/SKILL.md` first, then come back to `QueryForm` or `DataTable` for the inner page shell.
+
+Typical route:
+
+- choose `Modal` or `Drawer` for the outer shell
+- keep `QueryForm` or `DataTable` as the inner query-page surface

package/dist/skills/building-query-pages/references/field-selection.md

@@ -0,0 +1,24 @@
+# Field selection for query pages
+
+Use this guide as the **query-page extension** to the canonical business-form grid at `../../building-form-workflows/references/field-selection.md`.
+
+Start from the business-form field meaning first, then apply the query-specific rules below.
+
+## Start from the base field map
+
+- text-like filter input → `../../using-form-text/SKILL.md`
+- numeric filter input → `../../using-form-number/SKILL.md`
+- local wrapped select filter → `../../using-form-select/SKILL.md`
+- visible checkbox or radio filter → `../../using-form-checkbox-group/SKILL.md`, `../../using-form-radio-group/SKILL.md`
+- tree or cascade filter → `../../using-form-tree-select/SKILL.md`, `../../using-form-cascade-select/SKILL.md`
+- date or time filter → `../../using-form-date-picker/SKILL.md`, `../../using-form-time-picker/SKILL.md`
+- suggestion-driven filter text → `../../using-form-autocomplete/SKILL.md`
+
+## Apply query-specific rules
+
+- Use `../../using-data-select/SKILL.md` when option loading is request-driven, param-driven, or filter-aware enough that loading behavior is part of the component choice.
+- Stay with `../../using-form-select/SKILL.md` when the query field is still a wrapped local or enum-backed select and remote loading is not the real differentiator.
+- Prefer filter-oriented date, time, and select modes that match backend query semantics rather than full data-entry richness.
+- Do not introduce business-form-only fields such as `FormSwitch`, `FormTagInput`, or `FormRate` into this grid unless the page is no longer primarily a query surface.
+
+For broader business-form field routing outside query pages, keep using `../../building-form-workflows/references/field-selection.md` as the base map.

package/dist/skills/building-query-pages/references/gotchas.md

@@ -0,0 +1,10 @@
+# Query-page gotchas
+
+- This skill chooses page shells, not just field wrappers  
+  If the page also owns result rows and pagination, that shell decision matters more than any one field.
+
+- `QueryForm` and `DataTable` are not interchangeable  
+  Use `QueryForm` for filter surfaces only and `DataTable` when the page should own the full query-plus-results loop.
+
+- `ConfigProvider` is a shared-shell tool  
+  If only one table needs a custom empty or error state, keep that customization local instead of forcing a provider.

package/dist/skills/building-query-pages/references/workflow.md

@@ -0,0 +1,22 @@
+# Query-page workflow
+
+Use this checklist when the page is primarily a **filter plus results** workflow rather than a general business form.
+
+If the page is mainly create, edit, or settings oriented, switch to `../../building-form-workflows/SKILL.md` instead of stretching this workflow.
+
+1. Decide whether the page stops at collecting filters or also owns result rendering.
+   - filters only → `../../using-query-form/SKILL.md`
+   - filters plus rows, pagination, refresh, or table-state control → `../../using-data-table/SKILL.md`
+2. Map query fields with `./field-selection.md` before tuning the shell details.
+   - Use query-oriented field skills such as `using-data-select` only when the filter surface really needs request-driven option loading.
+   - Keep wrapper-family semantics in the background unless the field meaning is still unclear.
+3. Keep one clear source of truth for filter defaults, labels, placeholders, and option data.
+   - Avoid drifting into one set of semantics for the query schema and another for the page shell.
+4. Add `../../using-config-provider/SKILL.md` only when multiple nearby `DataTable` instances should share empty or error presentation.
+   - Keep one-off table customization local when the override belongs to a single list.
+5. Hand off to `../../building-form-workflows/SKILL.md` only when the page also contains broader business-form areas or the field semantics cannot be resolved from the query-field grid alone.
+   - Query-page workflow is about page-shell decisions.
+   - Form-workflow routing is about wrapper semantics and business-form field meaning.
+6. Recheck edge cases before finalizing.
+   - Use `./gotchas.md` for shell-level routing mistakes.
+   - Use `./examples.md` when you need scenario-shaped guidance for list pages, report pages, or admin search surfaces.