TenantAtlas/specs/376-browser-audit-fixture-coverage-evidence-system-surfaces/spec.md

Feature Specification: Browser Audit Fixture Coverage for Evidence/System Surfaces v1

Feature Branch: 376-browser-audit-fixture-coverage-evidence-system-surfaces Created: 2026-06-13 Status: Draft Input: User-provided Spec 376 candidate, Spec 368 browser audit findings, completed Spec 353/372 browser evidence, Spec 375 follow-up recommendation, current repo route/auth/test fixtures.

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

• Problem: Spec 368 could not browser-audit critical Evidence, Required Permissions, Provider Connection detail, and System panel surfaces because auth, scope, data, or screenshot fixtures were missing or unstable. Later specs proved parts of the admin-plane surface set, but no single Spec 376 evidence package records current route/auth/data/browser truth for all five surfaces, and system-panel browser proof remains a separate platform-auth gap.
• Today's failure: The product can claim these surfaces are repo-real, but a reviewer cannot reproducibly prove the full five-surface set in a browser without manually stitching together Spec 353/372 evidence, auth state, workspace/environment IDs, platform-user state, and fixture data.
• User-visible improvement: Maintainers and future audit agents can open the scoped surfaces through safe local/testing fixtures, capture screenshots, and classify any remaining block as auth-, data-, route-, scope-, or timeout-blocked with exact evidence.
• Smallest enterprise-capable version: A narrow browser fixture coverage slice for five surfaces: Evidence Snapshot View, Required Permissions, System Dashboard, System Operations, and Provider Connection Detail. Each surface is classified from current repo truth, then either fixture-backed and screenshot-captured in this package or documented with exact existing evidence, blocker, and follow-up.
• Explicit non-goals: No Evidence UI redesign, Required Permissions redesign, System panel redesign, Provider Connection UX refactor, production login backdoor, new product feature, migration, new product source of truth, RBAC weakening, or final platform-wide re-audit.
• Permanent complexity imported: Potentially one local/testing-only system smoke login path or fixture resolver only if existing Browser actingAs(..., 'platform') patterns are insufficient, fixture configuration entries, focused Feature/Browser tests, and spec-local audit artifacts. No new product table, product enum/status family, or reusable UI framework is approved by this spec.
• Why now: Specs 368-375 deliberately productized and guarded UI surfaces, but Spec 368 left a browser-proof gap for critical evidence/system/permission surfaces. Spec 375 explicitly deferred this candidate as the next fixture/auditability follow-up.
• Why not local: Manual browser login and ID lookup do not produce repeatable evidence, do not prove production safety of fixture routes, and cannot support future close-out audits.
• Approval class: Core Enterprise.
• Red flags triggered: New fixture/support path and multiple surfaces. Defense: all work is local/testing-only or test-owned, uses existing smoke-login/browser fixture patterns where possible, creates no product truth, and keeps UI/product behavior unchanged.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve as a narrow browser-fixture coverage and auditability slice.

Candidate Selection And Completed-Spec Guardrail

• Selected candidate: Browser Audit Fixture Coverage for Evidence/System Surfaces v1.
• Source: User-provided Spec 376 attachment, Spec 368 findings.md / audit.md / page-scorecard.csv, Spec 353 provider readiness browser coverage, Spec 372 Evidence Snapshot browser coverage, and Spec 375 follow-up recommendations.
• Roadmap relationship: Supports the current UI/product maturity and auditability lane by closing browser-proof gaps after Specs 368-375.
• Related completed specs:
  • Spec 368 is a completed browser audit input with blocked-page evidence; it is not modified.
  • Specs 370-374 are completed UI IA/productization/safety/diagnostic inputs; they are read-only context.
  • Spec 375 implemented or prepared the UI bloat guard and explicitly listed this fixture coverage candidate as deferred follow-up; it is not modified.
• Guardrail result: No existing spec package covers this exact consolidated five-surface fixture/evidence slice. Completed specs are current repo truth and context only; they must not be rewritten, normalized, reopened, or stripped of implementation history.
• Close alternatives deferred:
  • Full post-productization browser re-audit and closeout gate.
  • Provider Connections readiness redesign.
  • Evidence Snapshot customer/auditor productization.
  • System panel productization or ops workflow redesign.
  • Browser scorecard integration into guard output.
