TenantAtlas/specs/399-dashboard-inbox-table-contract/spec.md

Feature Specification: Spec 399 - Dashboard / Inbox / Table Contract Migration v1

Feature Branch: 399-dashboard-inbox-table-contract
Created: 2026-06-22
Status: Draft / Ready for preparation review
Type: Product Surface Contract migration / dashboard-inbox-table runtime reduction
Input: User-provided "Spec 399 - Dashboard / Inbox / Table Contract Migration v1" candidate, plus repo truth from Specs 327, 328, 330, 352, 370, 371, 391, 395, 397, 398, docs/product/spec-candidates.md, docs/product/roadmap.md, docs/product/standards/product-surface-contract.md, and current /admin surface code.

Candidate Selection Context

• Selected candidate: Dashboard / Inbox / Table Contract Migration v1.
• Source: Direct user-provided Spec 399 draft. Spec 395 also records "Dashboard and Inbox Link Budget Pass: Environment Dashboard, Workspace Overview, Governance Inbox, Findings, Operations Hub" as a follow-up candidate in specs/395-product-surface-gate/implementation-report.md.
• Why selected: The active automatic queue in docs/product/spec-candidates.md remains empty, but this request provides an explicit productization candidate. Spec 397 prepared the receipt-page pass and Spec 398 prepared the decision-page pass. This package covers the remaining Product Surface Contract runtime-reduction family named by Spec 395: dashboard, inbox, and table-heavy surfaces.
• Close alternatives deferred:
  • management-report-pdf-staging-runtime-validation: already represented by Spec 380 and not a dashboard/inbox/table migration.
  • governance-artifact-lifecycle-retention-runtime: manual-promotion only and broader than the selected UI contract pass.
  • provider-readiness-onboarding-productization: optional/manual provider-readiness work, not a surface-budget migration.
  • cross-domain-indicator-runtime-follow-through: broader guardrail follow-through; this spec is page-archetype based and narrower.
  • Receipt pages and decision pages: already covered by Specs 397 and 398 and must not be reopened here.
• Roadmap relationship: Supports the roadmap's UI/Product Maturity Polish lane and the Product Surface Contract runtime-reduction direction without reopening completed productization lanes.
• Completed-spec guardrail result: No specs/399-* package existed before this run. Related Specs 327, 328, 330, 352, 370, 371, 391, 395, 397, and 398 are context only. Completed close-out, validation, screenshots, browser evidence, checked task history, and post-implementation review language must not be rewritten.
• Smallest viable implementation slice: Migrate existing /admin dashboard, inbox, and table-heavy default views to the existing Product Surface Contract. Primary targets are Environment Dashboard, Workspace Overview, Governance Inbox, Findings list/inbox surfaces, Operations Hub classification, and only the hot tables directly touched by those surfaces. Secondary tables are included only when narrow and directly related.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Dashboard, inbox, and table-heavy /admin surfaces can still expose too many links, rows, statuses, readiness signals, technical proof references, bulk actions, or competing next actions by default.
• Today's failure: Operators can land on surfaces that behave like internal object graphs instead of answering what needs attention, what needs triage, or how to find the right record. This can obscure the next action, make technical proof feel like product truth, and preserve UI bloat that Spec 395 explicitly flagged for runtime reduction.
• User-visible improvement: Dashboards answer one attention question, inboxes prioritize triage work, hot tables cap or paginate default rows, and technical proof remains available only through deliberate detail/audit paths.
• Smallest enterprise-capable version: A Product Surface Contract migration over existing pages, widgets, resources, table declarations, and views only. Reduce default visible complexity, cap touched hot tables, demote OperationRun/evidence/raw technical links, and verify with focused Feature/Filament plus browser proof.
• Explicit non-goals: No new Product Surface runtime framework, no new presenter family, no new status enum family, no persisted taxonomy, no new dashboard redesign, no navigation redesign, no receipt-page rewrite, no decision-page rewrite, no customer portal work, no compatibility mode for old overloaded views, and no point-fix-only implementation.
• Permanent complexity imported: Focused tests, browser smoke coverage, implementation-report evidence, and possibly small page-local or existing-shared helper cleanup if it reduces review burden. No new database table, migration, provider framework, status taxonomy, cross-domain UI framework, or broad abstraction is approved by this spec.
• Why now: Spec 395 installed the Product Surface Contract gate and explicitly deferred dashboard/inbox/table reduction. Specs 397 and 398 prepared the adjacent receipt and decision page passes, leaving this as the next explicit Product Surface runtime-reduction slice.
• Why not local: One-card or one-table tweaks would preserve the same failure mode on adjacent dashboard/inbox/table surfaces. This spec is cross-surface enough to enforce the existing contract, but bounded to named surfaces and touched tables.
• Approval class: Cleanup / Workflow Compression.
• Red flags triggered: Multiple surfaces and UI contract migration. Defense: the scope reduces visible complexity on existing surfaces, adds no new product truth, preserves existing safety controls, and forbids broad frameworks, new status families, and compatibility paths.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 12/12
• Decision: approve as a bounded Product Surface Contract dashboard/inbox/table migration slice.

Spec Scope Fields (mandatory)

• Scope: canonical-view over existing /admin workspace and environment operator surfaces.
• Primary Routes / Surfaces:
  • Environment Dashboard: /admin/workspaces/{workspace}/environments/{environment}, App\Filament\Pages\EnvironmentDashboard, EnvironmentDashboardOverview, RecentOperations, and dashboard Blade sections.
  • Workspace Overview: /admin/workspaces/{workspace}/overview, App\Filament\Pages\WorkspaceOverview, WorkspaceOverviewBuilder, and workspace summary/attention/operations widgets.
  • Governance Inbox: current App\Filament\Pages\Governance\GovernanceInbox workspace-hub route, including the canonical environment_id page filter where present.
  • Findings list / inbox surfaces: App\Filament\Resources\FindingResource, ListFindings, MyFindingsInbox, and FindingsIntakeQueue where selected by implementation.
  • Operations Hub: App\Filament\Pages\Monitoring\Operations and the related operations table/default workbench; OperationRun detail stays technical/detail context.
  • Hot tables directly touched by this spec: Findings, Governance Inbox lanes/list sections, Environment Dashboard table/widget sections, Workspace Overview table/widget sections, and Operations Hub table/history. Evidence Overview, Inventory, Policies, Policy Versions, Required Permissions, Provider Connections, Backup Sets, Restore Runs, and Stored Reports are secondary targets only if implementation touches them directly and can keep the change narrow.
