.gitea/pull_request_template.md

@@ -27,5 +27,14 @@ ## UI (Filament/Livewire) (falls relevant)
 - [ ] Screenshots/Notizen hinzugefügt
 - [ ] UI Surface Impact in der Spec dokumentiert: entweder `[x] No UI surface impact` mit Begründung oder UI/Productization Coverage + Audit-Artefakte aktualisiert
 
+## Product Surface Contract (falls relevant)
+- [ ] Product Surface Contract geprüft (`docs/product/standards/product-surface-contract.md`)
+- [ ] No-Legacy / keine Compatibility-Shims bestätigt oder Ausnahme dokumentiert
+- [ ] Product Surface Impact, Page Archetype, Surface Budgets, Technical Annex / Deep-Link-Demotion und Status-Vocabulary dokumentiert
+- [ ] Product Surface Exceptions dokumentiert oder `none`
+- [ ] Browser proof erledigt oder `N/A - no rendered UI surface changed` begründet
+- [ ] Human Product Sanity Check und sichtbarer Complexity-Outcome dokumentiert
+- [ ] Implementation Report enthält Tests, Browser/No-Browser, Livewire v4, Provider-Registration, Global Search, destructive actions, Asset-Strategie und Deployment Impact
+
 ## Notes
 <!-- Links, Screenshots, Follow-ups, offene Punkte -->

.specify/README.md

@@ -31,6 +31,23 @@ ## Review Entry Point
 3. Apply the checklist and end with both one review outcome class (`blocker`, `strong-warning`, `documentation-required-exception`, or `acceptable-special-case`) and one workflow outcome (`keep`, `split`, `document-in-feature`, `follow-up-spec`, or `reject-or-split`).
 4. If a guarded surface or exception remains in scope, ensure the active feature PR close-out entry records the final note rather than leaving the decision in scattered review comments.
 
+## Product Surface Contract Gate
+
+Future UI-affecting specs must reference
+`docs/product/standards/product-surface-contract.md` and carry its completion
+gate through `spec.md`, `plan.md`, `tasks.md`, the generated checklist, and
+the PR close-out.
+
+The gate requires a no-legacy posture, Product Surface Impact, page
+archetype, surface-budget decision, Technical Annex/deep-link demotion,
+canonical status vocabulary, Product Surface exception handling, focused
+browser proof or a justified no-browser path, Human Product Sanity status,
+visible complexity outcome, and implementation-report fields.
+
+Completed historical specs are context only. Do not rewrite closed specs,
+delete validation history, or normalize old task/browser evidence solely to
+satisfy new Product Surface wording.
+
 ## Low-Impact Rule
 
 - Docs-only or template-only work may answer `N/A` or `none`.

.specify/memory/constitution.md

@@ -1,35 +1,32 @@
 <!--
 Sync Impact Report
 
-- Version change: 2.13.0 -> 2.14.0
+- Version change: 2.14.0 -> 2.15.0
 - Modified principles:
-  - Added UI/Productization Coverage (UI-COV-001) so every reachable
+  - Added Product Surface Contract Gate (PSC-001) so future UI-affecting
-    product surface needs an explicit productization and design coverage
+    specs must prove page archetype, surface budgets, technical demotion,
-    decision before a feature can be considered complete
+    browser/no-browser proof, human sanity review, and close-out evidence
-  - Expanded governance expectations so specs/PRs that change reachable
+  - Clarified that completed historical specs are context only and must not
-    UI must update the UI audit registry or document a checked no-impact
+    be rewritten to satisfy newer product-surface gate wording
-    decision
 - Added sections:
-  - UI/Productization Coverage (UI-COV-001)
+  - Product Surface Contract Gate (PSC-001)
 - Removed sections: None
 - Templates requiring updates:
-  - .specify/templates/spec-template.md: add mandatory UI Surface Impact
+  - .specify/templates/spec-template.md: add Product Surface Impact,
-    and UI/Productization Coverage blocks ✅
+    browser verification, human sanity, no-legacy, and merge gate prompts
-  - .specify/templates/plan-template.md: add UI coverage guardrail
+  - .specify/templates/plan-template.md: add Filament/Livewire/search/action/
-    planning fields and constitution check item ✅
+    asset/deployment posture and Product Surface close-out planning
-  - .specify/templates/tasks-template.md: add pre-implementation UI
+  - .specify/templates/tasks-template.md: add Product Surface implementation
-    coverage decision and artifact-update tasks ✅
+    report, browser/no-browser, human sanity, and stop-before-runtime-UI tasks
-  - .specify/templates/checklist-template.md: add UI coverage review
+  - .specify/templates/checklist-template.md: add Product Surface review checks
-    checks ✅
+  - .specify/README.md: add Product Surface Contract workflow gate
-  - .codex/prompts/speckit.implement.md: add implementation-loop UI
+  - AGENTS.md: add Product Surface implementation rule
-    coverage guardrail ✅
+  - .gitea/pull_request_template.md: add Product Surface close-out block
-  - .github/agents/speckit.implement.agent.md: add implementation-loop
-    UI coverage guardrail ✅
-  - .gitea/pull_request_template.md: add UI coverage close-out checkbox ✅
 - CI/script updates:
-  - scripts/check-ui-productization-coverage: new diff guard for UI
+  - apps/platform/tests/Feature/Guards/ProductSurfaceContractGateTest.php:
-    surface changes ✅
+    add deterministic file-based workflow guard
-  - .gitea/workflows/test-pr-fast-feedback.yml: run the guard on PRs ✅
+  - apps/platform/tests/Support/TestLaneManifest.php and tests/Pest.php:
+    register the guard as surface-guard / heavy-governance
 - Commands checked:
   - N/A `.specify/templates/commands/*.md` directory is not present
 - Follow-up TODOs: None
@@ -104,6 +101,14 @@ ### UI/Productization Coverage (UI-COV-001)
 - `No UI surface impact` is valid only when the feature does not add, remove, rename, or materially change any reachable UI surface, or when a guarded file path changed for non-surface reasons and the active spec explains that rationale.
 - Reviews and CI SHOULD block PRs that change UI surface files without either coverage artifact updates or an explicit checked no-impact decision.
 
+### Product Surface Contract Gate (PSC-001)
+- Future UI-affecting specs and PRs MUST satisfy the canonical Product Surface Contract at `docs/product/standards/product-surface-contract.md`.
+- The active spec, plan, tasks, checklist, implementation report, and PR close-out MUST carry the same Product Surface decision: no-legacy posture, Product Surface Impact, page archetype, surface-budget compliance or exception, Technical Annex/deep-link demotion, canonical status vocabulary, focused browser proof or justified no-browser path, Human Product Sanity result, visible complexity outcome, and deployment/test evidence.
+- Product Surface exceptions MUST be attributable to the active spec and include page, violated rule or budget, reason, why the exception is not customer/product-facing if applicable, and follow-up when temporary.
+- Runtime UI edits MUST stop until the active spec and plan name exact affected surfaces, browser proof, Product Surface exceptions, and human sanity criteria.
+- The Product Surface Contract MUST NOT become a runtime presenter, enum/status family, persisted taxonomy, component framework, or broad redesign mandate.
+- Completed historical specs are context only. They MUST NOT be rewritten, normalized, reopened, or stripped of close-out, validation, completed task, smoke, browser, or review history solely to satisfy newer Product Surface gate wording.
+
 ### Shared Pattern First For Cross-Cutting Interaction Classes (XCUT-001)
 - Cross-cutting interaction classes such as notifications, status messaging, action links, header actions, dashboard signals/cards, navigation entry points, alerts, evidence/report viewers, and similar operator-facing infrastructure MUST first attach to an existing shared contract, presenter, builder, renderer, or other shared path when one already exists.
 - New local or domain-specific implementations for an existing interaction class are allowed only when the current shared path is demonstrably insufficient for current-release truth.
@@ -1884,4 +1889,4 @@ ### Versioning Policy (SemVer)
 - **MINOR**: new principle/section or materially expanded guidance.
 - **MAJOR**: removing/redefining principles in a backward-incompatible way.
 
-**Version**: 2.14.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-05-17
+**Version**: 2.15.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-06-21

.specify/templates/checklist-template.md

@@ -24,6 +24,16 @@ ## Applicability And Low-Impact Gate
 - [ ] CHK032 Navigation entries/support code and Filament panel/provider changes were explicitly considered as possible reachable UI surface changes, with either coverage artifacts or a checked no-impact rationale.
 - [ ] CHK033 Screenshot and full page-report expectations are proportional; small non-material or pattern-reusing UI changes are not forced into unnecessary audit artifacts.
 
+## Product Surface Contract
+
+- [ ] CHK034 The spec references `docs/product/standards/product-surface-contract.md` when UI-affecting work or product-surface workflow gates are in scope.
+- [ ] CHK035 No-legacy posture is explicit: no compatibility shims, old labels, hidden routes, duplicate UI, fallback readers, or legacy fixtures remain unless an approved exception is documented.
+- [ ] CHK036 Product Surface Impact records page archetype, one primary question, one primary action, surface-budget result, Technical Annex / deep-link demotion, canonical status vocabulary, visible complexity outcome, and Product Surface exceptions or `none`.
+- [ ] CHK037 Browser proof is present for rendered UI changes, or `N/A - no rendered UI surface changed` is justified for docs/template/test-only work.
+- [ ] CHK038 Human Product Sanity is completed where required, or no-surface rationale is recorded.
+- [ ] CHK039 The implementation report / PR close-out includes Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, no completed-spec rewrite assertion, and follow-up candidates.
+- [ ] CHK040 Completed historical specs were not rewritten, normalized, reopened, or stripped of validation, task, smoke, browser, or review history solely to satisfy new Product Surface wording.
+
 ## Native, Shared-Family, And State Ownership
 
 - [ ] CHK003 The surface remains native/shared-primitives first; fake-native controls, GET-form page-body interactions, and simple-overview replacements are not treated as harmless customization.

.specify/templates/plan-template.md

@@ -54,6 +54,33 @@ ## UI / Surface Guardrail Plan
 - **Navigation / Filament provider-panel handling**: [N/A / coverage artifact updated / checked no-impact rationale because rendered UI is unchanged]
 - **Screenshot or page-report need**: [yes/no + proportional rationale; not every small UI change requires either]
 
+## Product Surface Contract Plan
+
+> **Fill for UI-affecting work and workflow gates that govern UI-affecting work. For docs/template/test-only work, state the no-rendered-surface rationale.**
+
+- **Product Surface Contract reference**: [`docs/product/standards/product-surface-contract.md` / N/A]
+- **No-legacy posture**: [canonical replacement / approved compatibility exception / N/A]
+- **Page archetype and surface budget plan**: [archetype + pass/exception / N/A]
+- **Technical Annex and deep-link demotion plan**: [OperationRun/evidence/raw IDs/source keys/payloads demoted / N/A]
+- **Canonical status vocabulary plan**: [mapping or N/A]
+- **Product Surface exceptions**: [none / page + violated rule + reason + follow-up]
+- **Browser verification plan**: [focused route/flow or `N/A - no rendered UI surface changed`]
+- **Human Product Sanity plan**: [review target or N/A]
+- **Visible complexity outcome target**: [decreased / neutral / approved exception / N/A]
+- **Implementation report target**: [path that will record close-out fields]
+
+## Filament / Livewire / Deployment Posture
+
+> **Required for Filament/UI-relevant plans and for implementation close-out. Use `N/A - no runtime UI change` when appropriate.**
+
+- **Livewire v4 compliance**: [Livewire v4.x confirmed / N/A]
+- **Panel provider registration location**: [`apps/platform/bootstrap/providers.php` / no panel change / N/A]
+- **Global search posture**: [no resource changed / disabled / View/Edit page present + `$recordTitleAttribute` / N/A]
+- **Destructive/high-impact action posture**: [none / list action + `->action(...)` + `->requiresConfirmation()` + authorization + audit + tests]
+- **Asset strategy**: [no assets / panel-only / shared registered asset / on-demand loading / `filament:assets` required?]
+- **Testing plan**: [pages/widgets/relation managers/actions/guard tests/browser smoke covered]
+- **Deployment impact**: [env vars / migrations / queues / scheduler / storage / assets / none]
+
 ## Shared Pattern & System Fit
 
 > **Fill when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, navigation entry points, alerts, evidence/report viewers, or any other shared interaction family. Docs-only or template-only work may use concise `N/A`. Carry the same decision forward from the spec instead of renaming it here.**

.specify/templates/spec-template.md

@@ -35,6 +35,14 @@ ## Spec Scope Fields *(mandatory)*
 - **Default filter behavior when tenant-context is active**: [e.g., prefilter to current tenant]
 - **Explicit entitlement checks preventing cross-tenant leakage**: [Describe checks]
 
+## No Legacy / No Backward Compatibility Constraint *(mandatory)*
+
+TenantPilot is pre-production unless this spec explicitly records a compatibility exception.
+
+- **Compatibility posture**: [canonical replacement / compatibility exception]
+- **Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?**: [no / yes + approved exception]
+- **Why clean replacement is safe now**: [current release truth or explicit exception]
+
 ## UI Surface Impact *(mandatory — UI-COV-001)*
 
 Does this spec add, remove, rename, or materially change any reachable UI surface?
@@ -75,6 +83,45 @@ ## UI/Productization Coverage *(mandatory when UI Surface Impact is not "No UI s
   - [ ] `N/A - no reachable UI surface impact`
 - **No-impact rationale when applicable**: [Required when `No UI surface impact` is checked]
 
+## Product Surface Impact *(mandatory for UI-affecting specs; otherwise write `N/A - no rendered product surface changed` plus rationale)*
+
+Reference: `docs/product/standards/product-surface-contract.md`.
+
+- **Product Surface Contract applies?**: [yes/no + rationale]
+- **Page archetype**: [Dashboard / Receipt / Decision / Inbox / Wizard / Report / Search/Index / Technical Annex / Settings / System Admin / N/A]
+- **Primary user question**: [one question or N/A]
+- **Primary action**: [one action or N/A]
+- **Surface budget result**: [pass / exception / N/A]
+- **Technical Annex / deep-link demotion**: [how OperationRun, raw evidence, IDs, payloads, source keys, detectors, fingerprints, and technical logs are hidden/demoted / N/A]
+- **Canonical status vocabulary**: [Ready / Needs attention / Blocked / Running / Failed / Expired / Not configured / Unknown / Historical / Superseded / severity mapping / N/A]
+- **Visible complexity impact**: [decreased / neutral / increased with approved exception / N/A]
+- **Product Surface exceptions**: [none / page + violated budget/rule + reason + follow-up if temporary]
+
+## Browser Verification Plan *(mandatory)*
+
+- **Browser proof required?**: [yes / no]
+- **No-browser rationale**: [`N/A - no rendered UI surface changed` / backend-only / docs-template-test-only / other]
+- **Focused path when required**: [route or flow]
+- **Primary interaction to execute**: [action/form/table/modal/navigation/download/report/readiness/evidence flow]
+- **Console, Livewire, Filament, network, and 500-error checks**: [planned / N/A]
+- **Full-suite failure triage**: [how unrelated failures will be documented if focused proof is green]
+
+## Human Product Sanity Check *(mandatory)*
+
+- **Required?**: [yes / no]
+- **No-human-sanity rationale**: [N/A - no product surface changed / other]
+- **Reviewer questions**: purpose clear, one dominant next action, technical details demoted, status labels canonical, complexity not worse, trust acceptable.
+- **Planned result location**: [implementation-report / PR close-out / N/A]
+
+## Product Surface Merge Gate Checklist *(mandatory)*
+
+- [ ] No-legacy posture or approved exception recorded.
+- [ ] Product Surface Impact is completed or `N/A` is justified.
+- [ ] Browser proof is completed or `N/A - no rendered UI surface changed` is justified.
+- [ ] Human Product Sanity is completed or not applicable with rationale.
+- [ ] Product Surface exceptions are documented or `none`.
+- [ ] Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, and visible complexity outcome.
+
 ## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
 
 - **Cross-cutting feature?**: [yes/no]
