TenantAtlas/specs/313-workspace-environment-context-browser-verification/spec.md

# Feature Specification: Full Workspace / Environment Context Browser Verification Audit

**Feature Branch**: `313-workspace-environment-context-browser-verification`
**Created**: 2026-05-16
**Status**: Draft
**Type**: Analysis-only / Browser verification / Context contract audit
**Runtime posture**: No fixes, no refactors, no runtime behavior changes
**Input**: User-provided Spec 313 completion-gate audit draft.

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

- **Problem**: TenantPilot admin workspace hubs, environment-owned pages, route/query state, Filament table state, remembered environment context, and browser navigation can disagree about the active Workspace / Managed Environment scope.
- **Today's failure**: After Spec 311 and Spec 312, repo-level tests and code review show foundation progress, but browser-observed behavior can still drift through Livewire hydration, persisted Filament table filters, environment dashboard CTAs, query parameter naming, back/forward behavior, and hidden remembered context. Operators can see "all environments" or "no environment selected" while data remains filtered, or see an environment filter without a clear route/filter ownership contract.
- **User-visible improvement**: Before any remediation spec starts, every relevant admin surface is classified with evidence as workspace-scoped, environment-scoped, system/platform scoped, ambiguous/mixed, unreachable/dead, blocked, or out of scope. Operators and implementers get a complete risk-ranked remediation map instead of another partial page-by-page fix.
- **Smallest enterprise-capable version**: One analysis-only audit package that discovers all relevant admin surfaces from repo sources, browser-verifies representative flows for every discovered in-scope surface, captures screenshots, records query/table/filter/shell behavior, and recommends the next remediation sequence. No runtime behavior changes.
- **Explicit non-goals**: No fixes, no refactors, no route/nav/resource/page/test/migration/config/view/runtime changes, no clear-filter implementation, no shared context system implementation, no compatibility layers, no product decisions made silently, and no start of follow-up specs 314+.
- **Permanent complexity imported**: Temporary audit markdown files, screenshot artifacts, and a surface matrix under this spec directory only. No new persisted truth, enum/status family, runtime abstraction, model, table, service, route, UI component, asset bundle, test helper, or framework.
- **Why now**: The user supplied a hard completion-gate audit for systemic context drift, and `docs/product/spec-candidates.md` already treats Spec 311 as completed foundation while listing provider connection scope and canonical query/link cleanup as post-311 gaps. Spec 313 prevents unsafe remediation ordering by proving the full blast radius first.
- **Why not local**: Provider Connections, Finding Exceptions Queue, Operations, Evidence, Reviews, Customer Reviews, Governance Inbox, Decision Register, Reports, Support Requests, and environment-owned resources all interact with different state carriers. A local fix would only hide the next mismatched surface.
- **Approval class**: Core Enterprise.
- **Red flags triggered**: Many surfaces and cross-cutting state carriers. Defense: this is analysis-only and imports no runtime abstraction or behavioral complexity; the broad discovery is the narrowest safe input for later scoped remediation.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
- **Decision**: approve.

## Spec Scope Fields *(mandatory)*

- **Scope**: canonical-view/admin workspace and environment context verification across the admin panel.
- **Primary Routes**:
  - Workspace hubs: `/admin/workspaces/{workspace}/overview`, `/admin/workspaces/{workspace}/operations`, `/admin/provider-connections`, `/admin/finding-exceptions/queue`, `/admin/evidence/overview`, `/admin/reviews`, `/admin/reviews/workspace`, `/admin/governance/inbox`, `/admin/governance/decisions`, `/admin/audit-log`, `/admin/alerts`, `/admin/settings/workspace`, `/admin/workspaces`.
  - Environment routes: `/admin/workspaces/{workspace}/environments/{environment}` plus child inventory, required permissions, diagnostics, findings, finding exceptions, evidence, environment reviews, review packs, backup, restore, policies, groups, reports, and access-scope routes.
  - System routes: `/system` surfaces are classification-only unless they interact with workspace/environment state.
- **Data Ownership**: No data ownership changes. The audit must classify each observed surface against existing workspace-owned, environment-owned, tenant-owned legacy, system/platform, or ambiguous ownership.
- **RBAC**: Existing authorization remains authoritative. The audit must document when a surface is blocked by missing access, not bypass RBAC or infer behavior from hidden data.

For canonical-view specs:

- **Default filter behavior when tenant-context is active**: Workspace-scoped hubs opened through sidebar/global navigation should clear active environment shell context and should not inherit route/query/Filament tenant/remembered/persisted-table environment scope. Environment dashboard CTAs may pass environment only as an explicit visible page filter.
- **Explicit entitlement checks preventing cross-tenant leakage**: Data scope can be marked proven only when browser evidence and seeded rows show the visible rows are limited to authorized workspace/environment records. Missing rows or insufficient seed data must be marked blocked or shell-only, not guessed.

## Cross-Cutting / Shared Pattern Reuse *(mandatory)*

- **Cross-cutting feature?**: yes.
- **Interaction class(es)**: navigation entry points, sidebar/global navigation, environment dashboard cards/actions, workspace overview actions, header actions, table row actions, context bar, breadcrumbs, table filters, clear-filter actions, evidence/report viewers, operation/review/support links.
- **Systems touched**: audit reads only from `AdminPanelProvider`, `WorkspaceSidebarNavigation`, Filament pages/resources/clusters, route definitions, workspace/environment dashboard builders, link helpers, context resolvers, table filter definitions, query-string definitions, and browser-observed rendered admin pages.
- **Existing pattern(s) to extend**: none during Spec 313. The audit observes existing `OperateHubShell`, `WorkspaceContext`, `NavigationScope`, `TenantPageCategory`, `ManagedEnvironmentLinks`, `OperationRunLinks`, and table filter/session behavior.
- **Shared contract / presenter / builder / renderer to reuse**: N/A for implementation; this spec produces evidence for later contract specs.
- **Why the existing shared path is sufficient or insufficient**: Current shared paths exist but may compete. The audit must map exactly which path controls which behavior before any remediation changes them.
- **Allowed deviation and why**: No runtime deviation allowed. Browser/manual verification is allowed as analysis output.
- **Consistency impact**: Later remediation depends on this matrix to prevent parallel local context rules.
- **Review focus**: Confirm no discovered admin surface is omitted and every final row has an allowed final status.

## OperationRun UX Impact *(mandatory)*

- **Touches OperationRun start/completion/link UX?**: audit-only. It observes Operations links, OperationRun link helpers, and operation-related environment dashboard CTAs.
- **Shared OperationRun UX contract/layer reused**: existing `OperationRunLinks` and Operations pages are inspected only.
- **Delegated start/completion UX behaviors**: unchanged.
- **Local surface-owned behavior that remains**: all runtime behavior remains unchanged.
- **Queued DB-notification policy**: N/A.
- **Terminal notification path**: N/A.
- **Exception required?**: none.

## Provider Boundary / Platform Core Check *(mandatory)*

- **Shared provider/platform boundary touched?**: audit-only across provider connections, provider readiness, required permissions, and provider-related environment CTAs.
- **Boundary classification**: observed seams may be provider-owned, platform-core, or mixed; `code-ownership-map.md` must classify them.
- **Seams affected**: provider connection list/detail/create/edit routes, provider readiness, required permissions links, context query params, and target-scope semantics.
- **Neutral platform terms preserved or introduced**: workspace, managed environment, provider connection, environment filter, workspace hub, environment-owned page.
- **Provider-specific semantics retained and why**: existing Microsoft/Intune/Entra semantics are observed only and must not be generalized during audit.
- **Why this does not deepen provider coupling accidentally**: no code or runtime contract changes are made.
- **Follow-up path**: likely follow-up spec for Provider Connections scope hardening or canonical query cleanup if the audit proves drift.

## UI / Surface Guardrail Impact *(mandatory)*

| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---:|---|---|---|---:|---|
| Browser verification screenshots | no runtime change | Existing UI only | navigation, shell, filters | observed shell/page/URL/session/browser | no | Audit artifact only |
| Audit report and matrices | no runtime change | N/A | navigation, filters, links, reports | repo-observed and browser-observed state | no | Spec-local markdown only |
| Admin surfaces under audit | observed only | Existing Filament pages/resources/views | all relevant shared interaction classes | route/query/Livewire/table/session/context/breadcrumb | no | Must not modify UI |

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

N/A - Spec 313 changes no operator-facing runtime surface. It audits decision and context surfaces only.

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

N/A - no runtime surface change. The audit must still record whether customer-safe surfaces such as Customer Review Workspace hide or expose environment scope truth.

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

