## Feature Specification: Post-Cutover Suite Stabilization & Baseline Reconciliation

**Feature Branch**: `293-post-cutover-suite-stabilization`  
**Created**: 2026-05-10  
**Status**: Ready  
**Input**: User description: "Prepare the already proposed stabilization package as a new safe slot `293-post-cutover-suite-stabilization` without touching Spec `289` or Spec `292`. The package stabilizes the suite after Spec `287` and Spec `288`, clears cutover-driven baseline debt, keeps Package Execution separate, and stays preparation-only in this step."

## Spec Candidate Check *(mandatory - SPEC-GATE-001)*

- **Problem**: Spec `287` completed the runtime prerequisites and Spec `288` locked the no-legacy enforcement baseline, but the broader suite still contains cutover-era assumptions that expect the retired TenantPanel, `/admin/t/...` runtime truth, tenant-scoped provider and required-permissions routes, workspace-unaware operations links, and pre-cutover action-surface semantics.
- **Today's failure**: targeted proof packs are green, yet broader lanes still surface red groups such as `PanelNavigationSegregationTest`, `ActionSurfaceContractTest`, multiple `tests/Feature/OpsUx/*` assumptions, and adjacent RBAC/action-surface expectations that no longer match the workspace-first, admin-panel-only runtime.
- **User-visible improvement**: maintainers get one bounded stabilization package that makes the suite reflect current runtime truth, keeps legacy behavior retired, and documents remaining unrelated baseline debt instead of letting it drift into future features.
- **Smallest enterprise-capable version**: one stabilization spec that classifies failures first, rebases retired TenantPanel and `/admin/t/...` assumptions, makes in-scope operations route generation workspace-aware, retires tenant-scoped required-permissions and provider-connection baseline expectations, performs a bounded action-surface cutover rebaseline, keeps the Spec `288` proof pack and browser anchors green, and records remaining unrelated or flaky failures in one explicit artifact.
- **Explicit non-goals**: no Package Execution work, no Guided Operations work, no Microsoft Starter Pack work, no Virtual Consultant work, no new product features, no new UI surfaces, no UI polish, no broad refactors, no reactivation of TenantPanel, no reactivation of `/admin/t/...`, no reactivation of retired provider-connection fallback routes, and no migration work unless a true workspace-first runtime regression proves a minimal blocker fix is required during later implementation.
- **Permanent complexity imported**: one spec-local failure-classification artifact, one bounded failure-category inventory, targeted suite/lane proof commands, and narrowly-scoped tasking for existing test and helper seams. No new runtime persistence, no new provider abstraction, no new RBAC model, and no new product surface are introduced.
- **Why now**: after `287` and `288`, leaving suite debt unclassified would force every subsequent cutover-adjacent feature to rediscover the same stale assumptions and blur the boundary between enforcement and repair.
- **Why not local**: the remaining debt is not isolated to one file or one product area. It spans panel navigation, operations route generation, provider and required-permissions links, workspace-first RBAC assumptions, and action-surface expectations, so a one-off local patch would leave the repo-wide cutover baseline inconsistent.
- **Approval class**: Cleanup
- **Red flags triggered**: cross-cutting suite stabilization, possible spillover into runtime fixes, and broad-lane reruns. Defense: the slice is bounded to cutover-driven debt, starts with classification, forbids legacy reactivation, and keeps Package Execution and broader product work out of scope.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | **Gesamt: 10/12**
- **Decision**: approve

## Review Outcome

- **Outcome class**: `acceptable-special-case`
- **Workflow outcome**: `keep`
- **Test-governance outcome**: `keep`
- **Reason**: the package is cross-cutting but remains implementation-ready because it stabilizes only cutover-driven suite debt, uses explicit failure classification, and forbids feature expansion or legacy reactivation.
- **Workflow result**: Ready for implementation as the shared stabilization package that follows Specs `287` and `288` without replacing later Package Execution work.

## Spec Scope Fields *(mandatory)*

- **Scope**: repository
- **Primary Routes**:
  - canonical workspace/environment admin routes such as `/admin/workspaces/{workspace}/environments/{managed_environment}/...`
  - canonical provider-connection routes such as `/admin/provider-connections...`
  - workspace-scoped operations routes generated through `admin.operations.index` and `admin.operations.view`
  - retired paths that must remain retired, including `/admin/t/{tenant}/...`, tenant-scoped required-permissions URLs, and tenant-scoped provider-connection fallback URLs
