docs: re-audit planning docs and prep guardrails

.github/skills/spec-kit-next-best-prep/SKILL.md

@@ -85,6 +85,9 @@ ## Hard Rules
 - Do not run destructive commands.
 - Do not force checkout, reset, stash, rebase, merge, or delete branches.
 - Do not overwrite existing specs.
+- Do not rewrite completed specs back into preparation state.
+- Do not remove or normalize implementation history, close-out notes, validation results, completed task markers, smoke results, or post-implementation review language from completed specs.
+- Treat completed-spec close-out and validation language as intentional repository history, not preparation drift.
 - Do not move from preparation to an implementation step inside this skill.
 
 ## Required Inputs
@@ -119,6 +122,32 @@ ## Required Repository Checks
 
 Do not edit application code.
 
+## Completed-Spec Guardrail
+
+Before selecting an existing spec package as a `next-best-prep` target, explicitly check whether the spec is already completed, implementation-closed, or validated.
+
+A spec must be treated as completed if any of the following signals are present in `spec.md`, `plan.md`, `tasks.md`, `quickstart.md`, checklist artifacts, or related Spec Kit package files:
+
+- `Implementation Close-Out`
+- `Implementation completed on`
+- `Implementation Validation Results`
+- `Implemented and validated`
+- `Review Outcome` or `Implementation Review Outcome`
+- passed validation, smoke, browser, or guardrail results
+- completed task checklist markers for the implementation tasks
+- post-implementation review or close-out language
+- a status marker indicating implemented, completed, closed, or validated
+
+If a spec is completed:
+
+- exclude it from `next-best-prep` candidate selection
+- do not patch, normalize, rewrite, or convert it back to preparation-only state
+- do not remove close-out sections, validation results, completed task markers, smoke results, or post-implementation review language
+- treat those artifacts as historical implementation evidence
+- only use the completed spec as context for dependency or roadmap reasoning
+
+If all high-priority candidates are already specced, active, or completed, stop and report `no safe next prep target` instead of modifying existing completed specs.
+
 ## Git and Branch Safety
 
 Before running any Spec Kit command:
@@ -143,6 +172,7 @@ ### Gate 1: Candidate Selection Gate
 
 - The selected candidate exists in roadmap/spec-candidate material or is directly provided by the user.
 - The selected candidate is not already covered by an existing active or completed spec.
+- The selected target is not a completed spec package with implementation close-out, validation results, completed tasks, smoke results, or post-implementation review history.
 - The selected candidate aligns with current roadmap priorities or explicitly documented product direction.
 - The candidate can be scoped as a small, reviewable, implementation-ready slice.
 - Major adjacent concerns are listed as follow-up candidates instead of being hidden inside the primary scope.
@@ -150,6 +180,7 @@ ### Gate 1: Candidate Selection Gate
 Fail behavior:
 
 - If no candidate satisfies the gate, stop and report the top candidates plus the reason none is ready.
+- If the only plausible targets are completed specs, stop and report `no safe next prep target`; do not modify those completed specs.
 - Do not invent a new roadmap direction to force progress.
 
 ### Gate 2: Spec Readiness Gate
@@ -180,6 +211,8 @@ ## Candidate Selection Rules
 - Read `docs/product/spec-candidates.md`.
 - Read relevant roadmap documents under `docs/product/`, especially `roadmap.md` if present.
 - Check existing specs to avoid duplicates.
+- Check existing specs for completed-spec signals before selecting an existing package as a refresh target.
+- Exclude completed specs from next-best-prep selection, even if their artifacts contain close-out, validation, or completed-task language that would look like drift in a preparation-only package.
 - Prefer candidates that align with current roadmap priorities, platform foundations, enterprise UX, RBAC/isolation, auditability, observability, and governance workflow maturity.
 - Prefer candidates that unlock roadmap progress, reduce architectural drift, harden foundations, or remove known blockers.
 - Prefer small, implementation-ready slices over broad platform rewrites.
@@ -198,6 +231,7 @@ ## Candidate Selection Rules
 5. **Repo Readiness**: Does the repo already have enough structure to implement the next slice safely?
 6. **Risk Reduction**: Does it reduce current architectural or product risk?
 7. **User/Product Value**: Does it produce visible operator value or make the platform more sellable without heavy scope?
+8. **Completion Safety**: Is the target genuinely unprepared or incomplete, rather than an already completed spec whose historical close-out artifacts should be preserved?
 
 ## Required Selection Output Before Spec Kit Execution
 
@@ -208,6 +242,7 @@ ## Required Selection Output Before Spec Kit Execution
 - why it was selected
 - why close alternatives were deferred
 - roadmap relationship
+- completed-spec check result for related existing specs
 - smallest viable implementation slice
 - proposed concise feature description to feed into `specify`
 
@@ -296,7 +331,7 @@ ### Step 5: Run preparation `analyze`
 
 ### Step 6: Fix preparation-artifact issues only
 
-If preparation analyze finds issues, fix only Spec Kit preparation artifacts such as:
+If preparation analyze finds issues, first confirm that the selected package is not completed. Then fix only Spec Kit preparation artifacts such as:
 
 - `spec.md`
 - `plan.md`
@@ -322,6 +357,10 @@ ### Step 6: Fix preparation-artifact issues only
 - editing models, services, jobs, policies, Filament resources, Livewire components, tests, commands, routes, or views
 - running implementation or test-fix loops
 - changing runtime behavior
+- removing implementation close-out history from completed specs
+- converting completed specs back to preparation-only wording
+- changing passed validation or smoke results into planned validation commands
+- unchecking completed implementation tasks in a completed spec
 
 ### Step 7: Evaluate the Spec Readiness Gate
 
@@ -478,23 +517,33 @@ ## Failure Handling
 2. Report the current branch and relevant uncommitted files.
 3. Ask the user to commit, stash, or move to a clean worktree.
 
+If a completed spec is accidentally selected or modified:
+
+1. Stop immediately.
+2. Report that the selected spec is completed and therefore not a valid preparation target.
+3. Revert only the changes made by this operation to that completed spec package, if they are isolated and safe to revert.
+4. Run `git status --short` and report remaining changes.
+5. Re-run candidate selection excluding completed specs.
+6. If no safe unprepared candidate exists, report `no safe next prep target`.
+
 ## Final Response Requirements
 
 Respond with:
 
 1. Selected candidate and why it was chosen
 2. Why close alternatives were deferred
-3. Current branch after Spec Kit execution, if changed
+3. Completed-spec guardrail result for related existing specs
-4. Generated spec path
+4. Current branch after Spec Kit execution, if changed
-5. Files created or updated by Spec Kit
+5. Generated spec path
-6. Preparation analyze result summary
+6. Files created or updated by Spec Kit
-7. Preparation-artifact fixes applied after analyze
+7. Preparation analyze result summary
-8. Assumptions made
+8. Preparation-artifact fixes applied after analyze
-9. Open questions, if any
+9. Assumptions made
-10. Candidate Selection Gate result
+10. Open questions, if any
-11. Spec Readiness Gate result
+11. Candidate Selection Gate result
-12. Recommended next implementation prompt
+12. Spec Readiness Gate result
-13. Explicit statement that no application implementation was performed
+13. Recommended next implementation prompt
+14. Explicit statement that no application implementation was performed
 
 Keep the final response concise, but include enough detail for the user to continue immediately.
 
@@ -550,13 +599,14 @@ ## Example Invocation
 2. Check branch and working tree safety.
 3. Compare candidate suitability.
 4. Select the next best candidate.