• Data Ownership: Existing workspace-owned and managed-environment-owned records remain authoritative. No new data owner, table, entity, persisted UI state, or Product Surface truth is introduced.
• RBAC: Existing workspace membership, managed-environment entitlement, resource policies, capability checks, UiEnforcement, WorkspaceUiEnforcement, and deny-as-not-found behavior remain authoritative. Technical/audit detail requires the same or stricter authorization as today.

For canonical-view specs:

• Default filter behavior when tenant-context is active: Target pages remain route-owned by explicit workspace and, when applicable, explicit managed-environment route parameters or environment_id page filters. Hidden session or shell context must not change which environment or rows are shown.
• Explicit entitlement checks preventing cross-tenant leakage: All linked findings, operation runs, evidence artifacts, provider connections, inventory rows, policies, backups, restore runs, and technical/audit paths must resolve through existing workspace/environment entitlement checks before display.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production for this product-surface behavior.

• Compatibility posture: canonical replacement.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no.
• Why clean replacement is safe now: There is no production customer-data compatibility requirement. Existing tests that assert old overloaded dashboard, inbox, or table defaults must be updated to the canonical Product Surface Contract behavior.

Forbidden implementation behavior:

• Keeping old overloaded dashboard/inbox/table layouts in parallel.
• Preserving old default row counts because tests expect 25 rows.
• Keeping OperationRun, Evidence Snapshot, source key, detector, fingerprint, UUID, or payload links as default product links.
• Keeping raw IDs or technical identifiers as primary row labels.
• Keeping destructive or bulk actions visually equivalent to normal navigation.
• Adding compatibility helpers for old action labels, route aliases, table behavior, or dashboard sections.
• Implementing isolated point fixes that do not satisfy the family-level dashboard/inbox/table contract for touched surfaces.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• Existing table/form/state presentation changed
• Customer-facing surface changed
• Dangerous or high-impact action presentation changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact")

Route/page/surface	Current/new archetype	Design depth	Repo-truth level	Existing pattern reused	New pattern required	Screenshot/browser proof	Page audit required	Customer-safe review	Dangerous-action review
Environment Dashboard	Dashboard Page	Strategic Surface	repo-verified	Specs 330/352, EnvironmentDashboardOverview, EnvironmentDashboardSummaryBuilder, Product Surface Contract	none expected; existing dashboard composition only	yes	no full page audit unless classification changes	no	yes for any touched operation/start/danger action
Workspace Overview	Dashboard Page	Strategic Surface	repo-verified	WorkspaceOverview, WorkspaceOverviewBuilder, workspace summary/attention widgets, Product Surface Contract	none expected; existing overview composition only	yes	no full page audit unless classification changes	no	yes if any action hierarchy changes
Governance Inbox	Inbox Page	Strategic Surface	repo-verified	Specs 327/346/389, GovernanceInbox, existing lane contracts and browser smoke	none expected; lane/link/demote work only	yes	no full page audit unless classification changes	no customer default	yes if any high-impact source actions are touched
Findings list / findings inbox	Inbox Page / Search-Index Page	Domain Pattern Surface	repo-verified	FindingResource, Findings inbox/intake pages, TablePaginationProfiles, action-surface contract	none expected; existing Filament table/page patterns	yes	no full page audit unless classification changes	no	yes for bulk/exception/assignment actions
Operations Hub	Inbox Page with technical details demoted	Strategic / Technical Boundary Surface	repo-verified	Specs 328/365/367/391, Operations, OperationRunLinks, OperationsWorkbenchStats	none expected; classify and reduce default technical exposure	yes	no full page audit unless route purpose changes	no	yes if retry/cancel/rerun actions are touched
Hot tables directly touched	Search/Index, Inbox, Dashboard section, or Technical Annex by host page	Domain Pattern Surface	repo-verified per host	TablePaginationProfiles, Filament table standards, action-surface declarations	none expected	yes for rendered changed host page	no unless existing registry is inaccurate	no unless customer path is touched	yes where destructive/bulk actions exist

Coverage files to update or explicitly not needed during implementation:

• docs/ui-ux-enterprise-audit/route-inventory.md
• docs/ui-ux-enterprise-audit/design-coverage-matrix.md
• docs/ui-ux-enterprise-audit/page-reports/...
• docs/ui-ux-enterprise-audit/strategic-surfaces.md
• docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md
• docs/ui-ux-enterprise-audit/unresolved-pages.md
• N/A - no reachable UI surface impact

Spec-level coverage registry decision:

Coverage artifact	Decision	Reason
docs/ui-ux-enterprise-audit/route-inventory.md	Update during implementation for each target surface whose default rendered UI changes.	Dashboard/Inbox/Table classification and Product Surface migration must be visible in durable route inventory.
docs/ui-ux-enterprise-audit/design-coverage-matrix.md	Update during implementation for each target surface whose default rendered UI changes.	The matrix must reflect Product Surface budget migration and focused browser-proof expectation.
docs/ui-ux-enterprise-audit/page-reports/...	Not required by default.	Add or update page reports only if implementation changes archetype, expands default content, or discovers an existing page report is materially inaccurate.
docs/ui-ux-enterprise-audit/strategic-surfaces.md	Not required by default.	No new strategic surface or navigation prominence is introduced.
docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md	Not required by default.	Follow-up candidates are recorded in this active spec.
docs/ui-ux-enterprise-audit/unresolved-pages.md	Not required unless implementation cannot classify or render a touched surface.	Planned target surfaces are classifiable under the Product Surface Contract.