N/A - no runtime UI changes. The audit output files classify existing surfaces for later specs.

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

N/A - no runtime operator surface contract is changed. Spec 313 verifies whether existing surfaces honor their apparent scope contract.

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: no runtime source of truth. Audit files are temporary evidence artifacts for this spec.
- **New persisted entity/table/artifact?**: no database entity/table/artifact. Markdown reports and screenshots under `specs/313-.../` only.
- **New abstraction?**: no.
- **New enum/state/reason family?**: no runtime enum/state/reason family. The audit uses fixed final status labels for reporting only.
- **New cross-domain UI framework/taxonomy?**: no runtime framework. The audit classifies existing surfaces to prepare later specs.
- **Current operator problem**: hidden or conflicting workspace/environment context can mislead operators on critical governance, evidence, review, provider, and operations surfaces.
- **Existing structure is insufficient because**: code-level tests and previous audit findings did not fully prove browser behavior across sidebar, CTA, reload, persisted filter, and back/forward flows.
- **Narrowest correct implementation**: produce a complete evidence matrix and remediation sequence before changing runtime code.
- **Ownership cost**: temporary review burden for comprehensive audit artifacts and screenshots.
- **Alternative intentionally rejected**: start fixes immediately for high-risk pages without classifying the full surface inventory.
- **Release truth**: current-release safety audit before context remediation.

### Compatibility posture

Pre-production compatibility does not matter for Spec 313 because it changes no runtime state. Existing legacy tenant naming and route compatibility must be observed and documented, not changed.

## Summary

Spec 313 is a strict completion-gate audit for Workspace / Managed Environment context behavior in the TenantPilot admin panel.

It must produce a complete repo-discovered and browser-verified evidence package for:

- all Filament pages, resources, clusters, routes, sidebar entries, dashboard cards, header actions, table row actions, link helpers, and notification/support/report/help links that can affect workspace/environment context;
- workspace hub behavior when entered from workspace origin, environment dashboard/sidebar origin, explicit environment CTA origin, manual filter origin, reload, and browser back/forward;
- environment page behavior for shell/header/breadcrumb/filter/data-scope consistency;
- query parameter drift across `tenant`, `tenant_id`, `managed_environment_id`, `environment_id`, `tenant_scope`, and `tableFilters`;
- clear-filter completeness across visible chips, URL, Livewire state, Filament table filters, deferred filters, persisted/session state, rendered rows, and reload/sidebar revisit behavior;
- code ownership seams that later remediation specs must edit.

No page may be silently skipped. No page may finish as "likely OK".

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Complete workspace hub verification (Priority: P1)

As an MSP operator using a workspace hub, I want sidebar/global navigation to open a workspace-wide surface without hidden environment scope so I can trust that operations, evidence, reviews, provider connections, finding exceptions, governance, alerts, and audit data are not silently narrowed.

**Why this priority**: Silent environment filtering on a workspace hub is a critical governance correctness and operator-confusion risk.

**Independent Test**: For every workspace-scoped or potentially workspace-scoped hub, run workspace-origin and environment-sidebar-origin browser flows, capture screenshots, and record shell, URL, breadcrumbs, visible filters, table filters, persisted state, reload, and data-scope evidence in `page-matrix.md`.

**Acceptance Scenarios**:

1. **Given** a selected Workspace and no active Environment, **When** a workspace hub is opened from sidebar/global navigation, **Then** the report records URL, query params, shell context, breadcrumbs, visible filters, table state, data-scope proof status, and screenshot path.
2. **Given** Environment A is active through Environment Dashboard, **When** the same workspace hub is opened from sidebar/global navigation, **Then** the report records whether shell environment clears and whether hidden query/table/session filters still constrain data.
3. **Given** reload/back/forward are feasible on a high-risk hub, **When** those browser actions are performed, **Then** the report records whether stale environment scope returns.

### User Story 2 - Complete environment-owned entry-point verification (Priority: P1)

As an MSP operator drilling from an Environment Dashboard, I want explicit environment CTAs to carry visible and clearable filters when they land on workspace hubs, and I want environment-owned pages to show true environment context.

**Why this priority**: Environment CTAs are legitimate entry points, but they must not create hidden workspace-hub scope.

**Independent Test**: For each Environment Dashboard CTA/card/action and each environment-scoped route, perform browser verification, capture screenshots, record explicit filters/clear actions, and classify final status.

