---
name: "model-component-coverage-check"
version: "1.0.0"
origin: "captured"
generation: 0
parent_skill_ids: []
status: "stable"
description: "Checks whether each data model and field from design docs, schema, DTOs, and APIs has corresponding frontend pages, components, interaction states, validation coverage, and dictionary-governed handling for state/enum fields. Use when validating model-to-UI completeness before or after development."
trigger_phases: ["review", "validation"]
applicable_agents: ["Copilot Drift Check", "Copilot Code Review"]
priority: 20
---

# Model Component Coverage Check

This skill validates that a business object is fully represented across design, frontend, backend, and test assets.

For IMEX EOMS, this also means: any design-doc-defined state machine field or fixed enum field must be represented as a dictionary-governed field, not left as raw codes, local constant arrays, or prose-only semantics.

## When To Use

- Before development starts, to detect missing page states or missing UI objects.
- After specs are produced, to verify that every data model has concrete component mapping.
- After implementation, to detect drift between design docs, API contracts, frontend views, and test cases.

## Inputs

- One or more design documents from `doc/ams-design/V3.0`
- Related schema or table definitions
- Frontend files from `pm-btplms-web/src/views`, `src/api`, `src/option`
- Backend files from `pm-btplms-server/src/main/java/org/springblade/modules/*`
- Optional Playwright/page-agent test assets
- Optional Architect `Dictionary Mapping Matrix`, `blade_dict_biz` seed SQL, and frontend dictionary loading assets

## Required Checks

### 1. Object Coverage

For each core object, verify whether the repo contains or the spec defines:

1. list page
2. add/create page
3. edit page
4. read/detail page
5. child-table or related-object presentation when required

### 2. Field Coverage

For each field in the design doc or schema, classify whether it appears in:

1. entity or DTO
2. API request/response
3. option config / form definition
4. list column or detail block
5. validation rule
6. test assertion or scenario

Additionally classify every field into one of these governance classes:

1. `business-core`
2. `business-extended`
3. `dictionary/status`
4. `FK/reference`
5. `read-only-derived`
6. `system-control`

For every `dictionary/status` field, also record:

1. `dictSource` — `existing-platform` / `existing-biz-dict` / `new-biz-dict` / `unresolved`
2. `dictCode` — concrete code when known
3. `displayMode` — translated label / select / radio / badge / unresolved

For frontend-facing objects, coverage must be checked against these UI states:

1. list
2. create
3. edit
4. detail
5. filter

Rules:
- `system-control` fields should normally be excluded from create/edit pages.
- `business-core` fields should appear first in list/create/edit states.
- `FK/reference` fields must display label fields in list/detail, not raw IDs.
- design-doc-defined status machines, state enums, type/category/grade/priority fields must be dictionary-governed unless they are explicit boolean flags
- `dictionary/status` fields must not remain `unresolved` once the slice is implementation-ready; missing `dictSource` or `dictCode` is a coverage gap
- Required fields must not be hidden from create/edit flow.

### 3. Interaction Coverage

Check whether the object has explicit definitions for:

1. status display and transitions
2. permissions and disabled states
3. workflow or approval actions
4. file/upload or attachment behavior
5. empty, loading, error, and success feedback
6. dictionary ownership and translated display path for every design-doc-defined fixed value field

### 4. Consistency Checks

- field names consistent across doc, API, entity, DTO, VO, and page
- enum/value semantics consistent across layers
- enum/state/value-set dictionary ownership consistent across design doc, architect contract, backend translation, frontend selector/display, and tests
- required fields not hidden from create/edit flow
- read-only/system fields not incorrectly editable
- planner field coverage matrix, codegen UI handoff contract, and UX field grouping plan are mutually consistent when they exist
- list/create/edit/detail/filter states do not silently omit business fields without an explicit deferred note

Additional dictionary closure rules:

- if a design doc defines a fixed value set, the release cannot be `ready` while that field is still `unresolved`
- raw enum codes shown in list/detail count as a component-coverage failure, not just a cosmetic issue
- page-level local arrays for state/type fields are only acceptable when they are explicitly sourced from the approved dictionary contract

## Output Format

- Coverage summary by object
- Field coverage matrix by object (`Field / Classification / DictSource / DictCode / List / Create / Edit / Detail / Filter / Notes`)
- Missing UI state list
- Missing field mapping list
- Missing dictionary mapping list
- Missing validation/test list
- Drift or inconsistency list
- Release readiness: ready / partial / blocked