@@ -317,6 +364,14 @@ ## Requirements *(mandatory)*
 If there is no reachable UI impact, the spec MUST check exactly `No UI surface impact` and provide a short rationale.
 Coverage is proportional: small non-material UI diffs may use a checked no-impact rationale, normal domain pages may reuse existing patterns, and only strategic, customer-facing, dangerous-action-bearing, or materially new surfaces require screenshots or full page reports.
 
+**Constitution alignment (PSC-001):** If this feature changes rendered UI, routes, actions, downloads, reports, readiness, evidence, provider state, restore flows, customer output, or product-surface workflow gates, the spec MUST satisfy `docs/product/standards/product-surface-contract.md` and describe:
+- no-legacy posture or approved exception,
+- Product Surface Impact, page archetype, surface-budget result, Technical Annex/deep-link demotion, canonical status vocabulary, visible complexity impact, and Product Surface exceptions,
+- focused browser proof or `N/A - no rendered UI surface changed`,
+- Human Product Sanity result or no-surface rationale,
+- implementation-report fields for tests, browser/no-browser, Livewire v4, provider registration, global search, destructive/high-impact actions, asset strategy, deployment impact, and completed-spec rewrite safety.
+Completed historical specs MUST NOT be rewritten or stripped of validation, task, smoke, browser, or review history solely to satisfy newer Product Surface wording.
+
 **Constitution alignment (DECIDE-AUD-001 / OPSURF-001):** If this feature changes a detail or status surface, the spec MUST describe:
 - how the surface separates customer-readable decision content, operator diagnostics, and support/raw evidence,
 - which audience modes are in scope (`customer/read-only`, `operator/MSP`, `support/platform`),

.specify/templates/tasks-template.md

@@ -65,6 +65,9 @@ # Tasks: [FEATURE NAME]
 - determining before implementation whether the spec adds, removes, renames, or materially changes any reachable UI surface,
 - checking exactly `No UI surface impact` in the spec with a short rationale when no reachable UI surface is affected,
 - classifying backend-only, docs-only, tooling-only, test-only, and non-material UI work with a no-impact rationale instead of creating unnecessary page reports,
+- reviewing `docs/product/standards/product-surface-contract.md` before any runtime UI edit,
+- recording the no-legacy posture or approved compatibility exception,
+- completing Product Surface Impact with page archetype, one primary question, one primary action, surface-budget result, Technical Annex / deep-link demotion, canonical status vocabulary, visible complexity impact, and Product Surface exceptions,
 - treating navigation entries, navigation support code, and Filament panel/provider changes as reachable UI surface signals when they affect rendered product access or panel behavior,
 - updating `docs/ui-ux-enterprise-audit/route-inventory.md` and `docs/ui-ux-enterprise-audit/design-coverage-matrix.md` when reachable UI is added or materially changed,
 - assigning page archetype, design depth, repo-truth level, target pattern/mockup need, customer-safe review need, and dangerous-action review need for each affected surface,
@@ -77,7 +80,11 @@ # Tasks: [FEATURE NAME]
 - adding explicit review or definition-of-done work when a guarded surface class, repository signal, or exception path is involved,
 - adding required tests or manual smoke for `shared-detail-family`, `monitoring-state-page`, `global-context-shell`, or `exception-coded-surface`, OR recording `standard-native-filament` relief when no special contract exists,
 - adding exception documentation and spread-control tasks whenever default surface rules are intentionally relaxed,
-- recording the active feature PR close-out entry with guardrail class, exception status, required tests/manual smoke, low-impact `N/A` use, and any deferred automation.
+- recording focused browser proof, or `N/A - no rendered UI surface changed`, before completion,
+- completing Human Product Sanity or documenting no-surface rationale,
+- stopping before runtime UI edits when the active spec/plan do not yet name exact affected surfaces, Product Surface exceptions, browser proof, and human sanity criteria,
+- recording implementation-report close-out fields for tests, browser/no-browser, Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, deployment impact, visible complexity outcome, no completed-spec rewrite assertion, and follow-up candidates,
+- recording the active feature PR close-out entry with guardrail class, exception status, required tests/manual smoke, low-impact `N/A` use, Product Surface outcome, and any deferred automation.
 **Operator Surfaces**: If this feature adds or materially refactors an operator-facing page or flow, tasks MUST include:
 - classifying each affected surface as Primary Decision, Secondary
   Context, or Tertiary Evidence / Diagnostics and keeping that role in
@@ -208,6 +215,8 @@ ## Test Governance Checklist
 - [ ] Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is isolated or documented.
 - [ ] Planned validation commands cover the change without pulling in unrelated lane cost.
 - [ ] The declared surface test profile or `standard-native-filament` relief is explicit.
+- [ ] Browser proof is explicitly `N/A - no rendered UI surface changed` for docs/template/test-only work and required for rendered UI changes.
+- [ ] Human Product Sanity and Product Surface implementation-report close-out are planned where applicable.
 - [ ] Any material budget, baseline, trend, or escalation note is recorded in the active spec or PR.
 
 ## Format: `[ID] [P?] [Story] Description`
@@ -354,6 +363,7 @@ ## Phase N: Polish & Cross-Cutting Concerns
 - [ ] TXXX [P] Additional unit tests (if requested) in tests/unit/
 - [ ] TXXX Security hardening
 - [ ] TXXX Proportionality cleanup: remove or collapse superseded layers introduced during implementation
+- [ ] TXXX Complete Product Surface Contract close-out: no-legacy, Product Surface Impact, browser/no-browser result, Human Product Sanity, visible complexity outcome, implementation report, and PR close-out
 - [ ] TXXX Record the active feature PR close-out entry with guardrail class, exception status, proof depth, and deferred automation
 - [ ] TXXX Run quickstart.md validation
 

Agents.md

@@ -372,6 +372,24 @@ ## Definition of Done
   - Production
   - migrations, env vars, queues
 
+## Product Surface Contract Gate
+
+For any UI-affecting spec or implementation, agents must review
+`docs/product/standards/product-surface-contract.md` before editing runtime
+UI files. The active spec/plan/tasks and PR close-out must state:
+
+- no-legacy posture or approved exception
+- Product Surface Impact and UI Surface Impact
+- page archetype, surface budgets, Technical Annex / deep-link demotion, and canonical status vocabulary
+- Product Surface exceptions or `none`
+- focused browser proof, or `N/A - no rendered UI surface changed`
+- Human Product Sanity result and visible complexity outcome
+- implementation-report fields for tests, browser/no-browser, Livewire v4, provider registration, global search, destructive/high-impact actions, asset strategy, and deployment impact
+
+Completed historical specs are read-only context for this gate. Do not rewrite
+closed specs or remove validation, task, smoke, browser, or review history
+solely to satisfy new Product Surface wording.
+
 ---
 
 ## AI Usage Note

apps/platform/tests/Feature/Guards/ProductSurfaceContractGateTest.php

@@ -0,0 +1,136 @@
+<?php
+
+declare(strict_types=1);
+
+use Tests\Support\TestLaneManifest;
+
+function productSurfaceGateContents(string $relativePath): string
+{
+    $absolutePath = repo_path($relativePath);
+
+    expect(file_exists($absolutePath))->toBeTrue("Missing expected Product Surface Contract file: {$relativePath}");
+
+    return (string) file_get_contents($absolutePath);
+}
+
+/**
+ * @param  list<string>  $needles
+ */
+function productSurfaceGateAssertContains(string $relativePath, array $needles): void
+{
+    $contents = productSurfaceGateContents($relativePath);
+    $missing = [];
+
+    foreach ($needles as $needle) {
+        if (! str_contains($contents, $needle)) {
+            $missing[] = $needle;
+        }
+    }
+
+    expect($missing)->toBeEmpty("Missing Product Surface Contract terms in {$relativePath}:\n".implode("\n", $missing));
+}
+
+it('keeps the product surface contract gate in surface-guard heavy-governance ownership', function (): void {
+    $family = TestLaneManifest::family('product-surface-contract-gate');
+
+    expect($family['classificationId'])->toBe('surface-guard')
+        ->and($family['targetLaneId'])->toBe('heavy-governance')
+        ->and($family['hotspotFiles'])->toContain('tests/Feature/Guards/ProductSurfaceContractGateTest.php');
+});
+
+it('publishes one canonical product surface contract with measurable rules', function (): void {
+    productSurfaceGateAssertContains('docs/product/standards/product-surface-contract.md', [
+        'Page Archetypes',
+        'Surface Budgets',
+        'Technical Evidence Layer',
+        'Canonical Status Vocabulary',
+        'Readiness Truth',
+        'Deep-Link Demotion',
+        'Table Caps',
+        'Browser Verification',
+        'Human Product Sanity',
+        'Implementation Report Fields',
+        'Completed Specs',
+        'This is workflow and standards truth only. It is not a runtime framework',
+    ]);
+
+    productSurfaceGateAssertContains('docs/product/standards/README.md', [
+        'Product Surface Contract',
+        'product-surface-contract.md',
+    ]);
+});
+
+it('requires future specs to carry product surface impact browser proof human sanity and no legacy posture', function (): void {
+    productSurfaceGateAssertContains('.specify/templates/spec-template.md', [
+        'No Legacy / No Backward Compatibility Constraint',
+        'Product Surface Impact',
+        'Browser Verification Plan',
+        'Human Product Sanity Check',
+        'Product Surface Merge Gate Checklist',
+        'docs/product/standards/product-surface-contract.md',
+        'N/A - no rendered UI surface changed',
+    ]);
+
+    productSurfaceGateAssertContains('.specify/templates/checklist-template.md', [
+        'Product Surface Contract',
+        'No-legacy posture is explicit',
+        'Browser proof is present for rendered UI changes',
+        'Human Product Sanity is completed where required',
+        'Completed historical specs were not rewritten',
+    ]);
+});
+
+it('carries product surface closeout posture through plans tasks agents and pull requests', function (): void {
+    productSurfaceGateAssertContains('.specify/templates/plan-template.md', [
+        'Product Surface Contract Plan',
+        'Filament / Livewire / Deployment Posture',
+        'Livewire v4 compliance',
+        'Panel provider registration location',
+        'Global search posture',
+        'Destructive/high-impact action posture',
+        'Asset strategy',
+        'Deployment impact',
+    ]);
+
+    productSurfaceGateAssertContains('.specify/templates/tasks-template.md', [
+        'reviewing `docs/product/standards/product-surface-contract.md` before any runtime UI edit',
+        'Browser proof is explicitly `N/A - no rendered UI surface changed`',
+        'Complete Product Surface Contract close-out',
+        'stopping before runtime UI edits',
+    ]);
+
+    productSurfaceGateAssertContains('Agents.md', [
+        'Product Surface Contract Gate',
+        'focused browser proof, or `N/A - no rendered UI surface changed`',
+        'implementation-report fields for tests, browser/no-browser, Livewire v4',
+    ]);
+
+    productSurfaceGateAssertContains('.gitea/pull_request_template.md', [
+        'Product Surface Contract',
+        'N/A - no rendered UI surface changed',
+        'Livewire v4',
+        'Provider-Registration',
+        'Global Search',
+        'Asset-Strategie',
+        'Deployment Impact',
+    ]);
+});
+
+it('keeps the gate future-facing and protects completed spec history', function (): void {
+    productSurfaceGateAssertContains('docs/product/standards/product-surface-contract.md', [
+        'This contract applies to future and active specs.',
+        'Completed historical specs',
+        'must not be rewritten',
+    ]);
+
+    productSurfaceGateAssertContains('.specify/README.md', [
+        'Completed historical specs are context only.',
+        'Do not rewrite closed specs',
+    ]);
+
+    productSurfaceGateAssertContains('.specify/memory/constitution.md', [
+        'Product Surface Contract Gate (PSC-001)',
+        'Runtime UI edits MUST stop until the active spec and plan name exact affected surfaces',
+        'Completed historical specs are context only.',
+    ]);
+});

apps/platform/tests/Pest.php

@@ -112,6 +112,7 @@
         'Feature/Filament/WorkspaceOnlySurfaceTenantIndependenceTest.php',
         'Feature/Guards/ActionSurfaceContractTest.php',
         'Feature/Guards/OperationLifecycleOpsUxGuardTest.php',
+        'Feature/Guards/ProductSurfaceContractGateTest.php',
         'Feature/Guards/UiBloatRegressionGuardTest.php',
         'Feature/ProviderConnections/CredentialLeakGuardTest.php',
         'Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php',

apps/platform/tests/Support/TestLaneManifest.php

@@ -591,6 +591,34 @@ public static function families(): array
                 'costSignals' => ['source-scan guard inventory', 'customer-safety leakage heuristics', 'manual-review finding classification'],
                 'validationStatus' => 'guarded',
             ],