**Acceptance Scenarios**:

1. **Given** Environment A is open, **When** a CTA opens a workspace hub, **Then** the matrix records whether the environment filter is visible, URL/query/table state is understandable, data appears filtered, and clear-filter exists.
2. **Given** clear-filter exists, **When** it is used and the page is reloaded, **Then** the matrix records whether visible chip, URL, Livewire property, table filter, deferred filters, persisted/session state, rows, breadcrumb/header, and shell context are cleared.
3. **Given** an environment-owned route is opened, **When** the page renders, **Then** shell/header/breadcrumbs clearly show the Environment or the surface is blocked/unreachable with evidence.

### User Story 3 - Complete repo inventory and code ownership map (Priority: P1)

As an implementer preparing remediation specs 314+, I want a repo-derived inventory of every relevant surface and likely code seam so follow-up specs can edit the correct owners in the right order.

**Why this priority**: Without a complete inventory, remediation can fix only obvious pages while leaving hidden CTAs, row links, resources, or persisted table state broken.

**Independent Test**: Run repo discovery against the mandatory sources and search terms, populate `surface-inventory.md`, `query-param-inventory.md`, `clear-filter-inventory.md`, and `code-ownership-map.md`, then reconcile them against browser-observed pages.

**Acceptance Scenarios**:

1. **Given** a surface appears in Filament navigation, routes, pages, resources, clusters, dashboard builders, header actions, row actions, link helpers, notifications, support links, report links, or help links, **When** the audit completes, **Then** it appears in `surface-inventory.md` with an allowed final status.
2. **Given** a query parameter or persisted filter affects environment context, **When** it is discovered, **Then** `query-param-inventory.md` records identifier type, visibility, clearability, persistence, conflicts, and pages using it.
3. **Given** a likely owner seam controls observed behavior, **When** the audit maps it, **Then** `code-ownership-map.md` names the file/class/method/view, affected pages, risk, and notes.

### User Story 4 - Risk-ranked remediation sequence (Priority: P2)

As a technical lead planning fixes, I want the final audit report to rank risks and recommend follow-up specs so the next work starts with the highest-impact contract and avoids broad runtime changes.

**Why this priority**: The expected follow-up order is likely 314 to 318, but the order must be adjusted if browser evidence shows a different dependency.

**Independent Test**: Review `audit-report.md` and confirm it contains executive summary, counts, mismatch findings, clear-filter findings, query parameter findings, persisted filter findings, code ownership summary, risk ranking, open questions, exact commands, and recommended follow-up specs.

**Acceptance Scenarios**:

1. **Given** all matrices are populated, **When** the final report is written, **Then** it states whether the issue is isolated, page-specific drift, or systemic context contract drift.
2. **Given** high-risk pages are verified, **When** risk ranking is produced, **Then** Provider Connections, Finding Exceptions Queue, Operations, Evidence, Reviews, Customer Reviews, Governance Inbox, Decision Register, Audit Log, Reports, and Support Requests are each explicitly classified or blocked.
3. **Given** follow-up specs are recommended, **When** the report is complete, **Then** it names the next remediation spec and explains why.

## Functional Requirements