• Smallest viable slice: Build or document safe local/testing fixture access for the five in-scope surfaces, then produce route/auth/data/screenshot evidence and a validation report.

Spec Scope Fields (mandatory)

• Scope: canonical-view / browser-fixture auditability.
• Primary Routes:
  • Evidence Snapshot View: EvidenceSnapshotResource::getUrl('view', ...), currently slugged under environment-scoped evidence/{record}.
  • Required Permissions: /admin/workspaces/{workspace}/environments/{environment}/required-permissions.
  • System Dashboard: /system.
  • System Operations: /system/ops/runs.
  • Provider Connection Detail: ProviderConnectionResource::getUrl('view', ...), currently provider-connections/{record} with workspace-hub authority and explicit environment_id/record-derived managed-environment authority.
• Data Ownership: Fixture data remains local/testing-only. Evidence snapshots are tenant-owned records requiring workspace and managed-environment entitlement. Provider connections are workspace-owned records with managed-environment authority for record actions and explicit environment context for scoped URLs. System panel actors are platform-plane PlatformUser records.
• RBAC: Admin surfaces require authenticated User membership plus the relevant capability. System surfaces require authenticated PlatformUser, platform guard, platform.access_system_panel, and any page-specific platform capability.

For canonical-view specs:

• Default filter behavior when tenant-context is active: Admin fixture URLs must establish workspace context and remembered environment context explicitly. They must not rely on arbitrary stale session state.
• Explicit entitlement checks preventing cross-tenant leakage: Fixture route/resolver work must use existing scoped resolvers, factories, policies, and capabilities. Non-member records remain 404/deny-as-not-found; member-without-capability remains 403 where the existing policy model says so.

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
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

No new route was needed during implementation. Browser coverage reuses the existing local/testing admin smoke-login route and Pest Browser platform-guard session support. The in-scope product pages already exist and were not redesigned or materially changed by this spec.

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

• Route/page/surface: No new route. Browser-audit coverage applies to Evidence Snapshot View, Required Permissions, System Dashboard, System Operations, and Provider Connection Detail through existing test/session fixtures.
• Current or new page archetype:
  • Evidence Snapshot View: History / Audit Surface, Tertiary Evidence / Diagnostics.
  • Required Permissions: Utility / System diagnostic surface, Secondary Context.
  • System Dashboard and System Operations: Utility / System, platform-admin surfaces.
  • Provider Connection Detail: Record / Detail / Edit, configuration/readiness surface.
  • Smoke auth/fixture route: test/tooling route, not product UI.
• Design depth: Existing product pages are Manual Review Required only for browser reachability proof; no design refactor in scope.
• Repo-truth level: repo-verified routes/classes; Spec 353, Spec 372, and Spec 283 already provide browser evidence for several admin-plane surfaces, while system-plane surfaces and any missing consolidated screenshots remain to be proven or documented by this spec.
• Existing pattern reused: /admin/local/smoke-login, direct Pest Browser actingAs()/workspace-session harnesses, SeedReviewOutputBrowserFixture, Spec 353 provider readiness browser smoke, Spec 372 Evidence Snapshot browser smoke, Spec 276 system-panel browser actingAs(..., 'platform') pattern, Pest Browser visit(), existing Feature tests for admin smoke login, system panel auth, EvidenceSnapshotResource, Required Permissions, and ProviderConnectionResource.
• New pattern required: None for production UI and none implemented. A local/testing-only system smoke fixture may be added only in a future spec if existing system browser auth patterns are insufficient and the new route preserves platform guard separation, environment gating, and redirect safety.
• Screenshot required: yes for every in-scope surface that is reachable; blocked screenshots or blocker notes are required when not reachable.
• Page audit required: no redesign audit in this spec; the browser verification report and screenshot index are required.
• Customer-safe review required: Evidence surfaces are audit/evidence-sensitive, but this spec does not change default customer/auditor content.
• Dangerous-action review required: no new destructive product action is allowed. If fixture routes authenticate users, production-safety and redirect validation are mandatory.
• Coverage files updated or explicitly not needed:
  • 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 production product UI surface material change
