TenantAtlas/specs/412-pilot-readiness-remediation-pack/checklists/requirements.md

Requirements Checklist: Spec 412 - Pilot Readiness Remediation Pack

Purpose: Preparation readiness checklist for a bounded Spec 407 remediation package. Created: 2026-06-24 Feature: specs/412-pilot-readiness-remediation-pack/

Candidate Selection

• The selected candidate was directly provided by the operator as the "Spec 408 - Pilot Readiness Remediation Pack" draft.
• The package records the numbering deviation because branches 408 through 411 are already reserved by existing local/remote work.
• docs/product/spec-candidates.md was reviewed and reports no safe automatic next-best-prep target.
• docs/product/roadmap.md was reviewed and supports management-report/customer-facing hardening as a near-term manual follow-through area.
• The selected candidate is not already present as specs/412-pilot-readiness-remediation-pack/.
• Related completed and historical specs are read-only context.
• The smallest viable slice is limited to four Spec 407 findings.
• Close alternatives are deferred instead of hidden inside this package.
• Candidate Selection Gate result: PASS WITH NUMBERING DEVIATION.

Completed-Spec Guardrail

• Spec 407 was checked as source context and not selected for rewrite.
• Specs 400-406 are treated as completed/validated/implementation-history context where applicable.
• No completed-spec close-out, validation results, completed task markers, smoke results, browser evidence, screenshots, or review language are removed or normalized.
• Existing branch/spec number 408 belongs to unrelated public website work on another branch and is not overwritten.

Spec Completeness

• Problem statement is clear and product-oriented.
• Business/product value is explicit.
• Primary users/operators are named.
• Scope fields cover routes/surfaces, ownership, RBAC, and leakage checks.
• Functional requirements are testable.
• Non-functional requirements cover security, reliability, auditability, performance, product safety, and test governance.
• User stories include independent tests and acceptance criteria.
• Edge cases are documented.
• Out-of-scope boundaries forbid broad rewrites, new surfaces, new product concepts, and full browser audit.
• Success criteria are measurable.
• Assumptions, risks, and open questions are explicit.

Constitution / Spec Gate

• 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.
• No new persisted entity, table, enum, status family, abstraction, taxonomy, or UI framework is approved.
• The plan reuses existing report/PDF, OperationRun, RBAC, Filament, and provider/finding surfaces.
• Runtime implementation must stop if broader architecture or product decisions are required.

Product Surface Contract

• docs/product/standards/product-surface-contract.md is referenced.
• No-legacy posture is recorded.
• UI Surface Impact is concrete and does not claim no-impact.
• Product Surface Impact is completed for review/report, operations, finding, and provider no-access surfaces.
• Page archetypes, surface budgets, Technical Annex/deep-link demotion, and canonical vocabulary are recorded.
• UI Action Matrix is recorded for the changed operator-facing surfaces.
• Browser proof is required for rendered UI changes.
• Human Product Sanity is required.
• Product Surface exceptions are none for preparation.
• Implementation report close-out fields are required.

Plan Completeness

• Plan identifies PHP/Laravel/Filament/Livewire/Pest/PostgreSQL/Sail context.
• Plan names likely affected existing runtime surfaces without making code changes.
• Plan distinguishes remediation from broad audit or architecture rewrite.
• Plan includes UI/Product Surface, Filament/Livewire/deployment, RBAC, audit, evidence/result truth, OperationRun, provider boundary, and test-governance posture.
• Plan defines implementation phases, output strategy, stop conditions, and risk controls.
• Plan does not contradict repository architecture or current code truth.

Task Completeness

• Tasks are ordered by safety/inventory, reproduction, tests, implementation, browser proof, and close-out.
• Tasks are small and verifiable.
• Tasks include dirty-state checks before/after.
• Tasks include reproduction/validation of each Spec 407 finding before fixing.
• Tasks include targeted tests for report/PDF, operations, finding detail, and provider no-access behavior.
• Tasks include authenticated-provider-denial coverage so no-access clarity is measurable.
• Tasks include focused browser proof and explicitly forbid claiming a full browser audit.
• Tasks include Product Surface and Filament output-contract close-out fields.
• Tasks include explicit non-goals and stop conditions.

Open Questions / Readiness

• No open product question blocks starting implementation.
• Any non-reproducible finding must be documented during implementation rather than silently marked fixed.
• Required final report matrices are named.
• Spec Readiness Gate result: PASS.

Review Outcome

• Review outcome class: acceptable-special-case for a focused pilot-readiness remediation pack after a broad browser audit.
• Workflow outcome: keep.
• Final note location: specs/412-pilot-readiness-remediation-pack/implementation-report.md during implementation.
• No application implementation was performed during preparation.