- **FR-001**: The audit MUST discover admin surfaces from repo sources, not only from the visible sidebar.
- **FR-002**: The audit MUST include every surface discovered from Filament navigation, `AdminPanelProvider`, Filament Page classes, Filament Resource classes, Filament Clusters, route definitions, workspace sidebar builder, workspace overview cards/actions, environment dashboard cards/actions, page header actions, table row actions, operation/review/evidence/support/report link helpers, contextual help/product knowledge links, notifications, and support/action links.
- **FR-003**: Every discovered surface MUST have exactly one final status from the allowed final status list.
- **FR-004**: The allowed final statuses are `verified_workspace_scoped_hub`, `verified_environment_scoped_page`, `verified_system_or_platform_scoped_page`, `verified_ambiguous_or_mixed`, `verified_unreachable`, `verified_legacy_or_dead_surface_candidate`, `blocked_missing_seed_data`, `blocked_browser_or_tooling_limitation`, and `out_of_scope_with_reason`.
- **FR-005**: The final report MUST NOT use "likely OK" as a final status.
- **FR-006**: Workspace hubs MUST be verified from workspace origin and environment-sidebar origin.
- **FR-007**: High-risk workspace hubs MUST be verified from environment CTA origin when such CTAs exist.
- **FR-008**: Environment-scoped pages MUST be verified for shell/header/breadcrumb correctness where browser access is possible.
- **FR-009**: Pages with environment-like filtering MUST be verified for URL query params, visible chips, Filament table filters, persisted/session state, reload behavior, and clear-filter behavior where applicable.
- **FR-010**: High-risk pages MUST be verified for browser back/forward behavior where feasible.
- **FR-011**: Data scope MUST be marked proven only when browser-visible seeded rows or equivalent UI evidence prove the scope.
- **FR-012**: Missing seed data MUST be documented as `blocked_missing_seed_data` or as a clearly marked shell-only browser observation that still maps to an allowed final status.
- **FR-013**: Browser/tooling limitations MUST be documented as `blocked_browser_or_tooling_limitation`, not inferred.
- **FR-014**: The audit MUST create the required report files under `specs/313-workspace-environment-context-browser-verification/`.
- **FR-015**: Screenshot filenames MUST use stable names and each screenshot referenced in `page-matrix.md` MUST exist.
- **FR-016**: The audit MUST record exact commands run, browser tooling used, tests run or not run, failures, and screenshot count.
- **FR-017**: The audit MUST make no application runtime changes and MUST not modify tests, migrations, routes, Filament pages/resources/components, config, seeders, or production code.
- **FR-018**: The audit MUST recommend a remediation sequence and the next spec to start.

## In Scope Surfaces

### Workspace-scoped or potentially workspace-scoped pages

Workspace Overview, Operations, Alerts, Audit Log, Governance Inbox, Decision Register, Finding Exceptions Queue, Risk Exceptions, Reviews, Customer Reviews / Customer Review Workspace, Evidence Overview, Reports, Stored Reports, Provider Connections, Integrations, Support Requests, Workspace Settings, Manage Workspaces, Product Knowledge / Help if visible, Operational Controls if visible, Customer Health if visible, Notification Routing if visible, Provider Health if workspace-level, Permission Posture if workspace-level, Entra Admin Roles if workspace-level, Review Packs / Exports if visible, and any other workspace-level hub discovered.

### Environment-scoped pages

Environment Dashboard / Environment Governance Overview, Environment Onboarding, Provider Readiness / Onboarding Readiness, Required Permissions, Permission Posture if environment-owned, Entra Admin Roles if environment-owned, Environment Diagnostics, Inventory, Inventory Coverage, Directory / Groups if environment-bound, Policies / Configurations, Backup Schedules, Backup Sets, Restore Runs, Restore Points, Baseline Profiles if environment-owned, Baseline Snapshots, Baseline Compare, Drift Findings, Findings, Evidence related to current Environment if exposed locally, Recent Operations card/links from Environment Dashboard, and any other environment-level page discovered.

### System / platform scoped pages

System panel pages, local platform user pages, platform settings, global app health, system-level audit/ops if present, billing/admin-only system pages if not workspace-bound. These are classification-only unless they interact with workspace/environment context.

## Required Output Files

The later Spec 313 audit implementation MUST create:

```text
specs/313-workspace-environment-context-browser-verification/audit-report.md
specs/313-workspace-environment-context-browser-verification/surface-inventory.md
specs/313-workspace-environment-context-browser-verification/page-matrix.md
specs/313-workspace-environment-context-browser-verification/query-param-inventory.md
specs/313-workspace-environment-context-browser-verification/clear-filter-inventory.md
specs/313-workspace-environment-context-browser-verification/code-ownership-map.md
specs/313-workspace-environment-context-browser-verification/artifacts/screenshots/
```

This preparation step creates only `spec.md`, `plan.md`, `tasks.md`, and the requirements checklist. It does not perform the audit.

## Required Report Structure

`audit-report.md` MUST include:

1. Executive Summary
2. Verified Surface Inventory Summary
3. Workspace Hub Behavior Matrix Summary
4. Environment Page Behavior Matrix Summary
5. Mismatched Scope Findings
6. Clear-Filter Findings
7. Query Parameter Findings
8. Persisted Filter Findings
9. Code Ownership Map Summary
10. Risk Ranking
11. Recommended Follow-Up Specs
12. Open Questions
13. Test / Browser Execution

`surface-inventory.md`, `page-matrix.md`, `query-param-inventory.md`, `clear-filter-inventory.md`, and `code-ownership-map.md` MUST use the columns described in `plan.md`.