Product Surface Impact (mandatory for UI-affecting specs)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes. This spec materially changes rendered product dashboard, inbox, and table-heavy surfaces.
• Page archetype:
  • Environment Dashboard: Dashboard Page.
  • Workspace Overview: Dashboard Page.
  • Governance Inbox: Inbox Page.
  • Findings list / findings inbox: Inbox Page or Search/Index Page, depending on the exact host.
  • Operations Hub: Inbox Page with technical details demoted. OperationRun detail remains technical/audit detail.
  • Hot tables: inherit the host page archetype, or Technical Annex/System Admin only when the host page is explicitly classified that way.
• Primary user question:
  • Environment Dashboard: What needs attention in this environment right now?
  • Workspace Overview: Which workspace areas need attention first?
  • Governance Inbox: Which governance items need triage and what is the next action?
  • Findings: Which findings need action first?
  • Operations Hub: Which operations need attention, and where can internal users inspect technical run detail?
• Primary action: Exactly one dominant product action or triage path per touched surface or focused card/row group.
• Surface budget result: planned pass. Any exception must be documented in this spec and plan before runtime UI edits continue.
• Technical Annex / deep-link demotion: OperationRun links, raw Evidence Snapshot or Evidence Artifact links, source keys, detectors, raw Finding fingerprints, UUIDs, provider payloads, raw report artifacts, restore operation proof, technical logs, JSON summaries, and payload links must be hidden, collapsed, capped, or moved to authorized detail/audit paths by default.
• Canonical status vocabulary: Use Ready, Needs attention, Blocked, Running, Failed, Expired, Not configured, Unknown, Historical, Superseded, plus allowed severity states Critical, High, Medium, Low, and Info.
• List surface review checklist: Because this spec modifies list/table surfaces, implementation must review docs/product/standards/list-surface-review-checklist.md before table edits and record the result in the implementation report.
• Visible complexity impact: decreased or neutral only with documented larger removal elsewhere on the same surface.
• Product Surface exceptions: none planned. Any unavoidable exception is a stop condition requiring spec and plan update.

UI Action Matrix

Surface	Primary action	Secondary actions	Technical/audit actions	Dangerous/high-impact actions	Mutation scope
Environment Dashboard	One state-based attention action such as Review blockers, Verify provider, Open review, or Resolve finding.	Up to two contextual actions per focused section, such as Open environment, Open report, or Compare to current.	View audit trail, View technical run details, or View internal evidence details; secondary and not default-dominant.	Existing operation-start or dangerous actions touched by implementation must remain non-primary, confirmed, authorized, audited, and observable.	Mostly read-only dashboard navigation; any operation start remains existing TenantPilot operation path.
Workspace Overview	One workspace triage path such as Review workspace attention, Open environment, or Review blockers.	Up to two contextual actions per focused card/section.	Operations, evidence, report, or audit links are secondary/detail only.	None expected; any touched high-impact action must remain separated and confirmed.	Read-only overview and navigation unless existing actions are explicitly invoked.
Governance Inbox	One triage action per work item or one top summary next action.	Up to two contextual links per item or lane.	Proof/evidence/run/detail links collapsed or secondary.	No new destructive action. Existing source-surface dangerous actions stay on their source pages or remain separated.	Mostly navigation/triage; mutations remain in source surfaces.
Findings list / inbox	One inspect/triage action per row, shaped by Inbox or Search/Index archetype.	Up to two row secondary actions where justified.	Fingerprint, source key, detector, raw evidence, and operation detail hidden or technical.	Bulk exception/assignment/destructive actions must be grouped and confirmation/authorization protected where mutating.	Existing finding lifecycle, assignment, and exception paths only.
Operations Hub	One attention/open action for the selected or highest-priority operation.	Up to two contextual artifact/source actions where authorized.	Raw OperationRun detail, context, payloads, failure internals, and technical run links are secondary or detail-only.	Retry/cancel/rerun actions, if touched, must remain secondary, confirmed where high-impact, authorized, audited, and Ops-UX compliant.	Existing OperationRun/operation action paths only.
Touched hot tables	One row primary action or inspect model.	At most two visible secondary row actions by default.	Technical columns/links hidden, toggleable, collapsed, or moved to detail.	Bulk destructive/high-impact actions grouped and not visually equivalent to navigation.	Existing model/action scopes only.

Browser Verification Plan (mandatory)

• Browser proof required?: yes.
• No-browser rationale: N/A - rendered UI changes are the purpose of this spec.
• Focused path when required:
  • Environment Dashboard for one attention-needed environment and one calm/no-action environment where feasible.
  • Workspace Overview for a workspace with multiple visible environments or attention families.
  • Governance Inbox with at least one non-empty lane and one filtered or calm state.
  • Findings list/inbox with enough rows to prove row cap or product pagination.
  • Operations Hub with one attention-needed operation and diagnostics collapsed by default.
  • At least one directly touched hot table.
• Primary interaction to execute:
  • Render first viewport and confirm one primary user question/action.
  • Verify table cap/pagination and one row primary action.
  • Expand one deliberate technical/audit disclosure where present and confirm technical detail is not default-visible.
  • Verify destructive/bulk actions are grouped/separated if touched.
• Console, Livewire, Filament, network, and 500-error checks: required for focused browser smoke.
• Full-suite failure triage: If unrelated browser failures remain, implementation must document the command, affected failures, why they are unrelated, and prove no touched dashboard/inbox/table surface failed.

Human Product Sanity Check (mandatory)

• Required?: yes.
• No-human-sanity rationale: N/A - rendered product surfaces change.
• Reviewer questions:
  • Does each dashboard answer what needs attention now?
  • Does each inbox answer what needs triage?
  • Are tables capped or paginated before they become product noise?
  • Are technical details demoted?
  • Are there fewer default deep links?
  • Is there one dominant next action or triage path?
  • Are destructive/bulk actions separated?
  • Does the page feel less complex than before?
  • Would an operator trust the page?
• Planned result location: implementation report and PR close-out.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed and exceptions are none or explicitly approved.
• Browser proof is completed for every rendered UI surface changed.
• Human Product Sanity is completed.
• Implementation report states Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.