-5. Evaluate the Candidate Selection Gate.
+5. Exclude already completed specs from preparation or refresh targets, preserving their close-out and validation history.
-6. Run the repository's real Spec Kit `specify` flow, letting it handle branch/spec setup.
+6. Evaluate the Candidate Selection Gate.
-7. Run the repository's real Spec Kit `plan` flow.
+7. Run the repository's real Spec Kit `specify` flow, letting it handle branch/spec setup.
-8. Run the repository's real Spec Kit `tasks` flow.
+8. Run the repository's real Spec Kit `plan` flow.
-9. Run the repository's real Spec Kit preparation `analyze` flow.
+9. Run the repository's real Spec Kit `tasks` flow.
-10. Fix analyze issues only in Spec Kit preparation artifacts.
+10. Run the repository's real Spec Kit preparation `analyze` flow.
-11. Evaluate the Spec Readiness Gate.
+11. Fix analyze issues only in Spec Kit preparation artifacts.
-12. Stop before application implementation.
+12. Evaluate the Spec Readiness Gate.
-13. Return selection rationale, branch/path summary, artifact summary, analyze summary, fixes applied, gates, and next implementation prompt.
+13. Stop before application implementation.
+14. Return selection rationale, branch/path summary, artifact summary, analyze summary, fixes applied, gates, and next implementation prompt.
 ```

docs/product/implementation-ledger.md

@@ -1,10 +1,10 @@
 # TenantPilot Implementation Ledger
 
 > **Status:** Active  
-> **Last reviewed:** 2026-04-30  
+> **Last reviewed:** 2026-05-01  
 > **Use for:** Repo-based implementation status and product-surface maturity assessment  
 > **Do not use for:** Roadmap priority, spec priority, or proof that tests were executed in the current branch
-> **Scoped maintenance:** 2026-05-01 provider-missing / Spec 261 alignment and doc hygiene only; no full repo-wide maturity re-audit was performed.
+> **Scoped maintenance:** 2026-05-01 full repo-based maturity refresh against current `specs/` truth and repo anchors, especially refreshed Spec 043 and Specs 251-260 plus the implemented compare/preflight, governance-package, compliance-interpretation, commercial-lifecycle, and external-support-handoff slices.
 
 ## Purpose
 
@@ -21,7 +21,7 @@ ## Purpose
 
 ## Current Product Position
 
-TenantPilot ist aktuell ein starkes internes Governance- und Operations-Produkt mit belastbaren Foundations fuer Execution Truth, Baselines/Drift, Findings, Evidence, Reviews, Review Packs, Supportability, Telemetry und Safety Controls sowie einer repo-real umgesetzten ersten Customer-Review-Surface, Risk-Acceptance/Exception-Workflow, Findings-/Governance-Inboxen und einer DE/EN-Locale-Foundation. Die Repo-Wahrheit liegt damit klar ueber einer simplen Lesart von "R1 done / R2 partial". Gleichzeitig ist das Produkt noch nicht voll als kundenseitig konsumierbare Portfolio- und Commercial-Plattform ausgereift: Die Customer-Review-Surface ist noch eher eine operator-led customer delivery view im Admin-Kontext als eine voll produktisierte, kundensichere Governance-of-Record Consumption-Flache; dazu bleiben Cross-Tenant-Workflows, Compare/Promotion, Billing-/Lifecycle-Reife und Private-AI-Governance unvollstaendig. Zusaetzlich zeigt der Repo-Stand weiterhin eine schmale Findings-Cleanup-Lane: sichtbare Lifecycle-Backfill-Runtime-Surfaces, `acknowledged`-Kompatibilitaet und fehlende explizite Creation-Time-Invariant-Absicherung sollten als getrennte Folgespecs behandelt werden.
+TenantPilot ist aktuell ein starkes internes Governance- und Operations-Produkt mit belastbaren Foundations fuer Execution Truth, Baselines/Drift, Findings, Evidence, Reviews, Review Packs, Supportability, Telemetry und Safety Controls. Darauf sitzen inzwischen mehrere repo-real productization slices: eine customer-safe Review-/Governance-Package-Surface im Admin-Kontext, released-review detail handoff, compliance interpretation overlays, bounded external support-desk handoff, commercial lifecycle state handling mit read-only gating sowie eine kanonische cross-tenant compare preview mit promotion preflight. Die Repo-Wahrheit liegt damit klar ueber einer simplen Lesart von "R1 done / R2 partial" und auch ueber einer rein foundation-only Interpretation fuer Reviews, Support und Portfolio-Preparation. Gleichzeitig ist das Produkt noch nicht voll als kundenseitig konsumierbare Portfolio- und Commercial-Plattform ausgereift: Es fehlen die letzte customer-safe self-serve productization ueber der Review-Surface, actual portfolio promotion execution und ein breiterer decision workboard/action layer, wiederholbare Billing-/Trial-/Demo-Operations sowie eine AI-governed execution foundation.
 
 ## Status Model
 
@@ -47,26 +47,28 @@ ## Roadmap Coverage Summary
 | Roadmap Area | Status | Evidence Level | UI Ready | Tested | Sellable | Notes |
 |---|---|---:|---|---|---|---|
 | R1 Golden Master Governance | adopted | strong | yes | repo tests, not run | yes | Baselines, Drift, Findings und OperationRun-Truth sind breit im Produkt verankert. |
-| R2 Tenant Reviews, Evidence & Control Foundation | adopted | strong | yes | repo tests, not run | almost | Reviews, Evidence, Review Packs, Customer Review Workspace und Control-/Exception-Layer greifen als reale Governance-Surface zusammen, aber die Customer-Consumption-Productization bleibt unvollstaendig. |
+| R2 Tenant Reviews, Evidence & Control Foundation | adopted | strong | yes | repo tests, not run | almost | Reviews, Evidence, Review Packs, Customer Review Workspace, governance-package delivery, compliance interpretation overlays und Control-/Exception-Layer greifen als reale Governance-Surface zusammen, aber die finale customer-safe self-serve productization bleibt offen. |
 | Alert escalation + notification routing | implemented_verified | strong | partial | repo tests, not run | yes | Alert-Regeln, Dispatch, Cooldown und Quiet Hours sind real. |
 | Governance & Architecture Hardening | implemented_partial | strong | partial | repo tests, not run | foundation-only | Viele Hardening-Slices sind bereits im Code, die Lane bleibt aber aktiv. |
 | UI & Product Maturity Polish | implemented_partial | strong | partial | partial repo tests, not run | no | Empty States, Navigation, Localization und read-only Review-Polish sind real, aber kein geschlossenes Theme-Completion-Signal. |
 | Secret & Security Hardening | implemented_verified | strong | yes | repo tests, not run | almost | Provider-Verifikation, Permission-Diagnostics und Redaction sind belastbar. |
 | Baseline Drift Engine (Cutover) | adopted | strong | yes | repo tests, not run | yes | Compare- und Drift-Workflow wirken als produktive Kernfunktion. |
 | R1.9 Platform Localization v1 | implemented_verified | strong | yes | repo tests, not run | foundation-only | Locale-Resolver, Override/Praeferenz, Workspace-Default, Fallback und lokalisierte Notifications sind repo-real. |
-| Product Scalability & Self-Service Foundation | implemented_partial | strong | yes | repo tests, not run | almost | Onboarding, Support, Help und Entitlements sind weit; Billing, Trial und Demo-Reife fehlen. |
+| Product Scalability & Self-Service Foundation | implemented_partial | strong | yes | repo tests, not run | almost | Onboarding, Support, Help, Entitlements, commercial lifecycle state handling und bounded support-desk handoff sind repo-real; Billing-, Trial- und Demo-Automation bleiben offen. |
 | R2.0 Canonical Control Catalog Foundation | implemented_verified | strong | partial | repo tests, not run | foundation-only | Bereits implementiert und in Evidence/Reviews referenziert, aber kein eigenstaendiger Kundennutzen-Surface. |
-| R2 Completion: customer review, support, help | implemented_partial | strong | yes | repo tests, not run | almost | Customer Review Workspace, Support Diagnostics/Requests und Help-Katalog sind repo-real, aber die Customer-Review-Consumption ist noch nicht voll productized. |
+| R2 Completion: customer review, support, help | implemented_partial | strong | yes | repo tests, not run | almost | Customer Review Workspace, released-review detail handoff, governance-package delivery, Support Diagnostics/Requests und Help-Katalog sind repo-real, aber die finale customer-safe productization ist noch nicht vollstaendig. |
+| Compliance Evidence Mapping v1 | implemented_partial | strong | yes | repo tests, not run | foundation-only | Canonical control interpretation is rendered in tenant reviews and the customer review workspace, but broader framework coverage and auditor-facing mapping remain open. |
+| Governance-as-a-Service Packaging v1 | implemented_partial | strong | yes | repo tests, not run | foundation-only | Governance package status, download messaging und current review-pack reuse sind repo-real, aber standalone recurring delivery workflows und breitere management packaging remain open. |
 | Findings Workflow v2 / Execution Layer | adopted | strong | yes | repo tests, not run | almost | Triage, Ownership, My Work, Intake, Governance Inbox, Exceptions und Alerts/Hygiene sind real; Cross-Tenant-Decisioning bleibt spaeter. |
 | Provider-missing policy visibility follow-up | specified | weak | no | no | no | Spec 261 ist als schmaler policy-only Follow-up vorbereitet; die breitere Lifecycle-Taxonomie bleibt strategisch und unimplementiert. |
 | Platform Operations Maturity | implemented_partial | strong | yes | repo tests, not run | almost | System Panel, Control Tower und Ops Controls sind real; CSV/Raw Drilldowns bleiben offen. |
 | Product Usage, Customer Health & Operational Controls | adopted | strong | yes | repo tests, not run | almost | Diese Mid-term-Lane ist im Repo bereits substanziell vorhanden. |
 | Private AI Execution Governance Foundation | planned | none | no | no | no | Keine belastbare AI-Governance-Foundation im Repo. |
-| MSP Portfolio & Operations | implemented_partial | medium | partial | repo tests, not run | foundation-only | Portfolio-Triage ist da; Compare/Promotion und Decision Workboard fehlen. |
+| MSP Portfolio & Operations | implemented_partial | strong | yes | repo tests, not run | foundation-only | Portfolio-Triage, canonical compare preview, preflight audit and launch continuity are repo-real; actual promotion execution and the broader decision workboard remain open. |
 | Human-in-the-Loop Autonomous Governance | planned | none | no | no | no | Kein repo-verifizierter Decision-Pack- oder Approval-Workflow jenseits des jetzigen Exception-/Review-Layers. |
 | Drift & Change Governance | implemented_partial | strong | yes | repo tests, not run | almost | Drift review, accepted-risk governance, exception validity und Governance-Inbox-Surfaces sind repo-real; portfolio-weite Eskalation bleibt offen. |
 | Standardization & Policy Quality | planned | none | no | no | no | Keine starke Repo-Evidence fuer eine Intune-Linting- oder Policy-Quality-Oberflaeche. |
-| PSA / Ticketing Handoff | planned | none | no | no | no | Support Requests existieren, externe Handoff-Integration aber nicht. |
+| PSA / Ticketing Handoff | implemented_verified | strong | yes | repo tests, not run | almost | Support Requests now include bounded external create/link handoff on the current tenant and operation-run contexts; broader multi-provider ITSM expansion remains separate work. |
 
 ## Implemented Capabilities
 
@@ -82,6 +84,8 @@ ## Implemented Capabilities
 | Tenant reviews | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Models/TenantReview.php`; `app/Services/TenantReviews/TenantReviewService.php`; `tests/Feature/TenantReview/*` |
 | Review pack generation and export | implemented_verified | yes | yes | repo tests, not run | yes | yes | `app/Models/ReviewPack.php`; `app/Services/ReviewPackService.php`; `tests/Feature/ReviewPack/*` |
 | Customer review workspace | implemented_partial | yes | yes | repo tests, not run | yes | almost | `app/Filament/Pages/Reviews/CustomerReviewWorkspace.php`; `tests/Feature/Reviews/*`; `tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php` |
