TenantAtlas/specs/407-full-browser-ux-runtime-audit/tasks.md

Tasks: Spec 407 - Full Browser/UX Runtime Audit

Input: specs/407-full-browser-ux-runtime-audit/spec.md, plan.md, checklists/requirements.md, user-provided Spec 407 draft, Specs 400-406 lineage, Product Surface Contract, current roadmap/spec-candidates, and repo truth.

Tests: No application tests are required or allowed by default. This spec performs a read-only browser/runtime audit and produces a final report. Existing tests may be referenced as evidence. New tests, fixtures, seeders, factories, migrations, runtime files, or docs outside this spec package are out of scope.

Test Governance Checklist

• Lane assignment is Browser / read-only audit; no runtime or test change.
• No new Pest, fixture, seed, factory, DB, workspace, tenant, provider, session, or browser harness setup is introduced; ordinary browser login/session state from the existing environment may be used and recorded.
• Existing browser/dev environment and actors are used where available.
• Planned validation commands are read-only and do not pull in unrelated suite cost.
• Browser proof is the audit output, not proof of changed UI.
• Dirty state before/after is recorded.
• Any saved report artifact is created only under this spec directory and only if the operator explicitly asks for saved output.
• Findings are grouped into bounded remediation recommendations rather than implemented.

Phase 1: Preparation And Safety

Purpose: Establish repo truth and prove the audit can run without implementation.