## High-Risk Pages To Verify Thoroughly

- Provider Connections / Integrations
- Finding Exceptions Queue
- Operations
- Evidence Overview
- Reviews / Review Register
- Customer Reviews / Customer Review Workspace
- Governance Inbox
- Decision Register
- Reports / Stored Reports
- Support Requests
- Audit Log
- Alerts

## Non-Functional Requirements

- **NFR-001**: Runtime behavior must remain unchanged.
- **NFR-002**: Browser verification must be evidence-backed with screenshots and exact notes.
- **NFR-003**: The audit must distinguish repo-verified, browser-observed, inferred from code, blocked due to missing data, blocked due to tooling, unresolved/ambiguous, and out of scope.
- **NFR-004**: The audit must prefer Sail/local project conventions and use local smoke login or seeded/demo data only where already supported.
- **NFR-005**: The audit must not fabricate data-scope proof.
- **NFR-006**: Screenshots must be stable, reviewable artifacts under the spec folder.
- **NFR-007**: Browser verification must not bypass normal access control; blocked access is valid evidence.

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

- **Test purpose / classification**: Browser audit and repo documentation audit. No runtime tests are required by this preparation package.
- **Validation lane(s)**: browser/manual verification during audit implementation; preparation validation uses docs/spec checks only.
- **Why this classification and these lanes are sufficient**: Spec 313 is itself a browser verification audit, not a runtime feature. The actual value is screenshots, matrix rows, and code ownership evidence.
- **New or expanded test families**: none in preparation. Later Spec 318 may add browser regression coverage.
- **Fixture / helper cost impact**: no new fixtures in preparation. Audit implementation may be blocked by missing seeded data and must document that instead of changing seeders.
- **Heavy-family visibility / justification**: browser verification is explicit and central to the audit, not accidental test-suite expansion.
- **Special surface test profile**: global-context-shell, monitoring-state-page, shared-detail-family, and exception-coded-surface as observed profiles.
- **Standard-native relief or required special coverage**: no runtime UI change; browser coverage is required for evidence, not styling verification.
- **Reviewer handoff**: reviewers must confirm no runtime files changed and every discovered surface has one allowed final status.
- **Budget / baseline / trend impact**: none.
- **Escalation needed**: follow-up-spec for remediation; no runtime escalation inside Spec 313.
- **Active feature PR close-out entry**: `Spec 313 Audit Evidence / No Runtime Changes`.
- **Planned validation commands**:
  - `git status --short --branch`
  - `git diff --name-only`
  - `git diff --check`
  - repo discovery commands listed in `tasks.md`
  - browser verification flows listed in `tasks.md`

## Acceptance Criteria

### Surface Discovery

- [ ] All Filament pages are discovered and listed.
- [ ] All Filament resources are discovered and listed.
- [ ] All Filament clusters are discovered and listed.
- [ ] All AdminPanelProvider navigation registrations are inspected.
- [ ] All workspace sidebar entries are listed.
- [ ] All relevant admin routes are listed.
- [ ] All Workspace Overview cards/actions are mapped.
- [ ] All Environment Dashboard cards/actions are mapped.
- [ ] All relevant header actions are mapped.
- [ ] All relevant table row actions are mapped.
- [ ] All operation/review/evidence/support/report link helpers are inspected.
- [ ] Every discovered surface has a final status.

### Browser Verification

- [ ] Every workspace-scoped hub is browser-verified from Workspace origin.
- [ ] Every workspace-scoped hub is browser-verified from Environment Dashboard via sidebar.
- [ ] Every high-risk workspace hub is browser-verified from Environment CTA origin where CTA exists.
- [ ] Every environment-scoped page is browser-verified for shell/header/breadcrumb correctness.
- [ ] Every page with environment-like filtering is verified for query params.
- [ ] Every page with environment-like filtering is verified for Filament table filters.
- [ ] Every page with environment-like filtering is verified for persisted filter behavior.
- [ ] Every page with clear-filter is verified for clear behavior.
- [ ] Every high-risk page is verified for reload behavior.
- [ ] Every high-risk page is verified for browser back/forward behavior where feasible.

### Completeness