+| Governance package delivery surface | implemented_partial | yes | yes | repo tests, not run | yes | almost | `app/Filament/Pages/Reviews/CustomerReviewWorkspace.php`; `app/Filament/Resources/TenantReviewResource.php`; `tests/Feature/Reviews/CustomerReviewWorkspacePackAccessTest.php`; `tests/Feature/TenantReview/TenantReviewExplanationSurfaceTest.php` |
+| Compliance evidence mapping overlay | implemented_partial | yes | yes | repo tests, not run | partial | foundation-only | `app/Support/Governance/Controls/ComplianceEvidenceMappingV1.php`; `app/Services/TenantReviews/TenantReviewSectionFactory.php`; `tests/Feature/TenantReview/TenantReviewCanonicalControlReferenceTest.php` |
 | Alerts and notification routing | implemented_verified | yes | partial | repo tests, not run | yes | yes | `app/Services/Alerts/AlertDispatchService.php`; `tests/Feature/*Alert*` |
 | Provider health, onboarding readiness and required permissions | adopted | yes | yes | repo tests, not run | yes | almost | `app/Jobs/ProviderConnectionHealthCheckJob.php`; `app/Services/Onboarding/OnboardingLifecycleService.php`; `app/Filament/Pages/TenantRequiredPermissions.php` |
 | Permission posture reporting | implemented_verified | yes | yes | repo tests, not run | yes | yes | `app/Services/PermissionPosture/PermissionPostureFindingGenerator.php`; `tests/Feature/PermissionPosture/*` |