Cross-Cutting / Shared Pattern Reuse (mandatory)

• Cross-cutting feature?: yes.
• Interaction classes: dashboard signals/cards, inbox lanes, table pagination/row actions, status messaging, action links, technical/audit links, OperationRun evidence links, destructive/bulk action grouping, and browser/human sanity proof.
• Systems touched:
  • App\Filament\Pages\EnvironmentDashboard
  • App\Filament\Widgets\Dashboard\EnvironmentDashboardOverview
  • apps/platform/resources/views/filament/widgets/dashboard/environment-dashboard-overview.blade.php
  • App\Filament\Pages\WorkspaceOverview
  • App\Support\Workspaces\WorkspaceOverviewBuilder
  • App\Filament\Pages\Governance\GovernanceInbox
  • apps/platform/resources/views/filament/pages/governance/governance-inbox.blade.php
  • App\Filament\Resources\FindingResource
  • App\Filament\Pages\Monitoring\Operations
  • apps/platform/resources/views/filament/pages/monitoring/operations.blade.php
  • directly touched table resources/pages/widgets.
• Existing pattern(s) to extend: Product Surface Contract, Filament Table UX Standard, TablePaginationProfiles, action-surface declarations, BadgeCatalog / BadgeRenderer, UiEnforcement, WorkspaceUiEnforcement, OperationRunLinks, OperationUxPresenter, and existing browser fixture helpers.
• Shared contract / presenter / builder / renderer to reuse: reuse existing builders/presenters/helpers first. New helper extraction is allowed only when it reduces real review burden inside touched surfaces and does not become a generic Product Surface runtime framework.
• Why the existing shared path is sufficient or insufficient: The Product Surface Contract already supplies the vocabulary and budgets. Existing page builders and Filament table APIs already supply most state and interaction structure. The gap is default-visible hierarchy, row/link/action budget enforcement, and technical demotion, not missing product truth.
• Allowed deviation and why: page-local collapsed detail, row-cap, or link-demotion helpers may be used if current Filament/table/view structure cannot express the contract cleanly. No cross-domain Product Surface runtime framework is approved.
• Consistency impact: one primary question/action, canonical status vocabulary, row/action/link budgets, technical demotion, and high-impact action separation must stay aligned across touched dashboard, inbox, and table surfaces.
• Review focus: no point fixes, no default OperationRun proof, no raw evidence/payload leakage, no duplicate readiness summaries, no fake "all clear", no weakened RBAC, no completed-spec rewrites, and no new framework.

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

• Touches OperationRun start/completion/link UX?: yes, by demoting default OperationRun proof links and preserving existing operation-start behavior on touched surfaces.
• Shared OperationRun UX contract/layer reused: existing OperationRunLinks, OperationUxPresenter, OpsUxBrowserEvents, OperationRunService, and current operation resource links.
• Delegated start/completion UX behaviors: existing queued toast, artifact link, Open operation link, run-enqueued browser event, tenant/workspace-safe URL resolution, dedupe/start-failure messaging, and terminal notification paths remain delegated to existing helpers.
• Local surface-owned behavior that remains: deciding whether an operation link is product-secondary/audit detail or hidden from the default dashboard/inbox/table view.
• Queued DB-notification policy: unchanged; no new queued DB notification opt-in.
• Terminal notification path: unchanged through central lifecycle mechanism.
• Exception required?: none planned.

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

• Shared provider/platform boundary touched?: no new shared provider/platform boundary.
• Boundary classification: N/A.
• Seams affected: existing provider-readiness/provider-connection display may be demoted when already present on dashboard/table surfaces, but no provider identity, contract, registry, credential, Graph endpoint, or provider capability seam changes are in scope.
• Neutral platform terms preserved or introduced: use provider, environment, operation, evidence, finding, and Product Surface vocabulary where product-facing; provider-specific terms remain diagnostics/detail when not required for the immediate decision.
• Provider-specific semantics retained and why: existing Microsoft/Intune details may remain in technical/audit detail only where repo-real and authorized.
• Why this does not deepen provider coupling accidentally: the spec reduces default-visible provider technical detail and introduces no new provider-owned truth.
• Follow-up path: none planned.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Environment Dashboard reduction	yes	mixed Filament Page, widgets, Blade	dashboard signals, action links, status messaging	page, widget payload, route environment	none planned	existing route only
Workspace Overview reduction	yes	mixed Filament Page, widgets, builder payload	dashboard signals, operations/action links	page, builder payload, workspace route	none planned	existing route only
Governance Inbox reduction	yes	custom Blade inside Filament Page	inbox lanes, action links, disclosure	page, URL-query filter, lane state	none planned	existing route only
Findings table/inbox reduction	yes	native Filament table/pages plus inbox pages	table/action-surface family	table state, row actions, bulk actions	none planned	existing routes only
Operations Hub classification/reduction	yes	mixed Filament Page, widgets, Blade/table	operations, OperationRun links, status messaging	page, URL-query filter, table state	none planned	existing route only
Touched hot table contract	yes	native Filament tables where possible	table/action-surface family	table pagination, columns, row/bulk actions	none planned	host-page bounded

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Environment Dashboard	Primary Decision Surface	Operator decides what needs attention in one environment	environment state, top attention items, compact summary, recommended action	operations, evidence, provider diagnostics, raw payloads	Primary because it is the environment command surface	environment readiness/governance workflow	prevents scanning proof cards and related object links first
Workspace Overview	Primary Decision Surface	Operator decides which workspace area or environment to inspect first	workspace state, top attention items, compact portfolio summary, triage path	operations history, evidence/report links, environment technical detail	Primary because it is the workspace entry surface	workspace triage workflow	reduces portfolio search and link floods
Governance Inbox	Primary Decision Surface	Operator triages governance work items	prioritized items, state/severity, scope, impact/reason, next action	proof links, source detail, diagnostics	Primary because it is the governance work queue	triage workflow	reduces proof graph navigation before work selection
Findings list / inbox	Primary Decision or Search/Index Surface	Operator finds and triages findings	finding label, severity/state, affected scope, owner/next action	fingerprint, detector, source key, raw evidence	Primary only for finding triage; search/index when browsing records	findings workflow	reduces row/link/action overload
Operations Hub	Secondary Context Surface with Inbox behavior	Operator identifies operations needing attention and opens deliberate run detail	operation purpose/state/impact/next action	raw run context, payloads, stack traces, diagnostics	Not a raw product noun hub; supports operations follow-up	operations attention workflow	keeps technical run inspection secondary

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

