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:

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.