- [ ] No page is silently skipped.
- [ ] No page remains "likely OK".
- [ ] Reports / Stored Reports are classified.
- [ ] Support Requests are classified.
- [ ] Workspace Settings are classified.
- [ ] Alerts are classified.
- [ ] Provider Connections are fully verified.
- [ ] Finding Exceptions Queue is fully verified.
- [ ] Evidence is fully verified.
- [ ] Reviews and Customer Reviews are fully verified.
- [ ] Operations are fully verified.
- [ ] Governance Inbox and Decision Register are verified as reference candidates or documented otherwise.

### Evidence

- [ ] Screenshots exist for every verified browser flow.
- [ ] Screenshot filenames are stable and referenced in the matrix.
- [ ] Missing seed data is documented as blocker, not guessed.
- [ ] Browser/tooling limitations are documented as blocker, not guessed.
- [ ] Data scope is only marked proven when seeded rows make it provable.

### Reporting

- [ ] `audit-report.md` exists.
- [ ] `surface-inventory.md` exists.
- [ ] `page-matrix.md` exists.
- [ ] `query-param-inventory.md` exists.
- [ ] `clear-filter-inventory.md` exists.
- [ ] `code-ownership-map.md` exists.
- [ ] Final remediation sequence is recommended.
- [ ] Tests/browser commands are reported exactly.

### Safety

- [ ] No runtime files changed.
- [ ] No tests changed.
- [ ] No migrations changed.
- [ ] No seeders changed.
- [ ] No commits created unless explicitly requested.
- [ ] No destructive git commands executed.

## Risks

- Browser verification may be blocked by missing local seed data for some surfaces.
- Browser SPA/Livewire behavior can vary from code assumptions; this is the reason for the audit and must be documented exactly.
- Some routes may be capability-gated or unreachable for the available local actor.
- Broad discovery can produce many low-risk pages; the final report must keep risk ranking clear and avoid burying critical findings.
- Existing terminology still mixes tenant and managed environment in code/query params. The audit must observe this without renaming anything.

## Assumptions

- Spec 311 and Spec 312 are completed context, not targets to rewrite.
- Local browser verification can use existing local smoke-login and seeded/demo data where available.
- If data is missing, the audit may still verify shell/URL/filter behavior but must not mark data scope proven.
- Follow-up specs 314+ will implement fixes separately.
- `docs/product/roadmap.md` still contains a historical recommendation that Decision-Based Governance Inbox v1 could become Spec 313. The user directly supplied this Spec 313 audit package, so this preparation keeps the explicit user-provided 313 target and does not edit product roadmap docs inside this preparation-only scope.

## Open Questions

- Which local fixture command or seed state provides the broadest two-environment workspace with rows for every high-risk page?
- Are Support Requests and Product Knowledge visible to the default local actor, or do they require system/support capabilities?
- Are Reports / Stored Reports reachable from sidebar, environment dashboard, review/evidence links, or only environment resource routes?
- Should shell-only browser observations map to `blocked_missing_seed_data` or `verified_ambiguous_or_mixed` when the surface is otherwise reachable but row scope cannot be proven? The audit must document the chosen mapping consistently.

## Expected Follow-Up Specs

The audit should recommend the exact order. The likely starting sequence is:

1. `314 - Workspace Hub Navigation Context Contract`
2. `315 - Environment CTA Explicit Filter Contract`
3. `316 - Workspace Hub Clear Filter Contract`
4. `317 - Legacy Tenant / Environment Context Cleanup`
5. `318 - Browser Regression Coverage / No-Drift Guard`

The final report may reorder these if browser evidence proves a different dependency.

## Filament v5 Output Contract

1. **Livewire v4.0+ compliance**: This app uses Livewire v4.1.4 with Filament v5.2.1. Spec 313 performs browser/Livewire behavior observation only and must not introduce Livewire v3 references.
2. **Provider registration**: No panel provider registration changes. Laravel 12 panel providers remain registered in `apps/platform/bootstrap/providers.php`.
3. **Global search**: No resource global search behavior changes. The audit must classify globally searchable resources if discovered, but no search settings are modified.
4. **Destructive actions**: No destructive actions are added or changed. Existing destructive actions are observed only where they affect page context or navigation.
5. **Assets**: No assets are added or changed. Existing Filament asset deployment posture remains unchanged; `cd apps/platform && php artisan filament:assets` is not newly required by Spec 313.
6. **Testing plan**: Spec 313 requires browser verification and repo-discovery validation, not Pest implementation tests. Future Spec 318 may add automated browser regression coverage.