• No-impact rationale when applicable: Product pages, panel navigation, product actions, product tables, forms, and rendered business copy are not changed. Fixture/audit artifacts live under this spec package unless implementation proves a durable UI audit registry update is required.

Cross-Cutting / Shared Pattern Reuse

• Cross-cutting feature?: yes, as browser fixture infrastructure and audit evidence across admin and system planes.
• Interaction class(es): auth/session fixture, browser smoke, evidence/report viewer reachability, system panel reachability.
• Systems touched: existing local smoke login route, fixture seed commands/config, Pest Browser tests, system panel auth, scoped route helpers.
• Existing pattern(s) to extend: existing admin smoke login, direct Browser actingAs()/workspace-session harnesses, review-output browser fixture patterns, Spec 353/372 admin browser coverage, existing system panel browser actingAs(..., 'platform'), system panel auth tests, and platform user capability model.
• Shared contract / presenter / builder / renderer to reuse: N/A for UI rendering. Reuse existing scoped URL helpers and auth/session middleware rather than inventing a product UI layer.
• Why the existing shared path is sufficient or insufficient: Admin smoke login and direct browser session fixtures now cover several admin-plane paths in completed follow-up specs, but the evidence is spread across packages. System panel has auth tests and browser smokes using actingAs(..., 'platform'); a separate smoke-login route is not justified unless those repo-native patterns cannot produce the required Spec 376 browser evidence.
• Allowed deviation and why: A system-specific local/testing smoke fixture is allowed only as a last resort when existing browser auth patterns are insufficient, and only if it preserves platform guard separation and production 404 behavior.
• Consistency impact: Auth fixtures must never become production access paths or alternate RBAC semantics.
• Review focus: Verify no production auth weakening, no arbitrary redirects, no shared tenant/platform identity shortcut, and no UI redesign slipped into fixture work.

OperationRun UX Impact

• Touches OperationRun start/completion/link UX?: no. It may open existing OperationRun/System Operations pages but must not create, queue, deduplicate, resume, block, complete, or change OperationRun UX.
• Shared OperationRun UX contract/layer reused: N/A.
• Delegated start/completion UX behaviors: N/A.
• Local surface-owned behavior that remains: browser verification only.
• Queued DB-notification policy: N/A.
• Terminal notification path: N/A.
• Exception required?: none.

Provider Boundary / Platform Core Check

• Shared provider/platform boundary touched?: yes, narrowly for Provider Connection detail fixture reachability and Required Permissions URLs.
• Boundary classification: mixed; provider-owned records remain provider-specific, while workspace/environment scope and auth fixture behavior are platform-core safety boundaries.
• Seams affected: ProviderConnectionResource view URL, RequiredPermissionsLinks, provider connection fixture selection, managed-environment scope.
• Neutral platform terms preserved or introduced: workspace, managed environment, provider connection, platform user, system panel.
• Provider-specific semantics retained and why: Microsoft permission/consent semantics remain in the existing Required Permissions surface; this spec only makes the page auditable.
• Why this does not deepen provider coupling accidentally: The fixture resolver must select existing provider records and URLs; it must not add a new provider framework, provider taxonomy, or Graph endpoint behavior.
• Follow-up path: Provider readiness or Required Permissions UX issues discovered during browser capture become follow-up recommendations, not in-scope refactors.

UI / Surface Guardrail Impact

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Local/testing smoke auth or fixture route	no production product surface change	N/A	auth fixture	session, route	no, if local/testing-only	test/tooling route only
Evidence Snapshot browser fixture	no rendered page change	Native Filament resource view	evidence viewer	route, auth, scope, data	no	browser reachability proof only
Required Permissions browser fixture	no rendered page change	Native Filament page/table	diagnostics/permissions	route, auth, scope, data	no	browser reachability proof only
System Dashboard/Ops browser fixture	no rendered page change	Native Filament system pages	system plane	route, auth guard, session	no	platform-auth proof only
Provider Connection Detail browser fixture	no rendered page change	Native Filament resource view	provider readiness/config	route, auth, scope, data	no	screenshot stability proof only