- **Data Ownership**:
  - no new application persistence is introduced
  - `workspace_memberships` remain the role-bearing authority source
  - `managed_environment_memberships` remain narrowing-only access scope
  - `failure-classification.md` is a spec-local artifact used to record baseline findings during later implementation; it is not a runtime source of truth
- **RBAC**:
  - reuse the workspace-first contract from Spec `285`
  - non-members or wrong-scope actors remain `404`
  - in-scope actors missing capability remain `403`
  - managed-environment membership rows must not regain independent role authority

## 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
- **Interaction class(es)**: suite baseline classification, canonical route/link generation, current browser smoke anchors, action-surface expectations, and workspace-first authorization expectations
- **Systems touched**:
  - `apps/platform/tests/Feature/Filament/PanelNavigationSegregationTest.php`
  - `apps/platform/tests/Feature/Guards/ActionSurfaceContractTest.php`
  - `apps/platform/tests/Feature/OpsUx/*`
  - `apps/platform/tests/Feature/ProviderConnections/*`
  - `apps/platform/tests/Feature/Verification/*`
  - `apps/platform/tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php`
  - `apps/platform/tests/Feature/Rbac/ProviderConnectionWorkspaceFirstPolicyTest.php`
  - `apps/platform/tests/Feature/Filament/ManagedEnvironmentAccessScopeManagementTest.php`
  - `apps/platform/tests/Browser/Spec281ProviderConnectionScopeSmokeTest.php`
  - `apps/platform/tests/Browser/Spec285WorkspaceRbacEnvironmentAccessSmokeTest.php`
  - `apps/platform/app/Support/OperationRunLinks.php`
  - `apps/platform/app/Support/OperateHub/OperateHubShell.php`
  - `apps/platform/app/Filament/Concerns/WorkspaceScopedTenantRoutes.php`
  - `apps/platform/app/Providers/Filament/AdminPanelProvider.php`
  - `apps/platform/app/Filament/Pages/TenantDashboard.php`
  - `apps/platform/app/Filament/Pages/TenantRequiredPermissions.php`
  - `apps/platform/app/Filament/Resources/TenantResource.php`
  - `apps/platform/tests/Pest.php`
- **Existing pattern(s) to extend**: existing workspace-first route helpers, existing OpsUx route/link helpers, existing browser smoke anchors, current action-surface contract tests, and the current workspace-first RBAC proof surfaces
- **Shared contract / presenter / builder / renderer to reuse**: `OperationRunLinks`, `OperateHubShell`, `WorkspaceScopedTenantRoutes`, existing provider/required-permissions helpers, current browser smoke anchors, and the existing feature-test authorization seams
- **Why the existing shared path is sufficient or insufficient**: the repo already contains the correct canonical helpers and proof surfaces; the missing piece is removing stale pre-cutover assumptions from tests and, only when proven, applying minimal fixes to the existing canonical helper path instead of reintroducing compatibility behavior.
- **Allowed deviation and why**: only minimal runtime fixes are allowed later if a current workspace-first primary path is demonstrably broken. Reintroducing legacy routes, panel bootstrapping, or fallback aliases is forbidden.
- **Consistency impact**: the same current runtime truth must appear across panel navigation, operations links, required-permissions links, provider-connection links, action-surface tests, browser anchors, and the failure-classification artifact.
- **Review focus**: reviewers must verify that `293` stabilizes the suite around current truth, does not create new product behavior, and keeps Package Execution and Guided Operations separate.

## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*

- **Touches OperationRun start/completion/link UX?**: yes, but only around canonical operations route generation and current workspace-aware `View run` or `Show all operations` links
- **Shared OperationRun UX contract/layer reused**: `OperationRunLinks` and current OpsUx shell/link resolution helpers
- **Delegated start/completion UX behaviors**: preserve current `View run` and operations index URL resolution through the existing shared helpers; no new queued toast, event, dedupe, or notification semantics are introduced
- **Local surface-owned behavior that remains**: none beyond the current page-specific assertions already owned by the tested surfaces
- **Queued DB-notification policy**: `N/A` - unchanged
- **Terminal notification path**: existing central lifecycle mechanism, unchanged
- **Exception required?**: none

## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*