Surface	Audience Modes In Scope	Decision-First Default-Visible Content	Operator Diagnostics	Support / Raw Evidence	One Dominant Next Action	Hidden / Gated By Default	Duplicate-Truth Prevention
Environment Dashboard	operator-MSP, manager, support-platform	state, reason, top attention, next action	operations/evidence/provider detail	raw provider payloads, run context, evidence internals	review/resolve the primary blocker	raw IDs, OperationRun proof, evidence links	one readiness/status model per concept
Workspace Overview	operator-MSP, manager	workspace posture, top attention items, environment scope	operations/evidence/report detail	internal raw records	open the highest-priority area	long tables, raw links, duplicate readiness	summary states each blocker once
Governance Inbox	operator-MSP, manager	prioritized work, severity/state, reason, next action	source detail, proof summaries	raw evidence/run/payload detail	triage selected item	proof graph links and diagnostics	lanes add context without restating top blocker repeatedly
Findings list / inbox	operator-MSP, manager	product finding label, severity/state, scope, owner/next action	source, detector, evidence when expanded	fingerprints, source keys, UUIDs	inspect/resolve finding	raw technical identifiers	table row uses one product identity
Operations Hub	operator-MSP, support-platform	operation purpose, state/outcome, impact, next action	run detail, related artifact, progress detail	raw context, stack traces, payloads	open/resolve attention operation	raw run IDs and payloads	active/terminal truths not repeated as dashboards

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type / Justification
Environment Dashboard	Dashboard / Workbench	Dashboard Page	review top attention item	primary action/link per focused area	N/A	secondary card/detail path	More/detail only	/admin/workspaces/{workspace}/environments/{environment}	existing child/detail routes	workspace + environment	Environment Dashboard	state, top attention, next action	none
Workspace Overview	Dashboard / Workbench	Dashboard Page	open highest-priority workspace area	primary card/action	N/A	secondary card/action group	More/detail only	/admin/workspaces/{workspace}/overview	existing environment/detail routes	workspace	Workspace Overview	workspace attention, environment priority	none
Governance Inbox	Queue / Review	Inbox Page	triage selected governance item	explicit item action or selected detail	not default full-row click	source/detail disclosure	source surfaces only	current Governance Inbox route	source record routes	workspace + optional environment filter	Governance Inbox	prioritized work, impact, next action	none
Findings list / inbox	List / Table / Queue	Inbox or Search/Index Page	inspect or resolve finding	row inspect/recordUrl per host contract	host-specific	More/detail or secondary row action	grouped bulk/detail	current FindingResource/inbox routes	finding detail route	workspace + environment	Findings	severity, state, scope, next action	none
Operations Hub	Workbench / Monitoring	Inbox with technical detail demoted	open attention operation or related source	selected operation/action	host-specific	technical/detail path	More/detail only if present	current Operations route	OperationRun detail route	workspace + optional environment filter	Operations	operation purpose, state/outcome, impact	none

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Environment Dashboard	MSP operator / manager	Decide which environment issue needs attention first	Dashboard Page	What needs attention in this environment right now?	state, reason, top attention items, compact summary, next action	raw evidence, OperationRun proof, provider payloads, technical diagnostics	readiness/lifecycle, severity, operation attention where relevant	mostly navigation; operation starts through existing actions only	review blocker, verify provider, resolve finding, open review	none introduced; touched existing danger actions stay separated
Workspace Overview	MSP operator / manager	Decide which workspace area or environment to inspect first	Dashboard Page	Which workspace areas need attention first?	workspace state, top environment/workspace attention, compact metrics, triage path	operations history, evidence/report internals	workspace attention, environment state, operation attention	navigation only unless existing action selected	open prioritized area/environment	none introduced
Governance Inbox	MSP operator / manager	Triage governance items	Inbox Page	Which governance items need triage and what is the next action?	item, severity/state, scope, reason/impact, next action	source detail, proof, diagnostics	governance state, severity, due/freshness where existing	source-surface mutations only	triage item, open source	none introduced
Findings list / inbox	MSP operator / manager	Triage findings by severity/state/scope	Inbox / Search-Index	Which findings need action first?	product label, severity, state, scope, owner/action	fingerprint, source key, detector output, raw evidence	finding state, severity, ownership	existing finding assignment/exception paths only	inspect/resolve finding	bulk/destructive actions grouped and confirmed
Operations Hub	Operator / support reviewer	Identify operations needing attention and open deliberate run detail	Inbox with technical detail demoted	Which operations need attention?	operation purpose, state/outcome, impact, environment, next action	raw run context, stack traces, payloads	execution status, outcome, progress if trustworthy	existing operation action paths only	open attention operation/source	retry/cancel/rerun only if existing and separated

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no.
• New persisted entity/table/artifact?: no.
• New abstraction?: no broad abstraction approved.
• New enum/state/reason family?: no.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: overloaded dashboards, inboxes, and tables hide the next action behind technical proof and row/link/action noise.
• Existing structure is insufficient because: existing surfaces already have the data and shared contracts, but default presentation still violates Product Surface budgets and deep-link demotion rules on the named surface family.
• Narrowest correct implementation: reduce existing pages, widgets, table definitions, views, and tests; do not introduce new Product Surface truth.
• Ownership cost: focused tests, focused browser proof, implementation-report evidence, and page/table-specific cleanup only.
• Alternative intentionally rejected: a reusable Product Surface runtime framework, dashboard engine, inbox engine, persisted surface taxonomy, or broad product redesign.
• Release truth: current-release productization cleanup.

Compatibility posture

