Frontend Coverage Audit

Metric	Count
MFE route artifacts reviewed	802
Stories with mapped frontend evidence	77
Explicit transaction/component ownership mappings	153
Direct feature-token mappings	377
Broad module-level mappings requiring review	272
Module/default route records with no route segment	223

Interpretation

• Direct feature-token mapping is strong traceability evidence, but still requires BA validation of field rules and workflow wording.
• Explicit transaction/component ownership uses maintained rules for known routes whose generic token scoring previously attached child screens to broad stories.
• Module-level mapping proves that the frontend artifact exists inside the module; it is not proof that the current story is the correct business owner. These rows are intentionally visible in each story table.
• Empty route segments normally represent module defaults, redirects, layouts, or lazy-loaded children. They are retained when a concrete target component exists and omitted when both route and target are non-descriptive.
• API-only stories can legitimately have no frontend route. They remain covered by endpoint/application evidence and must not be presented as a user page unless a UI is later found.

Review procedure

1. Confirm every direct route belongs to the mapped story and rename/split stories where one story absorbs unrelated pages.
2. Review every module-level row and either confirm it, remap it, or create a missing feature story.
3. Compare each add/edit form against its story's required, optional, conditional, calculated, and read-only fields.
4. Compare visible buttons and row actions against permissions, document states, API endpoints, and failure behavior.
5. Validate reports for filters, totals, drill-through, print/export, empty data, localization, and authorized scope.