TenantAtlas/specs/402-resource-policy-authorization-proof-matrix/checklists/requirements.md

Requirements Checklist: Spec 402 - Resource Policy & Authorization Proof Matrix

Purpose: Validate preparation quality for Spec 402 before implementation starts. Created: 2026-06-23 Feature: specs/402-resource-policy-authorization-proof-matrix/spec.md

Candidate Selection

• The selected candidate was directly provided by the operator.
• The candidate is linked to the Spec 400 P1 resource-policy matrix condition.
• docs/product/spec-candidates.md was reviewed and currently reports no safe automatic next-best-prep target.
• Close alternatives are deferred instead of hidden inside the primary scope.
• The target does not reopen completed Specs 400 or 401.
• No existing specs/402-resource-policy-authorization-proof-matrix/ package existed before preparation.
• Existing unrelated 402-screwfast-website-rebuild branch collision is documented as context.

Scope Quality

• The spec is bounded to existing resource authorization proof and minimal hardening.
• No new roles, permission product model, product surfaces, navigation, migrations, or broad RBAC redesign are included.
• Admin and system panels are both explicitly in scope.
• Workspace/environment isolation is explicitly in scope.
• System/admin separation is explicitly in scope.
• Global search, bulk actions, relation managers, controller-backed downloads/exports, and direct invocation are explicitly in scope.
• Customer/reviewer boundary proof is included only where existing surfaces/tests represent that access.
• Evidence currentness, management PDF staging validation, governance lifecycle, JSONB migration, and full browser audit are deferred.

Constitution And Product Surface

• Spec Candidate Check is filled out.
• Approval class is exactly one class: Core Enterprise.
• Score is recorded and above the minimum threshold.
• Proportionality Review is completed because the matrix is a review artifact.
• No runtime source of truth, persisted table, status family, enum, taxonomy, or framework is introduced.
• Product Surface Contract is referenced because existing rendered authorization behavior may change.
• UI Surface Impact is classified as existing-surface authorization hardening only.
• Browser proof is required for representative rendered authorization behavior.
• Human Product Sanity is required for changed rendered authorization behavior.
• Completed-spec rewrite guardrail is explicit.

Plan Quality

• Plan identifies Laravel, Filament, Livewire, Pest, and Sail versions from repo context.
• Plan names panel provider registration location.
• Plan names likely affected repository surfaces.
• Plan requires matrix-first work before adding policies or hardening code.
• Plan distinguishes policies, gates/capabilities, scoped queries, global search, bulk actions, relation managers, controller routes, and system-panel capability middleware.
• Plan requires existing capability services to remain authoritative where they already define product semantics.
• Plan forbids cosmetic policy generation.
• Plan includes rollout/deployment impact and expects no migrations/env/assets/queues/storage changes.

Task Quality

• Tasks are ordered by preparation, inventory, matrix, gap classification, tests, hardening, browser proof, and report close-out.
• Tasks require negative tests for every fixed authorization gap.
• Tasks include direct route/resource access tests.
• Tasks include cross-workspace denial tests.
• Tasks include system/admin separation tests.
• Tasks include Filament action execution authorization tests.
• Tasks include relation manager, bulk action, global search, and controller/download/export proof tasks.
• Tasks include focused browser proof and explicitly forbid claiming full browser audit.
• Tasks include dirty-state protocol before and after implementation.
• Tasks include final implementation report sections A through M.

Open Questions And Readiness

• No open question blocks implementation preparation.
• Product-ambiguous authorization decisions are required to be deferred rather than invented.
• Spec Readiness Gate can pass after artifact analysis.
• Candidate Selection Gate can pass as a manual operator-promoted candidate.

Review Outcome

• Review outcome class: acceptable-special-case for a bounded authorization proof matrix.
• Workflow outcome: keep.
• Final note location: future implementation report specs/402-resource-policy-authorization-proof-matrix/implementation-report.md.