- **Shared provider/platform boundary touched?**: yes
- **Boundary classification**: mixed
- **Seams affected**: provider-connection route expectations, required-permissions route expectations, workspace-aware operations links, and managed-environment access-scope assumptions
- **Neutral platform terms preserved or introduced**: `workspace`, `managed environment`, `provider connection`, `operation run`, `required permissions`
- **Provider-specific semantics retained and why**: provider-owned nested detail remains allowed only where the provider itself is the subject; `293` does not widen provider-specific semantics into platform-core truth
- **Why this does not deepen provider coupling accidentally**: the package removes stale tenant-first and compatibility assumptions and keeps canonical workspace-first helpers as the only accepted runtime truth
- **Follow-up path**: Package Execution remains a separate future package; `293` only stabilizes suite debt first

## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*

N/A - no new operator-facing surface is intentionally introduced. Later implementation may touch existing surfaces only to align tests or correct a proven primary-path regression without adding new UX.

## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*

N/A - existing surfaces remain the source of truth; `293` does not define a new decision surface.

## Audience-Aware Disclosure *(mandatory when operator-facing surfaces are changed)*

N/A - no new default-visible operator or customer disclosure layer is introduced.

## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*

N/A - the package stabilizes existing surfaces only.

## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*

N/A - no new operator-facing contract is introduced.

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: no runtime source of truth
- **New persisted entity/table/artifact?**: no application persistence; one spec-local `failure-classification.md` artifact is added for implementation tracking only
- **New abstraction?**: no
- **New enum/state/reason family?**: yes, one bounded failure-classification category set used only inside this spec package
- **New cross-domain UI framework/taxonomy?**: no
- **Current operator problem**: maintainers need one bounded way to distinguish cutover-driven suite debt from unrelated failures so the repo stops rediscovering stale assumptions after Specs `287` and `288`.
- **Existing structure is insufficient because**: ad hoc repair notes or one-off fixes would hide scope drift and make it unclear which failures belong to the cutover stabilization thread.
- **Narrowest correct implementation**: define one spec-local failure-classification artifact and one pinned category set, then point later implementation tasks at existing tests and helpers only.
- **Ownership cost**: low; maintain one spec-local table and keep the same category names aligned across the prep artifacts.
- **Alternative intentionally rejected**: a full-suite fix-all program or a new repo-wide stabilization framework. Both would widen scope far beyond the current cutover debt.
- **Release truth**: current-release test governance and suite stabilization only

### Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, compatibility routes, and compatibility-specific tests are out of scope unless a proven current primary-path regression later requires a minimal targeted fix.

Canonical replacement remains preferred over preservation.

## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*

- **Test purpose / classification**: Feature, Browser, Heavy-Governance
- **Validation lane(s)**: confidence, heavy-governance, browser, and an initial or final full-suite baseline run when output remains usable
- **Why this classification and these lanes are sufficient**: the package stabilizes cross-cutting suite debt, so it needs classification-first proof, targeted feature/browser reruns on the touched seams, the Spec `288` proof pack, and at least one broader confidence check to prove no cutover-related failures remain unclassified.
- **New or expanded test families**: none new by design; reuse existing panel, action-surface, OpsUx, provider-connection, verification, RBAC, and browser files
- **Fixture / helper cost impact**: moderate only because existing broad suites and browser anchors are re-run; the package must not introduce new expensive helper defaults
- **Heavy-family visibility / justification**: explicit. `293` intentionally uses the existing heavy-governance and confidence lanes as validation surfaces, but it must not turn that into a permanent fix-all obligation.
- **Special surface test profile**: `standard-native-filament`, `global-context-shell`, `browser-smoke`
- **Standard-native relief or required special coverage**: targeted feature tests plus the two named browser anchors are required; any broader rerun remains for classification and confidence only
- **Reviewer handoff**: reviewers must confirm that the implementation fixes only cutover-driven baseline debt, documents remaining unrelated or flaky failures, keeps the Spec `288` proof pack green, and does not restore legacy runtime behavior
- **Budget / baseline / trend impact**: classification-only documentation of remaining unrelated debt; no new permanent lane or guard subsystem
- **Escalation needed**: `document-in-feature`
- **Active feature PR close-out entry**: `SuiteStabilization`
- **Planned validation commands**:
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git status --short --branch`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && git diff --stat`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail artisan test --compact)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && ./scripts/platform-test-lane heavy-governance`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && ./scripts/platform-test-lane confidence`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/PanelNavigationSegregationTest.php tests/Feature/ManagedEnvironment/LegacyTenantCoreGuardTest.php)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/CanonicalViewRunLinksTest.php tests/Feature/OpsUx/OperateHubShellTest.php tests/Feature/OpsUx/FailureSanitizationTest.php tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/ProviderConnections tests/Feature/Verification)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php tests/Feature/Rbac/ProviderConnectionWorkspaceFirstPolicyTest.php tests/Feature/Filament/ManagedEnvironmentAccessScopeManagementTest.php tests/Feature/Rbac/BackupItemsRelationManagerUiEnforcementTest.php)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && REPO_ROOT="$(git rev-parse --show-toplevel)" && (cd "$REPO_ROOT/apps/platform" && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/Spec288NoLegacyRouteAndHelperGuardTest.php tests/Feature/Guards/Spec288ProviderCoreAndRoleAuthorityGuardTest.php tests/Feature/Guards/AdminWorkspaceRoutesGuardTest.php tests/Feature/Guards/ProviderBoundaryPlatformCoreGuardTest.php tests/Feature/ProviderConnections/LegacyRedirectTest.php tests/Feature/ManagedEnvironment/LegacyTenantCoreGuardTest.php tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php tests/Feature/Rbac/ProviderConnectionWorkspaceFirstPolicyTest.php tests/Feature/Filament/ManagedEnvironmentAccessScopeManagementTest.php tests/Feature/Guards/BrowserLaneIsolationTest.php tests/Feature/Guards/CiLaneFailureClassificationContractTest.php tests/Feature/Guards/CiHeavyBrowserWorkflowContractTest.php tests/Unit/Auth/NoRoleStringChecksTest.php)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && REPO_ROOT="$(git rev-parse --show-toplevel)" && (cd "$REPO_ROOT/apps/platform" && ./vendor/bin/sail artisan test --compact tests/Browser/Spec281ProviderConnectionScopeSmokeTest.php tests/Browser/Spec285WorkspaceRbacEnvironmentAccessSmokeTest.php)`
  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && (cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent)`