This feature assumes a pre-production environment. Backward compatibility, legacy aliases, migration shims, hidden old layouts, old table defaults, and compatibility-specific tests are out of scope unless this spec is updated with an explicit approved exception.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Feature / Filament-Livewire / Browser, with Unit tests only for existing builders/helpers if their output must drive the surface budget.
• Validation lane(s): confidence plus browser. Fast-feedback may cover pure helper assertions; browser proof is required for changed rendered surfaces.
• Why this classification and these lanes are sufficient: Feature/Livewire tests prove table row caps, link/action demotion, RBAC-visible action state, and default text. Browser smoke proves actual first-viewport hierarchy, table caps, disclosure state, and no runtime/console/Filament failures.
• New or expanded test families: one explicit Spec 399 focused Feature/Filament set and one explicit browser smoke file if existing browser coverage cannot prove the contract.
• Fixture / helper cost impact: reuse existing workspace/environment/browser harnesses and fixtures from Specs 327, 328, 330, 346, 352, 391, and related Feature tests. Do not widen default factories or browser setup.
• Heavy-family visibility / justification: one focused browser family is explicit and justified because rendered UI and Product Surface Contract behavior are the product value of this spec.
• Special surface test profile: standard-native-filament for native table reductions; monitoring-state-page for Operations Hub; global-context-shell for Workspace Overview/Governance Inbox filter behavior where affected.
• Standard-native relief or required special coverage: standard-native relief applies only to ordinary table pagination/columns after Feature tests prove row/action/link budgets. Dashboard/inbox/Operations changes still require browser smoke.
• Reviewer handoff: reviewers must confirm lane fit, hidden fixture cost, no completed-spec rewrite, Product Surface exceptions, and the exact proof commands in the implementation report.
• Budget / baseline / trend impact: low to medium; bounded Feature/Browser additions. Escalate in-feature if browser setup grows beyond the named surfaces.
• Escalation needed: document-in-feature for contained exceptions; follow-up-spec only if a recurring table/action framework gap is discovered.
• Active feature PR close-out entry: Guardrail / Exception / Smoke Coverage.
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=Spec399
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Spec399DashboardInboxTableContractMigrationSmokeTest.php
  • Affected existing Feature/Browser tests named by implementation discovery.
  • cd apps/platform && ./vendor/bin/sail pint --dirty
  • git diff --check

User Scenarios & Testing (mandatory)

User Story 1 - Dashboards answer one attention question (Priority: P1)

As an MSP operator, I want Environment Dashboard and Workspace Overview to show one primary attention question, compact summary, and a dominant next action so I can decide where to work without scanning technical proof and related object links first.

Why this priority: Dashboards are first-entry surfaces. If they remain noisy, later inbox/table reductions do not produce a calm operator path.

Independent Test: Open Environment Dashboard and Workspace Overview with representative fixtures. The first viewport shows the primary question, compact summary, top attention items, and one dominant next action. It does not default-show OperationRun proof links, raw evidence links, raw IDs, repeated readiness/status models, or long technical tables.

Acceptance Scenarios:

1. Given an environment with provider, findings, evidence, and operations context, When an authorized operator opens Environment Dashboard, Then the default view answers what needs attention and exposes only deliberate secondary/detail paths for proof.
2. Given a workspace with multiple visible environments or attention families, When an authorized operator opens Workspace Overview, Then the default view prioritizes workspace areas and does not expose a long operations/evidence/report table by default.
3. Given a calm/no-action environment or workspace, When the dashboard opens, Then it shows an honest calm state without false "all clear" product claims or duplicate readiness summaries.

---

User Story 2 - Inboxes prioritize triage work (Priority: P1)

As an operator, I want Governance Inbox and Findings surfaces to show the item, state/severity, scope, impact/reason, and next action so I can triage work without following a proof graph per row.

Why this priority: Governance Inbox and Findings are work queues. Their default state must support triage, not technical reconstruction.

Independent Test: Open Governance Inbox and Findings list/inbox with non-empty fixtures. Rows/items show product labels, severity/state, scope, impact/reason, and one primary triage/inspect action. Default rows do not expose OperationRun links, source keys, detectors, fingerprints, UUIDs, or excessive inline links.

Acceptance Scenarios:

1. Given active governance items, When Governance Inbox renders, Then each visible item has one primary triage path and technical/proof links are secondary or collapsed.
2. Given more findings than the default table budget, When Findings renders, Then the default list uses product pagination or a maximum of eight visible rows; any inability to meet that budget requires a Product Surface exception before implementation continues.
3. Given bulk or high-impact finding actions are available, When the operator scans the list, Then those actions are grouped/separated and cannot be confused with normal navigation.

---

User Story 3 - Hot tables obey row, link, and action budgets (Priority: P1)

As an operator scanning product-facing tables, I want hot tables to show a small number of product-labelled rows and one primary action so I can find the relevant record without technical columns and inline link floods.

Why this priority: Table overload is the repeated failure mode across dashboard and inbox surfaces.

Independent Test: For every hot table touched by implementation, Feature/Livewire tests assert row cap or product pagination, product row labels, one row primary action, no raw IDs as primary labels, no default technical columns, and grouped destructive/bulk actions.

Acceptance Scenarios:

1. Given a touched product-facing table with more than eight records, When it renders in a dashboard/inbox/default product context, Then it shows at most eight visible rows before Show more, pagination, or full-table navigation; any inability to meet that budget requires a Product Surface exception before implementation continues.
2. Given a touched row with technical references, When it renders, Then raw UUIDs, source keys, detector output, fingerprints, and raw payload references are absent from primary labels/default columns.
3. Given a touched table has destructive or bulk actions, When the action area renders, Then destructive/high-impact actions are grouped or separated and remain confirmation/authorization protected.

---

User Story 4 - Operations Hub is not a raw run browser by default (Priority: P2)

As an operations responder, I want Operations Hub to show operations needing attention while keeping raw OperationRun detail deliberate, so I can respond without treating internal run records as the product's primary noun.

Why this priority: Operations is a critical diagnostic surface, but it should not leak technical run detail into product entry points by default.