Decision-First Surface Role

No product surface is added or materially changed. The existing surfaces are classified only so browser coverage evidence is interpreted correctly:

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
Evidence Snapshot View	Tertiary Evidence / Diagnostics	Verify evidence backing a review/finding/report	Snapshot identity, status, scope, evidence basis	Raw payloads, related items, operation context	Not primary; supports proof and audit	Evidence verification	Removes manual ID hunting
Required Permissions	Secondary Context Surface	Decide what permission/readiness gap blocks provider-backed work	Missing/present permission status and guidance	Permission detail and admin consent links	Not primary; supports diagnostics	Provider readiness check	Makes blocked readiness inspectable
System Dashboard	Secondary Context Surface	Platform admin checks system health	System health and key platform status	Support diagnostics and raw ops context	System utility surface	Platform support workflow	Enables separate system audit path
System Operations	Tertiary Evidence / Diagnostics	Platform admin inspects system runs	Run list/status and filters	Run detail, logs, diagnostics	Audit/support evidence	Platform operations review	Proves system ops route separately
Provider Connection Detail	Secondary Context Surface	Operator/support checks provider readiness	Connection status, capability/readiness	Credentials/technical detail where authorized	Detail/config surface	Provider readiness	Stabilizes screenshot capture

Audience-Aware Disclosure

No rendered disclosure hierarchy is changed. Browser reports must still record whether any in-scope surface exposes unexpected raw/support detail by default, but implementation must not fix those issues inside this spec unless a blocker is caused by fixture-only code.

UI/UX Surface Classification

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
Evidence Snapshot View	Record / Detail / Edit	History / Audit Surface	Verify evidence snapshot	Dedicated detail page	N/A	Related links/actions only	None expected	evidence list	evidence detail	Workspace + environment	Evidence Snapshot	Snapshot status, scope, evidence basis	none
Required Permissions	Utility / System	Diagnostic Surface	Review missing permissions	Page table/matrix	N/A	Body guidance/reset	No destructive action in scope	N/A	required permissions page	Workspace + environment	Required Permissions	Permission status and guidance	none
System Dashboard	Utility / System	Platform Support Surface	Inspect system health	Dedicated system page	N/A	System nav/actions	Existing system actions only	/system	/system	System plane	System Dashboard	Platform health/status	none
System Operations	Utility / System	Monitoring / Queue / Workbench	Inspect runs	List/detail navigation	Existing page behavior	Existing system nav/actions	Existing system actions only	/system/ops/runs	/system/ops/runs/{run}	System plane	System Operations	Run state and filters	none
Provider Connection Detail	Record / Detail / Edit	Config-lite / configuration detail	Check readiness	Clickable row to detail	existing list behavior	More/detail header	Existing dangerous actions remain unchanged	provider connections list	provider connection view	Workspace + optional environment filter	Provider Connection	Readiness/capability state	none

Operator Surface Contract

No new operator product page is added. The implementation must produce evidence that each existing in-scope surface can be opened or is explicitly blocked, with no requirement to change default-visible content.

Proportionality Review

• New source of truth?: no product source of truth.
• New persisted entity/table/artifact?: no database table or product artifact. Spec-local Markdown reports and screenshots are implementation evidence only.
• New abstraction?: possibly, a narrow local/testing fixture resolver or config path if existing fixture commands cannot cover the surfaces.
• New enum/state/reason family?: no product status family. Verification labels are report classifications only.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Critical surfaces cannot be proven in browser audits without manual auth/data discovery, leaving false confidence gaps in evidence and system-plane readiness.
• Existing structure is insufficient because: Existing evidence is split across Spec 353, Spec 372, Spec 368, and route/auth tests; system panel auth remains separate and lacks a consolidated browser-audit fixture or procedure for this five-surface close-out slice.
• Narrowest correct implementation: Reuse existing fixtures first, add only local/testing-only fixture glue where necessary, and record exact blockers where not safely solvable.
• Ownership cost: Focused fixture tests, browser smoke upkeep, spec-local screenshot/report artifacts, and review of any local/testing route safety.
• Alternative intentionally rejected: Full UI redesign or final browser re-audit is too broad; manual-only browser notes do not create reproducible proof; production-accessible smoke login is forbidden.
• Release truth: Current-release truth; this is an auditability and safety proof gap now blocking a credible close-out browser audit.