## Failure Classification Categories

The implementation must classify every remaining relevant failure into exactly one of these categories:

- `cutover-baseline-debt`: stale suite expectation caused directly by the `287` and `288` cutover truth; fix in `293`
- `cutover-runtime-regression`: current workspace-first primary path is actually broken; a minimal fix may be allowed later in `293` if proven
- `unrelated-existing-debt`: existing failure outside the cutover stabilization scope; document instead of absorbing it
- `flaky-or-environment`: nondeterministic or local-environment issue; isolate, rerun, and document
- `resolved-or-not-needed`: initially suspected cutover debt that no longer needs code changes after reclassification or adjacent stabilization

## Stabilization Seams

The implementation must keep the seam inventory bounded to these exact keys:

- `tenant_panel_baseline`: stale TenantPanel or `panel: 'tenant'` assumptions in the suite baseline
- `legacy_admin_t_routes`: stale `/admin/t/...` management-route assumptions
- `workspace_aware_operations_routes`: operations links or helpers missing workspace context
- `legacy_required_permissions_provider_connections`: tenant-scoped required-permissions or provider-connection legacy expectations
- `action_surface_rebaseline`: stale action-surface expectations caused by the cutover

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Classify Remaining Cutover Failures First (Priority: P1)

As a maintainer, I want an initial baseline and failure-classification artifact before any fixes so `293` repairs only cutover-driven debt instead of silently turning into a general suite cleanup.

**Why this priority**: without classification first, every later change risks absorbing unrelated debt or reintroducing compatibility behavior by accident.

**Independent Test**: Can be fully tested by running the initial full suite or fallback lanes, recording the resulting groups in `failure-classification.md`, and proving every in-scope failure is assigned to one of the pinned categories.

**Acceptance Scenarios**:

1. **Given** the current post-`287` and post-`288` baseline, **When** the initial suite or lane commands run, **Then** the resulting failure groups are recorded in `failure-classification.md` using the pinned categories before any implementation work begins.
2. **Given** a failure is clearly unrelated to cutover debt, **When** it is classified, **Then** it is documented as `unrelated-existing-debt` or `flaky-or-environment` instead of being silently fixed under `293`.

---

### User Story 2 - Remove Retired TenantPanel and `/admin/t/...` Baseline Assumptions (Priority: P1)

As a maintainer, I want the suite to stop expecting the retired TenantPanel and `/admin/t/...` runtime truth so current admin-panel-only routing becomes the only accepted baseline.

**Why this priority**: these are the most visible stale assumptions and they distort multiple downstream tests and route expectations.

**Independent Test**: Can be fully tested by re-running `PanelNavigationSegregationTest`, the legacy tenant-core guard, and the browser anchors while proving that retired paths are treated as absent or forbidden instead of current runtime truth.

**Acceptance Scenarios**:

1. **Given** an in-scope test still expects `/admin/t/...` to return the current page, **When** `293` lands, **Then** that expectation is replaced with the current admin or workspace-aware baseline.
2. **Given** a test still depends on `panel: 'tenant'` or equivalent retired panel bootstrapping, **When** the stabilization work completes, **Then** the test uses the current admin-panel path or explicitly asserts retirement instead.

---

### User Story 3 - Make Operations and Legacy Provider/Permissions Baselines Canonical (Priority: P1)

As a maintainer, I want operations links, required-permissions links, and provider-connection links in the suite to resolve only through current canonical workspace-aware or tenantless admin paths.

**Why this priority**: workspace-unaware operations links and retired tenant-scoped provider or required-permissions assumptions are the main cutover debt still visible across OpsUx and verification-adjacent tests.

**Independent Test**: Can be fully tested by re-running the targeted OpsUx, ProviderConnections, and Verification proof sets and proving those tests no longer depend on tenant-scoped fallbacks or missing workspace parameters.

**Acceptance Scenarios**:

1. **Given** a test generates `admin.operations.index` or `admin.operations.view` without `workspace`, **When** `293` stabilizes the baseline, **Then** that test uses the canonical helper or explicit workspace parameter instead.
2. **Given** a test expects tenant-scoped required-permissions or provider-connection URLs to return `200`, **When** the stabilization work completes, **Then** it uses the current canonical surface instead of the retired path.

---

### User Story 4 - Rebaseline Action Surface Expectations Without Reopening Product Work (Priority: P2)

As a maintainer, I want stale action-surface expectations updated only where they are directly invalidated by workspace-first, environment-scope, or TenantPanel removal so `293` does not become a feature redesign.

**Why this priority**: action-surface drift is real, but it is also the easiest place for a stabilization spec to overreach into product behavior.

**Independent Test**: Can be fully tested by re-running the action-surface and adjacent RBAC feature tests while proving that only stale cutover-era expectations changed and no new actions were added merely to satisfy old assertions.

**Acceptance Scenarios**:

1. **Given** an action-surface test still expects an old cutover-era action or label, **When** `293` updates the baseline, **Then** the expectation is aligned to current runtime truth without adding a new product action.
2. **Given** an action mismatch is not actually caused by the cutover, **When** it is reviewed during `293`, **Then** it is documented in `failure-classification.md` instead of being silently absorbed.

### Edge Cases

- What happens when the initial full-suite run is too noisy or slow to classify accurately? The package must fall back to `heavy-governance` and `confidence` lanes without skipping classification.
- What happens when an in-scope test failure looks like cutover debt but is actually a true current runtime regression on the workspace-first primary path? The failure must be reclassified as `cutover-runtime-regression` before any minimal fix is considered later.
- What happens when one stale action-surface assertion sits beside an unrelated existing debt in the same file? Only the cutover-driven expectation may be fixed under `293`; the unrelated failure must be classified explicitly.
- What happens when the Spec `288` proof pack or browser anchors regress during stabilization? `293` must stop and restore that proof pack before claiming readiness.
- What happens when a test could be made green by restoring a tenant-scoped fallback route or TenantPanel bootstrapping shortcut? That remedy is forbidden under `293`.

## Requirements *(mandatory)*

**Constitution alignment (required):** This package introduces no new Graph integration surface, no new queue workflow, no new product workflow, and no new runtime source of truth. It stabilizes the suite and only allows minimal runtime fixes later when a current workspace-first primary path is demonstrably broken.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The package must reuse the current tests, helpers, route builders, browser anchors, and lane scripts. It may add one spec-local failure-classification artifact and one bounded category inventory, but it must not create a new runtime framework, lane system, or compatibility layer.

**Constitution alignment (XCUT-001 / PROV-001):** The package must reuse current shared link helpers, current provider and RBAC proof surfaces, and current browser anchors. It may correct existing canonical helpers if a true primary-path regression is proven later, but it must not restore tenant-first or provider-specific fallback behavior.

### Functional Requirements

