2026-06-22 21:37:00 +00:00
4 changed files with 812 additions and 0 deletions
--- a/specs/400-product-contract-spec-completeness-audit/checklists/requirements.md
+++ b/specs/400-product-contract-spec-completeness-audit/checklists/requirements.md
@ -0,0 +1,45 @@
+# Specification Quality Checklist: Spec 400 - Product Contract & Spec Completeness Audit
+
+**Purpose**: Validate specification completeness and quality before implementation preparation is handed off.
+**Created**: 2026-06-22
+**Feature**: `specs/400-product-contract-spec-completeness-audit/spec.md`
+
+## Content Quality
+
+- [x] No application implementation details are prescribed beyond read-only inspection targets.
+- [x] Focused on product value, operator trust, and customer-ready productization risk.
+- [x] Written as an audit/promotion gate that product and engineering reviewers can evaluate.
+- [x] Mandatory Spec Kit sections are completed or explicitly marked N/A with rationale.
+
+## Requirement Completeness
+
+- [x] No unresolved clarification markers remain.
+- [x] Requirements are testable and unambiguous for a read-only audit.
+- [x] Success criteria are measurable.
+- [x] Success criteria are technology-agnostic except for repo-path evidence references.
+- [x] Acceptance scenarios are defined.
+- [x] Edge cases are identified.
+- [x] Scope is clearly bounded to audit/reporting and excludes implementation.
+- [x] Dependencies and assumptions are identified.
+
+## Feature Readiness
+
+- [x] Functional requirements map to the final audit report structure.
+- [x] User scenarios cover gate result, surface matrix, decision debt, hallucination risk, and follow-up grouping.
+- [x] The feature meets measurable outcomes defined in Success Criteria.
+- [x] No runtime implementation is required to execute the audit.
+
+## Constitution And Product Surface Readiness
+
+- [x] Spec Candidate Check is completed with approval class, score, and decision.
+- [x] Completed-spec guardrail is explicit.
+- [x] No UI surface impact is checked with a clear rationale.
+- [x] Product Surface Contract is applied as an audit standard, not as runtime change.
+- [x] Browser verification is `N/A - no rendered UI surface changed` for preparation.
+- [x] Human Product Sanity is scoped to final-report sanity, not rendered UI.
+- [x] Proportionality review states report-only outputs and no runtime framework.
+- [x] Test governance states no tests, lanes, fixtures, or browser families are added.
+
+## Notes
+
+Preparation review result: pass. The package is ready for a separate read-only audit execution, provided the audit agent preserves the no-implementation boundary and records dirty state before/after.
--- a/specs/400-product-contract-spec-completeness-audit/plan.md
+++ b/specs/400-product-contract-spec-completeness-audit/plan.md
@ -0,0 +1,263 @@
+# Implementation Plan: Spec 400 - Product Contract & Spec Completeness Audit
+
+**Branch**: `400-product-contract-spec-completeness-audit` | **Date**: 2026-06-22 | **Spec**: `specs/400-product-contract-spec-completeness-audit/spec.md`
+**Input**: Feature specification from `specs/400-product-contract-spec-completeness-audit/spec.md`
+
+## Summary
+
+Prepare a read-only product-contract completeness audit that determines whether TenantPilot is sufficiently specified for customer-ready productization. The later audit execution must inspect repository truth, score critical product surfaces, identify decision debt and hallucination risk, group minimal follow-up specs, answer promotion readiness, and stop without implementation.
+
+The default audit output is the final response. A durable report file under this spec package is allowed only if the operator explicitly asks for one during audit execution.
+
+## Technical Context
+
+**Language/Version**: PHP 8.4.15, Laravel 12.52.0, Filament 5.2.1, Livewire 4.1.4.
+**Primary Dependencies**: Laravel, Filament, Livewire, Pest 4, PostgreSQL, existing Spec Kit artifacts, existing Product Surface Contract and UI audit artifacts.
+**Storage**: No database, migration, persisted product truth, fixture, or runtime artifact changes.
+**Testing**: N/A for preparation and runtime behavior; later audit execution records read-only validation commands and dirty state.
+**Validation Lanes**: N/A for runtime; optional `git diff --check` and read-only repo inspection during audit execution.
+**Target Platform**: TenantPilot Laravel monolith under `apps/platform`; Spec Kit artifacts under `specs/400-product-contract-spec-completeness-audit/`.
+**Project Type**: Web application plus Spec Kit workflow.
+**Performance Goals**: Audit should prefer targeted repo inspection and evidence-backed findings over exhaustive noisy scans.
+**Constraints**: Read-only only; no application code, tests, migrations, routes, views, policies, completed spec rewrites, or docs outside this spec package.
+**Scale/Scope**: Whole-product product-contract audit over critical admin, system, customer/report, evidence, operation, restore, provider, dashboard, and governance surfaces.
+
+## Repository Surfaces Likely Inspected
+
+Governance and roadmap:
+
+```text
+AGENTS.md
+.specify/
+docs/ai-coding-rules.md
+docs/product/roadmap.md
+docs/product/spec-candidates.md
+docs/product/standards/product-surface-contract.md
+docs/ui-ux-enterprise-audit/
+docs/product/implementation-ledger.md
+docs/product/operator-semantic-taxonomy.md
+```
+
+Recent and related specs:
+
+```text
+specs/376-browser-audit-fixture-coverage-evidence-system-surfaces/
+specs/377-post-productization-browser-reaudit-closeout-gate/
+specs/378-management-report-pdf-v1/
+specs/379-management-report-pdf-runtime/
+specs/380-management-report-pdf-staging-runtime-validation/
+specs/381-provider-resource-identity-binding/
+specs/382-baseline-matching-canonicalization/
+specs/383-baseline-result-semantics/
+specs/384-baseline-subject-resolution-ui/
+specs/385-evidence-review-readiness/
+specs/386-review-publication-resolution-workflow-v1/
+specs/387-review-publication-resolution-decision-ux-v1/
+specs/388-resolution-proof-currentness-contract-v1/
+specs/389-governance-inbox-resolution-intake-v1/
+specs/390-restore-readiness-resolution-adapter-v1/
+specs/391-operations-hub-stability-debug-safe-runtime/
+specs/392-customer-output-gating-review-pack-navigation/
+specs/393-evidence-anchor-reconciliation-v1/
+specs/394-provider-freshness-permission-semantics/
+specs/395-product-surface-gate/
+specs/396-system-panel-branding/
+specs/397-receipt-page-reduction/
+specs/398-decision-page-contract-migration/
+specs/399-dashboard-inbox-table-contract/
+```
+
+Application surfaces for read-only inspection:
+
+```text
+apps/platform/routes/
+apps/platform/app/Providers/
+apps/platform/bootstrap/providers.php
+apps/platform/app/Filament/
+apps/platform/resources/views/
+apps/platform/app/Models/
+apps/platform/app/Policies/
+apps/platform/app/Services/
+apps/platform/app/Jobs/
+apps/platform/database/migrations/
+apps/platform/database/factories/
+apps/platform/tests/
+```
+
+## Audit Method
+
+1. Record branch, HEAD, and dirty state before any audit command.
+2. Build a surface inventory from routes, Filament panels/pages/resources/widgets, Livewire/Blade views, models, policies, tests, and recent specs.
+3. For each primary surface, identify route/navigation entry, owning panel, primary model(s), primary user role(s), workspace/environment scope, visible decision/action, evidence or OperationRun dependency, customer-visible status, and relevant tests/specs.
+4. Score product-contract completeness across the required dimensions using the 0-4 model from `spec.md`.
+5. Identify decision debt, implementation defects, test gaps, surface drift, terminology drift, and agent hallucination risk.
+6. Compare recent critical specs against implementation evidence where relevant.
+7. Group findings into must-fix before customer pilot, should-fix before broader productization, can defer, duplicate/already covered, and not-a-spec review feedback.
+8. Produce final audit report using the required structure.
+9. Record dirty state after the audit and stop if unexpected file changes occurred.
+
+## Output Strategy
+
+- **Default**: final audit report in the assistant response only.
+- **Optional**: a spec-local report file under `specs/400-product-contract-spec-completeness-audit/` only when the operator explicitly asks for file output during audit execution.
+- **Forbidden by default**: generated reports in `docs/`, runtime screenshots, new fixtures, tests, application files, or completed-spec edits.
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: read-only audit of existing surfaces.
+- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**: none changed; many inspected.
+- **No-impact class**: spec preparation and read-only audit.
+- **Native vs custom classification summary**: N/A for changes; audit may classify existing surfaces.
+- **Shared-family relevance**: evidence/report viewers, status messaging, dashboards, inboxes, restore readiness, provider readiness, operation proof, customer output, and technical/audit links are audit targets only.
+- **State layers in scope**: shell/page/detail/query state are inspected but not changed.
+- **Audience modes in scope**: customer/read-only, operator/MSP, support/platform, and system admin as audit classifications.
+- **Decision/diagnostic/raw hierarchy plan**: inspect whether the hierarchy is specified; do not alter hierarchy.
+- **Raw/support gating plan**: inspect customer-safe vs operator diagnostic vs support/raw boundaries.
+- **One-primary-action / duplicate-truth control**: inspect whether surfaces define one primary question/action and avoid repeated readiness/status truth.
+- **Handling modes**: report-only for this spec; follow-up-spec only when structural, evidence-backed gaps require it.
+- **Repository-signal treatment**: report findings only.
+- **Special surface test profiles**: N/A for preparation.
+- **Required tests or manual smoke**: none for preparation; later audit may use existing evidence or read-only browser inspection if explicitly scoped.
+- **Exception path and spread control**: Product Surface exceptions discovered during audit become findings, not fixes.
+- **Active feature PR close-out entry**: N/A for runtime; preparation final response records no implementation.
+- **UI/Productization coverage decision**: No UI surface impact.
+- **Coverage artifacts to update**: none.
+- **No-impact rationale**: no rendered UI changes.
+- **Screenshot or page-report need**: no for preparation. Later audit may reference existing screenshots or create none unless explicitly authorized.
+
+## Product Surface Contract Plan
+
+- **Product Surface Contract reference**: `docs/product/standards/product-surface-contract.md`.
+- **No-legacy posture**: no compatibility changes; completed specs remain historical context.
+- **Page archetype and surface budget plan**: audit existing surfaces against archetype/budget definitions where evidence exists.
+- **Technical Annex and deep-link demotion plan**: inspect whether technical links and raw evidence are default product content or demoted by contract.
+- **Canonical status vocabulary plan**: inspect whether product-facing states are mapped or exceptioned.
+- **Product Surface exceptions**: none in preparation; audit may report exceptions/gaps.
+- **Browser verification plan**: `N/A - no rendered UI surface changed`.
+- **Human Product Sanity plan**: final report sanity check.
+- **Visible complexity outcome target**: neutral runtime; report may recommend later reduction.
+- **Implementation report target**: final response; optional spec-local audit report only by explicit operator request.
+
+## Filament / Livewire / Deployment Posture
+
+- **Livewire v4 compliance**: Livewire 4.1.4 confirmed by Laravel Boost; no Livewire code change.
+- **Panel provider registration location**: `apps/platform/bootstrap/providers.php`; no panel provider change.
+- **Global search posture**: no globally searchable resource is changed. Audit may inspect search posture as evidence.
+- **Destructive/high-impact action posture**: no action is added or changed. Audit may inspect whether existing destructive/high-impact contracts are specified.
+- **Asset strategy**: no assets, no `FilamentAsset` registration, no `filament:assets` deployment change.
+- **Testing plan**: no tests are added or changed. Later audit records read-only commands and limitations.
+- **Deployment impact**: none. No env vars, migrations, queues, scheduler, storage, assets, provider scopes, or Dokploy changes.
+
+## Domain / Model Implications
+
+No model, migration, enum, table, persisted artifact, service, job, policy, route, query, Graph contract, OperationRun type, audit event, or customer-output artifact is introduced or changed.
+
+The audit may read models and migrations to classify source-of-truth, ownership, and scope. Reading does not create domain truth.
+
+## RBAC / Security / Audit Implications
+
+- No authorization behavior changes.
+- The audit inspects whether specs, policies, gates, tests, and UI enforcement define workspace isolation, managed-environment entitlement, platform-plane separation, 404/403 semantics, customer visibility, and audit responsibility.
+- Security findings are report-only and must cite evidence.
+- The audit must never weaken auth, create smoke login routes, seed users, or bypass policies.
+
+## OperationRun / Evidence / Result Truth Implications
+
+The audit must distinguish:
+
+- execution truth: `OperationRun` state, outcome, summary counts, failure reason, and audit trail;
+- artifact truth: review packs, stored reports, evidence snapshots, backup sets, and report/download outputs;
+- backup/snapshot truth: immutable capture and source/currentness;
+- recovery/evidence truth: restore preview/readiness, proof, stale/failure state, and customer-safe output;
+- operator next action: the decision/action the surface supports.
+
+No OperationRun or evidence behavior changes are allowed.
+
+## Constitution Check
+
+- Inventory-first: PASS, audit inspects inventory/snapshot truth only.
+- Read/write separation: PASS, no writes or change functions.
+- Graph contract path: PASS, no Graph calls.
+- Deterministic capabilities: PASS by inspection only; no resolver changes.
+- RBAC-UX: PASS, audit checks contracts but changes none.
+- Workspace isolation: PASS, audit checks evidence but changes none.
+- Tenant isolation: PASS, audit checks evidence but changes none.
+- Run observability: PASS, audit inspects OperationRun proof contracts but creates no runs.
+- OperationRun start UX: N/A.
+- Ops-UX 3-surface feedback: N/A.
+- Data minimization: PASS, no sensitive output beyond cited repo evidence; avoid copying secrets or raw sensitive payloads into the report.
+- Test governance: PASS, no tests or lanes added.
+- Proportionality: PASS, report-only audit outputs are the narrowest current-release gate.
+- No premature abstraction: PASS, no runtime abstraction.
+- Persisted truth: PASS, no database persistence.
+- Behavioral state: PASS, severity/scoring labels are report-only.
+- UI semantics: PASS, audit uses existing Product Surface language and does not create runtime semantics.
+- Shared pattern first: PASS, no runtime interaction class is implemented.
+- Provider boundary: PASS, provider/platform seams are inspected only.
+- V1 explicitness / few layers: PASS, no layers added.
+- Spec discipline / bloat check: PASS, one coherent audit spec instead of many speculative micro-specs.
+- Filament-native UI: PASS by no runtime UI changes.
+- UI/Productization coverage: PASS, No UI surface impact recorded.
+- Product Surface Contract Gate: PASS, audit-only application and no completed-spec rewriting.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: N/A - no runtime or test changes.
+- **Affected validation lanes**: none.
+- **Why this lane mix is the narrowest sufficient proof**: No code behavior changes need test proof.
+- **Narrowest proving command(s)**:
+  - `git status --short --branch`
+  - `git diff --name-only`
+  - `git diff --check`
+- **Fixture / helper / factory / seed / context cost risks**: none.
+- **Expensive defaults or shared helper growth introduced?**: no.
+- **Heavy-family additions, promotions, or visibility changes**: none.
+- **Surface-class relief / special coverage rule**: `N/A - no rendered UI surface changed`.
+- **Closing validation and reviewer handoff**: confirm final audit is read-only, evidence-backed, and recommendation-bounded.
+- **Budget / baseline / trend follow-up**: none.
+- **Review-stop questions**: Did any command dirty the tree? Did any finding lack evidence? Did any recommendation invent a product decision? Did any completed spec get rewritten?
+- **Escalation path**: follow-up-spec only from final report recommendations, not during audit execution.
+- **Active feature PR close-out entry**: N/A.
+- **Why no dedicated follow-up spec is needed now**: This spec is the gate that determines which follow-up specs, if any, are needed.
+
+## Project Structure
+
+### Spec Package
+
+```text
+specs/400-product-contract-spec-completeness-audit/
+├── spec.md
+├── plan.md
+├── tasks.md
+└── checklists/
+    └── requirements.md
+```
+
+### Optional Future Audit Artifact
+
+```text
+specs/400-product-contract-spec-completeness-audit/
+└── artifacts/
+    └── product-contract-audit-report.md
+```
+
+The optional artifact path is not created by preparation and must not be created during audit execution unless the operator explicitly requests file output.
+
+## Implementation Phases
+
+1. Repo-truth and dirty-state initialization.
+2. Surface inventory and evidence collection.
+3. Product contract scoring.
+4. Decision debt and hallucination-risk classification.
+5. Spec gap grouping and promotion readiness decision.
+6. Final report and dirty-state close-out.
+
+## Stop Conditions
+
+Stop and report immediately if:
+
+- the working tree is dirty before audit execution and the changes are unrelated;
+- a read-only command unexpectedly modifies files;
+- a required surface cannot be inspected and no existing evidence can substitute;
+- the audit would require product decisions to continue;
+- implementation or test changes appear necessary to answer the audit.
--- a/specs/400-product-contract-spec-completeness-audit/spec.md
+++ b/specs/400-product-contract-spec-completeness-audit/spec.md
@ -0,0 +1,402 @@
+# Feature Specification: Spec 400 - Product Contract & Spec Completeness Audit
+
+**Feature Branch**: `400-product-contract-spec-completeness-audit`
+**Created**: 2026-06-22
+**Status**: Draft / Ready for preparation review
+**Type**: Read-only audit / discovery / promotion gate
+**Input**: User-provided "Spec 400 - Product Contract & Spec Completeness Audit" draft, current roadmap and spec-candidate queue, Specs 376-399 productization lineage, and the Product Surface Contract.
+
+## Candidate Selection Context
+
+- **Selected candidate**: Product Contract & Spec Completeness Audit.
+- **Source**: Direct user-provided Spec 400 draft in the Codex attachment.
+- **Why selected**: `docs/product/spec-candidates.md` currently says there is no safe automatic next-best-prep target, but the operator supplied a direct manual-promotion candidate. The candidate addresses a different question from the recent Product Surface Contract implementation specs: whether TenantPilot is sufficiently specified for future agents to continue without inventing product, RBAC, evidence, customer-output, failure-state, or surface-ownership decisions.
+- **Close alternatives deferred**:
+  - `management-report-pdf-staging-runtime-validation`: manual backlog follow-through, already represented by Specs 378-380.
+  - `governance-artifact-lifecycle-retention-runtime`: broader runtime product decision, manual promotion only.
+  - `provider-readiness-onboarding-productization`: optional/manual provider-readiness work, not the supplied audit gate.
+  - `cross-domain-indicator-runtime-follow-through`: semantic runtime adoption, not a whole-product specification completeness audit.
+  - Reopening Specs 395-399: forbidden; they are context and recent completed/current product-surface work, not preparation targets.
+- **Roadmap relationship**: Supports the current productization and moat priorities by creating a read-only decision gate before more customer-ready product work proceeds.
+- **Completed-spec guardrail result**: No `specs/400-product-contract-spec-completeness-audit` package existed before this preparation. Related specs 376, 377, 378, 379, 380, 381-399, and earlier productization specs are context only. Completed close-out, validation, screenshots, browser evidence, checked task history, implementation reports, and post-implementation review language must not be rewritten or normalized.
+- **Smallest viable implementation slice**: Perform a repo-based, read-only product-contract completeness audit across current specs, docs, routes, Filament panels/pages/resources, Livewire/views, policies, models, tests, and existing browser/runtime evidence. Produce a final audit report with a Product Contract Coverage Matrix, Decision Debt Register, Agent Hallucination Risk Map, Spec Gap List, surface freeze/reduction recommendations, promotion readiness answers, and one recommended next action. Do not implement fixes.
+- **Feature description for Spec Kit**: Determine whether TenantPilot is sufficiently specified for customer-ready productization without requiring implementation agents to invent product, architecture, RBAC, evidence, OperationRun, customer-output, failure-state, or navigation/surface ownership decisions.
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: TenantPilot now has many implemented and prepared productization specs, but future agents may still have to infer critical product decisions from implementation, naming, or precedent instead of explicit contract artifacts.
+- **Today's failure**: A future implementation can pass tests while inventing intended behavior for roles, customer visibility, evidence/currentness, OperationRun proof, stale/failed/empty states, restore readiness, report output, or page ownership because no current audit says which product contracts are complete and which are decision debt.
+- **User-visible improvement**: Product and engineering reviewers get a single evidence-backed answer to whether the next implementation block can proceed safely, plus a bounded list of gaps that must become specs or decisions first.
+- **Smallest enterprise-capable version**: A read-only audit that inventories major surfaces, scores contract completeness, distinguishes implementation bugs from missing product decisions, and groups recommended follow-up specs without editing runtime or completed specs.
+- **Explicit non-goals**: No implementation, no bug fixing, no visual redesign, no copy cleanup, no migrations, no tests, no fixture creation, no broad browser bug hunt, no security penetration test, no performance audit, no deployment review, and no automatic spec explosion.
+- **Permanent complexity imported**: One spec package and a future final audit report. The scoring model, decision-debt register, hallucination-risk map, and spec gap list are report-only audit outputs, not runtime product truth, persisted state, or reusable application frameworks.
+- **Why now**: Specs 395-399 installed and exercised Product Surface Contract enforcement and several runtime-reduction passes. The next risk is false confidence that all product contracts are now explicit enough for customer-ready productization.
+- **Why not local**: A local note on one page or a narrow Product Surface Contract pass cannot answer the whole-agent question: "Can implementation continue without inventing product decisions?"
+- **Approval class**: Core Enterprise.
+- **Red flags triggered**: Many surfaces and audit scoring axes. Defense: the slice is read-only, report-only, and explicitly forbids runtime changes, new frameworks, new persisted truth, and rewriting completed specs.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 12/12**
+- **Decision**: approve as a bounded read-only product-contract completeness audit.
+
+## Problem Statement
+
+TenantPilot has reached a stage where the main product risk is not only missing implementation. The larger risk is implicit product logic. Agents can keep adding screens, flows, and rules while key contracts are still ambiguous.
+
+This audit answers:
+
+```text
+Can an implementation agent safely continue building TenantPilot without inventing product decisions?
+```
+
+A flow is sufficiently defined only when existing repo/spec artifacts identify who uses it, what decision or action it supports, what data is authoritative, what scope and permissions apply, what evidence is created or displayed, what the customer may see, what stale/failed/empty states mean, what tests prove the contract, and what is explicitly out of scope.
+
+If the answer depends on assumption, convention, or "probably", it is a finding.
+
+## Product / Business Value
+
+The audit prevents false productization confidence. It creates one reviewable gate that tells the operator whether TenantPilot is ready for the next implementation block, a full browser/UX/runtime audit, customer-facing hardening, or controlled pilot work. It also limits future specs to the smallest coherent follow-up set instead of one spec per small finding.
+
+## Primary Users / Operators
+
+- Product owner deciding whether customer-ready productization can continue.
+- Senior implementation agent deciding whether existing specs are explicit enough to implement safely.
+- Engineering reviewer checking whether future work has a clear product contract.
+- MSP/operator representative whose workflows depend on clear role, scope, evidence, and next-action semantics.
+- Customer/auditor reviewer whose output must not expose internal-only evidence or false readiness claims.
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: canonical-view / read-only audit / promotion gate.
+- **Primary Routes**: No route is added or changed. The audit inspects current `/admin`, `/system`, and relevant customer/report/download surfaces where repo evidence exists.
+- **Data Ownership**: No data ownership changes. The audit must classify existing workspace-owned, managed-environment-owned, tenant-owned, platform-owned, evidence, OperationRun, report, and audit artifacts from repo truth only.
+- **RBAC**: No runtime authorization changes. The audit inspects whether current specs/code/tests define workspace membership, managed-environment entitlement, capability requirements, deny-as-not-found semantics, platform-plane separation, customer-readonly boundaries, and audit responsibilities for each critical surface.
+
+For canonical-view specs:
+
+- **Default filter behavior when tenant-context is active**: The audit observes existing route-owned workspace/environment scope and page-level filters. It must flag any surface whose default scope behavior is ambiguous or only implied.
+- **Explicit entitlement checks preventing cross-tenant leakage**: The audit must inspect policies, gates, scoped resolvers, Filament queries, global search posture, route generation, tests, and existing browser evidence where relevant, but it must not change enforcement.
+
+## No Legacy / No Backward Compatibility Constraint *(mandatory)*
+
+TenantPilot is pre-production for this audit. The audit must not introduce compatibility behavior.
+
+- **Compatibility posture**: read-only assessment; no compatibility changes.
+- **Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?**: no new aliases, readers, routes, UI, labels, or fixtures are introduced.
+- **Why clean assessment is safe now**: The audit does not mutate runtime behavior. Existing historical specs and implementation reports remain immutable context.
+
+The audit must not reopen or rewrite completed specs to satisfy current Product Surface wording.
+
+## UI Surface Impact *(mandatory - UI-COV-001)*
+
+Does this spec add, remove, rename, or materially change any reachable UI surface?
+
+- [x] 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
+
+## UI/Productization Coverage
+
+N/A - no reachable UI surface impact.
+
+- **No-impact rationale**: Spec 400 prepares and later executes a read-only audit. It may inspect UI files, routes, existing screenshots, and existing browser evidence, but it must not change rendered pages, navigation, Filament panel providers, resources, Livewire components, Blade views, CSS, JavaScript, actions, tables, forms, or customer-facing output.
+
+## Product Surface Impact
+
+Reference: `docs/product/standards/product-surface-contract.md`.
+
+- **Product Surface Contract applies?**: yes as an audit standard; no rendered product surface is changed.
+- **Page archetype**: N/A for this spec package. The audit must classify inspected surfaces against the applicable Product Surface archetypes where evidence exists.
+- **Primary user question**: "Can future implementation continue without inventing product decisions?"
+- **Primary action**: Produce a gate result and recommended next action.
+- **Surface budget result**: N/A for runtime; the audit must flag surfaces whose budget/Technical Annex/default-detail posture is not contractually defined.
+- **Technical Annex / deep-link demotion**: The audit inspects whether OperationRun, raw evidence, IDs, payloads, source keys, detectors, fingerprints, logs, and internal proof are defined as product-default, secondary, or technical/audit detail. It must not change links.
+- **Canonical status vocabulary**: The audit checks whether product-facing statuses map to canonical vocabulary or have explicit exceptions.
+- **Visible complexity impact**: neutral at runtime. The future audit may recommend reduction/freeze actions, but must not perform them.
+- **Product Surface exceptions**: none for this preparation. Any future audit finding may recommend a later bounded spec or product decision.
+
+## Browser Verification Plan *(mandatory)*
+
+- **Browser proof required?**: no for this preparation package.
+- **No-browser rationale**: `N/A - no rendered UI surface changed`.
+- **Focused path when required**: N/A. The future audit may read existing browser artifacts and may run read-only browser inspection only if explicitly chosen as audit evidence; it must not mutate app state or create fixtures.
+- **Primary interaction to execute**: N/A for preparation.
+- **Console, Livewire, Filament, network, and 500-error checks**: N/A for preparation; if the audit uses browser evidence, record exact scope and limitations.
+- **Full-suite failure triage**: N/A.
+
+## Human Product Sanity Check *(mandatory)*
+
+- **Required?**: yes as workflow sanity for the final audit report, not as rendered-page sanity for preparation.
+- **No-human-sanity rationale**: no rendered surface changes.
+- **Reviewer questions**: Does the audit answer the core gate question? Are P0/P1 findings evidence-backed? Are recommendations bounded? Does it avoid inventing product decisions? Does it avoid rewriting completed specs?
+- **Planned result location**: final audit report / implementation response.
+
+## Product Surface Merge Gate Checklist *(mandatory)*
+
+- [x] No-legacy posture or approved exception recorded.
+- [x] Product Surface Impact is completed as audit-only with no rendered surface change.
+- [x] Browser proof is `N/A - no rendered UI surface changed` for preparation.
+- [x] Human Product Sanity is planned as report sanity rather than rendered-page sanity.
+- [x] Product Surface exceptions are `none` for preparation.
+- [x] Implementation report/final response must state tests/browser result, Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, deployment impact, and no application implementation performed.
+
+## Cross-Cutting / Shared Pattern Reuse
+
+- **Cross-cutting feature?**: yes, as a read-only audit across product contracts.
+- **Interaction class(es)**: evidence/report viewers, operation proof, dashboard/readiness signals, restore readiness, provider state, customer output, governance inbox, review packs, navigation/surface ownership, status messaging, and audit logs are inspected only.
+- **Systems touched**: Spec artifacts only. Runtime systems are read-only inspection targets.
+- **Existing pattern(s) to extend**: Product Surface Contract, Product Surface gate wording from Spec 395, recent Product Surface migration specs, UI audit artifacts, route inventory, design coverage matrix, implementation ledger, and existing Spec Kit templates.
+- **Shared contract / presenter / builder / renderer to reuse**: N/A - no runtime code.
+- **Why the existing shared path is sufficient or insufficient**: Existing contracts govern individual changes. This audit determines whether those contracts collectively cover the whole product enough for safe continuation.
+- **Allowed deviation and why**: none.
+- **Consistency impact**: Findings must use consistent severity, evidence, and resolution type language.
+- **Review focus**: Confirm the audit does not become implementation, bug fixing, or speculative product design.
+
+## OperationRun UX Impact
+
+- **Touches OperationRun start/completion/link UX?**: no runtime change. OperationRun proof semantics are audited only.
+- **Shared OperationRun UX contract/layer reused**: N/A.
+- **Delegated start/completion UX behaviors**: N/A.
+- **Local surface-owned behavior that remains**: N/A.
+- **Queued DB-notification policy**: N/A.
+- **Terminal notification path**: N/A.
+- **Exception required?**: none.
+
+## Provider Boundary / Platform Core Check
+
+- **Shared provider/platform boundary touched?**: no runtime seam change. The audit inspects provider/platform boundary definitions.
+- **Boundary classification**: audit target only.
+- **Seams affected**: Provider connections, provider freshness, required permissions, managed environments, report/evidence output, Graph contract references, and provider-specific vocabulary may be inspected.
+- **Neutral platform terms preserved or introduced**: No new runtime terms. Audit language should preserve workspace, managed environment, provider, connection, operation, evidence, customer output, and technical/audit detail.
+- **Provider-specific semantics retained and why**: Existing Microsoft/Intune semantics remain repo truth where provider-owned.
+- **Why this does not deepen provider coupling accidentally**: No code, labels, persistence, routing, or operator vocabulary is changed.
+- **Follow-up path**: Provider-boundary gaps become bounded follow-up recommendations, not in-scope fixes.
+
+## UI / Surface Guardrail Impact
+
+N/A - no operator-facing surface change. The audit inspects existing operator/customer/system surfaces and produces report findings only.
+
+## Decision-First Surface Role
+
+N/A - no surface changed. The audit must classify inspected surfaces by decision role where evidence supports it and must flag ambiguity where the role is not specified.
+
+## Audience-Aware Disclosure
+
+N/A - no disclosure changed. The audit must inspect whether customer-readable, operator diagnostic, and support/raw evidence layers are specified for critical surfaces.
+
+## UI/UX Surface Classification
+
+N/A - no surface changed. The audit may report classification gaps.
+
+## Operator Surface Contract
+
+N/A - no new or materially refactored operator-facing page. The audit checks whether existing pages have a clear operator surface contract.
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no runtime source of truth. The final audit report is review evidence only.
+- **New persisted entity/table/artifact?**: no application entity/table. A report may be produced in the final response; a spec-local file is allowed only if the operator explicitly asks for a file output during audit execution.
+- **New abstraction?**: no runtime abstraction.
+- **New enum/state/reason family?**: no runtime status family. Severity and scoring labels are report-only classifications.
+- **New cross-domain UI framework/taxonomy?**: no runtime framework. The audit uses existing Product Surface and Spec Kit vocabulary.
+- **Current operator problem**: Productization can continue while agents still infer product decisions from implementation details.
+- **Existing structure is insufficient because**: Existing specs prove slices, but no current artifact answers whether the combined product contract is complete enough for the next implementation block.
+- **Narrowest correct implementation**: Read-only inventory, scoring, decision-debt register, hallucination-risk map, spec gap list, surface freeze/reduction recommendations, promotion readiness answers, and a single next action.
+- **Ownership cost**: One audit pass and future review of the final report. No recurring runtime maintenance.
+- **Alternative intentionally rejected**: Creating immediate fix specs or runtime changes from assumed gaps. The audit must identify decision debt before implementation.
+- **Release truth**: Current-release productization readiness gate.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: N/A for preparation; read-only audit validation for execution.
+- **Validation lane(s)**: N/A for runtime. Future audit execution must record read-only commands used and dirty state before/after.
+- **Why this classification and these lanes are sufficient**: The spec does not change runtime behavior or tests.
+- **New or expanded test families**: none.
+- **Fixture / helper cost impact**: none.
+- **Heavy-family visibility / justification**: none.
+- **Special surface test profile**: read-only product-contract audit.
+- **Standard-native relief or required special coverage**: N/A - no UI code changes.
+- **Reviewer handoff**: Confirm no application code/tests/docs outside the spec package are changed, no completed specs are rewritten, all P0/P1 findings cite evidence, and recommended follow-up specs are minimal.
+- **Budget / baseline / trend impact**: none.
+- **Escalation needed**: final report may recommend follow-up specs; no implementation in this spec.
+- **Active feature PR close-out entry**: N/A unless this preparation package is reviewed as a specs-only PR.
+- **Planned validation commands**:
+  - `git status --short --branch`
+  - `git diff --name-only`
+  - `git diff --check`
+  - Read-only repo inspection commands selected during audit.
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Determine Whether Product Contracts Are Complete Enough (Priority: P1)
+
+As a product reviewer, I want a repo-based gate result that says whether implementation can continue without inventing product decisions, so that customer-ready productization does not proceed on implicit assumptions.
+
+**Why this priority**: The gate result is the primary value of the audit.
+
+**Independent Test**: The final audit report includes exactly one Candidate Gate Result: `PASS`, `PASS WITH CONDITIONS`, or `FAIL`, with a short evidence-backed reason.
+
+**Acceptance Scenarios**:
+
+1. **Given** a critical surface lacks explicit role, scope, RBAC, evidence, customer visibility, or state semantics, **When** the audit scores the surface, **Then** the report records a decision-debt finding instead of inventing the missing contract.
+2. **Given** no P0/P1 decision debts remain across critical surfaces, **When** the audit completes, **Then** the report may return `PASS` with evidence and remaining residual risks.
+
+---
+
+### User Story 2 - Inventory And Score Critical Product Surfaces (Priority: P1)
+
+As an implementation lead, I want every critical TenantPilot surface scored for product-contract completeness, so that future work can target the real gaps instead of broad rewrites.
+
+**Why this priority**: Without a surface matrix, recommendations become subjective and noisy.
+
+**Independent Test**: The final audit report contains a Product Contract Coverage Matrix covering at least the required primary surfaces from this spec.
+
+**Acceptance Scenarios**:
+
+1. **Given** an audited surface has repo evidence for purpose, role, scope, RBAC, source of truth, evidence/audit, customer visibility, state semantics, and test proof, **When** it is scored, **Then** the matrix records dimension scores and an overall risk.
+2. **Given** a surface lacks evidence for one dimension, **When** it is scored, **Then** the matrix records the gap and does not treat implementation presence as product-contract proof.
+
+---
+
+### User Story 3 - Identify Decision Debt And Hallucination Risk (Priority: P2)
+
+As a future agent reviewer, I want decision debt and hallucination risks named with concrete evidence, so that implementation agents know where to stop and ask for a product decision.
+
+**Why this priority**: This prevents agents from filling gaps with plausible but unapproved behavior.
+
+**Independent Test**: The final audit report contains a Decision Debt Register and Agent Hallucination Risk Map with severity, evidence, impact, and containment.
+
+**Acceptance Scenarios**:
+
+1. **Given** a future agent would likely invent a status, permission, customer-output category, evidence type, navigation structure, readiness rule, or fallback behavior, **When** the audit identifies the risk, **Then** the report records trigger, impact, and containment.
+2. **Given** a behavior contradicts an existing contract, **When** the audit records it, **Then** it is classified as implementation defect rather than product-contract gap.
+
+---
+
+### User Story 4 - Recommend Minimal Follow-Up Specs Or Decisions (Priority: P3)
+
+As a product owner, I want findings grouped into the smallest coherent follow-up set, so that the next step is bounded and reviewable.
+
+**Why this priority**: The audit must prevent automatic spec explosion.
+
+**Independent Test**: The final audit report includes a Spec Gap List, surface freeze/reduction recommendations, promotion readiness answers, and one operational recommended next action.
+
+**Acceptance Scenarios**:
+
+1. **Given** multiple small findings share a product decision root cause, **When** the report recommends follow-up, **Then** it groups them into one coherent spec or product decision instead of many tiny specs.
+2. **Given** a finding is only implementation feedback or can defer, **When** the report classifies it, **Then** it is not promoted into a spec recommendation.
+
+### Edge Cases
+
+- A critical route or surface cannot be inspected because fixtures/auth/runtime are unavailable.
+- A completed spec contains close-out language that looks inconsistent with newer gate wording.
+- A recent implementation report proves a runtime fix, but the corresponding product contract remains under-specified.
+- A surface is implemented and tested but lacks customer visibility semantics.
+- Existing browser screenshots prove rendering but not product-contract completeness.
+- Multiple surfaces use similar readiness words with different implied meanings.
+- A missing product decision could be hidden by passing tests.
+- The working tree becomes dirty during read-only audit commands.
+
+## Functional Requirements
+
+- **FR-001**: The audit MUST inspect repo/spec evidence for at least these surfaces: Workspace-first admin surface, System panel, workspace/environment context selection, Baseline Compare, restore preview/readiness, backup/restore flows, provider connections, provider freshness/permission semantics, evidence overview/anchors, findings, review packs, customer review workspace, OperationRun proof/audit trail, governance inbox, reports/exports/customer output, dashboard/readiness surfaces, support/operational handoff, and stale/failed/partial/empty/warning states.
+- **FR-002**: The audit MUST create an evidence summary listing inspected and not inspected specs, docs, routes/panels, models/policies, tests, views/pages, and browser/runtime evidence.
+- **FR-003**: The audit MUST score each audited surface from 0 to 4 across product purpose, user/role ownership, scope boundary, RBAC/capability contract, source of truth, evidence/audit contract, customer visibility, state semantics, navigation/IA contract, and test/proof coverage.
+- **FR-004**: The audit MUST produce a Product Contract Coverage Matrix with surface, purpose, role/user, scope, RBAC, source of truth, evidence/audit, customer visibility, state semantics, test/proof, score, and risk.
+- **FR-005**: The audit MUST produce a Decision Debt Register with ID, surface, missing decision, why it matters, current evidence, severity, and recommended resolution type.
+- **FR-006**: The audit MUST produce an Agent Hallucination Risk Map with surface, likely hallucination, trigger, impact, and containment.
+- **FR-007**: The audit MUST produce a Spec Gap List that groups future work into the minimum coherent set and labels amendment, new bounded spec, product decision, test contract addition, browser proof addition, documentation clarification, explicit defer, or not-a-spec review feedback.
+- **FR-008**: The audit MUST produce surface freeze/reduction recommendations for major surfaces using one of: freeze as product contract stable, keep but clarify, keep but merge/reduce, hide from customer-facing path, defer from pilot scope, or requires product decision before more work.
+- **FR-009**: The audit MUST answer promotion readiness for next implementation block, full browser/UX/runtime audit, customer-facing hardening, and controlled pilot as Yes, No, or Conditional with one short reason each.
+- **FR-010**: Every P0/P1 finding MUST cite concrete repo/spec evidence such as file path, line number when practical, route, test, spec section, model/policy reference, or visible page/surface reference.
+- **FR-011**: The audit MUST distinguish product-contract gaps, implementation defects, test gaps, surface drift, and terminology drift.
+- **FR-012**: The audit MUST not fix bugs, create tests, create migrations, edit code, edit docs outside this spec package, rewrite completed specs, normalize labels, or add new product decisions.
+- **FR-013**: The audit MUST record dirty state before and after execution and stop/report if a supposedly read-only command changes files.
+- **FR-014**: The audit MUST end with one operational recommended next action.
+
+## Non-Functional Requirements
+
+- **NFR-001**: Work strictly repo-based; no external assumptions may override repository truth.
+- **NFR-002**: Prefer fewer, stronger findings over long noisy lists.
+- **NFR-003**: Treat silence as a finding, not as permission.
+- **NFR-004**: Keep recommendation scope bounded and avoid automatic spec explosion.
+- **NFR-005**: Preserve completed spec history and validation evidence.
+- **NFR-006**: Use read-only commands only during audit execution unless the operator explicitly requests a report file under this spec package.
+
+## Explicitly Out Of Scope
+
+- Application implementation.
+- Bug fixing.
+- Visual redesign.
+- Copywriting cleanup.
+- Database migrations.
+- Test creation or modification.
+- Browser-wide bug hunt.
+- Security penetration testing.
+- Performance audit.
+- Dependency upgrade.
+- Production deployment review.
+- Sales/marketing positioning review.
+- Customer launch approval by itself.
+
+## Required Final Audit Report Structure
+
+The future audit must use this exact top-level structure:
+
+```markdown
+# Spec 400 Audit Report - Product Contract & Spec Completeness
+
+## A. Candidate Gate Result
+## B. Evidence Summary
+## C. Product Contract Coverage Matrix
+## D. Decision Debt Register
+## E. Agent Hallucination Risk Map
+## F. Spec Gap List
+## G. Surface Freeze / Reduction Recommendation
+## H. Promotion Readiness
+## I. Recommended Next Step
+```
+
+## Success Criteria
+
+- **SC-001**: A reviewer can decide from the report whether the next implementation block may proceed, may proceed with conditions, or must stop for product-contract fixes.
+- **SC-002**: 100% of P0/P1 findings include concrete repo/spec evidence.
+- **SC-003**: The report covers every primary surface class listed in FR-001 or marks it explicitly not inspected with a reason.
+- **SC-004**: The report recommends the minimum coherent follow-up set and does not create one spec per small finding.
+- **SC-005**: Dirty state before and after the audit is recorded and unchanged unless the operator explicitly asked for a report file.
+- **SC-006**: No application runtime files, tests, migrations, config, routes, views, policies, models, jobs, or completed spec artifacts are modified.
+
+## Assumptions
+
+- The operator-provided Spec 400 draft is a manual promotion even though the automatic candidate queue is empty.
+- The default output for audit execution is the final response. A durable report file under `specs/400-product-contract-spec-completeness-audit/` requires explicit operator approval during audit execution.
+- Existing completed specs and implementation reports are reliable historical evidence unless current repo truth contradicts them.
+- If browser/runtime inspection is unavailable, the audit records the limitation rather than creating fixtures or changing runtime behavior.
+
+## Risks
+
+- The audit scope is broad; the implementation agent must keep findings high-signal and evidence-backed.
+- Product-contract gaps may be confused with implementation defects unless classification is applied consistently.
+- Existing productization specs may look incomplete under newer wording; completed-spec history must be preserved.
+- Running non-mutating framework commands can still create caches/logs in some environments; dirty-state checks are mandatory.
+
+## Open Questions
+
+None blocking preparation. During audit execution, use response-only output unless the operator explicitly asks for a spec-local report file.
+
+## Follow-Up Spec Candidates *(report-only placeholders)*
+
+The audit may recommend follow-up specs only after evidence is collected. Likely grouping categories, not pre-approved scope:
+
+- Customer-visible evidence and report contract gaps.
+- Restore/readiness and safe-action decision semantics.
+- Provider freshness and permission-state contract gaps.
+- OperationRun proof/currentness and audit-trail contract gaps.
+- Surface ownership, navigation, or Product Surface budget clarifications.
+- Test/browser proof additions where behavior is already defined but not proven.
--- a/specs/400-product-contract-spec-completeness-audit/tasks.md
+++ b/specs/400-product-contract-spec-completeness-audit/tasks.md
@ -0,0 +1,102 @@
+# Tasks: Spec 400 - Product Contract & Spec Completeness Audit
+
+**Input**: `specs/400-product-contract-spec-completeness-audit/spec.md`, `plan.md`, `checklists/requirements.md`, user-provided Spec 400 draft, current roadmap/spec-candidate queue, recent Specs 376-399, Product Surface Contract, and repo truth.
+
+**Tests**: No application tests are required or allowed by default because this spec performs a read-only audit and does not change runtime behavior. The later audit execution records read-only commands, evidence limitations, and dirty state before/after.
+
+## Test Governance Checklist
+
+- [ ] Lane assignment is `N/A - no runtime or test change`.
+- [ ] No Pest, browser, fixture, seed, factory, DB, workspace, tenant, provider, or session setup is introduced.
+- [ ] Planned validation commands are read-only and do not pull in unrelated suite cost.
+- [ ] Browser proof is `N/A - no rendered UI surface changed` unless the operator explicitly asks for read-only browser evidence.
+- [ ] Dirty state before/after is recorded.
+- [ ] Any final follow-up recommendation is grouped and bounded rather than implemented.
+
+## Phase 1: Preparation And Safety
+
+**Purpose**: Establish repo truth and prove the audit can run without implementation.
+
+- [ ] T001 Read `specs/400-product-contract-spec-completeness-audit/spec.md`, `plan.md`, `tasks.md`, and `checklists/requirements.md`.
+- [ ] T002 Record current branch, HEAD, and dirty state before audit execution using read-only git commands.
+- [ ] T003 Use response-only output unless the operator explicitly requests a spec-local report file; record the chosen output mode.
+- [ ] T004 Re-read `.specify/memory/constitution.md`, `.specify/README.md`, `AGENTS.md`, `docs/ai-coding-rules.md`, and relevant `docs/*-guidelines.md`.
+- [ ] T005 Re-read `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `docs/product/standards/product-surface-contract.md`, `docs/product/implementation-ledger.md`, and current UI audit artifacts.
+- [ ] T006 Re-read recent productization specs 376-399 and preserve their completed close-out, validation, screenshot, task, smoke, and implementation-report history as read-only context.
+- [ ] T007 Confirm no migrations, models, services, jobs, policies, routes, Filament resources/pages/widgets, Livewire components, views, tests, config, lock files, docs outside this package, or completed specs will be edited.
+
+## Phase 2: Surface Inventory And Evidence Collection
+
+**Purpose**: Build the audit inventory from repo truth, not assumptions.
+
+- [ ] T008 Inventory routes, panels, navigation, Filament pages/resources/widgets, Livewire/Blade views, policies, models, services, jobs, migrations, tests, and existing browser/artifact evidence relevant to the required surfaces.
+- [ ] T009 For each required surface, record route or navigation entry, owning panel, primary model(s), primary role(s), workspace/environment scope, visible decision/action, evidence or OperationRun dependency, customer-visible status, and relevant tests/specs.
+- [ ] T010 Inspect the Workspace-first admin surface and workspace/environment context-selection contracts.
+- [ ] T011 Inspect the System panel surface and platform-plane access/proof contracts.
+- [ ] T012 Inspect Baseline Compare, restore preview/readiness, backup/restore flows, and restore safety contract evidence.
+- [ ] T013 Inspect provider connections, provider freshness, required permissions, and provider/platform boundary contract evidence.
+- [ ] T014 Inspect evidence overview/anchors, findings, review packs, customer review workspace, reports/exports/customer output, and customer-visible evidence contracts.
+- [ ] T015 Inspect OperationRun proof, audit trail, dashboard/readiness surfaces, governance inbox, support/operational handoff, and stale/failed/partial/empty/warning states.
+- [ ] T016 Record inspected and not-inspected evidence explicitly, including blocker reasons for unavailable surfaces or missing artifacts.
+
+## Phase 3: Product Contract Scoring
+
+**Purpose**: Convert the inventory into an evidence-backed completeness matrix.
+
+- [ ] T017 Score every audited surface from 0 to 4 across product purpose, user/role ownership, scope boundary, RBAC/capability contract, source of truth, evidence/audit contract, customer visibility, state semantics, navigation/IA contract, and test/proof coverage.
+- [ ] T018 Produce the Product Contract Coverage Matrix with surface, purpose, role/user, scope, RBAC, source of truth, evidence/audit, customer visibility, state semantics, test/proof, score, and risk.
+- [ ] T019 Mark any score that depends on assumption, convention, or "probably" as a finding rather than proof.
+- [ ] T020 Distinguish implementation presence from product-contract definition and test/browser proof.
+
+## Phase 4: Decision Debt, Defects, And Hallucination Risk
+
+**Purpose**: Identify where future implementation would be unsafe without a product decision.
+
+- [ ] T021 Create the Decision Debt Register with ID, surface, missing decision, why it matters, current evidence, severity, and recommended resolution type.
+- [ ] T022 Classify each issue as product-contract gap, implementation defect, test gap, surface drift, terminology drift, duplicate/already covered, defer, or not-a-spec review feedback.
+- [ ] T023 Create the Agent Hallucination Risk Map with surface, likely hallucination, trigger, impact, and containment.
+- [ ] T024 Ensure every P0/P1 finding cites concrete repo/spec evidence such as file path, line number where practical, route, test, spec section, model/policy reference, or visible surface reference.
+- [ ] T025 Avoid inventing intended behavior where repo/spec evidence is silent; treat silence as a finding.
+
+## Phase 5: Gap Grouping And Promotion Readiness
+
+**Purpose**: Turn findings into the smallest actionable next step.
+
+- [ ] T026 Group required future work into the minimum coherent Spec Gap List, separating amendments, new bounded specs, product decisions, test contract additions, browser proof additions, documentation clarifications, explicit defers, and non-spec review feedback.
+- [ ] T027 Limit recommended new specs to the smallest necessary set and avoid one spec per tiny finding.
+- [ ] T028 Produce surface freeze/reduction recommendations for each major surface.
+- [ ] T029 Answer whether TenantPilot is ready for the next implementation block, full browser/UX/runtime audit, customer-facing hardening, and controlled pilot as Yes, No, or Conditional with one short reason each.
+- [ ] T030 End with one operational recommended next action.
+
+## Phase 6: Final Report And Close-Out
+
+**Purpose**: Deliver the audit result and prove no implementation occurred.
+
+- [ ] T031 Write the final audit report using the exact required structure from `spec.md`.
+- [ ] T032 If the operator did not explicitly request a file, keep the report in the final response only and do not create artifacts.
+- [ ] T033 If the operator explicitly requested a file, write only the approved spec-local report path and record that file in dirty-state close-out.
+- [ ] T034 Run final read-only dirty-state checks and record dirty state after audit execution.
+- [ ] T035 If unexpected files changed, stop, report exact paths, whether the audit caused them, and whether the result remains trustworthy.
+- [ ] T036 Confirm no application runtime code, tests, migrations, config, routes, views, policies, models, jobs, or completed specs were modified.
+- [ ] T037 Confirm final response states Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, browser/no-browser result, tests/run commands, deployment impact, and explicit no-implementation status.
+
+## Non-Goals Checklist
+
+- [ ] NT001 Do not implement fixes or refactors.
+- [ ] NT002 Do not change application code, tests, migrations, routes, config, policies, models, services, jobs, Filament resources/pages/widgets, Livewire components, Blade views, CSS, JavaScript, seeders, factories, or lock files.
+- [ ] NT003 Do not rewrite completed specs, remove validation evidence, normalize completed task markers, or strip close-out language.
+- [ ] NT004 Do not create fixtures, users, browser auth bypasses, screenshots, or generated reports unless explicitly authorized by the operator.
+- [ ] NT005 Do not invent product decisions, statuses, role rules, readiness logic, customer-output categories, evidence types, or navigation structures.
+- [ ] NT006 Do not turn every finding into a new spec.
+
+## Dependencies And Execution Order
+
+- Phase 1 must complete before any repo inspection beyond already-read preparation context.
+- Phase 2 inventory must complete before scoring.
+- Phase 3 scoring feeds Phase 4 findings.
+- Phase 4 findings feed Phase 5 gap grouping and readiness.
+- Phase 6 must record dirty state and no-implementation proof.
+
+## Recommended Implementation Strategy
+
+Treat the implementation of this spec as an audit, not a code change. Work from repo truth, keep evidence concrete, prefer fewer strong findings, and stop if answering the audit would require product decisions or runtime changes.