Compatibility posture

This feature assumes a pre-production environment. No legacy aliases, migration shims, production backfills, or compatibility-specific paths are needed. Any fixture route must be unavailable outside local and testing; any fixture command must fail closed outside approved environments.

Testing / Lane / Runtime Impact

• Test purpose / classification: Feature tests for route/auth fixture safety, Browser tests/smoke for reachability and screenshot capture, targeted existing Feature tests for Evidence/Required Permissions/Provider/System behavior.
• Validation lane(s): fast-feedback/confidence for Feature tests; browser lane for Pest Browser smoke; git diff --check; Pint only if PHP changes.
• Why this classification and these lanes are sufficient: The change is about HTTP/session/auth reachability and real browser proof, not domain calculation. Browser assertions must include assertNoJavaScriptErrors() and assertNoConsoleLogs() where pages are reachable.
• New or expanded test families: One bounded Spec 376 browser fixture coverage family; possibly one focused Feature test family for system smoke-login safety if a system local/testing route is added.
• Fixture / helper cost impact: Workspace, environment, membership/capability, evidence snapshot, provider connection, and platform-user fixtures may be required, but must stay explicit and opt-in.
• Heavy-family visibility / justification: Browser coverage is explicit because this spec exists to close browser-audit gaps. It must not silently broaden generic smoke coverage.
• Special surface test profile: browser-fixture-coverage / system-auth-boundary.
• Standard-native relief or required special coverage: No UI component contract tests are required unless fixture implementation changes rendered UI, which is out of scope.
• Reviewer handoff: Confirm local/testing-only route guards where routes are added, command environment fail-closed behavior where commands are added or changed, safe redirect validation, platform/admin guard separation, workspace/environment entitlement, no production data dependency, and screenshot/report completeness.
• Budget / baseline / trend impact: One bounded browser smoke family may add browser-lane cost; record runtime in artifacts/validation-report.md.
• Escalation needed: document-in-feature. Escalate to follow-up-spec only if system auth fixture work requires a broader platform support-access decision.
• Active feature PR close-out entry: Smoke Coverage / Fixture Coverage.
• Planned validation commands:
  • git diff --check
  • cd apps/platform && ./vendor/bin/pint --dirty if PHP files change
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=AdminLocalSmokeLogin
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=SystemPanel
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=EvidenceSnapshot
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=RequiredPermissions
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProviderConnection
  • targeted Pest Browser command for the Spec 376 fixture coverage test, if added.

User Scenarios & Testing (mandatory)

User Story 1 - Evidence And Permission Surfaces Are Browser-Auditable (Priority: P1)

As a maintainer preparing a productization close-out audit, I want fixture-backed browser URLs for Evidence Snapshot View and Required Permissions so that evidence/permission surfaces are not merely repo-verified.

Why this priority: Spec 368 marked both surfaces P1 because they redirected to admin login in the available smoke context.

Independent Test: Generate or resolve a local/testing workspace, environment, admin user, evidence snapshot, and provider readiness context; visit both URLs through the smoke fixture and capture screenshots or exact blockers.

Acceptance Scenarios:

1. Given a local/testing fixture with workspace/environment membership and evidence view capability, When the browser opens the Evidence Snapshot View, Then the page renders without redirecting to /admin/login, a screenshot is stored, and route/auth/data inputs are documented.
2. Given a local/testing fixture with workspace/environment membership and provider readiness data, When the browser opens Required Permissions, Then the page renders without redirecting to /admin/login, a screenshot is stored, and the fixture context is documented.
3. Given a surface cannot be reached safely, When the browser attempt is recorded, Then the report classifies the exact blocker as auth-, scope-, data-, route-, or timeout-blocked and names the follow-up.

User Story 2 - System Panel Surfaces Are Browser-Auditable Without Weakening Auth (Priority: P1)