Independent Test: Open Operations Hub with attention-needed and completed runs. The default surface shows operation purpose, state/outcome, impact, environment/scope, and one next action. Raw run IDs, payloads, debug errors, and technical diagnostics are not default-visible. OperationRun detail remains reachable through authorized deliberate paths.

Acceptance Scenarios:

1. Given an attention-needed operation exists, When Operations Hub opens, Then the page answers which operation needs attention and shows one primary action or source/detail path.
2. Given raw run context or failure internals exist, When the page opens, Then those details are collapsed, hidden, or moved to technical detail.
3. Given successful historical operations exist, When the page opens, Then the surface does not present them as environment health, governance health, or a primary product success dashboard.

---

User Story 5 - Technical proof remains reachable and safe (Priority: P2)

As an authorized internal user, I want technical proof and audit detail to remain reachable through deliberate paths so surface simplification does not remove troubleshooting or auditability.

Why this priority: Product Surface reduction must reduce default-visible complexity without hiding evidence from authorized users who need it.

Independent Test: For each touched surface, tests or browser smoke prove technical/audit/detail links are absent from the default primary hierarchy but available through an authorized secondary/detail path where the existing product already supported them.

Acceptance Scenarios:

1. Given an authorized operator has access to a touched source record, When they choose a secondary/detail path, Then existing technical/audit proof remains reachable subject to current authorization.
2. Given a user lacks workspace/environment entitlement, When they attempt to reach a demoted technical path, Then the system still denies as not found or forbidden according to existing RBAC semantics.
3. Given implementation demotes a link from a dashboard/inbox/table, When the feature closes, Then the implementation report states where authorized users can still inspect the technical proof or why that proof path was intentionally not present before.

Edge Cases

• A touched dashboard has no attention items: show an honest no-action state without fake health or duplicate readiness claims.
• A touched table cannot practically show exactly eight rows because it uses native pagination defaults: document the Product Surface pass or exception and prove the default does not create a product-facing row flood.
• A table is clearly Technical Annex or System Admin: it may show more technical detail only when the host page is classified accordingly.
• An OperationRun link is the only available path to diagnose a failed operation: keep it as secondary/detail, not as default product proof.
• A destructive/bulk action is hidden by RBAC: the server-side authorization remains authoritative and tests must cover denied execution where the action is touched.
• Existing browser full-suite failures unrelated to touched surfaces: document them without marking Spec 399 green if any touched surface fails.

Requirements (mandatory)

Functional Requirements

• FR-399-001: Environment Dashboard MUST answer "What needs attention in this environment right now?" and reduce default proof, deep-link, readiness, and diagnostics overload.
• FR-399-002: Workspace Overview MUST answer "Which workspace areas need attention first?" and reduce default operations/evidence/report table overload.
• FR-399-003: Governance Inbox MUST prioritize governance work items and demote proof/evidence/operation links from default row/item actions.
• FR-399-004: Findings list/inbox surfaces touched by implementation MUST show product labels, severity/state, affected scope, owner or next action, and one primary inspect/triage action.
• FR-399-005: Operations Hub MUST be treated as an Inbox Page with technical details demoted from the default view; OperationRun detail remains deliberate technical/audit context.
• FR-399-006: Every touched product-facing hot table MUST obey row, link, action, and technical-column budgets from the Product Surface Contract or document a bounded exception before implementation continues.
• FR-399-007: Touched dashboard/inbox/table default views MUST NOT expose OperationRun proof links, raw Evidence links, source keys, detectors, fingerprints, raw payloads, UUIDs, or technical logs as primary product content.
• FR-399-008: Touched surfaces MUST keep exactly one dominant next action or triage path per page/section/item; any inability to meet this budget requires a Product Surface exception before implementation continues.
• FR-399-009: Touched destructive, bulk, or high-impact actions MUST remain visually separated, confirmation-protected where mutating/destructive, server-authorized, and audit-safe.
• FR-399-010: Tests that assert old overloaded dashboards, 25-row hot tables, default OperationRun proof links, or excessive evidence links MUST be updated to assert the new contract.
• FR-399-011: Implementation MUST NOT create a Product Surface runtime framework, presenter family, status enum family, component framework, persisted taxonomy, or broad design system.
• FR-399-012: Implementation MUST update Product Surface implementation-report fields and UI coverage artifacts for each rendered surface whose default UI changes.

Non-Functional Requirements

• NFR-399-001: Rendered /admin pages must remain DB-only where they are currently DB-only; no Graph calls may be introduced during render.
• NFR-399-002: Browser smoke must remain focused and fixture-bounded to touched surfaces.
• NFR-399-003: Visible complexity must decrease or remain neutral only when the implementation report proves a larger removal on the same surface.
• NFR-399-004: The implementation must preserve dark mode correctness, accessibility affordances, and Filament-native semantics for custom Blade areas touched.
• NFR-399-005: The implementation must not broaden test fixtures, factories, browser setup, workspace context helpers, or heavy-governance lane cost beyond the named surface proof.

UX Requirements

• Dashboard pages must default to compact attention, summary, and next-action content rather than proof graphs.
• Inbox pages must default to prioritized work items rather than raw related-object navigation.
• Product-facing tables must default to clear row identity, one primary action, product status, and capped/paginated rows.
• Technical detail remains behind deliberate secondary/detail/audit disclosure.
• Product copy must prefer Needs attention, Review blockers, Resolve finding, Verify provider, Open environment, View audit trail, and View details.
• Default product copy must avoid OperationRun, Evidence artifact, Source key, Detector, Fingerprint, Payload, UUID, Raw metadata, Scope key, and Technical dimension except in technical/audit paths.

RBAC / Security Requirements

• Existing workspace and managed-environment entitlement checks remain authoritative.
• UI visibility is not authorization; every touched mutating action must retain server-side policy/gate enforcement.
• Non-members or non-entitled users must continue to receive deny-as-not-found semantics where currently required.
• Member-but-missing-capability execution denial remains 403 where existing policy semantics require it.
• Technical/audit detail requires the same or stricter authorization as before.
• Global search posture must not change unless the active implementation explicitly touches a Resource's global search behavior and updates this spec/plan first.