• T001 Read specs/407-full-browser-ux-runtime-audit/spec.md, plan.md, tasks.md, and checklists/requirements.md.
• T002 Re-read AGENTS.md, .specify/memory/constitution.md, .specify/README.md, docs/ai-coding-rules.md, relevant docs/*-guidelines.md, and docs/product/standards/product-surface-contract.md.
• T003 Re-read Specs 400-406 as read-only lineage and record their gate results and caveats without editing them.
• T004 Record current branch, HEAD, dirty state, tracked files, untracked files, and git diff --check before audit execution.
• T005 Confirm output mode: response-only report by default; spec-local saved report only if the operator explicitly requests it during execution.
• T006 Confirm no application code, tests, migrations, routes, config, policies, models, services, jobs, Filament resources/pages/widgets, Livewire components, Blade views, CSS, JavaScript, seeders, factories, lock files, generated assets, docs outside this package, or completed specs will be edited.
• T007 Confirm the target browser environment/base URL and whether Sail/dev server/browser session is already available; start only the necessary existing dev services if safe and required.
• T008 Identify available actors and existing actor/session sources without exposing secrets: workspace admin, limited workspace user, system operator, customer reviewer, unauthorized user, and cross-workspace user; record unavailable actors or missing actor sources as limitations.

Phase 2: Route And Surface Inventory

Purpose: Build a coverage inventory from repo truth, not assumptions.

• T009 Run read-only route/panel inventory commands, including route list and targeted rg searches for panels, resources, pages, relation managers, navigation, global search, policies, and customer/download routes.
• T010 Classify discovered surfaces as Admin, System, Customer, Shared/Internal, or Unknown/Ambiguous.
• T011 Inventory login/auth entry points, admin panel shell, system panel shell, workspace selection/context, environment selection/context, navigation groups, breadcrumbs, and global search posture.
• T012 Inventory dashboard/readiness, baseline compare, restore preview/readiness, backup schedules/sets/runs, provider setup/detail/readiness/freshness/permissions, evidence overview/detail/anchors, OperationRun list/detail/proof, findings/governance inbox, review packs, customer review workspace, reports/PDF, artifact lifecycle, membership/access-scope, and operational pages.
• T013 Record surfaces that are unreachable, blocked by missing fixtures, blocked by auth, blocked by external services, or intentionally not applicable.
• T014 Record existing browser/screenshot/test artifacts that can support or limit coverage claims.

Phase 3: Browser Walkthrough

Purpose: Inspect rendered behavior safely across actor perspectives.

• T015 Open the target application in the browser and record base URL, environment, browser name/version if available, and test data assumptions.
• T016 Audit login/auth entry behavior without exposing credentials.
• T017 Audit admin shell, navigation, page titles, breadcrumbs, workspace/environment context, empty/wrong context behavior, sidebar clarity, global search, and direct route behavior.
• T018 Audit system panel access, system dashboard/pages, system-only navigation, platform capability behavior, admin-user blocking, and cross-plane separation.
• T019 Audit workspace/environment switching, stale context, filters/table scoping, direct URL cross-workspace behavior, empty/no-environment state, and action target context.
• T020 Audit provider setup/detail/readiness, permission state, freshness, failed/partial/stale state, provider actions, and raw data exposure.
• T021 Audit baseline compare landing, drift summary, comparison matrix, evidence links, readiness labels, findings links, OperationRun proof links, and empty/stale snapshot states.
• T022 Audit restore preview/readiness safely up to confirmation/disabled state, including expired/stale/conflict/partial/failure states, action guard behavior, and proof links.
• T023 Audit backup schedules/sets/runs/detail, backup action guards, failure/partial/blocked states, evidence/audit links, and table/list action consistency.
• T024 Audit evidence overview/detail/anchors, current/stale/missing/failed/partial labels, customer-safe evidence output, and cross-workspace anchor access.
• T025 Audit OperationRun list/detail/proof, failed/cancelled/success states, customer-safe visibility, admin/system boundaries, and proof links.
• T026 Audit findings list/detail, risk states, governance inbox, exception/reference fields, evidence links, lifecycle states, ownership/next-step clarity, and customer-safe boundaries.
• T027 Audit review packs, released/current state, customer reviewer view, download/export links, archived/expired/held/deleted/missing artifact states where visible, and customer-safe data boundaries, including absence by default of raw payloads, OperationRun internals, raw IDs, source keys, fingerprints, stack traces, private URLs, and system/admin links.
• T028 Audit report receipt, management report/PDF state, failed/unavailable report state, customer-safe content, direct download authorization, stale/currentness labels, and broken PDF links.
• T029 Audit governance artifact lifecycle states including released, archived, expired, held, deleted/missing-file, download/export visibility, and lifecycle state labels where present.
• T030 Audit responsive/visual sanity at desktop and one narrower viewport where feasible, including modals, table overflow, long labels, status badges, warning banners, PDF/report links, actions, and empty/error states.
• T031 Record browser console, Livewire, Filament, network, HTTP, asset, modal/action, table/filter/search, PDF/download, and file-not-found symptoms as they occur, while avoiding load/performance testing and repeated polling beyond visible-state observation.

Phase 4: Critical Journey Matrix

Purpose: Convert walkthrough coverage into journey-level readiness evidence.

• T032 Complete Admin readiness review journey.
• T033 Complete Provider readiness review journey.
• T034 Complete Baseline drift review journey.
• T035 Complete Evidence/proof review journey.
• T036 Complete Backup readiness review journey.
• T037 Complete Restore readiness review journey without destructive execution.
• T038 Complete Finding/governance triage journey.
• T039 Complete Review pack/customer review journey.
• T040 Complete Report/PDF review journey.
• T041 Complete System operator review journey.
• T042 Complete Unauthorized/cross-workspace blocked access journey.
• T043 For each journey, record actor, start, end, completion, blocking issue, confidence, and follow-up.

Phase 5: Findings And Matrices

Purpose: Turn observations into evidence-backed decisions.

• T044 Populate Browser Coverage Matrix with surface, actor, route/page, state tested, result, runtime errors, UX issues, authorization issues, customer-safe issues, severity, and follow-up.
• T045 Populate Runtime Error Log with route/page, actor, action, error type, symptom, severity, and follow-up.
• T046 Create Findings sections for P0, P1, P2, and P3 using the required finding fields.
• T047 Classify each finding by category: runtime defect, UX/productization defect, authorization defect, customer-safe boundary defect, evidence/currentness defect, lifecycle defect, navigation/IA defect, empty/error-state defect, copy/terminology defect, test/proof gap, product decision gap, known deferred item, or duplicate/already covered.
• T048 Ensure every P0/P1 finding cites concrete browser evidence and repo/spec contract evidence where available.
• T049 Distinguish missing fixture/service conditions from product empty-state issues and runtime defects.
• T050 Verify findings do not include secrets, tokens, raw credential payloads, sensitive provider payloads, private signed URLs, customer data, or stack traces.

Phase 6: Boundary, Evidence, Lifecycle, And UX Summaries

Purpose: Produce the required decision-quality summaries.

• T051 Summarize Authorization / Boundary Results for admin panel, system panel, customer review, workspace isolation, environment isolation, direct URL checks, global search/navigation exposure, and download/export access.
• T052 Summarize Evidence / Currentness / Proof Results for evidence overview, evidence anchors, OperationRun proof, baseline evidence, restore/backup proof, review pack proof, report/PDF proof, customer-safe proof, and internal-detail demotion.
• T053 Summarize Governance Artifact Lifecycle Results for released, archived/expired, held, deleted/missing-file, export/download, and customer-safe lifecycle behavior.
• T054 Summarize UX / Productization Results for navigation clarity, page purpose clarity, empty states, failure/stale/partial states, terminology consistency, customer-facing polish, technical/internal leakage, and CTA/action clarity.
• T055 Carry forward Spec 404/405 external staging/Dokploy conditions and Spec 406 lifecycle/product-decision residuals honestly in the relevant summaries.

Phase 7: Readiness Decision And Remediation Plan

Purpose: Decide what should happen next without implementing it.

• T056 Set Candidate Gate Result to PASS, PASS WITH CONDITIONS, or FAIL according to the Spec 407 gate rules.
• T057 Answer readiness questions for controlled pilot, customer-facing hardening, sales/demo use, broader customer claims, production deployment, and next implementation block as Yes, No, or Conditional with short reasons.
• T058 Group findings into the fewest coherent follow-up specs or product decisions, such as authorization/boundary remediation, customer-safe output remediation, evidence/currentness remediation, runtime crash remediation, navigation/surface reduction remediation, report/PDF remediation, governance lifecycle remediation, or UX/productization polish.
• T059 Identify findings that should not become specs, known deferred items, and duplicate/already covered issues.
• T060 Provide one recommended next action based on the gate result.

Phase 8: Final Report And Close-Out

Purpose: Deliver the audit result and prove no implementation occurred.

• T061 Write the final audit report with sections A through P required by spec.md.
• T062 If no saved artifact was explicitly requested, keep the report in the final response only.
• T063 If a saved artifact was explicitly requested, create only the approved spec-local report path and record it in dirty-state close-out.
• T064 Run final read-only dirty-state checks and record branch, HEAD, tracked changes, untracked files, and git diff --check.
• T065 If unexpected files changed, stop and report exact paths, likely cause, and whether the audit remains trustworthy.
• T066 Confirm no application runtime code, tests, migrations, config, routes, views, policies, models, services, jobs, Filament resources/pages/widgets, Livewire components, Blade views, CSS, JavaScript, seeders, factories, lock files, generated assets, docs outside this package, or completed specs were modified.
• T067 Confirm final response states Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, browser result, tests/commands, deployment impact, visible complexity outcome, completed-spec rewrite assertion, and explicit no-implementation status.

Non-Goals Checklist

• NT001 Do not implement fixes, refactors, UI redesign, copy cleanup, policy changes, route changes, or runtime hardening.
• NT002 Do not add or update tests, migrations, seeders, factories, fixtures, browser harnesses, or support helpers.
• NT003 Do not create users, mutate business data, execute destructive actions, release customer artifacts, send emails, trigger provider writes, or change billing/commercial/account settings.
• NT004 Do not rewrite completed specs, remove validation evidence, normalize completed task markers, or strip close-out language.
• NT005 Do not create docs outside this spec package or saved audit artifacts unless explicitly requested.
• NT006 Do not invent product decisions, statuses, role rules, readiness logic, customer-output categories, evidence types, lifecycle semantics, or navigation structures.
• NT007 Do not turn every finding into a new spec.
• NT008 Do not claim production/staging/Dokploy readiness from local-only browser proof.

Dependencies And Execution Order

• Phase 1 must complete before browser work.
• Phase 2 inventory must complete before claiming coverage completeness.
• Phase 3 and Phase 4 can interleave by actor, but findings must reference exact route/page/actor/state.
• Phase 5 findings feed Phase 6 summaries.
• Phase 6 summaries feed Phase 7 readiness and remediation decisions.
• Phase 8 must record dirty state and no-implementation proof before final response.

Parallel Execution Examples

• T011 through T014 can be performed in parallel by separate read-only file inspections.
• T020 through T029 can be split by domain surface if multiple reviewers are available, as long as all observations feed one final report.
• T051 through T054 can be drafted in parallel after findings are classified.

Recommended Implementation Strategy

Run the audit like a release readiness gate, not a bug-fix session. Prioritize critical journeys and customer/boundary safety first, keep P0/P1 findings concrete, group lower-severity issues by root cause, and stop if proving behavior would require mutation, fixture creation, or a product decision.