As a platform maintainer, I want system dashboard and system operations browser coverage to use platform-plane auth only, so system panel screenshots prove the separate /system surface without creating a tenant-user shortcut.

Why this priority: Spec 368 could not score the system panel because /system and /system/ops/runs redirected to /system/login.

Independent Test: Create or reuse a local/testing platform user fixture with platform.access_system_panel, authenticate through a safe fixture path or documented test harness, and visit /system plus /system/ops/runs.

Acceptance Scenarios:

1. Given a local/testing platform user with required capabilities, When the browser opens /system, Then the dashboard renders without using the admin web guard and a screenshot is stored.
2. Given a local/testing platform user with required capabilities, When the browser opens /system/ops/runs, Then system operations renders or shows a meaningful empty state and a screenshot is stored.
3. Given the same fixture route is requested outside local or testing, When the route is invoked, Then it returns not found and does not authenticate any user.

User Story 3 - Provider Connection Detail Has Stable Browser Evidence (Priority: P2)

As a maintainer reviewing provider readiness, I want Provider Connection Detail to open and capture reliably so that timeouts are separated from real UI defects.

Why this priority: Spec 368 browser-audited the provider connections list but the detail screenshot attempt timed out.

Independent Test: Resolve or create a local/testing provider connection fixture, open its detail page through scoped admin auth, and capture either the detail screenshot or exact timeout/blocker evidence.

Acceptance Scenarios:

1. Given a valid local/testing provider connection and authorized user, When the browser opens the detail URL, Then the page screenshot is captured and route/auth/data inputs are documented.
2. Given the page still times out, When the browser attempt finishes, Then the verification report records timeout-blocked status, final URL if known, console/JS state if available, and a follow-up recommendation without refactoring the UI.

Functional Requirements

• FR-376-001: The implementation MUST create artifacts/source-audit-summary.md documenting Spec 368 blocked pages, relevant Spec 353 and Spec 370-375 input status, current route/auth/data/browser-evidence status, and remaining non-browser-verified surfaces.
• FR-376-002: The implementation MUST create artifacts/fixture-design.md with surface, route, auth guard, scope, data, existing fixture source, new fixture source if any, local/testing guarantee, browser URL, and failure mode for each in-scope surface.
• FR-376-003: The implementation MUST create artifacts/fixture-coverage-matrix.md with one row per in-scope surface and classifications for previous status, required fixture, implemented fixture, reachability result, screenshot, verification level, and remaining limitation.
• FR-376-004: The implementation MUST create artifacts/route-reachability-report.md listing route name, path, panel, middleware, auth guard, parameters, resolved fixture parameters, HTTP result, redirect result, final URL, and browser outcome.
• FR-376-005: The implementation MUST use existing admin local smoke-login and review/browser fixture patterns before adding new fixture code.
• FR-376-006: Any new smoke-login or fixture HTTP route MUST be available only in local and testing, return not found in all other environments, validate redirects against local app paths, and avoid secrets or real customer data. Any new or extended Artisan fixture command MUST be available only in local and testing, fail closed with a non-zero result outside those environments, and avoid secrets or real customer data.
• FR-376-007: System panel fixture work MUST authenticate PlatformUser through the platform guard and MUST NOT authenticate ordinary tenant users into /system.
• FR-376-008: The Evidence Snapshot fixture MUST use existing Spec 372-compatible browser evidence where sufficient, or a workspace/environment-authorized user with evidence view capability and a deterministic local/testing evidence snapshot, or document the exact blocker.
• FR-376-009: The Required Permissions fixture MUST use existing Spec 353/Spec 283-compatible browser evidence where sufficient, or a workspace/environment-authorized user and deterministic provider readiness/permission context, or document the exact blocker.
• FR-376-010: Provider Connection Detail fixture work MUST use scoped provider connection data, explicit environment_id/record-derived managed-environment context, and existing ProviderConnectionResource routes or document the exact route/data/timeout blocker.
• FR-376-011: Browser verification MUST attempt all five in-scope surfaces and create screenshots for reachable pages under artifacts/screenshots/; blocked pages require blocked screenshots when possible or explicit blocker notes.
• FR-376-012: The implementation MUST create artifacts/browser-verification-report.md, artifacts/screenshot-index.md, artifacts/affected-files.md, artifacts/validation-report.md, and artifacts/follow-up-recommendations.md.
• FR-376-013: The implementation MUST NOT intentionally change product UI layout, copy, action hierarchy, policies, Graph contracts, OperationRun semantics, migrations, models, or production runtime behavior outside local/testing fixtures.
• FR-376-014: All verification claims MUST use explicit levels: repo-verified, browser-verified, fixture-backed, local-only, test-only, auth-blocked, scope-blocked, data-blocked, route-blocked, timeout-blocked, deferred, or not available.