Auditability / Observability Requirements

• No new OperationRun type, status, summary-count key, notification class, or operation lifecycle path is introduced.
• Existing OperationRun start/completion UX must remain delegated to the central OperationRun UX layer when touched.
• Existing audit logging for mutating/destructive/high-impact actions must not be weakened.
• If a touched action newly changes mutation placement or grouping, tests must prove confirmation/authorization/audit behavior remains intact.

Data / Truth-Source Requirements

• Prefer existing data and computed states.
• No new tables, migrations, persisted UI state, or compatibility fields are in scope.
• Product status display must map from existing domain truth to Product Surface vocabulary without creating a new status family.
• Technical proof demotion must move display placement only; it must not delete evidence, operation, or audit truth.

Out Of Scope

• Rewriting Spec 395, Spec 397, or Spec 398.
• Rewriting completed specs or removing historical validation/browser evidence.
• Evidence Snapshot detail, Baseline Snapshot detail, Baseline Compare, Restore Preview, Review Publication Resolution, Customer Review Workspace, System Panel branding, and report receipt pages unless a small table/widget inside a target dashboard/inbox is directly touched and documented.
• New dashboard redesign, navigation redesign, runtime Product Surface framework, presenter family, enum/status family, component framework, persisted taxonomy, or design-system rewrite.
• New Microsoft Graph calls, Graph contract changes, migrations, models, jobs, queues, scheduler changes, env vars, storage changes, or external service dependencies.

Acceptance Criteria (mandatory)

• AC-399-001: Environment Dashboard default view shows environment state, top attention items, compact summary, and recommended next action without default OperationRun proof/raw evidence/deep-link overload.
• AC-399-002: Workspace Overview default view shows workspace-level triage and top attention items without long operations/evidence/report tables or raw technical links by default.
• AC-399-003: Governance Inbox rows/items show work item, state/severity, scope, impact/reason, and next action without default proof-graph navigation.
• AC-399-004: Findings default table/list shows at most eight visible rows before pagination/show more unless a Product Surface exception is documented before implementation continues, uses product labels, and avoids UUID/fingerprint/detector/source key as primary labels.
• AC-399-005: Operations Hub shows operation attention and deliberate technical detail paths without making raw OperationRun detail the default product surface.
• AC-399-006: Every touched hot table respects row, link, action, and technical-column budgets or records a bounded Product Surface exception before code changes continue.
• AC-399-007: Touched destructive/bulk/high-impact actions are visually separated and confirmation-protected/authorized/audited where mutating.
• AC-399-008: Tests no longer expect old overloaded dashboards, 25-row hot tables, default OperationRun proof links, or excessive evidence links on touched surfaces.
• AC-399-009: Implementation introduces no new Product Surface runtime framework, presenter/status enum family, component framework, or persisted taxonomy.
• AC-399-010: Focused Spec 399 Feature/Filament tests, focused browser smoke, Pint, and diff checks pass or failures are documented as unrelated only when no touched surface failed.

Success Criteria (mandatory)

Measurable Outcomes

• SC-399-001: Each touched primary page has exactly one documented primary user question and one dominant next action/triage path in the implementation report.
• SC-399-002: Each touched product-facing table either defaults to at most eight visible rows before Show more/pagination/full-table path or documents an approved exception.
• SC-399-003: Focused browser proof verifies no default-visible OperationRun proof links, raw evidence/source key/detector/payload identifiers, or default-open diagnostics on the touched dashboard/inbox/table surfaces.
• SC-399-004: Human Product Sanity records visible complexity as decreased or neutral with proof, and no touched surface is judged louder or more ambiguous than before.
• SC-399-005: No application implementation introduces migrations, new persisted truth, new status families, or new Product Surface framework code for this spec.

Risks

• Risk 1 - Operators lose access to proof/detail: mitigate by preserving authorized secondary/detail/audit paths and documenting proof continuity in the implementation report.
• Risk 2 - Tests preserve overloaded defaults: mitigate by updating tests to the new table/dashboard/inbox contract and forbidding compatibility behavior.
• Risk 3 - Dashboards become too sparse: mitigate by requiring state, top attention items, compact summary, and next action.
• Risk 4 - Operations Hub classification remains ambiguous: mitigate by treating the default route as Inbox behavior with technical detail demoted; any Technical Annex exception must be documented before implementation continues.
• Risk 5 - Scope expands into broad redesign: mitigate by limiting implementation to named surfaces and touched hot tables, with receipt/decision/customer/system surfaces out of scope.
• Risk 6 - Runtime framework creep: mitigate by explicitly forbidding new Product Surface frameworks, presenter families, enum/status families, component frameworks, and persisted taxonomies.

Assumptions

• The current /admin panel remains the operator surface; /system and retired /admin/t routes are not product targets for this spec.
• Existing Specs 327, 328, 330, 346, 352, 391, 397, and 398 provide context and tests/browser fixtures that can be reused or updated, but their historical close-out evidence must not be rewritten.
• Existing Filament v5 / Livewire v4 behavior, TablePaginationProfiles, action-surface declarations, BadgeCatalog, and OperationRun helpers are sufficient for the intended migration.
• Implementation may narrow secondary hot tables if touching all listed tables would exceed a bounded implementation loop; every touched table must still obey the contract.

Open Questions

• None blocking preparation. During implementation, if a touched table cannot practically meet the eight-row default because of native pagination constraints or route purpose, the implementer must update this spec and plan with a Product Surface exception before continuing.

Follow-up Spec Candidates

• Secondary hot-table follow-through for Evidence Overview, Inventory, Policies, Policy Versions, Required Permissions, Provider Connections, Backup Sets, Restore Runs, or Stored Reports if implementation discovers recurring table overload outside the primary surfaces.
• Product Surface strictness/guard expansion only after at least one more runtime surface migration proves false-positive behavior is manageable.
• Manual system-panel browser fixture or audit procedure remains separate from this /admin product-surface migration.