+            [
+                'familyId' => 'product-surface-contract-gate',
+                'classificationId' => 'surface-guard',
+                'purpose' => 'Keep Product Surface Contract workflow, template, PR, and close-out gates present for future UI-affecting specs.',
+                'currentLaneId' => 'heavy-governance',
+                'targetLaneId' => 'heavy-governance',
+                'selectors' => [
+                    [
+                        'selectorType' => 'group',
+                        'selectorValue' => 'surface-guard',
+                        'selectorRole' => 'include',
+                        'sourceOfTruth' => 'pest-group',
+                        'rationale' => 'Product surface workflow enforcement spans templates, standards, AGENTS, and PR review gates.',
+                    ],
+                    [
+                        'selectorType' => 'file',
+                        'selectorValue' => 'tests/Feature/Guards/ProductSurfaceContractGateTest.php',
+                        'selectorRole' => 'inventory-only',
+                        'sourceOfTruth' => 'manifest',
+                        'rationale' => 'Spec 395 file-based Product Surface Contract workflow gate.',
+                    ],
+                ],
+                'hotspotFiles' => [
+                    'tests/Feature/Guards/ProductSurfaceContractGateTest.php',
+                ],
+                'costSignals' => ['workflow template scan', 'standards contract scan', 'PR close-out gate assertions'],
+                'validationStatus' => 'guarded',
+            ],
             [
                 'familyId' => 'policy-resource-admin-search-parity',
                 'classificationId' => 'discovery-heavy',

docs/product/standards/README.md

@@ -16,6 +16,7 @@ ## Standards Index
 | Filter UX | [filament-filter-ux.md](filament-filter-ux.md) | Filter patterns, persistence, soft-delete, date range, enum sourcing, defaults |
 | Actions UX | [filament-actions-ux.md](filament-actions-ux.md) | Row/bulk/header actions, grouping, destructive safety, inspect affordance |
 | Filament Enterprise UI | [filament-native-enterprise-ui.md](filament-native-enterprise-ui.md) | Custom Blade/widget/page surfaces, primary action hierarchy, badge-first state semantics, and panel-consistent cards |
+| Product Surface Contract | [product-surface-contract.md](product-surface-contract.md) | Page archetypes, surface budgets, Technical Annex demotion, browser proof, human sanity, and implementation close-out gates |
 | Lifecycle Governance | [lifecycle-governance.md](lifecycle-governance.md) | Lifecycle taxonomy, source ownership, transition safeguards, follow-up boundaries |
 | Review Checklist | [list-surface-review-checklist.md](list-surface-review-checklist.md) | PR/spec checklist for any new or modified list surface |
 

docs/product/standards/product-surface-contract.md

@@ -0,0 +1,278 @@
+# Product Surface Contract
+
+> Canonical review and merge-gate contract for product-facing UI surfaces.
+> This is workflow and standards truth only. It is not a runtime framework,
+> database model, presenter layer, enum family, or component library.
+
+**Last reviewed**: 2026-06-21
+
+## Purpose
+
+TenantPilot product surfaces must help the current user make a safe decision.
+They must not expose everything the system knows by default.
+
+This contract applies when a spec adds, removes, renames, or materially changes
+any reachable product surface, including pages, routes, navigation entries,
+tables, forms, modals, drawers, wizard steps, actions, customer views,
+status/readiness/evidence presentation, downloads, reports, provider state,
+restore flows, or workspace/environment context presentation.
+
+Docs-only, template-only, tooling-only, and test-only changes may record
+`N/A - no rendered UI surface changed` when no reachable rendered UI changes.
+
+## No Legacy Posture
+
+TenantPilot is pre-production for this contract. Future product-surface work
+must prefer clean canonical behavior over compatibility with old labels,
+action keys, local status wording, duplicated UI, hidden routes, fallback
+readers, or legacy fixtures unless an active spec explicitly approves a
+compatibility exception.
+
+Do not show old and new concepts together just to preserve pre-production UI
+behavior.
+
+## Product Layers
+
+Every product-facing default view must separate these layers:
+
+- **Product Layer**: visible by default. Shows status, reason, impact, one
+  dominant next action, compact business context, customer-safe evidence
+  summary, and a small status summary when useful.
+- **Technical Evidence Layer**: hidden by default or moved to an internal
+  technical/audit path. Holds OperationRuns, raw evidence IDs, source keys,
+  detectors, fingerprints, UUIDs, payloads, provider payloads, diff internals,
+  logs, and full audit trails.
+
+Product-facing default pages must not expose Technical Evidence Layer content
+by default. Use one secondary/internal action such as `View audit trail`,
+`View internal evidence details`, or `View technical details`, with appropriate
+authorization.
+
+## Page Archetypes
+
+Every touched product page must declare exactly one primary archetype:
+
+- Dashboard Page: What needs attention now?
+- Receipt Page: What happened, when, and can I trust it?
+- Decision Page: What changed and what decision should I make?
+- Inbox Page: What work items need triage?
+- Wizard Page: What step am I on and what do I do next?
+- Report Page: What customer/operator summary can be consumed or exported?
+- Search/Index Page: How do I find a record?
+- Technical Annex Page: What are the internal technical details?
+- Settings Page: What behavior is configured?
+- System Admin Page: What is the platform/system state?
+
+If a page mixes archetypes, reduce it to one archetype, split the page, or
+document a temporary exception with a follow-up.
+
+## Surface Budgets
+
+Product-facing pages must satisfy these budgets unless classified as
+Technical Annex or System Admin, or unless the active spec records an
+exception:
+
+- Max 1 primary user question.
+- Max 1 primary action.
+- Max 2 secondary actions.
+- Max 4 summary metrics above the fold.
+- Max 1 main table visible by default.
+- Max 8 visible rows before Show more, pagination, or full table.
+- Max 1 readiness/status model.
+- Max 1 decision flow.
+- Max 0 raw technical identifiers in the default view.
+- Max 0 OperationRun links in the default view.
+- Max 0 raw Evidence deep links in the default view.
+- Max 0 Source Key, Detector, or Technical Dimension blocks in the default view.
+- Max 0 repeated readiness/status summaries on the same page.
+
+Exceptions must include page, violated budget, reason, why the page is not
+customer/product-facing if applicable, and a follow-up when temporary.
+
+## Canonical Status Vocabulary
+
+Allowed product-facing states:
+
+- Ready
+- Needs attention
+- Blocked
+- Running
+- Failed
+- Expired
+- Not configured
+- Unknown
+- Historical
+- Superseded
+
+Allowed severity states:
+
+- Critical
+- High
+- Medium
+- Low
+- Info
+
+Old or internal terms must be mapped before display. Do not expose `Healthy`,
+`OK`, `Warning`, `At risk`, `Degraded`, `Partially ready`, `Likely stale`,
+or similar terms as independent top-level product states unless an active spec
+records a mapping or exception.
+
+## Readiness Truth
+
+A page may show only one top-level readiness/status truth for a concept.
+
+Required shape:
+
+```text
+Provider readiness: Expired
+Reason: Verification is stale.
+Next action: Verify provider.
+```
+
+Forbidden shape:
+
+```text
+Provider: Healthy
+Verification: Stale
+Permissions: Missing
+Readiness: Ready
+Action: Needs attention
+```
+
+Future readiness-producing specs must declare the canonical source, consumer
+pages, display state, blocking reasons, and whether the state is customer-safe.
+
+## Deep-Link Demotion
+
+Default product views must not expose a graph of internal objects.
+
+Demote these links from default product views:
+
+- OperationRun.
+- Evidence Snapshot or Evidence Artifact.
+- Baseline Snapshot/Profile internals.
+- Detector, Source Key, raw Finding fingerprint.
+- Provider payload.
+- Raw report artifact.
+- Restore operation proof.
+- Technical logs.
+
+Allowed default product links include:
+
+- Open workspace.
+- Open environment.
+- Review blockers.
+- Open customer workspace.
+- Download customer output.
+- Compare to current.
+- Verify provider.
+- Resolve finding.
+- Open report.
+- Start restore.
+
+Internal/audit links are allowed as secondary/internal actions only.
+
+## Table Caps
+
+Product-facing hot tables must default to:
+
+- Max 8 visible rows.
+- Pagination or Show all for more.
+- Clear row status.
+- One row primary action.
+- No raw IDs as primary labels.
+- No excessive inline links.
+
+Technical Annex and System Admin pages may show more rows, but they must be
+clearly technical/system-facing.
+
+## Action Model
+
+Every product-facing page must define:
+
+- Primary action.
+- Secondary actions.
+- Danger/destructive actions.
+- Technical/audit actions.
+
+There may be only one primary action. Destructive or high-impact actions must
+be visually separated, authorization-checked, audit-logged when mutating, and
+confirmation-protected.
+
+## Role And Audience Boundaries
+
+Customer/read-only default paths must not expose raw evidence, raw IDs,
+OperationRun proof, fingerprints, payloads, source keys, internal reason
+ownership, platform reason families, or debug semantics by default.
+
+Operator diagnostics may expose more detail through progressive disclosure.
+Support/raw evidence must be capability-gated where the audience model
+distinguishes support or platform users from ordinary operators.
+
+Provider-specific terms remain Technical Annex or provider diagnostics detail
+unless the immediate product decision requires them.
+
+## Browser Verification
+
+Every implemented spec that changes rendered UI, routes, actions,
+authorization, downloads, reports, readiness, evidence, provider state,
+restore flows, customer output, or Product Surface Contract behavior must
+include focused browser verification.
+
+If no runtime UI files change, record browser proof as
+`N/A - no rendered UI surface changed`.
+
+If runtime UI changes, the implementation report must record affected routes,
+the focused browser path, primary interaction executed, expected state,
+console/runtime/network result, Livewire/Filament errors if any, and whether
+any full-suite browser failures are unrelated.
+
+## Human Product Sanity
+
+A 5 to 15 minute human product sanity check is required for customer-facing
+surfaces, dashboards, readiness/status surfaces, review/report output,
+restore/wizard flows, provider onboarding/readiness, evidence/baseline pages,
+navigation changes, and Product Surface Contract changes.
+
+The reviewer must answer:
+
+- Does the page immediately communicate its purpose?
+- Is there exactly one dominant next action?
+- Are technical details demoted?
+- Are status labels understandable and canonical?
+- Does the page feel less complex or at least not worse?
+- Would a customer/operator trust the flow?
+
+For docs/template/test-only contract changes, record this as a workflow sanity
+check rather than a rendered-page review.
+
+## Implementation Report Fields
+
+Every Product Surface Contract implementation close-out must state:
+
+- Active spec and selected slice.
+- Branch, HEAD, and dirty state.
+- Files changed.
+- Runtime UI files changed yes/no.
+- UI impact or no-impact decision.
+- Product Surface exceptions, if any.
+- Browser proof or `N/A - no rendered UI surface changed`.
+- Human product sanity result.
+- Visible complexity outcome.
+- No-legacy confirmation.
+- Completed-spec rewrite assertion.
+- Tests/checks run and results.
+- Livewire v4 compliance.
+- Provider registration location.
+- Global search posture.
+- Destructive/high-impact action posture.
+- Asset strategy and whether `filament:assets` is required.
+- Deployment impact for env vars, migrations, queues, scheduler, storage, and assets.
+- Unrelated failures and follow-up candidates.
+
+## Completed Specs
+
+This contract applies to future and active specs. Completed historical specs
+must not be rewritten, normalized, reopened, or stripped of close-out,
+validation, task, smoke, browser, or review history just to satisfy new gate
+wording.

docs/ui-ux-enterprise-audit/README.md

@@ -65,6 +65,12 @@ ## Ongoing Design Coverage Gate
 
 After Spec 323, every UI-relevant feature must update this registry when it introduces or materially changes a reachable page, modal, drawer, form, table, action, or customer-facing state.
 
+Spec and PR close-out must also satisfy the Product Surface Contract in
+`docs/product/standards/product-surface-contract.md`. The audit registry
+records coverage; the Product Surface Contract records the product-surface
+completion gate, browser/no-browser proof, human sanity review, surface
+budgets, Technical Annex demotion, and implementation-report requirements.
+
 The mechanical PR guard is `scripts/check-ui-productization-coverage`. The PR fast-feedback workflow runs it against `origin/dev`: if guarded UI surface paths change under `apps/platform/app/Filament/`, `apps/platform/app/Support/Navigation/`, `apps/platform/app/Providers/Filament/`, `apps/platform/resources/views/`, `apps/platform/app/Livewire/`, or `apps/platform/routes/`, the PR must also update a real UI coverage artifact, or the active spec must contain a checked UI impact decision or a checked `- [x] No UI surface impact` decision with nearby non-empty rationale.
 
 Standalone usage:

docs/ui/action-surface-contract.md

@@ -7,6 +7,12 @@ # Action surface contract
 
 This project enforces a small “action surface contract” for Filament Resources / Pages / RelationManagers to keep table UIs consistent, quiet, and safe.
 
+This contract governs Filament action placement and inspect affordances. The
+broader product-surface merge gate, including page archetypes, surface budgets,
+Technical Annex demotion, browser proof, human sanity review, and
+implementation-report fields, lives in
+`docs/product/standards/product-surface-contract.md`.
+
 ## Inspect affordance (required)
 
 Any list-style surface that exposes records must provide an **inspect affordance** so an admin can open a record.

docs/ui/operator-ux-surface-standards.md

@@ -21,6 +21,11 @@ # Operator UX & Surface Standards
 document complements the constitution and MUST NOT be used as a parallel
 rulebook that redefines those terms.
 
+For product-surface completion gates, page archetypes, surface budgets,
+Technical Annex demotion, browser proof, human sanity review, and
+implementation-report fields, use the canonical Product Surface Contract:
+`docs/product/standards/product-surface-contract.md`.
+
 ## 1. Purpose
 
 TenantPilot is not a generic admin UI. It is an enterprise operator product for managed Microsoft tenant governance, backup, restore, monitoring, drift detection, and review workflows.
@@ -499,6 +504,8 @@ ## 14. Adoption Rules
 `.specify/templates/checklist-template.md`, and `.specify/README.md`.
 This document remains the rule and reference layer, not a second checklist
 or close-out workflow.
+The Product Surface Contract in `docs/product/standards/product-surface-contract.md`
+is the close-out gate for future UI-affecting specs.
 
 Recommended spec fields:
 

specs/395-product-surface-gate/checklists/requirements.md

@@ -0,0 +1,49 @@
+# Requirements Checklist: Spec 395 - Product Surface Contract Enforcement and Surface Reduction Gate v1
+
+**Purpose**: Validate preparation readiness for Spec 395 before implementation.
+**Created**: 2026-06-21
+**Feature**: `specs/395-product-surface-gate/spec.md`
+
+## Spec Quality
+
+- [x] CHK001 The selected candidate is directly provided by the user as Spec 395 and is not inferred from the automatic candidate queue.
+- [x] CHK002 The completed-spec guardrail treats Specs 370, 375, and 377 as completed context only and does not reopen or rewrite their history.
+- [x] CHK003 The spec states the concrete product problem: UI-affecting work can pass technically while expanding operator surface area, duplicating truth, exposing raw details, or skipping human/browser review.
+- [x] CHK004 The spec defines the smallest enterprise-capable slice: a workflow/contract/guardrail gate with targeted tests, not a broad runtime redesign.
+- [x] CHK005 Functional requirements are testable through documentation/template/guard assertions.
+- [x] CHK006 Out-of-scope boundaries exclude broad page redesign, runtime Product Surface frameworks, migrations, models, routes, Filament page/resource changes, and browser visual regression infrastructure.
+- [x] CHK007 Risks, assumptions, and follow-up candidates are recorded.
+
+## Constitution And Guardrails
+
+- [x] CHK008 UI Surface Impact is completed as `No UI surface impact` for the default slice with a rationale.
+- [x] CHK009 Product Surface Impact requires future UI-affecting specs to declare page archetype, surface budget, technical demotion, browser proof, human sanity, and exception handling.
+- [x] CHK010 Cross-cutting shared pattern reuse names existing UI bloat/productization guards and avoids a runtime UI framework.
+- [x] CHK011 OperationRun UX impact states no OperationRun behavior is touched and future OperationRun links should be demoted by default.
+- [x] CHK012 Provider boundary treatment keeps provider-specific terms in Technical Annex/provider diagnostics, not platform-core product vocabulary.
+- [x] CHK013 Proportionality review justifies a narrow workflow gate and rejects full redesign, visual regression, and runtime taxonomy/framework work.
+- [x] CHK014 RBAC, workspace/tenant isolation, auditability, and data minimization are addressed as no-runtime-impact constraints.
+- [x] CHK015 Test governance names `surface-guard` / heavy-governance ownership and forbids hidden browser/DB fixture cost.
+- [x] CHK016 Filament v5 / Livewire v4 compliance, provider registration, global search, destructive action, asset, testing, and deployment posture are stated in the plan.
+
+## Task Readiness
+
+- [x] CHK017 `tasks.md` includes repo-truth and completed-spec source verification before implementation edits.
+- [x] CHK018 `tasks.md` includes canonical contract/documentation tasks before template references.
+- [x] CHK019 `tasks.md` includes Spec Kit template, AGENTS, and PR checklist gate tasks.
+- [x] CHK020 `tasks.md` includes targeted guard-test and lane-registration tasks.
+- [x] CHK021 `tasks.md` includes a stop-before-runtime-UI-change boundary and follow-up-candidate path.
+- [x] CHK022 `tasks.md` includes validation, browser/no-browser rationale, human sanity, and implementation-report tasks.
+- [x] CHK023 `tasks.md` includes explicit non-goals to prevent runtime UI redesign creep.
+
+## Preparation Outcome
+
+- [x] CHK024 Candidate Selection Gate result: pass for a user-provided explicit candidate.
+- [x] CHK025 Spec Readiness Gate result: pass for preparation.
+- [x] CHK026 Plan Readiness Gate result: pass for preparation.
+- [x] CHK027 Tasks Readiness Gate result: pass for implementation handoff.
+- [x] CHK028 Workflow outcome: keep as prepared, implementation not started.
+
+## Notes
+
+This checklist validates preparation only. It does not claim Product Surface Contract implementation, guard-test execution, PR-template enforcement, browser verification, human sanity review, or runtime UI reduction.

specs/395-product-surface-gate/implementation-report.md

@@ -0,0 +1,104 @@
+# Implementation Report: Spec 395 - Product Surface Contract Enforcement and Surface Reduction Gate v1
+
+## Repo State
+
+- **Branch**: `395-product-surface-gate`
+- **Starting HEAD**: `a6c064cb feat: improve provider readiness semantics and freshness guidance (#465)`
+- **Initial dirty state**: `specs/395-product-surface-gate/` existed as an untracked prepared spec directory before implementation.
+- **Selected implementation slice**: default workflow/docs/templates/tests slice.
+- **Runtime UI default**: no rendered UI, route, Filament, Livewire, Blade, CSS, JavaScript, navigation, panel provider, action, table, form, modal, resource, relation manager, widget, or asset change.
+
+## Product Surface Contract Location
+
+- **Canonical location**: `docs/product/standards/product-surface-contract.md`
+- **Why this location**: `docs/product/standards/` already owns concrete product standards and indexes guard-enforced review contracts. Keeping the Product Surface Contract there avoids duplicating full rule tables across `.specify/`, AGENTS, and PR templates.
+- **Related references updated**: `docs/product/standards/README.md`, `docs/ui/operator-ux-surface-standards.md`, `docs/ui/action-surface-contract.md`, and `docs/ui-ux-enterprise-audit/README.md`.
+
+## Constitution Amendment
+
+- **Amendment**: added `Product Surface Contract Gate (PSC-001)`.
+- **Version change**: `2.14.0 -> 2.15.0`.
+- **Last amended**: `2026-06-21`.
+- **Rationale**: Future UI-affecting specs need a hard completion gate for page archetype, surface budgets, technical demotion, browser/no-browser proof, human sanity review, no-legacy posture, visible complexity outcome, and close-out evidence.
+- **Impacted templates/specs list**: `.specify/templates/spec-template.md`, `.specify/templates/plan-template.md`, `.specify/templates/tasks-template.md`, `.specify/templates/checklist-template.md`, `.specify/README.md`, `Agents.md`, `.gitea/pull_request_template.md`, and Spec 395 implementation artifacts.
+
+## Guardrail And Test Governance
+
+- **Test purpose / classification**: Heavy-Governance / `surface-guard`.
+- **New guard family**: `product-surface-contract-gate`.
+- **Lane registration**: `apps/platform/tests/Support/TestLaneManifest.php` and `apps/platform/tests/Pest.php`.
+- **Fixture cost**: file-based repository assertions only; no browser, provider, tenant, workspace, session, queue, or seed fixture added by this feature.
+- **Runtime/lane impact**: one new deterministic guard file in the existing surface-guard family; no fast-feedback lane expansion.
+
+## Browser And Human Sanity
+
+- **Browser proof**: `N/A - no rendered UI surface changed`.
+- **No-browser rationale**: implementation changed workflow docs, standards docs, Spec Kit templates, PR checklist, and guard tests only.
+- **Human Product Sanity**: workflow sanity check completed against the contract wording. The default rendered product surface is unchanged, and the gate requires future UI-affecting specs to prove one dominant action, technical demotion, canonical statuses, and neutral/decreased visible complexity.
+
+## Runtime And Deployment Impact
+
+- **Livewire v4 compliance**: unchanged; project runs Livewire 4.1.4 and no Livewire code changed.
+- **Provider registration location**: unchanged; Laravel 12 panel providers remain in `apps/platform/bootstrap/providers.php`.
+- **Global search posture**: unchanged; no Filament Resource or globally searchable resource changed.
+- **Destructive/high-impact actions**: none added or changed.
+- **Asset strategy**: no Filament assets registered; `filament:assets` is not required for this slice.
+- **Environment variables**: none.
+- **Migrations**: none.
+- **Queues / scheduler**: unchanged.
+- **Storage / volumes**: unchanged.
+
+## Completed-Spec Rewrite Assertion
+
+Specs 368, 370, 375, and 377 were read as historical context only. No completed spec close-out, validation result, completed task, smoke result, browser evidence, screenshot, or review history was rewritten or removed.
+
+## First Reduction Boundary
+
+- **Runtime reduction included**: no.
+- **Reason**: all candidate runtime reductions would require page-specific UI coverage, browser proof, and human sanity criteria. Spec 395 v1 ships the gate first and records those runtime reductions as follow-up candidates.
+- **Follow-up candidates**:
+  - Receipt Page Reduction Pass: Evidence Snapshot, Baseline Snapshot, Restore Run Detail, Review Pack Receipt.
+  - Decision Page Reduction Pass: Baseline Compare, Restore Preview, Review Resolution Decision.
+  - Dashboard and Inbox Link Budget Pass: Environment Dashboard, Workspace Overview, Governance Inbox, Findings, Operations Hub.
+  - CI strictness expansion for UI bloat/product-surface guard rules after allowlist cleanup.
+  - Manual system-panel browser fixture or documented audit procedure from Spec 377.
+
+## Validation Results
+
+- `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProductSurface`: passed, 5 tests / 25 assertions. Final rerun duration: 11.88s.
+- `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=UiBloatRegressionGuard`: passed, 10 tests / 40 assertions. Duration: 26.20s.
+- `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=TestLaneManifest`: passed, 6 tests / 327 assertions. Duration: 25.94s.
+- `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`: passed.
+- `git diff --check`: passed.
+- New/untracked file whitespace check via `git diff --check --no-index`: passed for `ProductSurfaceContractGateTest.php`, `product-surface-contract.md`, and Spec 395 artifacts.
+- `bash scripts/check-ui-productization-coverage HEAD`: passed with `no guarded UI surface paths changed`.
+- Runtime-reduction inspection: `rg` found page-specific candidates such as OperationRun links, `Open operation` labels, and System widget `Healthy` / `Warning` labels. No runtime reduction was included because each candidate requires exact surface coverage, browser proof, and human sanity criteria under a separate scoped UI update.
+
+## Files Changed
+
+- `.gitea/pull_request_template.md`
+- `.specify/README.md`
+- `.specify/memory/constitution.md`
+- `.specify/templates/checklist-template.md`
+- `.specify/templates/plan-template.md`
+- `.specify/templates/spec-template.md`
+- `.specify/templates/tasks-template.md`
+- `Agents.md`
+- `apps/platform/tests/Feature/Guards/ProductSurfaceContractGateTest.php`
+- `apps/platform/tests/Pest.php`
+- `apps/platform/tests/Support/TestLaneManifest.php`
+- `docs/product/standards/README.md`
+- `docs/product/standards/product-surface-contract.md`
+- `docs/ui-ux-enterprise-audit/README.md`
+- `docs/ui/action-surface-contract.md`
+- `docs/ui/operator-ux-surface-standards.md`
+- `specs/395-product-surface-gate/checklists/requirements.md`
+- `specs/395-product-surface-gate/implementation-report.md`
+- `specs/395-product-surface-gate/plan.md`
+- `specs/395-product-surface-gate/spec.md`
+- `specs/395-product-surface-gate/tasks.md`
+
+## Known Limitations
+
+- The Product Surface Contract is a workflow and review gate, not a complete runtime scanner for every rule.
+- CI hard-fail expansion for all Product Surface rules remains out of scope until false-positive behavior is proven.

specs/395-product-surface-gate/plan.md

@@ -0,0 +1,267 @@
+# Implementation Plan: Spec 395 - Product Surface Contract Enforcement and Surface Reduction Gate v1
+
+**Branch**: `395-product-surface-gate` | **Date**: 2026-06-21 | **Spec**: `specs/395-product-surface-gate/spec.md`
+**Input**: Feature specification from `specs/395-product-surface-gate/spec.md`
+
+## Summary
+
+Install the Product Surface Contract as a hard workflow and merge gate without redesigning pages. The implementation should update durable principles, Spec Kit templates, AGENTS workflow instructions, PR/merge checklist, product-surface standards documentation, and targeted guard tests so future UI-affecting specs must declare surface impact, page archetype, surface budgets, technical demotion, canonical status vocabulary, focused browser verification, human product sanity review, and no-legacy behavior.
+
+The default slice is workflow/guardrail only. Runtime UI changes are out of scope unless this spec and plan are first updated with exact affected surfaces and UI/Productization Coverage.
+
+## Technical Context
+
+**Language/Version**: PHP 8.4.15, Laravel 12.52, Filament 5.2.1, Livewire 4.1.4.
+**Primary Dependencies**: Laravel, Filament, Livewire, Pest 4, existing Spec Kit scripts/templates, existing UI bloat/productization guards.
+**Storage**: No database or persisted product data changes.
+**Testing**: Pest 4 guard tests through Sail; optional browser smoke only if runtime UI is touched.
+**Validation Lanes**: heavy-governance/surface-guard for workflow/template guard tests; browser lane only for rendered UI changes.
+**Target Platform**: Laravel monolith under `apps/platform`, documentation/workflow files at repo root.
+**Project Type**: Web application and Spec Kit workflow.
+**Performance Goals**: Guard tests remain deterministic and avoid database/browser fixtures for the default slice.
+**Constraints**: No runtime UI change by default; no new dependencies; no completed spec rewriting; no broad page redesign.
+**Scale/Scope**: Cross-workflow enforcement for future specs touching `/admin`, `/system`, and product-facing surfaces.
+
+## Repository Surfaces Likely Affected
+
+Primary workflow and standards files:
+
+```text
+.specify/memory/constitution.md
+.specify/templates/spec-template.md
+.specify/templates/plan-template.md
+.specify/templates/tasks-template.md
+.specify/templates/checklist-template.md
+.specify/README.md
+AGENTS.md
+.gitea/pull_request_template.md
+docs/product/standards/README.md
+docs/ui/operator-ux-surface-standards.md
+docs/ui/action-surface-contract.md
+docs/ui-ux-enterprise-audit/README.md
+```
+
+Possible new or updated contract location, to be selected by implementation after checking current docs:
+
+```text
+docs/product/standards/product-surface-contract.md
+```
+
+Primary test/guard files:
+
+```text
+apps/platform/tests/Feature/Guards/UiBloatRegressionGuardTest.php
+apps/platform/tests/Feature/Guards/ProductSurfaceContractGateTest.php
+apps/platform/tests/Support/TestLaneManifest.php
+scripts/check-ui-productization-coverage
+scripts/validate-ui-productization-coverage-guard
+```
+
+Existing guard/test context to reuse:
+
+```text
+apps/platform/tests/Feature/Guards/ActionSurfaceContractTest.php
+apps/platform/tests/Feature/Guards/BrowserLaneIsolationTest.php
+apps/platform/tests/Architecture/Spec392DeprecatedCustomerOutputDownloadGuardTest.php
+apps/platform/tests/Feature/ProviderConnections/Spec394ProviderFreshnessProductSanityTest.php
+```
+
+Runtime UI files are not in the default scope.
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: workflow-only guardrail change by default.
+- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**: No rendered surface in the default slice.
+- **No-impact class, if applicable**: docs-only, template-only, tooling/test-only.
+- **Native vs custom classification summary**: N/A for rendered UI; future runtime work must be native/shared-primitives first.
+- **Shared-family relevance**: status messaging, action links, evidence/report viewers, technical/audit links, implementation close-out reports.
+- **State layers in scope**: workflow/template state only; no shell/page/detail runtime state.
+- **Audience modes in scope**: operator-MSP, customer/read-only, support-platform, and system admin as review categories, not runtime modes.
+- **Decision/diagnostic/raw hierarchy plan**: product layer first, technical evidence layer demoted to Technical Annex/internal/audit paths.
+- **Raw/support gating plan**: documented as future default; no runtime gating change in default slice.
+- **One-primary-action / duplicate-truth control**: templates and contract require future touched pages to identify one primary question and one primary action.
+- **Handling modes by drift class or surface**: hard-stop for missing gate sections; review-mandatory for budget exceptions; follow-up-spec for broad page reductions.
+- **Repository-signal treatment**: guarded UI path changes require UI impact decision or coverage artifacts; workflow docs/tests must enforce this.
+- **Special surface test profiles**: `surface-guard` for guard tests; browser smoke only when runtime UI changes.
+- **Required tests or manual smoke**: targeted Pest guard tests for template/workflow content; focused browser smoke if runtime UI changes.
+- **Exception path and spread control**: every Product Surface exception requires page, violated budget, reason, why not customer/product-facing, and follow-up if temporary.
+- **Active feature PR close-out entry**: Guardrail / Smoke Coverage / Human Product Sanity.
+- **UI/Productization coverage decision**: `No UI surface impact` for the default slice.
+- **Coverage artifacts to update**: none unless runtime UI changes. If runtime UI changes, update route inventory/design matrix/page report or explicit no-impact rationale before code.
+- **No-impact rationale**: workflow/template/docs/tests only.
+- **Navigation / Filament provider-panel handling**: no provider or navigation change by default.
+- **Screenshot or page-report need**: no for default slice; yes for any runtime UI reduction that changes rendered pages.
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes, as a workflow/guardrail and standards change.
+- **Systems touched**: Spec Kit templates, constitution, AGENTS, PR checklist, product UI standards, UI bloat guard, UI coverage guard, test lane manifest.
+- **Shared abstractions reused**: existing `UiBloatScanner`, UI coverage guard script, Pest guard patterns, `TestLaneManifest` surface-guard lane ownership, existing action-surface standards.
+- **New abstraction introduced? why?**: No runtime abstraction. A new guard test file may be introduced to enforce workflow content.
+- **Why existing abstraction was sufficient or insufficient**: Existing guards detect UI bloat and coverage acknowledgment, but do not ensure every future spec/implementation includes Product Surface Impact, Browser Verification Plan, Human Product Sanity Check, or Merge Gate Checklist.
+- **Bounded deviation / spread control**: New workflow terms are documentation and review terms only. They must not become a runtime presenter, enum, table, or component framework.
+
+## OperationRun UX Impact
+
+- **Touches OperationRun start/completion/link UX?**: no.
+- **Central contract reused**: N/A.
+- **Delegated UX behaviors**: N/A.
+- **Surface-owned behavior kept local**: none.
+- **Queued DB-notification policy**: N/A.
+- **Terminal notification path**: N/A.
+- **Exception path**: none.
+
+The Product Surface Contract requires future product default views to demote OperationRun links unless the page is Technical Annex/System Admin or an exception is documented.
+
+## Provider Boundary & Portability Fit
+
+- **Shared provider/platform boundary touched?**: no runtime seam.
+- **Provider-owned seams**: no code change; provider payload and required-permission examples remain provider-owned technical detail.
+- **Platform-core seams**: product-surface vocabulary, page archetypes, default status vocabulary, and Technical Annex rules.
+- **Neutral platform terms / contracts preserved**: workspace, environment, provider connection, evidence, operation, audit trail, technical details.
+- **Retained provider-specific semantics and why**: Microsoft/provider terms may appear in provider diagnostics and Technical Annex examples. They must not become default platform product vocabulary.
+- **Bounded extraction or follow-up path**: document-in-feature for contained exceptions; follow-up-spec for repeated provider-surface drift.
+
+## Domain / Model Implications
+
+No new model, migration, table, enum, persisted state, OperationRun type, queue job, policy, route, or service is planned. The only "entities" are documentation and workflow artifacts.
+
+If implementation discovers that enforcement needs runtime storage or a new status enum, it must stop and update the spec/plan because that exceeds this v1 scope.
+
+## UI / Filament / Livewire Implications
+
+- Livewire v4.1.4 compliance remains unchanged.
+- Filament panel providers remain registered in `apps/platform/bootstrap/providers.php`; no panel provider change is planned.
+- No Filament Resource, RelationManager, Page, action, table, form, modal, widget, cluster, render hook, asset, or navigation entry is changed by default.
+- If runtime UI changes become necessary, implementation must update the UI Surface Impact and UI Action Matrix before editing code.
+- Global search posture is unchanged. No globally searchable resource is added or modified.
+- No destructive/high-impact action is added or changed.
+- No Filament asset registration is planned; `filament:assets` is not required for this slice.
+
+## Constitution Check
+
+- Inventory-first: N/A, no inventory or snapshot behavior.
+- Read/write separation: PASS, no runtime writes.
+- Graph contract path: PASS, no Graph calls.
+- Deterministic capabilities: N/A.
+- RBAC-UX: PASS, no authorization changes; future specs must preserve capability-first RBAC.
+- Workspace isolation: PASS, no runtime queries.
+- Tenant isolation: PASS, no runtime queries.
+- Run observability: N/A, no long-running or remote work.
+- OperationRun start UX: N/A.
+- Ops-UX 3-surface feedback: N/A.
+- Automation: N/A.
+- Data minimization: PASS, no sensitive runtime data captured by default.
+- Test governance: PASS, surface-guard lane is explicit.
+- Proportionality: PASS with review in `spec.md`; new governance vocabulary is documentation/workflow truth only.
+- No premature abstraction: PASS, no runtime abstraction.
+- Persisted truth: PASS, no database persistence.
+- Behavioral state: PASS, no runtime state family.
+- UI semantics: PASS with risk; gate must not create a runtime UI semantics framework.
+- Shared pattern first: PASS, reuse existing UI bloat/productization guard paths.
+- Provider boundary: PASS, provider internals are demoted from default product UI.
+- V1 explicitness / few layers: PASS, direct template/docs/tests updates.
+- Spec discipline / bloat check: PASS, the broad gate is grouped into one coherent spec rather than many micro-specs.
+- Badge semantics: PASS, no badge mapping change. Future status display must use BADGE-001.
+- Filament-native UI: PASS by no runtime UI changes. Future runtime work must use native/shared primitives.
+- UI/Productization coverage: PASS, this plan carries a checked no-impact rationale.
+- Filament Action Surface Contract: PASS, no action topology change.
+- UX-001 Layout and IA: N/A for runtime UI.
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: Heavy-Governance / surface-guard for template/docs/workflow gate tests.
+- **Affected validation lanes**: targeted guard test; heavy-governance ownership if added to manifest.
+- **Why this lane mix is the narrowest sufficient proof**: The change is cross-workflow and surface-governance oriented; it should not enter fast-feedback unless implementation proves a tiny targeted assertion is cheap and non-broad.
+- **Narrowest proving commands**:
+  - `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProductSurface`
+  - `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=UiBloatRegressionGuard`
+  - `git diff --check`
+  - `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent` if PHP files change
+- **Fixture / helper / factory / seed / context cost risks**: none for workflow guard tests.
+- **Expensive defaults or shared helper growth introduced?**: no.
+- **Heavy-family additions, promotions, or visibility changes**: possible new `product-surface-contract-gate` family in `TestLaneManifest`, classified as `surface-guard`.
+- **Surface-class relief / special coverage rule**: no browser proof for docs/template/test-only default slice.
+- **Closing validation and reviewer handoff**: confirm guard tests pass, workflow artifacts contain required sections, no runtime files changed unless spec/plan updated, and completed specs are untouched.
+- **Budget / baseline / trend follow-up**: document runtime of any new guard family; no lane budget change expected.
+- **Review-stop questions**: Does the implementation create a runtime framework? Did it touch UI without updating coverage? Did it skip browser proof for rendered UI? Did it rewrite completed specs?
+- **Escalation path**: document-in-feature for contained exceptions; follow-up-spec for broad page reductions or CI hard-fail expansion.
+- **Active feature PR close-out entry**: Guardrail / Smoke Coverage / Human Product Sanity.
+- **Why no dedicated follow-up spec is needed**: The enforcement gate is a bounded workflow change. Page-specific reductions remain follow-up candidates and are explicitly out of the default slice.
+
+## Project Structure
+
+### Documentation And Workflow
+
+```text
+.specify/
+├── memory/constitution.md
+├── templates/spec-template.md
+├── templates/plan-template.md
+├── templates/tasks-template.md
+├── templates/checklist-template.md
+└── README.md
+
+AGENTS.md
+.gitea/pull_request_template.md
+docs/product/standards/
+docs/ui/
+```
+
+### Source And Tests
+
+```text
+apps/platform/
+├── tests/Feature/Guards/
+├── tests/Support/TestLaneManifest.php
+└── tests/Architecture/
+
+scripts/
+├── check-ui-productization-coverage
+└── validate-ui-productization-coverage-guard
+```
+
+**Structure Decision**: Keep enforcement in existing workflow/docs/test guard locations. Do not create a new base folder or runtime module.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|---|---|---|
+| Cross-surface product-surface vocabulary | Future specs need concrete page archetype, budget, Technical Annex, and status vocabulary checks | A one-line checklist would not make exceptions, browser proof, and human review attributable |
+| Guard/test workflow enforcement | Templates and docs alone are easy to ignore | Manual-only review already allowed product-surface drift to recur |
+
+## Proportionality Review
+
+- **Current operator problem**: UI-affecting specs can increase visible complexity and expose technical details while still passing tests.
+- **Existing structure is insufficient because**: Spec 370/375/377 artifacts exist, but workflow templates and completion gates do not yet make their rules mandatory for future specs.
+- **Narrowest correct implementation**: Update durable workflow artifacts and targeted guard tests. Do not add runtime framework, data persistence, or broad redesign.
+- **Ownership cost created**: More required spec sections, PR checklist fields, and guard tests. Reviewers must enforce exceptions.
+- **Alternative intentionally rejected**: Full redesign, browser visual regression framework, hard-fail scanner expansion for all rules, or runtime Product Surface service.
+- **Release truth**: Current-release truth. The product needs regression prevention now after the closeout program.
+
+## Implementation Phases
+
+1. Repo safety and source verification.
+2. Product Surface Contract wording and durable docs updates.
+3. Spec Kit template and AGENTS/PR checklist gate updates.
+4. Targeted guard tests and lane manifest updates.
+5. Bounded first reduction decision: either low-risk direct reduction or follow-up documentation.
+6. Validation, browser/human sanity applicability decision, and implementation report.
+
+## Rollout And Deployment Considerations
+
+- No env vars.
+- No migrations.
+- No queues or scheduler changes.
+- No storage/volume changes.
+- No Filament asset registration expected.
+- Dokploy/Sail runtime behavior unchanged for default slice.
+- If PHP tests are added, run through Sail.
+
+## Risk Controls
+
+- Guard against broad runtime edits by requiring spec/plan update before any rendered UI change.
+- Guard against completed-spec rewriting by treating Specs 368, 370, 375, and 377 as read-only historical context.
+- Keep Product Surface Contract in one documentation location and reference it from templates to avoid duplicate standards.
+- Reuse existing `UiBloatRegressionGuardTest` and UI coverage guard behavior where possible.
+- Classify new broad guard tests as surface-guard/heavy-governance, not fast-feedback.

specs/395-product-surface-gate/spec.md

@@ -0,0 +1,686 @@
+# Feature Specification: Spec 395 - Product Surface Contract Enforcement and Surface Reduction Gate v1
+
+**Feature Branch**: `395-product-surface-gate`
+**Created**: 2026-06-21
+**Status**: Draft / Ready for preparation review
+**Input**: User-provided Spec 395 draft, Product Surface Contract lineage from Specs 368, 370, 375, and 377, and current repo workflow/template guardrails.
+
+## Candidate Selection And Completed-Spec Guardrail
+
+- **Selected candidate**: Product Surface Contract Enforcement and Surface Reduction Gate v1.
+- **Source**: Direct user-provided full candidate "Spec 395 - Product Surface Contract Enforcement & Surface Reduction Gate v1".
+- **Roadmap relationship**: Supports the UI and Product Maturity Polish lane, the decision-based operating model, and the post-Spec-377 need to keep productization gains from regressing.
+- **Why selected**: `docs/product/spec-candidates.md` currently reports no safe automatic queue target, but the user provided an explicit P1 candidate. The candidate closes a real gap left by the productization program: the Product Surface Contract exists as guidance and guard context, but future specs can still add visible complexity unless the completion gate makes surface impact, browser proof, and product sanity review mandatory.
+- **Smallest viable slice**: Update durable workflow rules, templates, PR/merge checklist, and guard tests so future specs must declare product-surface impact, no-legacy posture, page archetype, surface budgets, browser verification, human sanity review, and implementation report fields. Add or prepare the Technical Annex/status/deep-link/table-cap contract as documented review truth. Do not redesign all pages.
+- **Completed-spec check result**: No `specs/395-*` package existed before this run. Related specs are historical inputs only:
+  - Spec 370 defined a docs-only Global Surface Information Architecture Contract.
+  - Spec 375 added a UI bloat regression guard and follow-up recommendations.
+  - Spec 377 completed browser closeout as `closed-with-follow-up`, with no P0/P1 findings and only system-panel manual fixture follow-up.
+  - Specs 368, 370, 375, and 377 must not be rewritten, normalized, reopened, or stripped of close-out, validation, completed task, smoke, browser, or review history.
+- **Close alternatives deferred**:
+  - Broad page redesign across Environment Dashboard, Evidence, Operations, Review, Provider, Restore, and System surfaces.
+  - CI hard-fail expansion for every UI bloat rule before false-positive behavior is stable.
+  - Manual system-panel browser fixture procedure from Spec 377.
+  - Page-specific Receipt, Decision, Dashboard, and Inbox reduction passes.
+
+## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
+
+- **Problem**: TenantPilot has product-surface rules, but they are not yet a hard completion gate. Future specs can still pass tests while adding cards, statuses, tables, technical links, raw identifiers, readiness blocks, or proof paths that make the product harder to understand.
+- **Today's failure**: A feature can add visible UI complexity without proving one primary question, one primary action, canonical status language, technical detail demotion, browser verification, or human product sanity review. The product can regress after the UI Signal-to-Noise program has been closed.
+- **User-visible improvement**: Operators, customer reviewers, and maintainers get quieter product pages over time because every future UI-affecting spec must prove it reduces or preserves visible complexity and must provide focused browser evidence.
+- **Smallest enterprise-capable version**: A workflow and merge-gate enforcement slice: constitution update, spec/plan/tasks/checklist template updates, AGENTS/PR checklist updates, a product-surface contract reference, targeted guard tests, implementation report requirements, and a bounded first reduction or documented follow-up.
+- **Explicit non-goals**: No full navigation rebuild, no design-system replacement, no broad page redesign, no new runtime UI framework, no new persisted data, no new product feature, no new readiness domain, no wholesale Filament resource rewrite, and no compatibility shim for pre-production UI behavior.
+- **Permanent complexity imported**: Durable workflow sections, merge checklist fields, guard tests, one product-surface contract reference, page archetype/surface budget vocabulary, Technical Annex rules, canonical status vocabulary, and implementation-report fields. These are governance and review contracts, not database or runtime product truth.
+- **Why now**: Spec 377 closed the prior productization program with only narrow follow-up. Without a hard gate, future implementation specs can quietly recreate the same product-surface bloat.
+- **Why not local**: Page-local fixes do not prevent the next unrelated feature from adding new surface noise. The drift is cross-surface and process-driven, so the remedy must live in templates, workflow instructions, PR/merge gates, and guard tests.
+- **Approval class**: Core Enterprise.
+- **Red flags triggered**: New cross-surface taxonomy/rules, meta-infrastructure, and many affected surfaces. Defense: the slice is workflow/guard-first, no new persisted truth, no runtime framework, no broad redesign, and it explicitly narrows page reductions into follow-up passes.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 10/12**
+- **Decision**: approve as a bounded enforcement and reduction-gate slice.
+
+## Problem Statement
+
+TenantPilot must not show everything the system knows. It must show what the current user needs to know to make a safe decision.
+
+The Product Surface Contract and UI Signal-to-Noise artifacts already define decision-first, diagnostics-second, evidence-aware product surfaces. The gap is enforcement. Future specs can still increase visible complexity unless the workflow blocks or documents that growth.
+
+Recurring risk patterns:
+
+- Pages show too many readiness/status signals at once.
+- Evidence, OperationRun, baseline, review, provider, report, and finding objects are over-linked.
+- Receipt pages behave like dashboards.
+- Decision pages behave like audit explorers.
+- Customer-safe pages expose internal proof or technical context.
+- Hot tables show too many rows by default.
+- Technical terms become product language.
+- Each feature creates local readiness/status logic.
+- Specs can pass tests while still making the product surface worse.
+
+## No Legacy / No Backward Compatibility Constraint
+
+TenantPilot is pre-production for this scope. No production customer UI compatibility is required unless a future spec explicitly records a compatibility exception.
+
+Clean canonical product behavior wins over preserving old labels, action keys, routes, local status logic, tests, fixtures, or UI structures that encode wrong semantics.
+
+Implementation must not:
+
+- Preserve old action keys when the key encodes the wrong product meaning.
+- Keep tests that assert overloaded default UI behavior.
+- Add transitional UI that shows both old and new concepts.
+- Add duplicate cards, tables, or statuses to explain old behavior.
+- Keep local readiness/status logic when a canonical source exists.
+- Add legacy aliases, compatibility shims, fallback readers, or hidden routes solely for pre-production behavior.
+
+## Product / Business Value
+
+This spec converts product-surface quality from advice into an implementation completion gate. It protects TenantPilot's sellability and operator trust by making every future UI-affecting spec prove that it preserves or reduces visible complexity, demotes technical details, uses canonical status vocabulary, and provides browser and human review evidence where relevant.
+
+## Primary Users / Operators
+
+- Product reviewer checking whether a spec can merge without increasing UI bloat.
+- Implementation agent completing a UI-affecting spec and needing a concrete completion gate.
+- MSP/operator using `/admin` surfaces and expecting one clear next action.
+- Customer reviewer or auditor consuming customer-safe review/report/evidence surfaces.
+- Platform/system operator using `/system` surfaces that may be technical but must not leak debug/default-framework clutter.
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: canonical-view / workflow guardrail / product-surface governance.
+- **Primary Routes**: No new route is introduced by the primary slice. The gate applies to future changes touching `/admin`, `/system`, and product-facing routes that expose readiness, evidence, operations, provider, review, baseline, restore, report, or governance state.
+- **Data Ownership**: No database or product data ownership changes. New or updated contract artifacts are documentation/workflow truth. Guard tests may inspect repository files but must not create persisted product truth.
+- **RBAC**: No runtime authorization behavior is changed by the gate. Future UI-affecting specs must keep workspace/tenant isolation, capability-first RBAC, and deny-as-not-found semantics explicit. Technical Annex or audit links must be internal/operator/system-authorized where applicable.
+
+For canonical-view specs:
+
+- **Default filter behavior when tenant-context is active**: N/A for this workflow-gate slice. Future touched pages must state route-owned workspace/environment scope and any default filter behavior.
+- **Explicit entitlement checks preventing cross-tenant leakage**: Existing policies, gates, and UI enforcement remain authoritative. Future specs must prove that product-surface changes do not expose inaccessible records, global search hints, technical links, or audit paths across workspace/tenant boundaries.
+
+## 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 *(mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write `N/A - no reachable UI surface impact` plus rationale)*
+
+N/A - no reachable UI surface impact.
+
+- **No-impact rationale**: The primary implementation slice updates workflow documentation, Spec Kit templates, PR/merge checklists, product-surface contract documentation, and guard tests. It does not add or change rendered pages, routes, navigation entries, Filament panel providers, resources, Livewire components, Blade views, CSS, JavaScript, modals, tables, forms, or user-facing actions. If implementation chooses a runtime UI reduction, it must first update this spec and plan with exact affected surfaces and UI/Productization Coverage.
+
+## Product Surface Impact
+
+- **Visible UI added**: None by default.
+- **Visible UI removed**: None by default. Runtime removal is allowed only after this spec and plan are updated with exact surfaces.
+- **Page archetypes touched directly by this implementation**: None directly. The gate defines required archetypes for future touched pages: Dashboard, Receipt, Decision, Inbox, Wizard, Report, Search/Index, Technical Annex, Settings, and System Admin.
+- **Surface budgets applied**: Future product-facing touched pages must apply the default budgets in this spec unless classified as Technical Annex or System Admin, or unless an explicit exception is documented.
+- **Technical details hidden/demoted**: The gate requires future product-facing default views to demote OperationRun links, raw evidence links, source keys, detectors, fingerprints, UUIDs, payloads, provider payloads, raw report artifacts, and baseline diff internals to secondary internal/audit paths.
+- **Status vocabulary used**: Product-facing states are limited to `Ready`, `Needs attention`, `Blocked`, `Running`, `Failed`, `Expired`, `Not configured`, `Unknown`, `Historical`, and `Superseded`, with severities `Critical`, `High`, `Medium`, `Low`, and `Info`.
+- **Visible complexity impact**: The primary slice is neutral in runtime UI and reduces future complexity by adding hard completion gates. If any visible runtime change is made, the implementation report must prove complexity decreased or stayed neutral.
+
+## Mandatory Product Layers
+
+### Product Layer
+
+Visible by default. Allowed content:
+
+- Workspace or environment state.
+- Readiness, confidence, or risk when it changes action.
+- Primary issue or decision.
+- Impact.
+- Next recommended action.
+- Compact business context.
+- Customer-safe evidence summary.
+- Small status summary.
+
+### Technical Evidence Layer
+
+Hidden by default or placed on a dedicated internal technical/audit page. Allowed content:
+
+- OperationRuns.
+- Raw evidence and evidence snapshot IDs.
+- Source keys, detectors, technical dimensions, raw counts, coverage inventory.
+- Payloads, fingerprints, UUIDs, internal IDs.
+- Full audit trails and diff internals.
+
+### Rule
+
+A product-facing default page must not expose Technical Evidence Layer content by default. If technical depth is necessary, expose it through one secondary/internal action such as `View audit trail`, `View internal evidence details`, or `View technical details`, and require appropriate authorization.
+
+## Mandatory Page Archetypes
+
+Every touched product page must declare exactly one primary archetype:
+
+- Dashboard Page: What needs attention now?
+- Receipt Page: What happened, when, and can I trust it?
+- Decision Page: What changed and what decision should I make?
+- Inbox Page: What work items need triage?
+- Wizard Page: What step am I on and what do I do next?
+- Report Page: What customer/operator summary can be consumed or exported?
+- Search/Index Page: How do I find a record?
+- Technical Annex Page: What are the internal technical details?
+- Settings Page: What behavior is configured?
+- System Admin Page: What is the platform/system state?
+
+If a page mixes archetypes, the implementation must reduce it to one archetype, split the page, or document a temporary exception with a follow-up.
+
+## Surface Budget Rules
+
+Product-facing pages must satisfy these budgets unless explicitly classified as Technical Annex or System Admin, or unless the active spec records an exception:
+
+- Max 1 primary user question.
+- Max 1 primary action.
+- Max 2 secondary actions.
+- Max 4 summary metrics above the fold.
+- Max 1 main table visible by default.
+- Max 8 visible rows before Show more, pagination, or full table.
+- Max 1 readiness/status model.
+- Max 1 decision flow.
+- Max 0 raw technical identifiers in default view.
+- Max 0 OperationRun links in default view.
+- Max 0 raw Evidence deep links in default view.
+- Max 0 Source Key, Detector, or Technical Dimension blocks in default view.
+- Max 0 repeated readiness/status summaries on the same page.
+
+Each exception must include page, violated budget, reason, why it is not customer/product-facing, and follow-up if temporary.
+
+## Canonical Status Vocabulary
+
+Allowed product-facing states:
+
+- Ready
+- Needs attention
+- Blocked
+- Running
+- Failed
+- Expired
+- Not configured
+- Unknown
+- Historical
+- Superseded
+
+Allowed severity states:
+
+- Critical
+- High
+- Medium
+- Low
+- Info
+
+Forbidden as independent top-level product states unless explicitly mapped:
+
+- Healthy
+- Calm
+- OK
+- Warning
+- At risk
+- Unhealthy
+- Degraded
+- Incomplete
+- Partially ready
+- Partially complete
+- Complete with warnings
+- Action needed
+- Needs follow-up
+- Coverage ready
+- Trustworthy artifact
+- Usable with warnings
+- Likely stale
+- Internal only
+- Terminal follow-up
+
+If old terms are still needed internally, they must be mapped before display.
+
+## Readiness Truth Rule
+
+A page may show only one top-level readiness/status truth for a given concept.
+
+Required pattern:
+
+```text
+Provider readiness: Expired
+Reason: Verification is stale.
+Next action: Verify provider.
+```
+
+Forbidden pattern:
+
+```text
+Provider: Healthy
+Verification: Stale
+Permissions: Missing
+Readiness: Ready
+Action: Needs attention
+```
+
+Future readiness-producing specs must declare canonical source, consumer pages, display state, blocking reasons, and whether the state is customer-safe.
+
+## Deep-Link Demotion Rules
+
+Default product views must not expose a graph of internal objects.
+
+Default-view links to demote:
+
+- OperationRun.
+- Evidence Snapshot or Evidence Artifact.
+- Baseline Snapshot/Profile internals.
+- Detector, Source Key, raw Finding fingerprint.
+- Provider payload.
+- Raw report artifact.
+- Restore operation proof.
+- Technical logs.
+
+Allowed default product links:
+
+- Open workspace.
+- Open environment.
+- Review blockers.
+- Open customer workspace.
+- Download customer output.
+- Compare to current.
+- Verify provider.
+- Resolve finding.
+- Open report.
+- Start restore.
+
+Internal/audit links are allowed only as secondary/internal actions.
+
+## Table Cap Rules
+
+Product-facing hot tables must default to:
+
+- Max 8 visible rows.
+- Pagination or Show all for more.
+- Clear row status.
+- One row primary action.
+- No raw IDs as primary labels.
+- No excessive inline links.
+
+Technical Annex/System Admin pages may show more rows, but must be clearly technical/system-facing.
+
+## Action Model Rules
+
+Every product-facing page must define:
+
+- Primary action.
+- Secondary actions.
+- Danger/destructive actions.
+- Technical/audit actions.
+
+There may be only one primary action. Destructive/high-impact actions must be visually separated, authorization-checked, audit-logged when they mutate, and confirmation-protected.
+
+## Browser Verification Plan
+
+Every implemented spec that changes UI, routes, actions, authorization, downloads, reports, readiness, evidence, provider state, restore flows, customer output, or Product Surface Contract behavior must include focused browser verification.
+
+Spec 395 implementation must:
+
+- Run targeted guard/template tests for the workflow gate.
+- If no runtime UI files change, record that browser smoke is not required for runtime proof, and optionally run the focused existing smoke matrix as confidence only.
+- If any runtime UI surface changes, run focused browser smoke for affected pages and direct-route bypasses where relevant.
+- Check console, Livewire, Filament, network, and 500 errors where browser proof is required.
+- Document full browser-suite failures as unrelated only when focused affected browser proof is green and no touched surface fails.
+
+Suggested focus surfaces when runtime UI is touched:
+
+- Environment Dashboard.
+- Workspace Overview.
+- Evidence Overview or Evidence Snapshot.
+- Customer Review Workspace.
+- Review Pack Detail.
+- Provider Connections / Required Permissions.
+- Operations Hub.
+- System Dashboard when fixture access exists.
+
+## Human Product Sanity Check
+
+A 5 to 15 minute human product sanity check is required for:
+
+- Customer-facing surfaces.
+- Dashboards.
+- Readiness/status surfaces.
+- Review/report output.
+- Restore/wizard flows.
+- Provider onboarding/readiness.
+- Evidence/baseline pages.
+- Navigation changes.
+- Product Surface Contract changes.
+
+The reviewer must answer:
+
+- Does the page immediately communicate its purpose?
+- Is there exactly one dominant next action?
+- Are technical details demoted?
+- Are status labels understandable and canonical?
+- Does the page feel less complex or at least not worse?
+- Would a customer/operator trust the flow?
+
+If the answer is no for a touched surface, the implementation is not complete unless the issue is documented as pre-existing and not worsened.
+
+## Cross-Cutting / Shared Pattern Reuse
+
+- **Cross-cutting feature?**: yes, workflow and product-surface guardrail.
+- **Interaction class(es)**: status messaging, action links, header actions, dashboard signals, evidence/report viewers, technical/audit detail links, browser verification, implementation close-out reports.
+- **Systems touched**: Spec Kit templates, constitution, AGENTS instructions, PR checklist, product standards, guard tests, and existing UI bloat/productization coverage guard context.
+- **Existing pattern(s) to extend**: UI-COV-001, Spec 370 Global Surface IA Contract, Spec 375 UI bloat guard, `.specify/templates/checklist-template.md`, `scripts/check-ui-productization-coverage`, and existing Pest guard families.
+- **Shared contract / presenter / builder / renderer to reuse**: No runtime shared presenter/builder is introduced. Existing `BadgeCatalog`, `BadgeRenderer`, `ActionSurfaceDeclaration`, `UiBloatScanner`, `UiEnforcement`, and `WorkspaceUiEnforcement` remain the preferred implementation paths when future runtime surfaces are changed.
+- **Why the existing shared path is sufficient or insufficient**: Existing paths cover action surface and bloat detection, but do not yet make no-legacy, product-surface impact, focused browser proof, human sanity review, surface budgets, Technical Annex rules, and implementation report fields mandatory for every future UI-affecting spec.
+- **Allowed deviation and why**: Workflow docs and tests may introduce review vocabulary, but must not create a runtime UI framework or duplicate existing surface enums.
+- **Consistency impact**: Future specs must use one product-surface vocabulary, one status vocabulary, and one completion report shape.
+- **Review focus**: Confirm the implementation remains a gate and reduction contract, not a broad page rewrite.
+
+## OperationRun UX Impact
+
+N/A - no OperationRun start or link semantics are changed by the gate itself.
+
+Future touched product pages must demote OperationRun links from default product views unless the page is explicitly Technical Annex/System Admin or the spec records an exception. Any future action that creates, queues, deduplicates, completes, or links an OperationRun must continue to reuse the central OperationRun UX contract.
+
+## Provider Boundary / Platform Core Check
+
+- **Shared provider/platform boundary touched?**: no runtime provider seam change.
+- **Boundary classification**: platform-core product-surface vocabulary with provider-owned examples.
+- **Seams affected**: Future provider readiness/status display and technical detail demotion rules.
+- **Neutral platform terms preserved or introduced**: workspace, environment, provider connection, readiness, evidence, operation, audit trail, technical details, product surface.
+- **Provider-specific semantics retained and why**: Provider-specific terms may remain in provider-owned diagnostics and Technical Annex content. They are not allowed as default product language unless needed for the user decision.
+- **Why this does not deepen provider coupling accidentally**: The gate demotes provider payloads and provider-specific internals from platform-core product UI by default.
+- **Follow-up path**: `document-in-feature` for contained exceptions; `follow-up-spec` for recurring provider-surface drift.
+
+## 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 |
+|---|---|---|---|---|---|---|
+| Workflow rules, templates, AGENTS, PR checklist | no rendered surface change | N/A | product-surface review workflow | none | no | Gate-only implementation |
+| Product Surface Contract documentation | no rendered surface change | N/A | status/action/evidence/technical annex rules | none | no | Documentation/standards contract |
+| Guard tests | no rendered surface change | N/A | heavy-governance surface guard | none | no | Validates workflow gate exists |
+| Optional runtime UI reduction | only if spec/plan updated first | native/shared first | depends on selected surface | page/detail | maybe | Not in default slice |
+
+## Decision-First Surface Role
+
+N/A - no rendered operator-facing surface is changed by the default slice.
+
+Future touched pages must declare whether they are Primary Decision, Secondary Context, or Tertiary Evidence/Diagnostics surfaces and must keep one primary user question.
+
+## Audience-Aware Disclosure
+
+N/A for rendered UI in this slice.
+
+The gate requires future detail/status surfaces to separate customer-safe decision content, operator diagnostics, and support/raw evidence. Customer/read-only default paths must not expose raw JSON, fingerprints, OperationRun proof links, internal reason ownership, platform reason families, payloads, or debug semantics by default.
+
+## UI/UX Surface Classification
+
+N/A for rendered UI in this slice.
+
+Future affected pages must declare a page archetype and surface budget compliance. The Product Surface Contract must not be treated as a replacement for existing Filament action-surface classifications.
+
+## Operator Surface Contract
+
+N/A - no new or materially refactored operator-facing page is introduced by the default slice.
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: yes, workflow/standards truth for product-surface completion gates. No runtime or database truth.
+- **New persisted entity/table/artifact?**: yes, documentation/template/test artifacts only. No database persistence.
+- **New abstraction?**: no runtime abstraction. Guard tests may add a focused test family or assertions.
+- **New enum/state/reason family?**: no runtime enum. A canonical product-facing vocabulary is introduced as review/display guidance.
+- **New cross-domain UI framework/taxonomy?**: yes, a documented page archetype/surface budget/Technical Annex gate, explicitly not a runtime framework.
+- **Current operator problem**: Future specs can increase visible complexity and expose technical internals by default, causing operator confusion and reducing trust.
+- **Existing structure is insufficient because**: Specs 370 and 375 provide contract and guard context, but templates, AGENTS workflow, PR checklist, and implementation report requirements do not yet make these checks unavoidable.
+- **Narrowest correct implementation**: Add concise durable rules to constitution/workflow docs, update templates/checklists, add targeted guard tests, and document the product-surface contract. Avoid broad page rewrites and runtime frameworkization.
+- **Ownership cost**: Reviewers and agents must complete additional product-surface sections. Guard tests and templates require maintenance when the workflow changes.
+- **Alternative intentionally rejected**: A full UI redesign, visual regression framework, product-surface runtime engine, new component library, or broad hard-fail scanner expansion. These are broader than needed for v1 enforcement.
+- **Release truth**: current-release truth. The platform is now mature enough that product-surface drift is a sellability and trust risk.
+
+### Compatibility posture
+
+Pre-production no-legacy posture applies. Clean canonical behavior wins.
+
+## Testing / Lane / Runtime Impact
+
+- **Test purpose / classification**: Heavy-Governance / surface-guard for template/workflow/product-surface gate tests; Browser only when runtime UI changes are made.
+- **Validation lane(s)**: targeted guard tests, heavy-governance lane ownership check, optional browser lane for touched UI surfaces, `git diff --check`, and Pint if PHP changes.
+- **Why this classification and these lanes are sufficient**: The default implementation is workflow/guardrail breadth across templates and docs, not local runtime behavior. If UI changes occur, browser proof becomes blocking for affected surfaces.
+- **New or expanded test families**: One targeted Spec 395 workflow/product-surface gate guard family may be added or existing guard tests may be extended.
+- **Fixture / helper cost impact**: No database, workspace, provider, queue, or browser fixture is required for workflow guard tests. Browser fixture cost is opt-in only when runtime UI surfaces change.
+- **Heavy-family visibility / justification**: Surface gate tests are heavy-governance owned and must not silently enter fast-feedback.
+- **Special surface test profile**: surface-guard; browser smoke when runtime UI changes.
+- **Standard-native relief or required special coverage**: No rendered UI means no runtime browser proof required. Any runtime UI change must use native Filament/shared primitives and focused smoke.
+- **Reviewer handoff**: Reviewers must confirm template sections, AGENTS/PR checklist gate, contract documentation, guard coverage, no runtime UI drift unless explicitly scoped, and no completed specs rewritten.
+- **Budget / baseline / trend impact**: Potential small heavy-governance cost. Record if a new guard family is added.
+- **Escalation needed**: document-in-feature for contained exceptions; follow-up-spec for broad page reduction passes or CI strictness expansion.
+- **Active feature PR close-out entry**: Guardrail / Smoke Coverage / Human Product Sanity.
+- **Planned validation commands**:
+  - `git diff --check`
+  - `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProductSurface`
+  - `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=UiBloatRegressionGuard`
+  - `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent` if PHP files change
+  - Focused browser smoke only if runtime UI changes are made.
+
+## User Scenarios & Testing
+
+### User Story 1 - Future specs cannot skip product-surface impact (Priority: P1)
+
+As a maintainer, I want every future spec that changes UI or workflow surfaces to declare product-surface impact, archetype, budget, technical demotion, browser verification, and human sanity requirements, so visible complexity cannot increase silently.
+
+**Why this priority**: This is the main enforcement gap after Spec 377.
+
+**Independent Test**: Inspect the updated spec template and guard test output. A future sample UI spec without Product Surface Impact, Browser Verification Plan, Human Product Sanity Check, or Merge Gate Checklist must fail or be clearly incomplete.
+
+**Acceptance Scenarios**:
+
+1. **Given** a future spec changes a product-facing page, **When** it is written from the template, **Then** it contains Product Surface Impact with page archetype, budgets, status vocabulary, technical detail demotion, and complexity impact.
+2. **Given** a future spec claims no UI surface impact, **When** guarded UI paths changed, **Then** the workflow requires a checked no-impact rationale or coverage artifact.
+3. **Given** visible complexity increases, **When** the spec is reviewed, **Then** it must explicitly justify the exception and name a follow-up if temporary.
+
+### User Story 2 - Implementations cannot complete without focused proof (Priority: P1)
+
+As an implementation reviewer, I want every UI-affecting spec to report focused tests, browser smoke, console/runtime error checks, human product sanity status, and visible complexity outcome before merge.
+
+**Why this priority**: Tests alone can pass while the product surface gets worse.
+
+**Independent Test**: Inspect AGENTS/PR checklist/template updates and guard tests. The completion gate must require focused browser verification and implementation report fields for UI-affecting specs.
+
+**Acceptance Scenarios**:
+
+1. **Given** a spec changes UI, routes, actions, downloads, readiness, evidence, reports, provider state, restore flows, or customer output, **When** the implementation report is prepared, **Then** it lists focused tests, affected browser smoke, console/runtime checks, human sanity status, and complexity impact.
+2. **Given** full browser suite failures are unrelated, **When** the report claims non-blocking status, **Then** it records the focused affected matrix as green, lists unrelated failures, and proves no touched surface failed.
+3. **Given** a UI-affecting implementation skipped browser proof, **When** reviewed, **Then** the merge checklist blocks completion unless the spec is purely internal and explains why browser proof is not applicable.
+
+### User Story 3 - Product surfaces have measurable default budgets (Priority: P2)
+
+As a product reviewer, I want page archetypes, surface budgets, status vocabulary, Technical Annex rules, deep-link demotion, and table caps documented and enforceable, so future UI reviews have concrete pass/fail criteria.
+
+**Why this priority**: Reviewers need measurable rules, not generic "make it calmer" comments.
+
+**Independent Test**: Review the Product Surface Contract documentation and guard tests. The contract must name budgets, archetypes, forbidden default technical links, canonical statuses, table caps, and exception format.
+
+**Acceptance Scenarios**:
+
+1. **Given** a future touched page has more than one readiness model or more than one primary action, **When** reviewed, **Then** it must reduce the conflict or document an explicit exception.
+2. **Given** a future default product view exposes OperationRun or raw Evidence links, **When** reviewed, **Then** those links must be demoted to a Technical Annex/internal/audit path or justified as a Technical Annex/System Admin exception.
+3. **Given** a hot product-facing table has more than 8 default rows, **When** reviewed, **Then** it must paginate, show more, move full detail to Technical Annex, or be classified as Technical Annex/System Admin.
+
+### User Story 4 - First reduction work stays bounded (Priority: P3)
+
+As a maintainer, I want Spec 395 to start reducing surface drift without turning into a broad redesign, so the gate ships while page-specific reductions remain separate.
+
+**Why this priority**: The gate should prevent future drift and create a bounded path for reductions, not hide a large refactor.
+
+**Independent Test**: Inspect the implementation report. It must either document a low-risk reduction made through a central/touched path or explain why runtime reductions require separate follow-up specs.
+
+**Acceptance Scenarios**:
+
+1. **Given** a low-risk central reduction is available in a touched contract/guard path, **When** implemented, **Then** it demotes or clarifies technical details without adding visible complexity.
+2. **Given** all runtime reductions require page-specific refactors, **When** the implementation closes, **Then** it records follow-up candidates for Receipt Page Reduction, Decision Page Reduction, and Dashboard/Inbox Link Budget rather than changing unrelated pages.
+
+### Edge Cases
+
+- A spec changes guarded UI files only for test fixtures or non-rendered support code.
+- A System Admin page legitimately needs technical detail.
+- A Technical Annex page needs long tables or raw IDs.
+- A customer-facing page needs evidence provenance without exposing raw evidence.
+- A browser smoke matrix cannot access `/system` in the in-app browser but has existing Pest Browser proof.
+- Existing tests assert deprecated labels or overloaded UI behavior.
+- A future spec creates a new status term for internal logic but product UI maps it to canonical vocabulary.
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+- **FR-395-001**: The implementation MUST update durable workflow rules so future specs include Product Surface Impact, No Legacy constraint, Browser Verification Plan, Human Product Sanity Check, and Merge Gate Checklist.
+- **FR-395-002**: The spec template MUST require page archetype, surface budgets, technical detail demotion, status vocabulary, visible complexity impact, browser verification plan, and human sanity requirement when UI, routes, labels, readiness, statuses, actions, downloads, reports, evidence, provider state, restore flow, customer output, or page behavior changes.
+- **FR-395-003**: The plan and tasks templates MUST carry product-surface proof into implementation phases, validation commands, browser smoke, human sanity, and implementation report tasks.
+- **FR-395-004**: AGENTS/workflow instructions MUST require focused tests, affected regression tests, focused browser smoke, direct-route checks where relevant, console/network/runtime checks where relevant, formatting/lint/diff checks, acceptance-criteria reporting, unrelated failure triage, and browser evidence for UI-affecting specs.
+- **FR-395-005**: PR/merge checklist MUST include no-legacy confirmation, product-surface impact, browser smoke, human sanity, visible complexity outcome, status vocabulary, technical detail demotion, table caps, deep-link demotion, and implementation report completion.
+- **FR-395-006**: Product Surface Contract documentation MUST define mandatory page archetypes, product/technical layers, surface budgets, Technical Annex rules, canonical status vocabulary, readiness truth rule, deep-link demotion, table caps, role boundaries, action model, exception format, browser verification, human sanity review, and implementation report fields.
+- **FR-395-007**: Future touched product-facing pages MUST declare exactly one primary archetype or document an exception with follow-up.
+- **FR-395-008**: Future touched product-facing pages MUST satisfy surface budgets or document an exception.
+- **FR-395-009**: Future touched product-facing default views MUST demote technical evidence-layer content to internal/audit/Technical Annex paths unless the page is Technical Annex/System Admin or has a documented exception.
+- **FR-395-010**: Future touched pages MUST use canonical status vocabulary or explicitly map old/internal terms before display.
+- **FR-395-011**: The implementation MUST add or update targeted guard tests proving the workflow artifacts contain required sections and at least one high-risk regression guard remains active.
+- **FR-395-012**: The implementation MUST not rewrite completed specs or remove implementation close-out, validation results, completed tasks, smoke results, browser evidence, or review history from completed specs.
+- **FR-395-013**: The implementation MUST perform a small first reduction step only when it is low-risk and directly connected to the touched gate/contract path. Otherwise it MUST document why runtime reductions are follow-up specs.
+- **FR-395-014**: Any runtime UI reduction performed under this spec MUST be preceded by an update to this spec and plan with exact affected surfaces, UI/Productization Coverage, tests, browser smoke, and human sanity expectations.
+- **FR-395-015**: The implementation report MUST list files changed, workflow/template changes, merge checklist changes, tests, browser smokes, human sanity status, no-legacy confirmation, visible complexity outcome, unrelated failures, and follow-up surface-reduction backlog.
+
+### Non-Functional Requirements
+
+- **NFR-395-001**: The gate MUST keep detailed product-surface rules in one canonical Product Surface Contract location; templates, AGENTS, and PR/checklist updates MUST reference that contract and include only the completion prompts needed for implementation review instead of duplicating full rule tables.
+- **NFR-395-002**: Rules must be measurable and reviewable, not subjective.
+- **NFR-395-003**: Enforcement must not introduce a runtime Product Surface framework, database table, model, enum, service, presenter, or component library in v1.
+- **NFR-395-004**: Browser verification must be focused and proportional. Full browser suite failures are non-blocking only when unrelated and documented.
+- **NFR-395-005**: Human sanity review must be lightweight, 5 to 15 minutes, and focused on trust, clarity, actionability, and visible complexity.
+- **NFR-395-006**: Guard tests must remain deterministic and avoid browser, database, provider, queue, or workspace fixtures unless a runtime UI change is explicitly scoped.
+
+### RBAC / Security Requirements
+
+- **SEC-395-001**: UI visibility remains non-authoritative; future action and technical/audit paths must be server-authorized.
+- **SEC-395-002**: Technical Annex/internal/audit paths must be capability-gated where they expose raw evidence, OperationRun details, provider payloads, source keys, detectors, fingerprints, UUIDs, payloads, or technical logs.
+- **SEC-395-003**: Customer-facing default paths must not expose raw evidence, raw IDs, OperationRun proof, fingerprints, payloads, source keys, internal reason ownership, or debug semantics by default.
+- **SEC-395-004**: Destructive/high-impact actions remain subject to `->action(...)`, `->requiresConfirmation()`, policy/gate authorization, audit logging where mutating, and tests.
+
+### Auditability / Observability Requirements
+
+- **AUD-395-001**: The implementation report must record branch, HEAD, dirty state, commands run, tests, browser smoke, human sanity status, affected surfaces, runtime files changed yes/no, and known limitations.
+- **AUD-395-002**: Product-surface exceptions must be attributable to the active spec and include follow-up where temporary.
+- **AUD-395-003**: No AuditLog or OperationRun records are created by the workflow gate itself.
+
+### Data / Truth Source Requirements
+
+- **DATA-395-001**: The Product Surface Contract is workflow/standards truth for review and merge gates, not product data truth.
+- **DATA-395-002**: Spec 370, Spec 375, and Spec 377 artifacts are historical inputs and context.
+- **DATA-395-003**: Future runtime page truth remains in application code, tests, browser proof, and implementation reports.
+
+## UI Action Matrix *(mandatory when Filament is changed)*
+
+N/A - the default slice changes no Filament Resource, RelationManager, Page, panel provider, action, table, form, modal, widget, or navigation entry.
+
+If implementation later scopes a runtime UI reduction, this matrix must be completed before code changes.
+
+## Acceptance Criteria
+
+- **AC-395-001**: Spec template includes Product Surface Impact, No Legacy / No Backward Compatibility Constraint, Browser Verification Plan, Human Product Sanity Check, and Merge Gate Checklist requirements.
+- **AC-395-002**: Plan/tasks/checklist templates carry product-surface proof through implementation, validation, and close-out.
+- **AC-395-003**: Constitution or equivalent project principles include concise durable product-surface enforcement rules without duplicating detailed implementation text.
+- **AC-395-004**: AGENTS/workflow docs require focused browser smoke after UI-affecting implementation and forbid marking UI-affecting specs complete without browser evidence or a justified no-browser path.
+- **AC-395-005**: PR/merge checklist includes product-surface completion gate items.
+- **AC-395-006**: Surface budgets, page archetypes, Technical Annex rules, canonical status vocabulary, readiness truth rule, deep-link demotion, table caps, role boundaries, action model, and exception format are documented in one reviewable contract location.
+- **AC-395-007**: At least one targeted guard test proves the new workflow/template/checklist gate exists.
+- **AC-395-008**: Existing Spec 375 UI bloat guard or equivalent targeted architecture guard remains active and is referenced rather than duplicated unnecessarily.
+- **AC-395-009**: No runtime UI complexity increases.
+- **AC-395-010**: Any first reduction is low-risk, bounded, tested, browser-verified if rendered UI changes, and documented; otherwise follow-up candidates are recorded.
+- **AC-395-011**: No completed spec history is rewritten or removed.
+- **AC-395-012**: `git diff --check` passes and targeted guard tests pass.
+- **AC-395-013**: Implementation report includes Livewire v4 compliance, provider registration location, global-search posture, destructive/high-impact action status, asset strategy, tests/browser verification, and deployment impact.
+
+## Key Entities *(documentation/workflow only)*
+
+- **Product Surface Contract**: Review and merge-gate contract describing page archetypes, budgets, Technical Annex rules, status vocabulary, table caps, deep-link demotion, and exception format.
+- **Page Archetype Declaration**: A required future-spec declaration of a touched page's single primary product role.
+- **Surface Budget Exception**: A documented exception with page, violated budget, reason, non-customer/product-facing rationale, and follow-up if temporary.
+- **Technical Annex**: Internal/audit/technical detail path that holds raw and diagnostic details outside the default product layer.
+- **Implementation Completion Gate**: Required close-out proof fields for tests, browser smoke, human sanity review, no-legacy posture, complexity outcome, and unrelated failure triage.
+
+## Success Criteria
+
+- **SC-395-001**: A future UI-affecting spec generated from templates cannot omit product-surface impact, browser verification, human sanity, and merge-gate questions.
+- **SC-395-002**: Reviewers can determine from the PR checklist whether visible complexity increased, stayed neutral, or decreased.
+- **SC-395-003**: Product-surface exceptions are attributable and cannot remain silent.
+- **SC-395-004**: The implementation changes no runtime UI by default and no runtime UI complexity increases.
+- **SC-395-005**: Targeted guard tests prove the workflow gate is present.
+
+## Out Of Scope
+
+- Full TenantPilot navigation rebuild.
+- Visual redesign of every page.
+- New design system or component library.
+- New product capability, readiness domain, evidence domain, provider feature, restore feature, or report feature.
+- Broad Filament resource rewrite.
+- New persisted data, migrations, models, services, jobs, queues, OperationRun types, routes, policies, or assets for the default gate slice.
+- Creating a generic runtime product-surface framework.
+- CI hard-fail expansion for all UI bloat scanner rules before false-positive behavior is stable.
+- Manual system-panel browser fixture procedure from Spec 377.
+- Rewriting or normalizing completed specs.
+
+## Merge Gate Checklist
+
+Spec 395 may be implemented and merged only when:
+
+- [ ] Spec template includes No Legacy constraint.
+- [ ] Spec template includes Product Surface Impact.
+- [ ] Spec template includes Browser Verification Plan.
+- [ ] Spec template includes Human Product Sanity Check.
+- [ ] Spec template includes Merge Gate Checklist.
+- [ ] AGENTS/workflow docs require focused browser smoke after UI-affecting implementation.
+- [ ] AGENTS/workflow docs require affected regression tests.
+- [ ] AGENTS/workflow docs forbid legacy compatibility shims by default.
+- [ ] Surface budgets are documented.
+- [ ] Page archetypes are documented.
+- [ ] Technical Annex rules are documented.
+- [ ] Canonical status vocabulary is documented.
+- [ ] Deep-link demotion rules are documented.
+- [ ] Table cap rules are documented.
+- [ ] Implementation completion gate exists.
+- [ ] At least one targeted architecture/regression guard is added or updated where practical.
+- [ ] Focused Spec 395 tests pass.
+- [ ] Focused browser smoke passes when runtime UI is touched, or no-browser applicability is justified.
+- [ ] Pint passes when PHP changes.
+- [ ] `git diff --check` passes.
+- [ ] Human product sanity check is completed when runtime/product-surface changes are made.
+- [ ] Visible UI complexity did not increase.
+
+## Risks
+
+- **Gate becomes checklist theater**: Mitigate with guard tests, concrete required report fields, and PR checklist items.
+- **Too much enforcement blocks technical pages**: Mitigate with explicit Technical Annex and System Admin exceptions.
+- **Browser verification slows development**: Mitigate with focused affected smoke, not mandatory full suite.
+- **False positives in guard tests**: Mitigate by reusing existing Spec 375 guard behavior and making ambiguous findings manual review.
+- **Surface reduction becomes too broad**: Mitigate by limiting runtime reductions to low-risk touched paths and moving broader passes to follow-up specs.
+
+## Assumptions
+
+- Existing Spec 370, 375, and 377 artifacts remain available as historical context.
+- Existing `UiBloatRegressionGuardTest`, `UiBloatScanner`, UI coverage guard, and test lane manifest provide enough guard infrastructure for Spec 395 without new dependencies.
+- The implementation will use Sail for Laravel/Pest/Pint commands.
+- No application code change is required for the default enforcement slice.
+
+## Open Questions
+
+- None blocking preparation.
+- Non-blocking implementation decision: whether the Product Surface Contract lives only in existing docs or gets a new `docs/product/standards/product-surface-contract.md` file. The implementation should choose the narrowest discoverable location and avoid duplicate standards text.
+
+## Follow-Up Spec Candidates
+
+- Receipt Page Reduction Pass: Evidence Snapshot, Baseline Snapshot, Restore Run Detail, Review Pack Receipt.
+- Decision Page Reduction Pass: Baseline Compare, Restore Preview, Review Resolution Decision.
+- Dashboard and Inbox Link Budget Pass: Environment Dashboard, Workspace Overview, Governance Inbox, Findings, Operations Hub.
+- CI strictness expansion for UI bloat/product-surface guard rules after allowlist cleanup.
+- Manual system-panel browser fixture or documented audit procedure from Spec 377.

specs/395-product-surface-gate/tasks.md

@@ -0,0 +1,110 @@
+# Tasks: Spec 395 - Product Surface Contract Enforcement and Surface Reduction Gate v1
+
+**Input**: `specs/395-product-surface-gate/spec.md`, `plan.md`, `checklists/requirements.md`, user-provided Spec 395 candidate, Specs 370, 375, and 377 artifacts, and current repo workflow/test conventions.
+
+**Tests**: Required for later implementation because this spec changes repository workflow enforcement and guard tests. The default slice is docs/templates/tests only and does not require browser proof unless runtime UI is touched after updating the spec and plan.
+
+## Test Governance Checklist
+
+- [x] Lane assignment is named and narrow: Heavy-Governance / `surface-guard` for workflow/template guard tests unless implementation proves a cheaper targeted lane.
+- [x] New or changed tests stay in the smallest honest family; no browser, DB, workspace, tenant, provider, session, queue, or seed fixture is introduced for the default slice.
+- [x] Shared helpers and scanner fixtures stay cheap by default; no heavy application setup is hidden in a broad helper.
+- [x] Planned validation commands cover the gate without pulling in unrelated suite cost.
+- [x] Browser proof is explicitly `N/A` for docs/template/test-only work and required for any runtime rendered UI change.
+- [x] Any material runtime, lane, baseline, trend, or CI strictness impact is recorded in `specs/395-product-surface-gate/implementation-report.md`.
+
+## Phase 1: Preparation And Repo Truth
+
+**Purpose**: Confirm Spec 395 installs a workflow gate and does not reopen completed productization specs.
+
+- [x] T001 Re-read `specs/395-product-surface-gate/spec.md`, `plan.md`, `tasks.md`, and `checklists/requirements.md` before implementation.
+- [x] T002 Record branch, HEAD, dirty state, selected implementation slice, and no-runtime-UI default in `specs/395-product-surface-gate/implementation-report.md`.
+- [x] T003 Re-read current workflow sources: `.specify/memory/constitution.md`, `.specify/templates/spec-template.md`, `.specify/templates/plan-template.md`, `.specify/templates/tasks-template.md`, `.specify/templates/checklist-template.md`, `.specify/README.md`, `AGENTS.md`, and `.gitea/pull_request_template.md`.
+- [x] T004 Re-read product-surface sources: `docs/ui/operator-ux-surface-standards.md`, `docs/ui/action-surface-contract.md`, `docs/product/standards/README.md`, and `docs/ui-ux-enterprise-audit/README.md`.
+- [x] T005 Re-read completed source context without rewriting it: Spec 370 surface IA artifacts, Spec 375 UI bloat guard artifacts, and Spec 377 closeout artifacts.
+- [x] T006 Inspect guard/test conventions in `apps/platform/tests/Feature/Guards`, `apps/platform/tests/Architecture`, `apps/platform/tests/Pest.php`, `apps/platform/tests/Support/TestLaneManifest.php`, `scripts/check-ui-productization-coverage`, and `scripts/validate-ui-productization-coverage-guard`.
+- [x] T007 Confirm no migrations, models, policies, routes, Filament pages/resources, Livewire components, views, panel providers, Graph contracts, jobs, queues, scheduler, storage, or runtime UI files are intentionally changed for the default slice.
+
+## Phase 2: Product Surface Contract And Workflow Wording
+
+**Purpose**: Make the contract durable in one canonical documentation location and reference it from workflow gates.
+
+- [x] T008 Select the canonical Product Surface Contract location after checking existing docs; prefer `docs/product/standards/product-surface-contract.md` unless the source review proves an existing document is the better owner.
+- [x] T009 Create or update the selected Product Surface Contract document with page archetypes, surface budgets, Technical Annex rules, canonical status vocabulary, readiness truth rule, deep-link demotion, table caps, role/audience boundaries, action model, exception format, browser proof rule, and human sanity rule.
+- [x] T010 Update `docs/product/standards/README.md` or the selected standards index so reviewers can find the Product Surface Contract.
+- [x] T011 Update `docs/ui/operator-ux-surface-standards.md`, `docs/ui/action-surface-contract.md`, and `docs/ui-ux-enterprise-audit/README.md` where they need direct Product Surface Contract references, or record in `specs/395-product-surface-gate/implementation-report.md` why the canonical contract location is sufficient without direct edits.
+- [x] T012 Update `.specify/memory/constitution.md` with concise durable Product Surface Contract principles and a proportionality-aware exception path.
+- [x] T013 If `.specify/memory/constitution.md` changes, update its `Last Amended` date and record the required amendment rationale plus impacted templates/specs list in `specs/395-product-surface-gate/implementation-report.md` and the PR close-out.
+- [x] T014 Ensure Product Surface wording treats provider-specific terms as Technical Annex/provider diagnostics detail, not platform-core operator vocabulary.
+- [x] T015 Ensure Product Surface wording does not introduce a runtime presenter, enum/status family, persisted taxonomy, component framework, or broad UI redesign requirement.
+
+## Phase 3: Spec Kit Templates And PR Gate
+
+**Purpose**: Make future UI-affecting work declare surface impact before implementation.
+
+- [x] T016 Update `.specify/templates/spec-template.md` with required sections for No Legacy, Product Surface Impact, UI Surface Impact, Browser Verification Plan, Human Product Sanity Check, Product Surface exceptions, and Merge Gate Checklist.
+- [x] T017 Update `.specify/templates/plan-template.md` so plans carry Livewire v4 compliance, provider registration location, global search posture, destructive-action posture, asset strategy, testing plan, and deployment impact for Filament/UI-relevant work.
+- [x] T018 Update `.specify/templates/tasks-template.md` so task lists include Product Surface classification, browser/no-browser rationale, human sanity review, close-out report, and stop-before-runtime-UI-change instructions.
+- [x] T019 Update `.specify/templates/checklist-template.md` so generated checklists verify Product Surface sections, no-legacy behavior, exceptions, and browser/human sanity applicability.
+- [x] T020 Update `.specify/README.md` to describe when the Product Surface Contract gate applies and how exceptions are handled.
+- [x] T021 Update `AGENTS.md` to require Product Surface Contract review before UI-affecting implementation, while preserving Sail-first and Spec Kit workflow guidance.
+- [x] T022 Update `.gitea/pull_request_template.md` with a Product Surface close-out block covering guardrail class, UI impact, exceptions, browser proof, human sanity, tests, and deployment impact.
+
+## Phase 4: Guard Tests And Lane Registration
+
+**Purpose**: Make workflow omissions fail in a deterministic, non-browser guard.
+
+- [x] T023 Add or update `apps/platform/tests/Feature/Guards/ProductSurfaceContractGateTest.php` to assert required Product Surface sections exist in templates, AGENTS workflow guidance, PR checklist, and the canonical contract document.
+- [x] T024 Reuse existing `apps/platform/tests/Feature/Guards/UiBloatRegressionGuardTest.php` patterns where helpful, but do not duplicate the static scanner as the Product Surface Contract gate.
+- [x] T025 Add assertions that completed specs are not required to be rewritten and that the gate targets future specs/templates/workflow.
+- [x] T026 Add assertions for no-runtime-UI default behavior: docs/template/test-only changes may record browser `N/A`, while rendered UI changes must declare browser proof.
+- [x] T027 Add assertions for required implementation close-out fields: Livewire v4 compliance, provider registration location, global search posture, destructive-action posture, asset strategy, testing/browser result, and deployment impact.
+- [x] T028 Update `apps/platform/tests/Support/TestLaneManifest.php` if a new guard family is added, classifying it as `surface-guard` / heavy-governance or documenting targeted-only ownership in `implementation-report.md`.
+- [x] T029 Update `apps/platform/tests/Pest.php` only if the selected test lane requires group registration.
+- [x] T030 Keep guard fixtures local, cheap, and file-based; do not introduce database, browser, tenant, provider, or session setup.
+
+## Phase 5: First Reduction Boundary Decision
+
+**Purpose**: Decide whether this v1 gate can safely include a tiny direct surface reduction or should defer all page changes.
+
+- [x] T031 Inspect high-risk central paths with `rg` for repeated technical links, raw/support default labels, duplicate status truth, table overload, and implementation-first action names.
+- [x] T032 Record the inspection result in `specs/395-product-surface-gate/implementation-report.md` with either `no runtime reduction included` or one bounded proposed runtime reduction.
+- [x] T033 If a runtime reduction is proposed, stop before editing runtime files and update `spec.md` and `plan.md` with exact affected surfaces, UI/Productization Coverage, UI Action Matrix if applicable, browser proof, and human sanity criteria. *(N/A: no runtime reduction proposed.)*
+- [x] T034 If no low-risk runtime reduction is included, record follow-up candidates only; do not broad-refactor pages.
+
+## Phase 6: Validation And Close-Out
+
+**Purpose**: Finish with bounded proof and clear reviewer handoff.
+
+- [x] T035 Run the narrow Product Surface guard command selected by implementation, expected shape: `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=ProductSurface`.
+- [x] T036 Run existing related guard coverage as needed, expected shape: `cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=UiBloatRegressionGuard`.
+- [x] T037 Run `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent` if PHP files changed.
+- [x] T038 Run `git diff --check`.
+- [x] T039 If no runtime UI was changed, record browser proof as `N/A - no rendered UI surface changed` in `implementation-report.md` and PR close-out.
+- [x] T040 If runtime UI was changed after approved spec/plan update, run a focused browser smoke for the affected routes and capture screenshots or page-report evidence. *(N/A: no runtime UI changed.)*
+- [x] T041 Complete the Human Product Sanity Check result in `implementation-report.md`, including whether the default screen reads product-first and whether technical detail is demoted.
+- [x] T042 Complete `implementation-report.md` with changed files, commands run, results, known limitations, no completed-spec rewrite assertion, and follow-up candidates.
+- [x] T043 Confirm final implementation response states Livewire v4 compliance, provider registration location, global search status, destructive-action safety, asset strategy, tests/browser coverage, and deployment impact.
+
+## Non-Goals Checklist
+
+- [x] NT001 Do not redesign product pages in the default slice.
+- [x] NT002 Do not modify runtime UI files unless `spec.md` and `plan.md` are updated first with exact UI impact and verification requirements.
+- [x] NT003 Do not add migrations, models, persisted product truth, enum/status families, jobs, policies, routes, Livewire components, Filament pages/resources, navigation entries, or Graph calls.
+- [x] NT004 Do not add screenshot diff infrastructure, full visual regression, broad browser audit, accessibility audit, or performance audit.
+- [x] NT005 Do not make all Product Surface rules CI-blocking before exception policy and false-positive behavior are proven.
+- [x] NT006 Do not rewrite completed historical specs or remove implementation close-out, validation, or browser evidence from completed specs.
+- [x] NT007 Do not create a runtime Product Surface framework, presenter, registry, or component system.
+
+## Dependencies And Execution Order
+
+- Phase 1 must complete before any workflow or test edits.
+- Phase 2 establishes the contract before templates reference it.
+- Phase 3 updates workflow gates before guard tests assert them.
+- Phase 4 implements guard enforcement and lane ownership.
+- Phase 5 decides whether runtime reduction stays deferred or requires an explicit spec/plan update.
+- Phase 6 validates and closes the implementation report.
+
+## Recommended Implementation Strategy
+
+Implement the default docs/templates/tests slice first. Prefer a targeted Pest guard under `tests/Feature/Guards` because the repo already uses file-based guard tests and `surface-guard` lane classification. Keep browser proof out of the default slice, but make any future rendered UI change a hard stop until the spec and plan declare exact affected surfaces, page archetypes, exception handling, focused browser proof, and human sanity review.