@@ -89,23 +93,26 @@ ## Implemented Capabilities
 | Stored reports substrate | implemented_verified | yes | partial | repo tests, not run | partial | foundation-only | `app/Models/StoredReport.php`; `tests/Feature/PermissionPosture/StoredReportModelTest.php`; `tests/Feature/EntraAdminRoles/StoredReportFingerprintTest.php` |
 | Support diagnostics | adopted | yes | yes | repo tests, not run | yes | almost | `app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php`; `app/Filament/Pages/TenantDashboard.php`; `tests/Feature/SupportDiagnostics/*` |
 | In-app support requests | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Models/SupportRequest.php`; `app/Support/SupportRequests/*`; `tests/Feature/SupportRequests/*` |
+| External support-desk handoff | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Support/SupportRequests/ExternalSupportDeskHandoffService.php`; `app/Support/SupportRequests/SupportRequestSubmissionService.php`; `tests/Unit/Support/SupportRequests/ExternalSupportDeskHandoffServiceTest.php` |
 | Product knowledge and contextual help | implemented_partial | yes | yes | repo tests, not run | partial | almost | `app/Support/ProductKnowledge/ContextualHelpCatalog.php`; `tests/Feature/Onboarding/ProductKnowledgeOnboardingHelpTest.php` |
 | Localization foundation | implemented_verified | yes | yes | repo tests, not run | partial | foundation-only | `app/Services/Localization/LocaleResolver.php`; `app/Http/Controllers/LocalizationController.php`; `tests/Feature/Localization/*` |
 | Product telemetry | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Models/ProductUsageEvent.php`; `app/Filament/System/Widgets/ProductTelemetryKpis.php`; `tests/Feature/System/ProductTelemetry/*` |
 | Customer health scoring | implemented_verified | yes | yes | repo tests, not run | partial | almost | `app/Filament/System/Widgets/CustomerHealthKpis.php`; `app/Filament/System/Widgets/CustomerHealthTopWorkspaces.php`; `tests/Feature/System/CustomerHealth/*` |
 | Operational controls | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Models/OperationalControlActivation.php`; `app/Support/OperationalControls/*`; `tests/Feature/System/OpsControls/*` |
 | Workspace entitlements | implemented_verified | yes | yes | repo tests, not run | yes | foundation-only | `app/Services/Entitlements/WorkspaceEntitlementResolver.php`; `tests/Feature/Filament/Settings/WorkspaceEntitlementsSettingsPageTest.php` |
+| Commercial lifecycle state handling | implemented_verified | yes | yes | repo tests, not run | yes | foundation-only | `app/Services/Entitlements/WorkspaceCommercialLifecycleResolver.php`; `app/Filament/System/Pages/Directory/ViewWorkspace.php`; `tests/Feature/System/ViewWorkspaceEntitlementsTest.php`; `tests/Unit/Entitlements/WorkspaceCommercialLifecycleResolverTest.php` |
 | Capability-first RBAC | adopted | yes | yes | repo tests, not run | yes | foundation-only | `app/Services/Auth/CapabilityResolver.php`; `app/Services/Auth/RoleCapabilityMap.php`; many `tests/Feature/Rbac/*` |
 | Audit log foundation | adopted | yes | yes | repo tests, not run | yes | foundation-only | `app/Models/AuditLog.php`; `app/Services/Audit/WorkspaceAuditLogger.php`; many audit-focused feature tests |
 | Canonical control catalog | implemented_verified | yes | partial | repo tests, not run | partial | foundation-only | `app/Support/Governance/Controls/CanonicalControlCatalog.php`; `config/canonical_controls.php`; `tests/Unit/Governance/*` |
 | Portfolio triage continuity | implemented_verified | yes | yes | repo tests, not run | yes | foundation-only | `app/Services/PortfolioTriage/TenantTriageReviewService.php`; `app/Support/PortfolioTriage/*`; `tests/Feature/Filament/TenantRegistryTriageReviewStateTest.php` |
+| Cross-tenant compare preview and promotion preflight | implemented_verified | yes | yes | repo tests, not run | yes | foundation-only | `app/Filament/Pages/CrossTenantComparePage.php`; `app/Support/PortfolioCompare/CrossTenantComparePreviewBuilder.php`; `app/Support/PortfolioCompare/CrossTenantPromotionPreflight.php`; `tests/Feature/PortfolioCompare/*`; `tests/Unit/Support/PortfolioCompare/*` |
 
 ## Foundation-Only Capabilities
 
 - OperationRun truth and canonical operation typing: starke Execution-Foundation, aber kein eigenstaendiger Kundennutzen-Surface.
 - Audit log foundation: breit genutzt und wichtig fuer Governance, aber allein nicht verkaufbar.
 - Capability-first RBAC: belastbar und testnah, bleibt aber Enablement-Layer.
-- Workspace entitlements: reale Gate- und Override-Logik, aber noch keine volle Commercial Lifecycle Story.
+- Workspace entitlements und commercial lifecycle policy engine: reale Gate-, Lifecycle- und Override-Logik, aber noch keine volle Billing-/Contract-Ops story.
 - Canonical control catalog: starke semantische Foundation fuer Evidence, Findings und Reviews.
 - Stored reports substrate: wichtig fuer Reports, Evidence und Diagnostics, aber kein eigenstaendiges Produktversprechen.
 - Evidence snapshot substrate: tragende technische Basis fuer Reviews und Exports.
@@ -116,10 +123,10 @@ ## Foundation-Only Capabilities
 
 ## Partial Capabilities
 
-- Customer-facing review consumption: Tenant Reviews, Evidence Snapshots, Review Packs und der Customer Review Workspace sind repo-real, aber die Surface bleibt noch operator-led im Admin-Kontext; customer-safe wording, evidence summarization boundaries, audit-grade access semantics und calmer consumption states brauchen ein eigenes Productization-Follow-up.
+- Customer-facing review consumption: Tenant Reviews, Evidence Snapshots, Review Packs, the Customer Review Workspace, the customer-safe released-review detail mode, governance-package delivery cues, compliance interpretation overlays, and commercial-lifecycle-aware access states are repo-real; broader lifecycle/governance taxonomy work remains separate.
-- Findings Workflow v2: Triage, Assignment, My Work, Intake, Governance Inbox, Exceptions und Notifications sind vorhanden; spaetere Cross-Tenant-Decisioning-Layer und Cleanup debt um Lifecycle-Backfill-Surfaces, `acknowledged`-Kompatibilitaet und explizite Creation-Time-Invarianten bleiben offen.
+- Findings Workflow v2: Triage, Assignment, My Work, Intake, Governance Inbox, Exceptions, notifications, and the three queue-facing cleanup/hardening follow-through packages are now repo-backed; later cross-tenant action layers remain separate work.
-- Product scalability and self-service: Onboarding, Support, Help und Entitlements sind weit, Billing-, Trial- und Demo-Reife aber nicht.
+- Product scalability and self-service: Onboarding, Support, Help, Entitlements, commercial lifecycle state handling, and external support-desk handoff are repo-real; broader trial/demo and commercialization layers still remain.
-- MSP portfolio operations: Portfolio-Triage ist vorhanden, Cross-Tenant Compare und Promotion fehlen.
+- MSP portfolio operations: Portfolio-Triage plus cross-tenant compare preview and promotion preflight are repo-real; actual promotion execution and broader portfolio action orchestration remain open.
 - Platform operations maturity: Control Tower und Ops Controls sind stark, aber einige geplante operatorseitige Drilldowns/Exports fehlen noch.
 - Product knowledge rollout: Help-Katalog und Resolver sind real, aber noch nicht breit genug adoptiert fuer "fertig".
 
@@ -128,20 +135,18 @@ ## Planned But Not Implemented
 - Private AI Execution Governance Foundation
 - Human-in-the-Loop Autonomous Governance
 - Standardization & Policy Quality / Intune Linting
-- PSA / Ticketing Handoff
-- Cross-Tenant Compare and Promotion v1
 - Provider-Missing Policy Visibility & Restore Continuity v1 (Spec 261, specified only)
-- Later compliance overlays beyond the current control/evidence foundation
+- Broader compliance frameworks and auditor-facing mapping beyond the current evidence overlay
 
 ## Release Readiness
 
 | Release / Theme | Readiness | Notes |
 |---|---|---|
 | R1 Golden Master Governance | implemented | Die zentrale Governance- und Execution-Layer ist repo-verifiziert und breit adoptiert. |
-| R2 Tenant Reviews & Evidence Packs | implemented | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace und Exception-/Accepted-Risk-Workflow sind repo-real; die Customer-Review-Productization bleibt aber als sellability follow-up offen. |
+| R2 Tenant Reviews & Evidence Packs | implemented | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, released-review detail handoff, governance-package delivery, compliance interpretation overlays und Exception-/Accepted-Risk-Workflow sind repo-real; die finale customer-safe Productization bleibt als sellability follow-up offen. |
-| R3 MSP Portfolio OS | foundation only | Portfolio-Triage und Governance-Surfaces sind da, aber Compare/Promotion und portfolio-weite Action-Layer fehlen. |
+| R3 MSP Portfolio OS | partial | Portfolio-Triage sowie canonical compare preview/preflight sind da, aber actual promotion execution und portfolio-weite Action-Layer fehlen weiter. |
-| Compliance Evidence Mapping v1 | foundation only | Canonical Controls, Evidence, Stored Reports und Exceptions existieren als Grundlage; eine customer-safe Mapping-Layer ist nicht repo-proven. |
+| Compliance Evidence Mapping v1 | partial | Compliance interpretation overlays sind repo-real in Tenant Reviews und Customer Review Workspace, aber breitere Framework-Abdeckung und auditor-facing mapping fehlen weiter. |
-| Governance-as-a-Service Packaging v1 | foundation only | Review Packs, Exports, Evidence und Accepted-Risk-Truth sind repo-real; eine wiederholbare management-taugliche Governance-Verpackung ist nicht repo-proven. |
+| Governance-as-a-Service Packaging v1 | partial | Governance package status, delivery messaging und current review-pack reuse sind repo-real; eine wiederholbare management-taugliche Packaging-Workflow-Layer ist nicht vollstaendig. |
 
 ## Commercial Readiness
 
@@ -150,17 +155,18 @@ ### Demo-ready
 - Baseline compare and drift walkthroughs
 - Review pack generation and export
 - Customer review workspace walkthroughs with operator guidance
+- Cross-tenant compare preview and promotion preflight walkthroughs
 - Provider health, onboarding readiness and required permissions
 - Support diagnostics
 - Permission posture and Entra admin roles reporting
 
 ### Almost sellable
 
-- Review-driven governance workflow rund um Tenant Reviews, Customer Review Workspace, accepted risks und Review Packs, aber noch nicht als vollstaendig productisierte customer-safe consumption experience
+- Review-driven governance workflow rund um Tenant Reviews, Customer Review Workspace, governance-package delivery, compliance interpretation overlays, accepted risks und Review Packs, aber noch nicht als vollstaendig productisierte customer-safe consumption experience
 - Baseline drift and restore governance
 - Findings workflow mit persönlicher Inbox, Intake, Governance Inbox und Exception-Handling
 - Alerting and run visibility for governance operations
-- Support requests with contextual diagnostics
+- Support requests with contextual diagnostics and bounded external create/link handoff
 - Provider readiness and permission posture reporting
 
 ### Foundation-only
@@ -180,42 +186,31 @@ ### Foundation-only
 
 ### Not sellable yet
 
-- Cross-Tenant Compare and Promotion v1
+- Portfolio-wide promotion execution and decision workboard
-- Compliance Evidence Mapping v1
+- Broader compliance evidence mapping surface
-- Governance-as-a-Service Packaging v1
+- Standalone governance-as-a-service packaging workflow
 - Private AI Execution Governance Foundation
-- External Support Desk / PSA Handoff
 
 ## Open Gaps & Blockers
 
+Queue audit note: the former queue-facing gap rows for customer review productization, governance convergence, the findings cleanup trio, compare/preflight, commercial lifecycle maturity, compliance evidence mapping, governance packaging, and external support-desk handoff were narrowed or removed here on 2026-05-01 because refreshed Spec 043 and Specs 251-260 now provide prepared or implemented packages for those bounded slices.
+
 | Gap | Type | Impact | Roadmap Area | Recommended Spec |
 |---|---|---|---|---|
-| Customer review productization remains incomplete | Sellability blocker | The repo has a real read-only customer review surface, but it still sits too close to operator/admin semantics and does not yet enforce a fully customer-safe consumption contract for findings, evidence, accepted risks, and audit-grade access/download flows | R2 completion / Customer review | P0 Customer Review Workspace Productization v1 |
+| No safe automatic next-best-prep target is currently active | Planning blocker | `spec-candidates.md` had drifted behind current `specs/` truth, so automatic next-spec selection would have reopened already prepared or completed packages | Product planning / queue hygiene | none - require explicit promotion of the next candidate |
-| Decisioning still spans multiple repo-real inboxes | UX blocker | My Findings, Intake, Governance Inbox und Exception Queue sind real, aber Operators springen weiter zwischen mehreren Spezial-Surfaces und es gibt noch keinen portfolio-weiten Action-Layer | Findings Workflow / MSP Portfolio | P1 Governance Decision Surface Convergence |
+| Customer-safe review productization is not fully complete | Productization blocker | Customer review workspace, released-review details, governance-package delivery, compliance overlays, and lifecycle-aware access are repo-real, but the final calmer self-serve customer-safe polish is still incomplete | R2 review consumption | explicit follow-through only if re-promoted; do not reopen completed specs automatically |
-| Findings lifecycle backfill runtime surfaces remain productized | Cleanup blocker | Runbooks, commands, capabilities and tenant actions still expose a pre-production repair path that should not ship as product truth | Findings Workflow / Legacy Removal | P1 Remove Findings Lifecycle Backfill Runtime Surfaces |
+| Portfolio promotion execution and the broader decision workboard remain absent | Product blocker | Compare preview and preflight are repo-real, but no execution path, persisted drafts, queueing, or wider portfolio action orchestration exists | MSP Portfolio & Operations | explicit new candidate or follow-up; do not reopen Spec 043 automatically |
-| Legacy `acknowledged` status compatibility still survives | Semantics blocker | Status helpers, filters, badges, capability aliases and tests keep non-canonical workflow semantics alive | Findings Workflow / RBAC | P1 Remove Legacy Acknowledged Finding Status Compatibility |
+| Provider-missing policy visibility follow-up remains specified only | Product blocker | Spec 261 exists as a bounded policy-only correction, but implementation has not landed and the broader lifecycle taxonomy stays deferred | Lifecycle governance / provider truth | Spec 261 if pressure becomes immediate |
-| Creation-time finding invariants are implied but not explicitly protected | Integrity blocker | Future finding generators could regress into partial lifecycle writes and recreate the need for repair tooling | Findings Workflow / Data Integrity | P1 Enforce Creation-Time Finding Invariants |
+| Workspace, Tenant & Managed Object Lifecycle Governance v1 remains deferred by design | Strategic blocker | The lifecycle taxonomy is still intentionally broader than the bounded slices that just landed and should not be auto-selected without an explicit roadmap decision | Lifecycle governance / enterprise trust | deferred strategic candidate only |
-| Cross-tenant compare and promotion is not repo-proven | Release blocker | MSP portfolio story remains partial | MSP Portfolio & Operations | P1 Cross-Tenant Compare and Promotion v1 |
-| Entitlements stop short of full commercial lifecycle | Commercialization blocker | Plan gating exists, but trial, grace and suspension semantics remain incomplete | Product Scalability & Self-Service Foundation | P2 Commercial Entitlements and Billing-State Maturity |
-| Compliance-oriented control mapping is not productized | Moat blocker | Canonical controls and evidence exist, but the product still lacks a bounded customer-safe layer that maps technical truth into control/readiness language | Compliance Evidence Mapping | P2 Compliance Evidence Mapping v1 |
-| Review truth is not yet packaged as a repeatable MSP deliverable | Sellability blocker | Review packs and evidence are real, but recurring management-ready governance packaging still depends on manual interpretation and presentation | Governance-as-a-Service Packaging | P2 Governance-as-a-Service Packaging v1 |
-| Support requests do not hand off to an external desk | Commercialization blocker | Support operations still depend on manual follow-through outside the product | R2 completion / Support | P2 External Support Desk / PSA Handoff |
 | AI governance foundation is absent | Architecture blocker | Future AI features would risk trust and policy drift if added directly | Private AI Execution Governance | P3 Private AI Execution Governance Foundation |
-| Roadmap understates current repo truth | Architecture blocker | Prioritization can drift because strategy docs still lag neuere Review-, Findings- und Localization-Surfaces | Product planning / roadmap maintenance | none - docs alignment |
+| Roadmap understates current repo truth | Documentation blocker | Prioritization can drift because strategy docs still lag compare/preflight, governance-package delivery, compliance overlays, commercial lifecycle handling, and support handoff slices | Product planning / roadmap maintenance | none - docs alignment |
 | Test files were not executed for this ledger update | Testing blocker | This document relies on code plus test presence, not live runtime validation | all areas | none - run targeted suites |
 
 ## Recommended Next Specs
 
-- `P0 Customer Review Workspace Productization v1`: turns the existing admin-plane handoff into a more explicit customer-safe review consumption contract with calmer wording, progressive disclosure, explicit access states, and auditable download/view semantics.
+- `No safe automatic next-best-prep target`: queue hygiene work is complete; do not reopen Specs 043 or 251-260 through another automatic selection pass.
-- `P1 Governance Decision Surface Convergence`: verbindet My Findings, Intake, Governance Inbox, Customer Review Workspace und Exception Queue zu weniger Operator-Journeys und bereitet die Portfolio-Ebene vor.
+- `Spec 261 execution decision`: if provider-missing pressure is immediate, execute the already-prepared policy-only follow-up instead of drafting a broader lifecycle patch.
-- `P1 Remove Findings Lifecycle Backfill Runtime Surfaces`: removes visible pre-production repair tooling from runbooks, commands, actions, capabilities and deploy/runtime hooks.
+- `Workspace, Tenant & Managed Object Lifecycle Governance v1`: still the main deferred strategic candidate, but only after an explicit roadmap/product decision promotes it into the active queue.
-- `P1 Remove Legacy Acknowledged Finding Status Compatibility`: collapses findings workflow semantics onto the canonical `triaged` model and removes stale RBAC/query aliases.
-- `P1 Enforce Creation-Time Finding Invariants`: proves that new findings are lifecycle-ready at write time so no repair backfill has to return later.
-- `P1 Cross-Tenant Compare and Promotion v1`: needed to move from portfolio visibility to portfolio action.
-- `P2 Commercial Entitlements and Billing-State Maturity`: extends the already real entitlement substrate into a usable commercial lifecycle.
-- `P2 Compliance Evidence Mapping v1`: should start as one bounded versioned overlay that maps existing technical truth into one customer-safe control/readiness view and one reuse path into review or export surfaces.
-- `P2 Governance-as-a-Service Packaging v1`: should start as one on-demand management-ready governance package built from existing review-pack, evidence, and accepted-risk truth rather than a broad recurring reporting suite.
-- `P2 External Support Desk / PSA Handoff`: extends support requests beyond internal persistence.
 - `P3 Private AI Execution Governance Foundation`: should exist before feature-level AI adoption, not after it.
 
 ## Roadmap Drift Notes
@@ -226,8 +221,11 @@ ## Roadmap Drift Notes
 - `roadmap.md` understates the current R2 control foundation. Canonical controls, stored reports, permission posture and Entra admin roles are already repo-real, not just near-term ideas.
 - `roadmap.md` understates product supportability. Support diagnostics, in-app support requests and contextual help already exist in the repo.
 - `roadmap.md` understates operational maturity. Product telemetry, customer health and operational controls are already implemented and wired into the system panel.
-- `roadmap.md` understates commercial foundations. A workspace entitlement resolver, plan profiles and enforcement points already exist, even though full billing-state maturity does not.
+- `roadmap.md` understates commercial foundations. Workspace entitlements, commercial lifecycle state handling, plan profiles and enforcement points already exist, even though full billing-state maturity does not.
-- The roadmap is now better at describing still-missing portfolio- und commercial-Layer than the current state of review/findings/localization implementation. Cross-Tenant Compare and Promotion, full billing-state maturity, external PSA handoff and AI Governance still look genuinely unimplemented.
+- `roadmap.md` understates MSP portfolio preparation. Cross-tenant compare preview, promotion preflight, audit logging and launch continuity are already repo-real.
+- `roadmap.md` understates governance-package delivery and compliance interpretation. The customer review workspace and released-review detail now expose governance-package status/download cues plus current evidence interpretation overlays.
+- `roadmap.md` understates bounded external support handoff. Support requests now support current-scope external create/link handoff without introducing a separate support queue product.
+- Queue-facing drift had become larger than roadmap drift alone: this ledger and `spec-candidates.md` were still naming already prepared or completed slices as open candidates even though refreshed Spec 043 and Specs 251-260 now carry prep or implementation-close-out evidence.
 - The main drift pattern is still underestimation, but customer-review sellability now needs a more precise reading: the missing piece is no longer basic review read-only access, but the final customer-safe productization layer over an already real surface.
 
 ## Evidence Sources
@@ -243,6 +241,7 @@ ## Evidence Sources
 - `apps/platform/app/Providers/Filament/AdminPanelProvider.php`
 - `apps/platform/app/Providers/Filament/SystemPanelProvider.php`
 - `apps/platform/app/Filament/Pages/TenantDashboard.php`
+- `apps/platform/app/Filament/Pages/CrossTenantComparePage.php`
 - `apps/platform/app/Filament/System/Pages/Dashboard.php`
 - `apps/platform/app/Filament/Pages/TenantRequiredPermissions.php`
 - `apps/platform/app/Filament/Pages/Reviews/CustomerReviewWorkspace.php`
@@ -275,12 +274,17 @@ ## Evidence Sources
 - `apps/platform/app/Services/TenantReviews/TenantReviewService.php`
 - `apps/platform/app/Services/Evidence/EvidenceSnapshotService.php`
 - `apps/platform/app/Services/Baselines/BaselineCompareService.php`
+- `apps/platform/app/Services/Entitlements/WorkspaceCommercialLifecycleResolver.php`
 - `apps/platform/app/Services/Alerts/AlertDispatchService.php`
 - `apps/platform/app/Services/Findings/FindingExceptionService.php`
 - `apps/platform/app/Jobs/ProviderConnectionHealthCheckJob.php`
 - `apps/platform/app/Services/Onboarding/OnboardingLifecycleService.php`
 - `apps/platform/app/Services/Entitlements/WorkspaceEntitlementResolver.php`
 - `apps/platform/app/Services/PortfolioTriage/TenantTriageReviewService.php`
+- `apps/platform/app/Support/Governance/Controls/ComplianceEvidenceMappingV1.php`
+- `apps/platform/app/Support/PortfolioCompare/CrossTenantComparePreviewBuilder.php`
+- `apps/platform/app/Support/PortfolioCompare/CrossTenantPromotionPreflight.php`
+- `apps/platform/app/Support/SupportRequests/ExternalSupportDeskHandoffService.php`
 - `apps/platform/app/Support/Governance/Controls/CanonicalControlCatalog.php`
 - `apps/platform/app/Services/Audit/WorkspaceAuditLogger.php`
 - `apps/platform/app/Services/Auth/CapabilityResolver.php`
@@ -288,19 +292,24 @@ ## Evidence Sources
 
 Wichtige Test-Anker im Repo:
 
+- `apps/platform/tests/Feature/PortfolioCompare/*`
 - `apps/platform/tests/Feature/ReviewPack/*`
 - `apps/platform/tests/Feature/Evidence/*`
 - `apps/platform/tests/Feature/PermissionPosture/*`
 - `apps/platform/tests/Feature/EntraAdminRoles/*`
 - `apps/platform/tests/Feature/SupportDiagnostics/*`
 - `apps/platform/tests/Feature/SupportRequests/*`
+- `apps/platform/tests/Feature/System/ViewWorkspaceEntitlementsTest.php`
+- `apps/platform/tests/Feature/TenantReview/TenantReviewCanonicalControlReferenceTest.php`
 - `apps/platform/tests/Feature/System/CustomerHealth/*`
 - `apps/platform/tests/Feature/System/ProductTelemetry/*`
 - `apps/platform/tests/Feature/System/OpsControls/*`
 - `apps/platform/tests/Feature/Filament/TenantRegistryTriageReviewStateTest.php`
 - `apps/platform/tests/Unit/Governance/*`
+- `apps/platform/tests/Unit/Support/PortfolioCompare/*`
+- `apps/platform/tests/Unit/Support/SupportRequests/ExternalSupportDeskHandoffServiceTest.php`
 - `apps/platform/tests/Unit/Entitlements/*`
 
 ## Last Updated
 
-2026-05-01 on branch `261-provider-missing-policy-visibility` (scoped provider-missing/docs alignment only)
+2026-05-01 on branch `platform-dev` (full repo-based maturity refresh against current specs and repo anchors)

docs/product/spec-candidates.md

@@ -1,10 +1,10 @@
 # Spec Candidates
 
 > **Status:** Active  
-> **Last reviewed:** 2026-04-30  
+> **Last reviewed:** 2026-05-01  
 > **Use for:** The active repo-based queue of spec candidates that may still need new or refreshed specs  
 > **Do not use for:** Proof that a candidate is already specced, implemented, or prioritized above the roadmap without repo verification
-> **Scoped maintenance:** 2026-05-01 provider-missing / Spec 261 alignment only; the active queue was not fully re-audited end-to-end.
+> **Scoped maintenance:** 2026-05-01 repo-based queue re-audit against current `specs/` truth, including refreshed Spec 043 and Specs 251-260; stale active candidates were cleared and no new candidate was promoted.
 >
 > Repo-based next-spec queue for TenantPilot.
 > This file is not a wishlist. It tracks only open gaps that are still worth turning into new or refreshed specs.
@@ -34,340 +34,24 @@ ## Current Source-Of-Truth Boundary
 
 ## Active Candidate Queue
 
-### P0 — Release Blockers
+**2026-05-01 queue re-audit result**: no safe automatic next-best-prep target remains in the active queue.
 
-### Customer Review Workspace Productization v1
+The previous P0-P2 candidates were removed from the active queue because current `specs/` truth already covers them as prepared or implemented packages:
-- **Priority**: P0
-- **Candidate type**: Productization / customer-safe consumption.
-- **Why this stays active**: The repo already has strong review foundations plus a repo-real `CustomerReviewWorkspace` page from Spec 249. What remains open is productization: the current surface still behaves more like an operator-led customer delivery view inside the admin plane than a fully customer-safe governance-of-record consumption experience.
-- **Roadmap relationship**: R2 completion / customer-facing review consumption and sellability polish.
-- **Existing implementation context**: Spec 249 (`customer-review-workspace`) delivered the first read-only workspace handoff. This candidate is the bounded follow-up that hardens the existing surface into a clearer customer-safe product contract instead of reopening review foundations from scratch.
-- **Goal**: Turn the existing customer review surface into a customer-safe, read-only review consumption experience for customer reviewers, customer admins, and auditors that answers what was reviewed, what is critical, what was accepted, what evidence exists, and what the next sensible step is.
-- **Dependencies**:
-  - `TenantReview`
-  - `ReviewPack`
-  - `EvidenceSnapshot`
-  - `Finding`
-  - accepted risks / exceptions workflow
-  - existing redaction behavior
-  - stored reports and canonical control catalog foundations
-  - workspace entitlements
-  - tenant/workspace RBAC, audit, localization, and workspace-isolation foundations
-- **Scope**:
-  - productize the existing customer review workspace into a clearer customer-safe read-only review consumption surface
-  - keep the primary surface centered on customer review workspace, review detail, findings summary, accepted-risk summary, evidence summary, and review-pack download areas
-  - visible findings semantics with severity, status, reason, impact, and recommendation in customer-safe language
-  - accepted risks / exceptions shown as understandable governance decisions rather than internal workflow residue, including decision reason, accountable person or role, decision timing, expiry / re-review state, evidence linkage, and review context in customer-safe language
-  - evidence snapshots shown as narrative summaries and proof pointers, not raw JSON or provider payloads
-  - review-pack download area with existing redaction and entitlement rules
-  - clearer control / baseline context and next-step guidance for customer reviewers, customer admins, and auditors
-  - explicit audit events for workspace access, review detail access, evidence summary access, and pack downloads
-  - explicit empty, permission, expired, and unavailable states
-  - DE/EN-ready labels for customer-facing review text
-  - progressive disclosure for technical detail instead of operator-default density
-- **Non-scope**:
-  - a new customer portal, separate identity plane, or broader customer product shell
-  - policy remediation, restore, or admin actions for customers
-  - a new review engine, evidence engine, or report-generation engine
-  - AI-generated summaries
-  - public-link sharing without authentication or RBAC
-  - raw operator diagnostics, provider-debug data, or raw evidence payloads as default-visible content
-- **Decision workflow**:
-  - customer reviewers can read released reviews, evidence summaries, and review packs
-  - customer acknowledgement can return later as a narrower v1.1 or v2 follow-up
-  - no technical remediation or admin mutation lives in this workspace
-- **Capability review**:
-  - validate or introduce customer-facing capability boundaries such as `reviews.customer.view`, `reviews.customer.download_pack`, `evidence.customer.view`, `findings.customer.view`, and `risks.customer.view`
-  - existing operator capabilities must not automatically imply customer access
-- **Export posture**:
-  - review packs remain the primary export and proof artifact
-  - evidence stays narrative and customer-safe by default rather than raw-payload first
-  - downloads must remain auditable
-- **Acceptance criteria**:
-  - the customer-facing review workspace does not expose internal run, debug, provider, or raw JSON details by default
-  - findings are shown with severity, status, reason, impact, and recommendation in customer-safe wording
-  - accepted risks / exceptions are visible and understandable for non-operator consumers, including accountable role or person, decision timing, expiry or review status, and evidence linkage where product truth exists
-  - evidence is summarized without exposing raw payloads by default
-  - review packs are downloadable when entitlement and capability checks pass
-  - each relevant view and download action produces audit evidence
-  - tenant and workspace isolation are enforced and tested
-  - permission gaps and expired or unavailable access states are explicit and calm
-  - customer-facing labels are localization-ready
-  - global search does not leak customer review or evidence artifacts into unintended discovery paths
-- **Notes**: This is still the clearest repo-derived P0 blocker between today's operator-strong review foundations and a cleaner customer-safe sellable release. Do not split a second broad liability / accountability foundation candidate out of this unless a narrower internal expiry-cockpit or portfolio-risk gap proves separate product value.
 
-### P1 — Enterprise Maturity
+- `Customer Review Workspace Productization v1` -> Spec 258
+- `Governance Decision Surface Convergence` -> Spec 257
+- `Cross-Tenant Compare and Promotion v1` -> refreshed Spec 043
+- `Remove Findings Lifecycle Backfill Runtime Surfaces` -> Spec 253
+- `Remove Legacy Acknowledged Finding Status Compatibility` -> Spec 254
+- `Enforce Creation-Time Finding Invariants` -> Spec 255
+- `Commercial Entitlements and Billing-State Maturity` -> Spec 251
+- `Compliance Evidence Mapping v1` -> Spec 259
+- `Governance-as-a-Service Packaging v1` -> Spec 260
+- `External Support Desk / PSA Handoff` -> Spec 256
 
-### Governance Decision Surface Convergence
+These packages already provide the needed preparation surface, and several now carry completed task checklists or implementation close-out history. They must not be auto-selected again by `next-best-prep`.
-- **Priority**: P1
-- **Why this stays active**: The repo already has Governance Inbox, My Findings, Intake, Exception Queue, alerts, and review-linked action entry points. The open gap is no longer the first governance inbox; it is convergence across these repo-real surfaces so operators stop hopping between adjacent work queues.
-- **Roadmap relationship**: Findings workflow maturity; later MSP Portfolio OS prerequisite.
-- **Existing implementation context**:
-  - Spec 250 (`decision-governance-inbox`) delivered the first decision-oriented governance inbox surface.
-  - Specs 221, 222, 224, 225, 230, and 231 already cover major inbox, intake, notification, and workflow-adoption slices.
-  - `CustomerReviewWorkspace` and `FindingExceptionsQueue` now act as adjacent decision surfaces that should converge around one calmer operator journey instead of multiplying parallel entry points.
-- **Dependencies**:
-  - findings workflow semantics and inbox foundations from Specs 219, 221, 222, 224, 225, 230, 231
-  - alert routing foundation
-  - `OperationRun` truth
-  - portfolio triage continuity
-  - customer review and exception governance surfaces where decision work overlaps
-  - contextual help and reason-code surfaces where helpful
-- **Scope**:
-  - one decision-centered operator entry model across more than one existing queue or signal family
-  - reduce surface-hopping between My Findings, Intake, Governance Inbox, Exception Queue, and adjacent high-signal attention states
-  - preserve direct action links into compare, finding review, review-pack generation, exception handling, or triage paths instead of duplicating domain state
-  - add convergence rules, prioritization, and clearer routing before inventing more list surfaces
-  - auditable state changes such as snooze, assign, or acknowledge only where those state mutations already exist as product truth
-- **Non-scope**:
-  - rebuilding the first governance inbox from scratch
-  - autonomous remediation
-  - AI-generated recommendations
-  - customer-facing inboxes
-  - full cross-tenant workboard redesign
-- **Acceptance criteria**:
-  - operators can start from one decision-centered surface or convergence model that spans more than one existing signal family or queue
-  - existing surfaces keep one consistent routing model instead of growing more parallel queue concepts
-  - actions route to existing product truth rather than creating duplicate state or duplicate work ownership
-  - visibility is capability-aware and workspace-safe
-  - auditable state changes are recorded where the inbox mutates work state
-  - tests prove signal grouping, routing, and authorization boundaries
-- **Notes**: This is a follow-up to the existing Governance Inbox, not a greenfield inbox foundation.
 
-### Cross-Tenant Compare and Promotion v1
+`Workspace, Tenant & Managed Object Lifecycle Governance v1` remains deferred below and still requires an explicit product decision before it becomes a safe prep target.
-- **Priority**: P1
-- **Why this stays active**: Portfolio triage exists, but portfolio action does not. The repo already contains an older draft spec for this direction, yet the capability is not repo-proven as a finished product workflow.
-- **Roadmap relationship**: MSP Portfolio & Operations.
-- **Existing spec**: Spec 043 exists and should be refreshed against current repo truth rather than replaced by a new broad direction.
-- **Dependencies**:
-  - inventory foundations
-  - baseline compare truth
-  - restore and execution guardrails
-  - audit log foundation
-  - tenant and workspace isolation plus RBAC
-- **Scope**:
-  - choose source and target tenants within allowed scope
-  - show a structured compare preview
-  - support a dry-run or promotion preflight before any write path
-  - preserve auditability and scope boundaries
-- **Non-scope**:
-  - blind one-click promotion
-  - autonomous rollout
-  - multi-cloud or multi-provider compare
-  - full MSP control-plane redesign
-- **Acceptance criteria**:
-  - operator can produce a compare preview between two allowed tenants
-  - promotion path includes explicit preflight or dry-run semantics
-  - authorization and tenant isolation are enforced and tested
-  - audit trail exists for compare and promotion entry points
-  - the slice refreshes or narrows Spec 043 instead of reopening it as a vague ambition
-
-### Remove Findings Lifecycle Backfill Runtime Surfaces
-- **Priority**: P1
-- **Why this stays active**: Repo audit shows visible runtime surfaces for a pre-production findings lifecycle repair path even though active finding generators already write the relevant lifecycle fields directly. The remaining path is not just ballast; it appears partially detached from current operational-control truth and keeps internal repair tooling productized.
-- **Roadmap relationship**: Findings workflow cleanup / legacy removal.
-- **Dependencies**:
-  - current finding generators that already set lifecycle fields directly
-  - system runbook registry and execution surfaces
-  - tenant findings actions
-  - operation catalog, capability, and seeder bindings
-  - backfill jobs, runbook service, and deploy hooks
-- **Scope**:
-  - remove the system runbook `Rebuild Findings Lifecycle`
-  - remove the tenant action `Backfill findings lifecycle`
-  - remove the command `tenantpilot:findings:backfill-lifecycle`
-  - remove findings lifecycle backfill jobs, runbook services, and deploy/runtime hooks
-  - remove operation-catalog, capability, seeder, and test traces that exist only for this backfill path
-- **Non-scope**:
-  - removing the legacy `acknowledged` status or related compatibility helpers
-  - changing normal finding workflow actions such as triage, assignment, progress, resolve, or risk acceptance
-  - changing ownership, assignee, SLA, due-date, or risk-governance semantics
-  - changing historical migrations or adding replacement backfills
-- **Acceptance criteria**:
-  - no `/admin` surface exposes `Backfill findings lifecycle`
-  - no system runbook exposes `Rebuild Findings Lifecycle`
-  - `tenantpilot:findings:backfill-lifecycle` is no longer a supported command
-  - deploy or operational hooks do not start a findings lifecycle backfill
-  - `findings.lifecycle.backfill` is no longer used as an operational-control key, operation type, or capability
-  - tests no longer expect backfill preflight, start, or completion behavior
-  - normal finding workflows keep working unchanged for triage, assignment, start progress, resolve, and risk acceptance
-- **Notes**: This is the first and most important cleanup candidate because it removes visible product ballast without changing the canonical findings workflow semantics.
-
-### Remove Legacy Acknowledged Finding Status Compatibility
-- **Priority**: P1
-- **Why this stays active**: Repo audit indicates that `acknowledged` compatibility still survives in status helpers, filters, badges, capabilities, and tests even though the current operator workflow is centered on `triaged`. Keeping both semantics alive weakens workflow clarity and RBAC consistency.
-- **Roadmap relationship**: Findings workflow semantics / RBAC cleanup.
-- **Dependencies**:
-  - finding status constants and model helpers
-  - badge and filter catalogs
-  - role capability mappings and capability aliases
-  - workflow and bulk-action tests that still speak in acknowledge semantics
-- **Scope**:
-  - remove `Finding::STATUS_ACKNOWLEDGED`
-  - remove or simplify compatibility helpers that only map `acknowledged` to `triaged`
-  - remove `openStatusesForQuery()` compatibility for `acknowledged`
-  - remove legacy capability aliases such as `tenant_findings.acknowledge`
-  - rename, adapt, or remove tests that only protect the old acknowledge vocabulary
-  - ensure active workflow actions consistently use `triage` / `triaged`
-- **Non-scope**:
-  - removing findings lifecycle backfill runtime surfaces in the same slice
-  - changing SLA, ownership, assignee, or risk-acceptance behavior
-  - introducing new workflow states or new customer-facing workflow surfaces
-  - changing finding generators unless they still emit `acknowledged`
-- **Acceptance criteria**:
-  - no productive code path writes `acknowledged`
-  - no productive code path expects `acknowledged` as a valid workflow status
-  - `tenant_findings.acknowledge` no longer exists as a capability or alias
-  - workflow actions, filters, badges, and tests consistently use `triage` / `triaged`
-  - existing finding flows remain functional from `new` to `triaged`, `in_progress`, `resolved`, and risk-accepted outcomes
-- **Notes**: Keep this separate from backfill removal because it reaches deeper into workflow semantics, queries, badges, and RBAC mappings.
-
-### Enforce Creation-Time Finding Invariants
-- **Priority**: P1
-- **Why this stays active**: Removing lifecycle backfills only stays safe if new findings are always created in a lifecycle-ready state. The repo already hints at good direct-write behavior, but those invariants still need explicit protection so future generators do not recreate the need for repair jobs.
-- **Roadmap relationship**: Findings data integrity / workflow hardening.
-- **Dependencies**:
-  - drift and baseline compare finding generation
-  - permission posture finding generation
-  - Entra admin roles finding generation
-  - rediscovery, reopen, and deduplication behavior around recurrence keys and lifecycle timestamps
-- **Scope**:
-  - review active finding generators and verify lifecycle-ready creation
-  - add or tighten invariant tests around canonical status, first/last seen timestamps, `times_seen`, `sla_days`, and `due_at` where applicable
-  - verify reopen and rediscovery behavior
-  - verify drift idempotency and recurrence-key semantics
-  - consider a tightly bounded DB constraint only if the repo proves a safe, narrow case
-- **Non-scope**:
-  - reintroducing any backfill or repair runtime surface
-  - historical data migration work
-  - forcing owner or assignee fields to become mandatory
-  - introducing new finding types or broader customer review workflow changes
-- **Acceptance criteria**:
-  - repo-verified finding generators have tests that prove lifecycle-ready creation
-  - no new finding generation path relies on a later backfill or repair run
-  - repeated drift detection does not create uncontrolled canonical duplicates
-  - reopen or rediscovery behavior updates lifecycle fields correctly
-  - accountability remains a governance state rather than a forced owner/assignee requirement
-- **Notes**: This should follow the visible cleanup work and protects the target state so findings do not regress back into repair-job dependency.
-
-### P2 — Commercial / Scale
-
-### Commercial Entitlements and Billing-State Maturity
-- **Priority**: P2
-- **Why this stays active**: The repo already has a real entitlement foundation and an existing spec for plans and billing readiness. The remaining gap is narrower: commercial lifecycle maturity, not inventing entitlements from scratch.
-- **Roadmap relationship**: Product Scalability & Self-Service Foundation.
-- **Existing spec context**: Spec 247 exists for `Plans, Entitlements & Billing Readiness`. This candidate is the follow-up gap after the current entitlement substrate, not a duplicate foundation spec.
-- **Dependencies**:
-  - existing `WorkspaceEntitlementResolver`
-  - workspace settings surfaces
-  - review-pack entitlement gates
-  - audit foundation
-  - customer-facing read-only and suspension semantics where applicable
-- **Scope**:
-  - commercial lifecycle states such as trial, grace, suspended/read-only, and active paid usage
-  - clearer enforcement at key product gates
-  - explicit disabled and read-only messaging distinct from authorization failures
-  - audited state changes and overrides
-- **Non-scope**:
-  - payment provider integration
-  - invoicing
-  - tax or accounting workflows
-  - public pricing pages
-- **Acceptance criteria**:
-  - central commercial state can be resolved for a workspace
-  - at least two real behaviors are gated by lifecycle state, not scattered conditionals
-  - read-only or suspended behavior preserves safe access to needed history or evidence while blocking disallowed actions
-  - changes and overrides are audited
-  - tests cover blocked and allowed paths
-
-### Compliance Evidence Mapping v1
-- **Priority**: P2
-- **Why this stays active**: Canonical control catalog, evidence snapshots, stored reports, review packs, findings, and accepted-risk foundations are already repo-real. The missing gap is a versioned mapping layer from technical governance truth to customer-safe control or readiness views, not another control foundation rewrite.
-- **Roadmap relationship**: Compliance moat / executive review follow-through.
-- **Dependencies**:
-  - canonical control catalog foundation
-  - evidence snapshots and stored reports
-  - findings and accepted-risk workflow
-  - tenant reviews and review-pack export
-  - customer review productization and export maturity
-- **Scope**:
-  - one versioned control interpretation layer and one bounded overlay for a first customer-safe readiness/control view
-  - map findings, evidence, and accepted risks to customer-safe control views without certification claims
-  - show control, evidence, and recommendation linkage in one primary review or export surface before broad multi-surface rollout
-  - keep framework overlays downstream from the shared canonical control model
-- **Non-scope**:
-  - certification claims or legal guarantees
-  - hard-coded BSI, NIS2, CIS, or ISO semantics deep in the platform core
-  - separate technical control object models per framework
-  - full GRC suite or lawyer-facing workflow
-- **Acceptance criteria**:
-  - one bounded overlay maps existing technical truth to a control or readiness view
-  - one concrete review or export surface can show control status, evidence linkage, and recommended action from shared foundations
-  - mapping versions are explicit and auditable
-  - the product clearly separates technical findings from regulatory interpretation
-  - no framework-specific one-off output bypasses the common evidence, findings, exception, and export pipeline
-- **Smallest useful v1**: start with one overlay family and one customer-safe output path. Do not start by modeling multiple frameworks, multiple customer profiles, and multiple output surfaces at once.
-
-### Governance-as-a-Service Packaging v1
-- **Priority**: P2
-- **Why this stays active**: Review packs, evidence snapshots, stored reports, customer review foundations, and accepted-risk workflow are repo-real. The missing gap is repeatable MSP/customer-safe packaging, not raw reporting substrate.
-- **Roadmap relationship**: MSP sellability / recurring governance service.
-- **Dependencies**:
-  - customer review workspace productization
-  - compliance evidence mapping
-  - review packs, evidence snapshots, and stored reports
-  - findings and accepted-risk workflow
-  - localization, entitlements, and export maturity
-- **Scope**:
-  - one on-demand management-ready governance package built from the existing review-pack and evidence pipeline
-  - executive summary with customer-safe language
-  - top findings, accepted risks, open decisions, and evidence links
-  - bounded MSP branding and packaging rules
-  - no scheduling, batching, or report-program engine in the first slice
-- **Non-scope**:
-  - CRM, newsletter, or marketing automation
-  - PSA replacement or service-desk workflow
-  - raw operator-data dumps as the default deliverable
-  - a separate reporting engine that bypasses existing review/evidence/export truth
-- **Acceptance criteria**:
-  - an MSP can generate one repeatable on-demand governance package from existing review, evidence, and accepted-risk artifacts
-  - the output is customer-safe and management-readable by default
-  - top findings, accepted risks, open decisions, and evidence links are clearly represented
-  - packaging reuses shared review/evidence/export foundations instead of creating a parallel report domain
-  - bounded branding or presentation options do not weaken auditability or customer-safe defaults
-- **Smallest useful v1**: one management-ready package for one review context, generated on demand from existing artifacts. Leave recurring schedules, multi-pack campaigns, and broader customer-communications automation out of scope.
-
-### External Support Desk / PSA Handoff
-- **Priority**: P2
-- **Why this stays active**: In-app support requests are already repo-real. The remaining gap is external handoff and visible ticket linkage, not support-request creation itself.
-- **Roadmap relationship**: R2 support follow-through; later commercial scale.
-- **Dependencies**:
-  - support request context flow from Spec 246
-  - support diagnostic pack
-  - audit logging
-  - tenant and workspace authorization boundaries
-- **Scope**:
-  - outbound adapter seam for one support desk or PSA target
-  - store and display external ticket reference
-  - auditable create or link actions
-  - visible product linkage back from support requests to external references
-- **Non-scope**:
-  - full bidirectional sync
-  - SLA engine
-  - generic helpdesk product
-  - AI support automation
-- **Acceptance criteria**:
-  - a support request can create or link an external ticket through one bounded adapter
-  - resulting ticket reference is stored and visible in the right context
-  - failures are explicit and auditable
-  - tenant and workspace scope are enforced and tested
-  - the slice extends the existing support-request model instead of replacing it
-
-### P3 — Later Platform Ambitions
-
-- No active P3 candidate from the current focus set.
-- `Private AI Execution & Policy Foundation` is already promoted as Spec 248 and should no longer remain in the open candidate queue.
-- Broader AI-assisted customer operations can return later as a follow-up only after Spec 248 and the current customer-facing release gaps are materially closed.
 
 ## Deferred / Existing Drafts Outside the Current Queue
 
@@ -377,7 +61,8 @@ ### Workspace, Tenant & Managed Object Lifecycle Governance v1
 
 - **Priority**: P2 — Important hardening / enterprise trust
 - **Status**: Strategic candidate, not ready for immediate implementation
-- **Do not prep before**: Customer Review Workspace, Cross-Tenant Compare & Promotion, Governance Decision Convergence, and current sellability/productization follow-through are materially closed.
+- **Do not auto-prep from `next-best-prep`**: this candidate stays intentionally outside the active queue even after the 2026-05-01 repo re-audit. Promote it only through an explicit roadmap/product decision.
+- **Why it stays deferred after the queue cleanup**: the repo now has spec-backed follow-through for customer review productization, governance convergence, compare/preflight, commercial lifecycle maturity, compliance mapping, governance packaging, support-desk handoff, and the findings cleanup trio. The remaining lifecycle-governance question is still broader than the current automatic queue and must stay taxonomy-first rather than opportunistically selected.
 - **Why this replaces `Policy Lifecycle / Ghost Policies`**: A policy-only ghost lifecycle spec risks introducing local deletion semantics, Laravel `SoftDeletes`, or overloaded `ignored_at` behavior before TenantPilot has a clear platform lifecycle taxonomy. The real roadmap-fit problem is broader: TenantPilot needs consistent lifecycle truth for workspaces, tenants, managed provider objects, evidence, backups, restoreability, export, retention, and purge.
 - **Problem**: Lifecycle concerns currently appear across separate product areas such as policies, restore flows, commercial state, workspace entitlements, backup history, evidence snapshots, audit, support, and workspace administration. Without one shared taxonomy, local fixes can collapse different meanings into the same field or UI label: provider object missing, local TenantPilot record deleted, operator ignored the item, workspace suspended, data retained for compliance, data eligible for purge, or restore no longer possible.
 - **Product goal**: Define an enterprise-grade lifecycle model before implementing destructive or retention-sensitive workflows. TenantPilot must distinguish at least these dimensions:
@@ -431,6 +116,7 @@ ## Promoted to Spec
 
 Historical ledger for candidates that are no longer open. Keep them here so prioritization stays clean without losing decision history.
 
+- Cross-Tenant Compare and Promotion v1 -> Spec 043 (`cross-tenant-compare-and-promotion`)
 - Canonical Operation Type Source of Truth -> Spec 239 (`canonical-operation-type-source-of-truth`)
 - Self-Service Tenant Onboarding & Connection Readiness -> Spec 240 (`tenant-onboarding-readiness`)
 - Support Diagnostic Pack -> Spec 241 (`support-diagnostic-pack`)
@@ -443,6 +129,15 @@ ## Promoted to Spec
 - Private AI Execution & Policy Foundation -> Spec 248 (`private-ai-policy-foundation`)
 - Customer Review Workspace v1 -> Spec 249 (`customer-review-workspace`)
 - Decision-Based Governance Inbox v1 -> Spec 250 (`decision-governance-inbox`)
+- Commercial Entitlements and Billing-State Maturity -> Spec 251 (`commercial-entitlements-billing-state`)
+- Remove Findings Lifecycle Backfill Runtime Surfaces -> Spec 253 (`remove-findings-backfill-runtime-surfaces`)
+- Remove Legacy Acknowledged Finding Status Compatibility -> Spec 254 (`remove-acknowledged-compat`)
+- Enforce Creation-Time Finding Invariants -> Spec 255 (`enforce-finding-creation-invariants`)
+- External Support Desk / PSA Handoff -> Spec 256 (`external-support-desk-handoff`)
+- Governance Decision Surface Convergence -> Spec 257 (`governance-decision-convergence`)
+- Customer Review Workspace Productization v1 -> Spec 258 (`customer-review-productization`)
+- Compliance Evidence Mapping v1 -> Spec 259 (`compliance-evidence-mapping`)
+- Governance-as-a-Service Packaging v1 -> Spec 260 (`governance-service-packaging`)
 - Provider-Missing Policy Visibility & Restore Continuity v1 -> Spec 261 (`provider-missing-policy-visibility`)
 - Queued Execution Reauthorization and Scope Continuity -> Spec 149 (`queued-execution-reauthorization`)
 - Livewire Context Locking and Trusted-State Reduction -> Spec 152 (`livewire-context-locking`)
@@ -475,6 +170,8 @@ ## Superseded / Removed From Active Queue
 
 These items were previously open candidates or roadmap-fit ideas, but should no longer stay in the active queue.
 
+- The former 2026-04-30 active P0-P2 queue was cleared on 2026-05-01 because refreshed Spec 043 and Specs 251-260 now cover those slices, and several of those packages already include implementation close-out or completed-task history.
+
 - `R2.0 Canonical Control Catalog Foundation`: remove from active candidates because the ledger shows a repo-real catalog, config, bindings, review integration, and test coverage. This is no longer an open candidate; it is an implemented foundation.
 - `Self-Service Tenant Onboarding & Connection Readiness`: remove from active candidates because it is already Spec 240 and the repo already shows meaningful adoption.
 - `Support Diagnostic Pack`: remove from active candidates because it is already Spec 241 and repo-adopted.