Non-Functional Requirements

• NFR-376-001: Fixture data must be deterministic, minimal, and safe to recreate.
• NFR-376-002: Browser coverage must avoid broad page/product assertions; it proves reachability, no JS/console errors where reachable, and screenshot evidence.
• NFR-376-003: Production auth posture must remain unchanged. No fixture route may be production-accessible.
• NFR-376-004: Test setup must keep heavy browser cost explicit and opt-in.
• NFR-376-005: Reports must distinguish route truth, auth truth, data truth, browser screenshot truth, and operator follow-up truth.

Out Of Scope

• Evidence Snapshot UI productization or evidence-generation logic.
• Required Permissions UI productization or permission calculation changes.
• System Dashboard/System Operations redesign.
• Provider Connection list/detail redesign, provider auth flow changes, provider health logic changes, or new provider behavior.
• New migrations, backfills, production fixtures, production smoke-login, or real customer data.
• UI bloat guard rule changes, final platform-wide browser re-audit, or screenshot diff infrastructure.
• Customer Review Workspace, Environment Review, Review Pack, Stored Report, OperationRun View, Backup Set View, Restore Run View, Operations Hub, Environment Dashboard, Baseline Profile View, or diagnostic entrypoint productization.

Acceptance Criteria

• AC1: Evidence Snapshot View is backed by current browser evidence or captured through a local/testing fixture with screenshot; otherwise it is documented with an exact blocker and follow-up.
• AC2: Required Permissions is backed by current browser evidence or captured through a local/testing fixture with screenshot; otherwise it is documented with an exact blocker and follow-up.
• AC3: System Dashboard is browser-reachable through platform-plane browser session/local-testing auth and screenshot, or deferred with the exact system-auth gap.
• AC4: System Operations is browser-reachable through platform-plane browser session/local-testing auth and screenshot or meaningful empty-state screenshot, or blocked/deferred with exact reason.
• AC5: Provider Connection Detail is backed by current browser evidence or captured through explicit environment_id / record-derived authority; otherwise timeout, route, or data limitation is documented with final URL/state where available.
• AC6: Any new/changed fixture/auth route is local/testing-only, any new/changed fixture command fails closed outside approved environments, and both are redirect-safe, secret-free, not production-accessible, and not an RBAC bypass.
• AC7: No product UI refactor, production auth change, migration, model change, policy weakening, Graph change, or OperationRun behavior change is performed.
• AC8: All required artifacts and screenshot directory exist, even if some pages are documented as blocked.
• AC9: git diff --check passes; Pint and targeted tests are run if code changes, or limitations are documented.

Assumptions

• Existing admin local smoke-login behavior remains the preferred admin fixture path.
• Existing Pest Browser support is available in this repo and should be reused for browser smoke.
• The system panel must remain a separate platform-auth plane.
• Existing Spec 353/372 admin-plane browser evidence is current repo truth and must be recorded instead of rediscovered as if absent.
• If a surface is unavailable because a route or required fixture does not exist, documenting the exact blocker is a valid outcome for v1.

Open Questions

• None blocking preparation. During implementation, the agent must verify whether a system local/testing smoke-login route already exists or must be added as a narrow fixture.

Follow-Up Spec Candidates

• Spec 377 - Post-Productization Browser Re-Audit & Closeout Gate v1.
• Provider Connection readiness/detail productization if screenshots reveal a product-level readiness gap.
• Evidence Snapshot customer/auditor productization if reachability exposes customer-safety issues.
• Browser scorecard integration with the UI bloat guard if repeated audits need automated aggregation.