- **FR-001**: `293` MUST begin with an initial baseline and failure-classification pass before implementation fixes start.
- **FR-002**: `failure-classification.md` MUST classify every remaining relevant failure using exactly these categories: `cutover-baseline-debt`, `cutover-runtime-regression`, `unrelated-existing-debt`, `flaky-or-environment`, and `resolved-or-not-needed`.
- **FR-003**: In-scope tests MUST stop treating the retired TenantPanel, `panel: 'tenant'`, and `/admin/t/...` management paths as current runtime truth, except where a test explicitly verifies that those paths are retired or forbidden.
- **FR-004**: In-scope operations tests MUST generate `admin.operations.index` and `admin.operations.view` through current workspace-aware helpers or explicit workspace parameters.
- **FR-005**: In-scope required-permissions and provider-connection tests MUST stop expecting tenant-scoped legacy URLs to behave as canonical runtime paths.
- **FR-006**: In-scope tests MUST stop treating managed-environment membership rows as a second role-bearing authority source.
- **FR-007**: Action-surface rebaselining under `293` MUST stay bounded to stale cutover-era expectations and MUST NOT add or redesign product actions merely to satisfy old tests.
- **FR-008**: If later implementation proves a current workspace-first primary path regression, `293` MAY apply a minimal fix through the existing canonical helper or route path only; it MUST NOT restore legacy routes, TenantPanel bootstrapping, or tenant-scoped provider fallbacks.
- **FR-009**: The Spec `288` proof pack MUST remain green after `293` implementation.
- **FR-010**: The browser anchors `Spec281ProviderConnectionScopeSmokeTest` and `Spec285WorkspaceRbacEnvironmentAccessSmokeTest` MUST remain green after `293` implementation.
- **FR-011**: Remaining unrelated or flaky failures MUST stay documented in `failure-classification.md`; `293` MUST NOT silently absorb them.
- **FR-012**: `293` MUST remain a stabilization package only and MUST NOT absorb Package Execution, Guided Operations, Microsoft Starter Pack, Virtual Consultant, UI polish, or broad refactor work.

### Non-Functional Requirements

- **NFR-001**: Filament remains v5 on Livewire v4, and provider registration remains in `apps/platform/bootstrap/providers.php`.
- **NFR-002**: The package introduces no new panel, no new globally-searchable resource, no new asset registration, and no change to destructive-action policy.
- **NFR-003**: Validation remains bounded to the initial baseline or fallback lanes, targeted feature reruns, the Spec `288` proof pack, the two browser anchors, broad confidence rerun, and formatting.
- **NFR-004**: `293` must not reintroduce TenantPanel bootstrapping, `/admin/t/...` compatibility routes, tenant-scoped provider-connection fallback routes, or tenant-scoped required-permissions fallback routes.
- **NFR-005**: The pinned failure-classification category names must stay aligned across `spec.md`, `plan.md`, `tasks.md`, `research.md`, `data-model.md`, `quickstart.md`, `checklists/requirements.md`, and `failure-classification.md`, while the authoritative category meanings live in `data-model.md` and `failure-classification.md`.

## Out of Scope

- Package Execution
- Guided Operations
- Microsoft Starter Pack
- Virtual Consultant
- new product features
- new UI surfaces
- UI polish
- broad refactors
- compatibility route or panel restoration
- legacy provider-connection fallback restoration
- repo-wide non-cutover cleanup unrelated to `287` and `288`

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-001**: `failure-classification.md` exists and records the initial baseline groups with the pinned categories before cutover fixes are applied.
- **SC-002**: No in-scope test continues to treat TenantPanel bootstrapping, `panel: 'tenant'`, or retired `/admin/t/...` management paths as current runtime truth.
- **SC-003**: No in-scope operations test generates `admin.operations.index` or `admin.operations.view` without `workspace`.
- **SC-004**: No in-scope test expects tenant-scoped required-permissions or provider-connection legacy URLs to return `200` as canonical paths.
- **SC-005**: The Spec `288` proof pack remains green after `293`.
- **SC-006**: The browser anchors remain green after `293`.
- **SC-007**: A final full-suite or fallback-lane rerun leaves no unclassified cutover-related failures.
- **SC-008**: `293` does not restore legacy runtime behavior and does not replace future Package Execution work.

## Risks

- Some initially failing tests may prove to be unrelated existing debt rather than cutover debt, which makes disciplined classification essential.
- Broad suite noise may obscure root cause unless the initial baseline is split into the fallback lanes quickly.
- Action-surface mismatches can tempt feature expansion unless the bounded rebaseline rule is enforced strictly.

## Assumptions

- Specs `287` and `288` are the current cutover runtime and enforcement baseline.
- `292` already exists and remains unrelated to this stabilization package.
- The repo's current `heavy-governance`, `confidence`, and browser anchors are available and runnable during later implementation.

## Open Questions

- None. The scope, slot, branch name, and stabilization boundary were provided explicitly for this preparation pass.