ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

chore: finalize high risk admin action proof pack #472

Merged
ahmido merged 1 commits from 401-high-risk-admin-action-proof-pack into platform-dev 2026-06-23 00:24:10 +00:00
Conversation 0 Commits 1 Files Changed 9 +1501 -1
9 changed files with 1501 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
apps/platform/app/Filament/Resources/BackupScheduleResource.php
View File

@ -75,6 +75,8 @@ class BackupScheduleResource extends Resource
protected static ?string $tenantOwnershipRelationshipName = 'tenant';
protected static bool $isGloballySearchable = false;
protected static string|BackedEnum|null $navigationIcon = 'heroicon-o-clock';
protected static string|UnitEnum|null $navigationGroup = 'Backups & Restore';
@ -435,6 +437,9 @@ public static function table(Table $table): Table
->label('Run now')
->icon('heroicon-o-play')
->color('success')
->requiresConfirmation()
->modalHeading('Run backup schedule now?')
->modalDescription('This queues a backup run for the selected schedule and records an operation run.')
->visible(fn (BackupSchedule $record): bool => ! $record->trashed())
->action(function (BackupSchedule $record, HasTable $livewire): void {
$tenant = static::resolveTenantContextForCurrentPanel();
@ -506,6 +511,9 @@ public static function table(Table $table): Table
->label('Retry')
->icon('heroicon-o-arrow-path')
->color('warning')
->requiresConfirmation()
->modalHeading('Retry backup schedule now?')
->modalDescription('This queues another backup run for the selected schedule and records an operation run.')
->visible(fn (BackupSchedule $record): bool => ! $record->trashed())
->action(function (BackupSchedule $record, HasTable $livewire): void {
$tenant = static::resolveTenantContextForCurrentPanel();
@ -577,6 +585,9 @@ public static function table(Table $table): Table
->label('Restore')
->icon('heroicon-o-arrow-uturn-left')
->color('success')
->requiresConfirmation()
->modalHeading('Restore backup schedule?')
->modalDescription('The archived schedule will return to the active list without changing its enabled state.')
->visible(fn (BackupSchedule $record): bool => $record->trashed())
->action(function (BackupSchedule $record, AuditLogger $auditLogger): void {
$record = static::resolveProtectedScheduleRecordOrFail($record);
@ -724,6 +735,9 @@ public static function table(Table $table): Table
->label('Run now')
->icon('heroicon-o-play')
->color('success')
->requiresConfirmation()
->modalHeading(fn (Collection $records): string => "Run {$records->count()} backup schedules now?")
->modalDescription('This queues backup runs for the selected schedules and records operation runs.')
->action(function (Collection $records, HasTable $livewire): void {
$tenant = static::resolveTenantContextForCurrentPanel();
@ -821,6 +835,9 @@ public static function table(Table $table): Table
->label('Retry')
->icon('heroicon-o-arrow-path')
->color('warning')
->requiresConfirmation()
->modalHeading(fn (Collection $records): string => "Retry {$records->count()} backup schedules now?")
->modalDescription('This queues retry backup runs for the selected schedules and records operation runs.')
->action(function (Collection $records, HasTable $livewire): void {
$tenant = static::resolveTenantContextForCurrentPanel();

177
apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php Normal file
View File

@ -0,0 +1,177 @@
<?php
declare(strict_types=1);
use App\Filament\Resources\BackupScheduleResource;
use App\Filament\Resources\ProviderConnectionResource;
use App\Filament\Resources\RestoreRunResource;
use App\Models\BackupSchedule;
use App\Models\BackupSet;
use App\Models\ManagedEnvironment;
use App\Models\OperationRun;
use App\Models\ProviderConnection;
use App\Models\RestoreRun;
use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
pest()->browser()->timeout(60_000);
uses(RefreshDatabase::class);
function spec401BrowserLoginUrl(User $user, ManagedEnvironment $tenant, string $redirect): string
{
return route('admin.local.smoke-login', [
'email' => $user->email,
'tenant' => $tenant->external_id,
'workspace' => $tenant->workspace->slug,
'redirect' => $redirect,
]);
}
function spec401BrowserPath(string $url): string
{
$parts = parse_url($url);
return ($parts['path'] ?? '/admin').(isset($parts['query']) ? '?'.$parts['query'] : '');
}
function spec401BrowserBackupSchedule(ManagedEnvironment $tenant, array $attributes = []): BackupSchedule
{
return BackupSchedule::query()->create(array_merge([
'managed_environment_id' => (int) $tenant->getKey(),
'name' => 'Spec 401 Browser Backup Schedule',
'is_enabled' => true,
'timezone' => 'UTC',
'frequency' => 'daily',
'time_of_day' => '01:00:00',
'days_of_week' => null,
'policy_types' => ['deviceConfiguration'],
'include_foundations' => true,
'retention_keep_last' => 30,
], $attributes));
}
function spec401BrowserClickVisible($page, string $label): void
{
$encodedLabel = json_encode($label, JSON_THROW_ON_ERROR);
$clicked = $page->script(<<<JS
(() => {
const label = {$encodedLabel};
const candidates = Array.from(document.querySelectorAll('button, a, [role="button"]'));
const target = candidates.find((element) => {
const style = window.getComputedStyle(element);
const text = [
element.textContent || '',
element.getAttribute('aria-label') || '',
element.getAttribute('title') || '',
].join(' ').replace(/\\s+/g, ' ').trim();
return text.includes(label)
&& style.display !== 'none'
&& style.visibility !== 'hidden'
&& ! element.hidden
&& Boolean(element.offsetWidth || element.offsetHeight || element.getClientRects().length);
});
target?.scrollIntoView({ block: 'center', inline: 'center' });
target?.click();
return Boolean(target);
})()
JS);
expect($clicked)->toBeTrue();
}
it('smokes high-risk restore backup provider and unauthorized guards', function (): void {
bindFailHardGraphClient();
[$owner, $tenant] = createUserWithTenant(role: 'owner', workspaceRole: 'owner');
$backupSchedule = spec401BrowserBackupSchedule($tenant);
$backupSet = BackupSet::factory()->create([
'managed_environment_id' => (int) $tenant->getKey(),
'name' => 'Spec 401 Browser Restore Backup',
'status' => 'completed',
'item_count' => 1,
]);
$restoreRun = RestoreRun::factory()->for($tenant, 'tenant')->for($backupSet)->create([
'status' => 'draft',
'is_dry_run' => true,
'results' => [],
'metadata' => [],
'started_at' => null,
'completed_at' => null,
]);
$providerConnection = ProviderConnection::factory()
->platform()
->verifiedHealthy()
->create([
'managed_environment_id' => (int) $tenant->getKey(),
'workspace_id' => (int) $tenant->workspace_id,
'provider' => 'microsoft',
'is_default' => true,
'display_name' => 'Spec 401 Browser Expired Connection',
'last_health_check_at' => now()->subDays(31),
]);
$backupPath = spec401BrowserPath(BackupScheduleResource::getUrl('index', panel: 'admin', tenant: $tenant));
$restorePath = spec401BrowserPath(RestoreRunResource::getUrl('view', ['record' => $restoreRun], panel: 'admin', tenant: $tenant));
$providerPath = spec401BrowserPath(ProviderConnectionResource::getUrl('view', [
'record' => $providerConnection,
'environment_id' => (int) $tenant->getKey(),
], panel: 'admin'));
$page = visit(spec401BrowserLoginUrl($owner, $tenant, $backupPath))
->resize(1440, 1000)
->waitForText($backupSchedule->name)
->assertNoJavaScriptErrors()
->assertNoConsoleLogs();
$page
->click('[aria-label="More"]')
->wait(1)
->assertSee('Run now');
spec401BrowserClickVisible($page, 'Run now');
$page
->waitForText('Run backup schedule now?')
->assertSee('This queues a backup run for the selected schedule and records an operation run.')
->assertNoJavaScriptErrors()
->assertNoConsoleLogs();
spec401BrowserClickVisible($page, 'Cancel');
expect(OperationRun::query()
->where('managed_environment_id', (int) $tenant->getKey())
->where('type', 'backup.schedule.execute')
->count())->toBe(0);
visit($restorePath)
->resize(1440, 1000)
->waitForText('Was this restore executed safely, and is recovery proof available?')
->assertSee('Not configured')
->assertSee('View technical run details')
->assertNoJavaScriptErrors()
->assertNoConsoleLogs();
visit($providerPath)
->resize(1440, 1000)
->waitForText('Verification expired')
->assertDontSee('Healthy')
->assertNoJavaScriptErrors()
->assertNoConsoleLogs();
[$otherUser, $otherTenant] = createUserWithTenant(role: 'owner', workspaceRole: 'owner');
visit(spec401BrowserLoginUrl($otherUser, $otherTenant, $backupPath))
->resize(1440, 1000)
->assertScript('document.body.innerText.includes("404") || document.body.innerText.includes("Not Found") || document.body.innerText.includes("No access")', true)
->assertNoJavaScriptErrors()
->assertNoConsoleLogs();
});

2
apps/platform/tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php
View File

@ -76,7 +76,7 @@ function makeBackupScheduleForLifecycle(\App\Models\ManagedEnvironment $tenant,
Livewire::test(ListBackupSchedules::class)
->filterTable(TrashedFilter::class, false)
->assertTableActionExists('restore', function ($action): bool {
return $action->isConfirmationRequired() === false;
return $action->isConfirmationRequired();
}, BackupSchedule::withTrashed()->findOrFail($schedule->id))
->callTableAction('restore', BackupSchedule::withTrashed()->findOrFail($schedule->id))
->assertHasNoTableActionErrors();

121
apps/platform/tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php Normal file
View File

@ -0,0 +1,121 @@
<?php
use App\Filament\Resources\BackupScheduleResource;
use App\Filament\Resources\BackupScheduleResource\Pages\ListBackupSchedules;
use App\Jobs\RunBackupScheduleJob;
use App\Models\BackupSchedule;
use App\Models\ManagedEnvironment;
use App\Models\OperationRun;
use Filament\Actions\Action;
use Filament\Facades\Filament;
use Filament\Tables\Filters\TrashedFilter;
use Illuminate\Support\Facades\Queue;
use Livewire\Livewire;
function spec401BackupSchedule(ManagedEnvironment $tenant, array $attributes = []): BackupSchedule
{
return BackupSchedule::query()->create(array_merge([
'managed_environment_id' => $tenant->id,
'name' => 'Spec 401 backup schedule',
'is_enabled' => true,
'timezone' => 'UTC',
'frequency' => 'daily',
'time_of_day' => '01:00:00',
'days_of_week' => null,
'policy_types' => ['deviceConfiguration'],
'include_foundations' => true,
'retention_keep_last' => 30,
], $attributes));
}
test('backup schedule high-impact row actions require confirmation before side effects', function () {
Queue::fake([RunBackupScheduleJob::class]);
[$user, $tenant] = createUserWithTenant(role: 'owner');
$activeSchedule = spec401BackupSchedule($tenant, ['name' => 'Spec 401 active schedule']);
$archivedSchedule = spec401BackupSchedule($tenant, [
'name' => 'Spec 401 archived schedule',
'is_enabled' => false,
]);
$archivedSchedule->delete();
$this->actingAs($user);
Filament::setTenant($tenant, true);
$component = Livewire::test(ListBackupSchedules::class)
->assertTableActionExists('runNow', fn (Action $action): bool => $action->isConfirmationRequired(), $activeSchedule)
->mountTableAction('runNow', $activeSchedule);
expect($component->instance()->getMountedAction()?->getName())->toBe('runNow')
->and($component->instance()->getMountedAction()?->isConfirmationRequired())->toBeTrue();
expect(OperationRun::query()->where('managed_environment_id', $tenant->id)->count())->toBe(0);
Queue::assertNothingPushed();
$component->unmountTableAction();
$component
->assertTableActionExists('retry', fn (Action $action): bool => $action->isConfirmationRequired(), $activeSchedule)
->mountTableAction('retry', $activeSchedule);
expect($component->instance()->getMountedAction()?->getName())->toBe('retry')
->and($component->instance()->getMountedAction()?->isConfirmationRequired())->toBeTrue();
expect(OperationRun::query()->where('managed_environment_id', $tenant->id)->count())->toBe(0);
Queue::assertNothingPushed();
$component->unmountTableAction();
$trashedSchedule = BackupSchedule::withTrashed()->findOrFail($archivedSchedule->id);
$component = Livewire::test(ListBackupSchedules::class)
->filterTable(TrashedFilter::class, false)
->assertTableActionExists('restore', fn (Action $action): bool => $action->isConfirmationRequired(), $trashedSchedule)
->mountTableAction('restore', $trashedSchedule);
expect($component->instance()->getMountedAction()?->getName())->toBe('restore')
->and($component->instance()->getMountedAction()?->isConfirmationRequired())->toBeTrue();
expect(BackupSchedule::withTrashed()->findOrFail($archivedSchedule->id)->trashed())->toBeTrue();
$this->assertDatabaseMissing('audit_logs', [
'managed_environment_id' => $tenant->id,
'action' => 'backup_schedule.restored',
'resource_type' => 'backup_schedule',
'resource_id' => (string) $archivedSchedule->id,
]);
});
test('backup schedule high-impact bulk actions require confirmation before side effects', function () {
Queue::fake([RunBackupScheduleJob::class]);
[$user, $tenant] = createUserWithTenant(role: 'owner');
$scheduleA = spec401BackupSchedule($tenant, ['name' => 'Spec 401 bulk schedule A']);
$scheduleB = spec401BackupSchedule($tenant, ['name' => 'Spec 401 bulk schedule B']);
$this->actingAs($user);
Filament::setTenant($tenant, true);
$component = Livewire::test(ListBackupSchedules::class)
->assertTableBulkActionExists('bulk_run_now')
->mountTableBulkAction('bulk_run_now', collect([$scheduleA, $scheduleB]))
->assertTableBulkActionMounted('bulk_run_now');
expect($component->instance()->getMountedAction()?->isConfirmationRequired())->toBeTrue();
expect(OperationRun::query()->where('managed_environment_id', $tenant->id)->count())->toBe(0);
Queue::assertNothingPushed();
$component->unmountAction();
$component = Livewire::test(ListBackupSchedules::class)
->assertTableBulkActionExists('bulk_retry')
->mountTableBulkAction('bulk_retry', collect([$scheduleA, $scheduleB]))
->assertTableBulkActionMounted('bulk_retry');
expect($component->instance()->getMountedAction()?->isConfirmationRequired())->toBeTrue();
expect(OperationRun::query()->where('managed_environment_id', $tenant->id)->count())->toBe(0);
Queue::assertNothingPushed();
});
test('backup schedules keep global search disabled for this proof pack', function () {
expect(BackupScheduleResource::canGloballySearch())->toBeFalse();
});

80
specs/401-high-risk-admin-action-proof-pack/checklists/requirements.md Normal file
View File

@ -0,0 +1,80 @@
# Specification Quality Checklist: Spec 401 - High-risk Admin Action Proof Pack
**Purpose**: Validate preparation completeness and quality before implementation.
**Created**: 2026-06-22
**Feature**: `specs/401-high-risk-admin-action-proof-pack/spec.md`
## Content Quality
- [x] No unresolved template placeholders remain.
- [x] Mandatory Spec Kit sections are completed or explicitly marked with rationale.
- [x] The spec focuses on product/operator value and high-risk action safety.
- [x] Implementation details are used only where repo truth, proof paths, or safety constraints require them.
- [x] Existing TenantPilot terminology is preserved.
## Candidate Selection Gate
- [x] Candidate source is direct user-provided Spec 401 draft.
- [x] `docs/product/spec-candidates.md` auto-queue status was checked and does not override the direct user-provided candidate.
- [x] Related existing specs were checked for duplication/completed-spec risk.
- [x] No existing `specs/401-high-risk-admin-action-proof-pack/` package existed before preparation.
- [x] Close alternatives are deferred with reasons.
- [x] Smallest viable implementation slice is bounded to proof map, focused tests/browser proof, and minimal hardening.
## Requirement Completeness
- [x] Requirements are testable and unambiguous.
- [x] Restore, backup, and provider target domains are all covered.
- [x] Authorization, workspace/environment isolation, direct invocation, confirmation, cancellation, audit/evidence, OperationRun, and browser proof are covered.
- [x] Functional requirements include negative proof for cancelled/forbidden actions.
- [x] Product Surface Contract, Filament/Livewire, global search, destructive action, asset, and deployment posture are covered.
- [x] Out-of-scope boundaries prevent feature expansion.
- [x] Assumptions and stop conditions are documented.
- [x] No blocking open questions remain.
## Plan Quality
- [x] Plan identifies likely repo surfaces without inventing new architecture.
- [x] Plan distinguishes execution truth, artifact truth, backup/snapshot truth, recovery/evidence truth, and operator next action.
- [x] Plan states no migrations, env vars, assets, panel provider changes, queues, scheduler, or storage changes expected by default.
- [x] Plan includes Product Surface, UI guardrail, Filament/Livewire, OperationRun UX, provider-boundary, RBAC, security, audit, and test governance handling.
- [x] Plan includes stop conditions for scope expansion.
## Task Quality
- [x] Tasks are ordered by safety/inventory, foundational tests, restore proof, backup proof, provider proof, browser proof, and close-out.
- [x] Tasks use checkbox format with stable IDs and file paths.
- [x] Tests are planned before implementation where feasible.
- [x] Browser proof and Human Product Sanity are explicit.
- [x] Tasks include final validation and implementation-report requirements.
- [x] Tasks explicitly forbid completed-spec rewrites and broad scope expansion.
## Product Surface Contract
- [x] Spec references `docs/product/standards/product-surface-contract.md`.
- [x] No-legacy posture is explicit.
- [x] Product Surface Impact records archetypes, primary question/action, surface-budget expectation, technical demotion, canonical status vocabulary, visible complexity, and exceptions.
- [x] Browser proof is required for rendered UI/action changes.
- [x] Human Product Sanity is required.
- [x] Implementation-report fields are specified.
- [x] Completed historical specs are protected from rewrite/normalization.
## Constitution Alignment
- [x] No new persisted truth is planned.
- [x] No new enum/status/reason family is planned.
- [x] No new runtime abstraction/framework is planned.
- [x] No new provider family or provider-core generalization is planned.
- [x] RBAC, workspace isolation, tenant isolation, auditability, and OperationRun semantics are addressed.
- [x] Test governance and lane scope are explicit.
- [x] Spec Candidate Check is completed with approval class, score, red flags, and decision.
## Review Outcome
- [x] Review outcome class: `acceptable-special-case` for a bounded high-risk proof pack.
- [x] Workflow outcome: `keep`.
- [x] Final note location: implementation report / final implementation response.
## Notes
This checklist validates preparation only. It does not claim runtime implementation, test execution, browser proof, Human Product Sanity completion, or implementation close-out.

71
specs/401-high-risk-admin-action-proof-pack/implementation-report.md Normal file
View File

@ -0,0 +1,71 @@
# Spec 401 Implementation Report
## Start State
- Active branch: `401-high-risk-admin-action-proof-pack`
- Start HEAD: `23225434 spec: add completeness audit spec artifacts for product contract (#471)`
- Initial dirty state: untracked `specs/401-high-risk-admin-action-proof-pack/`
- Active spec package: `specs/401-high-risk-admin-action-proof-pack/`
- Related historical specs inspected as read-only context: 333, 335, 364, 390, 394, 395, 396, 397, 398, 399, 400.
- Runtime edit gate: passed. The implementation scope is existing restore, backup, provider, OperationRun, audit, and evidence surfaces only.
- New surface/persistence gate: passed. No new pages, routes, panels, navigation, persisted truth, status family, provider family, migration, or runtime framework is required.
## Proof Map
| Flow | State / risk | Existing proof | Missing proof before implementation | Fix needed? | Classification |
| --- | --- | --- | --- | --- | --- |
| Restore create/execution | direct authorization, non-member deny-as-not-found, missing capability denied | `RestoreRunResource::createRestoreRun()`, `CreateRestoreRun::authorizeAccess()`, `RestoreRunUiEnforcementTest`, restore hardening tests | No runtime defect found during inventory | No | Fully proven |
| Restore execution | stale preview, blocking checks, write gate, acknowledgement, tenant confirmation | `RestoreStartGateStaleTest`, `RestoreStartGatePassesTest`, `RestoreStartGateBypassTest`, `ExecuteRestoreRunExecutionReauthorizationTest` | Browser proof still required by Spec 401 | No | Fully proven except browser proof |
| Restore actions | destructive/archive/force-delete/rerun confirmations | `RestoreRunResource` action definitions and action tests | No runtime defect found during inventory | No | Fully proven |
| Backup schedule row actions | run now / retry are high-impact queueing actions | `RunNowRetryActionsTest` proves accepted path, no DB notification, no dedupe, readonly block | Confirmation/cancel proof missing; actions lacked confirmation | Yes | Implementation defect found and fixed |
| Backup schedule restore | archived schedule restore mutates lifecycle state | `BackupScheduleLifecycleTest` proves accepted path and audit | Existing test expected no confirmation; action lacked confirmation | Yes | Implementation defect found and fixed |
| Backup schedule bulk actions | bulk run now / bulk retry queue multiple operation runs | `RunNowRetryActionsTest`, `BackupScheduleBulkDeleteTest` prove accepted path and no bulk delete | Confirmation/cancel proof missing; actions lacked confirmation | Yes | Implementation defect found and fixed |
| Backup schedule list posture | empty state and action hierarchy | `BackupScheduleResource` empty state and action group | Global search posture was implicit because no record title attribute was declared | Yes | Product contract missing and fixed |
| Backup set list/detail/items | archive/restore/force-delete/remove confirmations, detail decision hierarchy | `Spec371BackupSetProductizationTest`, `Spec371BackupSetProductizationSmokeTest`, relation-manager RBAC tests | No runtime defect found during inventory | No | Fully proven |
| Provider connection actions | setup/readiness/list/detail capability gating and sensitive mutation confirmations | `Spec394ProviderFreshnessPermissionSmokeTest`, provider resource action definitions, mutation confirmation inventory | Existing `ProviderConnectionsUiEnforcementTest` has one reproducible readonly `check_connection` list visibility assertion failure unrelated to the backup changes | No provider runtime fix in this proof pack | Proven except explicitly deferred state |
| Provider required permissions | stale/missing/ready state, raw grant detail demotion | `Spec394ProviderFreshnessPermissionSmokeTest`, required-permissions page empty state | No runtime defect found during inventory | No | Fully proven |
| OperationRun/audit/evidence links | scoped proof links and technical-detail demotion | Existing OperationRun link helpers and related smoke/tests from Specs 371, 391, 394, 399 | No runtime defect found during inventory | No | Fully proven for touched paths |
## Action Inventory Result
- Restore: destructive and high-impact actions are action-backed, confirmation-gated where applicable, and server-authorized. Global search is disabled.
- Backup schedules: `runNow`, `retry`, `restore`, `bulk_run_now`, and `bulk_retry` were action-backed and capability-gated, but missing confirmation. This report records the defect before hardening.
- Backup sets/items: destructive and high-impact actions are action-backed and confirmation-gated. Global search is disabled.
- Provider connections: sensitive mutation actions are action-backed, confirmation-gated, and capability-gated. Navigation-only URL actions remain navigation-only. Global search is disabled.
## Product Surface Close-Out
- No-legacy posture: clean current contract behavior; no compatibility aliases or legacy fixtures introduced.
- Product Surface exceptions: none.
- Page archetypes touched: Backup schedules Search/Index page with high-impact row and bulk actions.
- Technical Annex / deep-link demotion: unchanged; OperationRun links stay secondary action links.
- Canonical status vocabulary: unchanged.
- Visible complexity outcome: neutral. The only UI change is adding confirmation modals to existing high-impact backup schedule actions.
- Asset strategy: no new assets and no `FilamentAsset` registration. No new `filament:assets` deployment step beyond the existing deployment baseline.
- Deployment impact: no migrations, env vars, scheduler/storage/worker changes, panel provider changes, routes, or navigation changes.
- Livewire v4 compliance: Laravel Boost reported Livewire 4.1.4. No Livewire v3 APIs introduced.
- Provider registration location: unchanged; Laravel 12 panel providers remain registered through `apps/platform/bootstrap/providers.php`.
- Global search posture: `RestoreRunResource`, `BackupSetResource`, `ProviderConnectionResource`, and now `BackupScheduleResource` have global search disabled for these high-risk surfaces.
- Destructive/high-impact action posture: backup schedule `runNow`, `retry`, `restore`, `bulk_run_now`, and `bulk_retry` are `Action` / `BulkAction` backed, capability-gated through existing `UiEnforcement`, and now confirmation-gated. Archive/force-delete confirmations were already present.
- Browser proof: `apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php` covers backup schedule confirmation/cancel, restore detail state, stale provider state, and a cross-tenant denied backup schedule path with no JavaScript/console errors.
- Human Product Sanity result: pass for the changed backup schedule surface. Confirmation copy states exactly that operation runs will be queued, restore does not silently change enabled state, and cancellation creates no operation/audit side effects.
## Validation Log
- PASS: `cd apps/platform && ./vendor/bin/sail artisan test tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php tests/Feature/BackupScheduling/RunNowRetryActionsTest.php tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php tests/Feature/BackupScheduling/BackupScheduleLifecycleAuthorizationTest.php tests/Feature/BackupScheduling/BackupScheduleBulkDeleteTest.php --compact` -> 29 tests, 237 assertions.
- PASS: `cd apps/platform && ./vendor/bin/sail artisan test tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php --compact` -> 1 test, 23 assertions.
- PASS: restore subset inside `cd apps/platform && ./vendor/bin/sail artisan test tests/Feature/Filament/RestoreRunUiEnforcementTest.php tests/Feature/Hardening/RestoreStartGateStaleTest.php tests/Feature/Filament/ProviderConnectionsUiEnforcementTest.php --compact` -> `RestoreRunUiEnforcementTest` 7 passed and `RestoreStartGateStaleTest` 4 passed before provider residual.
- RESIDUAL: `tests/Feature/Filament/ProviderConnectionsUiEnforcementTest.php` fails independently on `members without capability see provider connection actions disabled with standard tooltip`; failure is `check_connection` not visible on the provider connection list for that fixture. No provider runtime file was changed in this implementation.
- PASS: `cd apps/platform && ./vendor/bin/sail pint app/Filament/Resources/BackupScheduleResource.php tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`.
- PASS: `cd apps/platform && ./vendor/bin/sail pint tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php`.
- PASS: `git diff --check`.
## Final State
- Changed runtime files: `apps/platform/app/Filament/Resources/BackupScheduleResource.php`.
- Changed existing tests: `apps/platform/tests/Feature/BackupScheduling/BackupScheduleLifecycleTest.php`.
- Added tests: `apps/platform/tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php`, `apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php`.
- Added spec evidence: `specs/401-high-risk-admin-action-proof-pack/implementation-report.md`.
- Completed-spec rewrite assertion: no completed historical specs were modified.
- No new migrations, env vars, queue/scheduler/storage/assets/panel provider changes, routes/pages/navigation, status vocabulary, provider families, persisted truth, or broad runtime framework were introduced.
- Merge readiness: changed backup schedule hardening is ready for review with focused Feature and Browser proof. Full provider proof still has the independently reproducible provider UI enforcement residual noted above.

392
specs/401-high-risk-admin-action-proof-pack/plan.md Normal file
View File

@ -0,0 +1,392 @@
# Implementation Plan: Spec 401 - High-risk Admin Action Proof Pack
**Branch**: `401-high-risk-admin-action-proof-pack` | **Date**: 2026-06-22 | **Spec**: `specs/401-high-risk-admin-action-proof-pack/spec.md`
**Input**: Feature specification from `specs/401-high-risk-admin-action-proof-pack/spec.md`
## Summary
Prepare a targeted proof and minimal-hardening implementation package over existing restore, backup, and provider setup/detail admin flows. The implementation must first inventory current actions and tests, then build a proof map, add focused tests and browser proof for missing coverage, apply only minimal in-scope hardening defects, and close out with evidence that no new surfaces, concepts, persisted truth, or completed-spec rewrites were introduced.
## Technical Context
**Language/Version**: PHP 8.4.15, Laravel 12.52.0, Filament 5.2.1, Livewire 4.1.4.
**Primary Dependencies**: Laravel, Filament v5, Livewire v4, Pest 4, PostgreSQL via Sail, existing Spec Kit artifacts, Product Surface Contract, existing OperationRun/audit/evidence/provider/restore/backup support classes.
**Storage**: No new database table, migration, persisted product truth, or storage disk expected. Existing tables inspected or touched by tests include `restore_runs`, `backup_sets`, `backup_items`, `backup_schedules`, `provider_connections`, `managed_environment_permissions`, `operation_runs`, `audit_logs`, and `evidence_snapshots`.
**Testing**: Pest Feature/Filament/Livewire tests, Unit tests only where derived state helpers need proof, and one focused Pest Browser smoke.
**Validation Lanes**: confidence + browser; fast-feedback for pure unit/helper tests; PostgreSQL only if implementation unexpectedly touches PostgreSQL-specific behavior; no heavy-governance lane unless proof map reveals a structural guard need and spec is updated.
**Target Platform**: TenantPilot Laravel monolith under `apps/platform`; Spec Kit package under `specs/401-high-risk-admin-action-proof-pack/`.
**Project Type**: Laravel web application with Filament admin UI.
**Performance Goals**: No material query or browser-suite expansion. Focused tests should prove high-risk behavior without becoming a broad audit.
**Constraints**: Existing surfaces only; no new routes/pages/navigation/panels/product concepts/status families/persistence/frameworks; no completed-spec rewrites; no external Graph calls in tests/browser proof.
**Scale/Scope**: Three high-risk domains: restore preview/readiness/execution, backup schedules/sets/runs, provider setup/detail/readiness/permissions.
## Candidate Selection And Gate Result
- **Candidate source**: direct user-provided Spec 401 draft.
- **Auto queue status**: `docs/product/spec-candidates.md` reports no safe automatic next-best-prep target; this is a manually supplied candidate.
- **Completed-spec guardrail**: PASS. No `401-*` package existed before preparation. Related Specs 333, 335, 364, 390, 394, and 395-400 are read-only context.
- **Smallest slice**: proof map + focused tests + minimal hardening for existing high-risk actions only.
- **Close alternatives deferred**: management-report PDF runtime validation, governance artifact lifecycle, provider onboarding redesign, cross-domain indicator follow-through, and reopening recent completed specs.
## Repository Surfaces Likely Affected
Restore:
```text
apps/platform/app/Filament/Resources/RestoreRunResource.php
apps/platform/app/Filament/Resources/RestoreRunResource/Pages/CreateRestoreRun.php
apps/platform/app/Filament/Resources/RestoreRunResource/Pages/ViewRestoreRun.php
apps/platform/app/Filament/Resources/RestoreRunResource/Pages/ListRestoreRuns.php
apps/platform/app/Filament/Resources/RestoreRunResource/Presenters/RestoreRunCreatePresenter.php
apps/platform/app/Filament/Resources/RestoreRunResource/Presenters/RestoreRunDetailPresenter.php
apps/platform/resources/views/filament/forms/components/restore-run-*.blade.php
apps/platform/resources/views/filament/infolists/entries/restore-*.blade.php
apps/platform/app/Jobs/ExecuteRestoreRunJob.php
apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php
apps/platform/app/Services/Intune/RestoreService.php
apps/platform/app/Services/Intune/RestoreRiskChecker.php
apps/platform/app/Services/AssignmentRestoreService.php
```
Backup:
```text
apps/platform/app/Filament/Resources/BackupScheduleResource.php
apps/platform/app/Filament/Resources/BackupScheduleResource/Pages/*
apps/platform/app/Filament/Resources/BackupScheduleResource/RelationManagers/BackupScheduleOperationRunsRelationManager.php
apps/platform/app/Filament/Resources/BackupSetResource.php
apps/platform/app/Filament/Resources/BackupSetResource/Pages/*
apps/platform/app/Filament/Resources/BackupSetResource/RelationManagers/BackupItemsRelationManager.php
apps/platform/app/Jobs/RunBackupScheduleJob.php
apps/platform/app/Jobs/AddPoliciesToBackupSetJob.php
apps/platform/app/Jobs/RemovePoliciesFromBackupSetJob.php
apps/platform/app/Services/BackupScheduling/*
apps/platform/app/Services/AssignmentBackupService.php
apps/platform/app/Support/BackupHealth/*
apps/platform/app/Support/BackupQuality/*
```
Provider:
```text
apps/platform/app/Filament/Resources/ProviderConnectionResource.php
apps/platform/app/Filament/Resources/ProviderConnectionResource/Pages/*
apps/platform/app/Filament/Pages/EnvironmentRequiredPermissions.php
apps/platform/resources/views/filament/infolists/entries/provider-*.blade.php
apps/platform/resources/views/filament/widgets/provider-connections/provider-readiness-guidance.blade.php
apps/platform/app/Services/Providers/*
apps/platform/app/Support/Providers/*
apps/platform/app/Services/Intune/ManagedEnvironmentPermissionService.php
apps/platform/app/Services/Intune/ManagedEnvironmentRequiredPermissionsViewModelBuilder.php
apps/platform/app/Jobs/ProviderConnectionHealthCheckJob.php
```
Shared proof and safety:
```text
apps/platform/app/Filament/Pages/Monitoring/Operations.php
apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php
apps/platform/app/Filament/Pages/Monitoring/AuditLog.php
apps/platform/app/Filament/Pages/Monitoring/EvidenceOverview.php
apps/platform/app/Support/OpsUx/*
apps/platform/app/Support/OperationRunLinks.php
apps/platform/app/Services/OperationRunService.php
apps/platform/app/Services/Audit/*
apps/platform/app/Models/OperationRun.php
apps/platform/app/Models/AuditLog.php
```
Likely test surfaces:
```text
apps/platform/tests/Feature/Filament/Spec401HighRiskAdminActionProofPackTest.php
apps/platform/tests/Feature/Operations/Spec401HighRiskAdminActionProofPackTest.php
apps/platform/tests/Feature/ProviderConnections/Spec401HighRiskAdminActionProofPackTest.php
apps/platform/tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php
apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php
specs/401-high-risk-admin-action-proof-pack/implementation-report.md
```
Exact test-file split may be adjusted during implementation to fit existing test organization, but every task must keep the Spec 401 prefix or report mapping.
## Implementation Method
### Phase 1 - Read-only inventory
Record current branch, HEAD, dirty state, related routes, Filament resources/pages/actions, Livewire/Blade components, models, policies/gates/capabilities, migrations/schema, existing tests, and recent spec evidence. Do not edit runtime files before the proof map exists.
### Phase 2 - Proof gap mapping
Create a Spec 401 proof map in `implementation-report.md` or a spec-local `proof-map.md` if the map is too large. Each row must include:
```text
Flow
State
Existing proof
Missing proof
Fix needed?
Test needed?
Browser proof needed?
Out of scope?
Classification
```
### Phase 3 - Tests first
Add or update tests in this preferred order:
1. Authorization/direct-invocation tests.
2. State semantics tests.
3. Confirmation/cancel tests.
4. Audit/evidence side-effect tests.
5. Browser smoke proof.
### Phase 4 - Minimal hardening
Fix only confirmed in-scope defects required by existing product contracts. Acceptable fixes include missing confirmation, missing server-side authorization, stale action execution guard, wrong partial/failed/blocking display, false audit/evidence creation, or raw detail exposure on default product paths. Stop and update spec/plan if a fix requires new surfaces, new persistence, new status vocabulary, broad resource decomposition, or a new architecture layer.
### Phase 5 - Browser proof and close-out
Run focused browser proof for restore, backup, provider, and one unauthorized/blocked path. Complete implementation report with files changed, tests, browser proof, states proven/deferred, Product Surface fields, deployment impact, no completed-spec rewrite assertion, and visible complexity outcome.
## UI / Surface Guardrail Plan
- **Guardrail scope**: existing high-risk operator-facing surfaces may be minimally hardened.
- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**: RestoreRun create/view/list, BackupSchedule list/create/edit/run, BackupSet list/create/view/items, ProviderConnection list/create/view/edit, EnvironmentRequiredPermissions, OperationRun/audit/evidence links where already exposed.
- **No-impact class**: N/A.
- **Native vs custom classification summary**: mixed. Prefer native Filament actions/resources and shared primitives; existing custom Blade/presenter fragments may be touched only when proof gaps require it.
- **Shared-family relevance**: destructive/high-impact actions, OperationRun links/start UX, provider readiness, restore readiness, backup quality, audit/evidence links, status messaging.
- **State layers in scope**: page, detail, modal/action, table/relation manager, and route/query context. Shell/navigation/panel state is out of scope unless implementation finds a direct high-risk action leak.
- **Audience modes in scope**: operator-MSP and support-platform. No new customer-facing surface.
- **Decision/diagnostic/raw hierarchy plan**: decision-first default; diagnostics and raw/support proof hidden, demoted, or capability-gated.
- **Raw/support gating plan**: keep raw provider payloads, credentials, source keys, raw evidence, raw backup payloads, and technical logs out of default product surfaces.
- **One-primary-action / duplicate-truth control**: each changed surface keeps one dominant next safe action and avoids duplicate readiness/status summaries.
- **Handling modes by drift class or surface**: in-scope proof gaps are fixed if safe and bounded; missing product contracts become `document-in-feature` or `follow-up-spec`; broad architecture becomes stop condition.
- **Repository-signal treatment**: review-mandatory for high-risk actions; exception-required for any Product Surface budget or action-contract deviation.
- **Special surface test profiles**: dangerous-workflow wizard, shared-detail-family, monitoring-state-page, standard-native-filament where applicable.
- **Required tests or manual smoke**: Feature/Filament tests plus focused browser smoke.
- **Exception path and spread control**: none planned. Exceptions must be named in the implementation report.
- **Active feature PR close-out entry**: Guardrail / Exception / Smoke Coverage.
- **UI/Productization coverage decision**: existing coverage remains valid by default; update coverage artifacts only if implementation materially changes surface classification or finds registry drift.
- **Coverage artifacts to update**: none planned.
- **No-impact rationale**: N/A.
- **Screenshot or page-report need**: focused browser proof required; full page reports not required by default.
## Product Surface Contract Plan
- **Product Surface Contract reference**: `docs/product/standards/product-surface-contract.md`.
- **No-legacy posture**: clean canonical behavior; no compatibility shims or legacy fixtures by default.
- **Page archetype and surface budget plan**: keep existing archetypes; document any materially touched surface as Wizard, Receipt, Search/Index, Settings, Decision sub-surface, or Technical Annex; expect pass.
- **Technical Annex and deep-link demotion plan**: OperationRun/raw evidence/raw IDs/source keys/fingerprints/payloads/logs remain secondary, internal, or gated.
- **Canonical status vocabulary plan**: visible product statuses map to existing Product Surface vocabulary. No new status family.
- **Product Surface exceptions**: none planned.
- **Browser verification plan**: focused Spec 401 browser smoke over restore, backup, provider, and one unauthorized/blocked path.
- **Human Product Sanity plan**: complete in implementation report.
- **Visible complexity outcome target**: neutral or decreased.
- **Implementation report target**: `specs/401-high-risk-admin-action-proof-pack/implementation-report.md` unless final response carries the full report and the operator accepts no file output.
## Filament / Livewire / Deployment Posture
- **Livewire v4 compliance**: Livewire 4.1.4 confirmed by Laravel Boost; no Livewire v3 APIs allowed.
- **Panel provider registration location**: `apps/platform/bootstrap/providers.php`; no panel provider change expected.
- **Global search posture**: no global search change expected. Any touched globally searchable resource must have View/Edit plus `$recordTitleAttribute`, or global search disabled.
- **Destructive/high-impact action posture**:
- Touched destructive/high-impact actions must execute through `Action::make(...)->action(...)`.
- Touched destructive/high-impact actions must include `->requiresConfirmation()`.
- Backup action proof must classify each touched backup action by existing contract source before asserting whether confirmation is required.
- URL-only actions remain navigation-only and are not confirmation-protected.
- Server-side Gate/Policy authorization and audit/proof side effects must be tested.
- **Asset strategy**: no new assets. No `FilamentAsset` registration and no `filament:assets` deployment change expected.
- **Testing plan**: Feature/Filament action tests, direct authorization/action execution tests, audit/evidence side-effect tests, state semantics tests, focused browser smoke.
- **Deployment impact**: none expected for env vars, migrations, queues, scheduler, storage, assets, provider scopes, or Dokploy. If an existing job/action path is touched, document queue impact but do not add new workers.
## Shared Pattern & System Fit
- **Cross-cutting feature marker**: yes.
- **Systems touched**: existing Filament action APIs, `UiEnforcement` / `WorkspaceUiEnforcement`, policies/gates, OperationRun UX, provider readiness, restore readiness, backup quality/health, audit/evidence links.
- **Shared abstractions reused**: existing helpers/services/presenters should be reused before adding local logic.
- **New abstraction introduced? why?**: none planned. A small local test helper is allowed only if it reduces duplicated test setup and stays explicit.
- **Why existing abstractions are sufficient or insufficient**: existing action, authorization, OperationRun, provider, restore, backup, and audit paths cover the proof categories. The gap is evidence coverage, not a missing runtime framework.
- **Bounded deviation / spread control**: any local deviation must be documented in the implementation report and must not create a parallel operator-facing language.
## OperationRun UX Impact
- **Touches OperationRun start/completion/link UX?**: yes where existing restore/backup/provider actions create, queue, block, complete, reconcile, or link runs.
- **Central contract reused**: existing OperationRun Start UX Contract, `OperationUxPresenter`, `OperationRunLinks`, `OperationRunService`, `OperationRunCompleted`.
- **Delegated UX behaviors**: queued toast, run link, artifact link, browser event, dedupe/blocked/start-failure messaging, tenant/workspace-safe URL resolution, terminal notification.
- **Surface-owned behavior kept local**: domain input collection, confirmation copy, and proof display.
- **Queued DB-notification policy**: unchanged; no new queued DB notification.
- **Terminal notification path**: central lifecycle mechanism.
- **Exception path**: none planned.
## Provider Boundary & Portability Fit
- **Shared provider/platform boundary touched?**: yes.
- **Provider-owned seams**: Microsoft/Intune/Entra connection details, provider verification reports, required Graph permission evidence, provider errors, provider credentials/consent.
- **Platform-core seams**: workspace, managed environment, provider connection reference, operation, evidence, audit, readiness, blocked/failed/expired state display, action authorization.
- **Neutral platform terms / contracts preserved**: workspace, managed environment, provider, connection, operation, evidence, audit trail, backup, restore, readiness.
- **Retained provider-specific semantics and why**: current runtime is Microsoft-backed; provider-specific details stay in technical/provider-owned layers.
- **Bounded extraction or follow-up path**: follow-up-spec only if proof uncovers structural provider coupling beyond this minimal hardening slice.
## Domain / Model Implications
No new model, migration, enum, table, persisted artifact, provider integration, Graph contract, operation type, queue, scheduler, or customer-output artifact is expected.
Existing model relationships and policies must be inspected before tests/hardening. If a required test cannot be written because ownership or scope is ambiguous, record product-decision debt.
## RBAC / Security / Audit Implications
- Non-members and wrong-scope actors remain 404.
- Members missing capability remain 403 or disabled/hidden per current UI enforcement.
- Direct action invocation must be tested; hidden buttons are not proof.
- Mutating actions must write audit entries where existing contracts require audit.
- Cancelled and forbidden actions must not write successful audit/evidence/OperationRun proof.
- Provider credentials, raw tokens, raw provider payloads, raw tenant data, and secrets must never appear in tests, logs, screenshots, or implementation reports.
## OperationRun / Evidence / Result Truth Implications
The implementation must distinguish:
- **Execution truth**: `OperationRun` status/outcome/summary/failure/audit trail.
- **Artifact truth**: evidence snapshots, stored report/review artifacts where already linked.
- **Backup/snapshot truth**: backup sets/items/schedules and immutable captured payload truth.
- **Recovery/evidence truth**: restore preview/readiness/result, stale/failed/partial proof, provider prerequisites.
- **Operator next action**: the single safe action or blocked/deferred state shown to the operator.
No product surface may collapse these truths into one false success state.
## Constitution Check
- Inventory-first: PASS. Existing inventory/backup/provider/restore truth remains authoritative.
- Read/write separation: PASS planned. Restore/backup/provider mutations require preview/dry-run where existing, confirmation, audit, and tests.
- Graph contract path: PASS planned. No new Graph calls; existing calls remain behind current abstractions.
- Deterministic capabilities: PASS planned. Use existing capability registry/policies; no raw role checks.
- RBAC-UX: PASS planned. Direct invocation tests cover 404/403 boundaries and server-side authorization.
- Workspace isolation: PASS planned. Tests must prove workspace/environment scope.
- Tenant isolation: PASS planned. No cross-tenant leakage or ID shortcuts.
- Run observability: PASS planned. Existing long-running/high-impact operations use/reuse OperationRun; no new local run UX.
- OperationRun start UX: PASS planned. Existing shared paths reused.
- Ops-UX 3-surface feedback: PASS planned. No new queued DB notification or local terminal notification.
- Data minimization: PASS planned. No secrets/raw provider payloads in output.
- Test governance: PASS planned. Confidence + browser lanes are explicit and bounded.
- Proportionality: PASS. Proof map/tests/minimal hardening are narrower than a framework.
- No premature abstraction: PASS. No new runtime abstraction planned.
- Persisted truth: PASS. No new persistence planned.
- Behavioral state: PASS. Existing states/vocabulary only.
- UI semantics: PASS. Use Product Surface vocabulary and existing shared badge/status paths.
- Shared pattern first: PASS. Existing shared paths are named and preferred.
- Provider boundary: PASS. Provider-specific semantics remain provider-owned.
- V1 explicitness / few layers: PASS. Direct tests and local hardening only.
- Spec discipline / bloat check: PASS. One coherent proof-pack spec instead of many micro-specs.
- Filament-native UI: PASS planned. Native Filament/shared primitives first.
- UI/Productization coverage: PASS planned. Existing surfaces only; coverage updates only if material classification drift appears.
- Product Surface Contract Gate: PASS planned. Spec/plan/tasks name surfaces, browser proof, human sanity, destructive/high-impact actions, deployment impact, and no completed-spec rewrite assertion.
## Test Governance Check
- **Test purpose / classification by changed surface**: Feature/Filament for action/authorization/state/audit proof; Browser for focused rendered workflow proof; Unit only for derived state helpers if touched.
- **Affected validation lanes**: confidence + browser; fast-feedback for unit-only changes; PostgreSQL only if database-specific behavior changes unexpectedly.
- **Why this lane mix is the narrowest sufficient proof**: Direct action behavior and side effects require Feature/Filament tests. Rendered confirmation/status behavior needs focused Browser smoke. Broad heavy-governance is not needed for a bounded proof pack.
- **Narrowest proving command(s)**:
- `cd apps/platform && ./vendor/bin/sail artisan test tests/Feature/Filament/Spec401HighRiskAdminActionProofPackTest.php tests/Feature/Operations/Spec401HighRiskAdminActionProofPackTest.php tests/Feature/ProviderConnections/Spec401HighRiskAdminActionProofPackTest.php tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php --compact`
- `cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php --compact`
- `cd apps/platform && ./vendor/bin/sail pint --dirty`
- `git diff --check`
- **Fixture / helper / factory / seed / context cost risks**: use existing explicit workspace/environment/provider/backup/restore fixtures; do not widen default setup.
- **Expensive defaults or shared helper growth introduced?**: no planned; any helper must be opt-in.
- **Heavy-family additions, promotions, or visibility changes**: one named focused browser smoke only.
- **Surface-class relief / special coverage rule**: dangerous-workflow wizard and shared-detail-family for restore; standard-native-filament for ordinary lists/actions; monitoring-state-page where OperationRun proof is touched.
- **Closing validation and reviewer handoff**: reviewers verify proof map completeness, task coverage, test commands/results, browser proof, no secrets/screenshots leak, Product Surface close-out, and no completed-spec rewrites.
- **Budget / baseline / trend follow-up**: none expected; document-in-feature if browser fixture cost grows.
- **Review-stop questions**: Did implementation add a new surface/status/persistence? Did cancelled/forbidden actions avoid success artifacts? Did direct invocation get tested? Did browser proof stay focused? Did raw detail remain demoted?
- **Escalation path**: document-in-feature for contained proof gaps; follow-up-spec for structural missing product contracts; reject-or-split for broad redesign.
- **Active feature PR close-out entry**: Guardrail / Exception / Smoke Coverage.
- **Why no dedicated follow-up spec is needed now**: this spec is the bounded proof pack. Follow-ups are created only for confirmed out-of-scope defects or product-decision gaps.
## Project Structure
### Spec Package
```text
specs/401-high-risk-admin-action-proof-pack/
├── spec.md
├── plan.md
├── tasks.md
├── checklists/
│ └── requirements.md
└── implementation-report.md # created during implementation close-out if file output is used
```
### Source Code
```text
apps/platform/app/
├── Filament/
├── Jobs/
├── Models/
├── Policies/
├── Services/
└── Support/
apps/platform/resources/views/
└── filament/
apps/platform/tests/
├── Feature/
├── Unit/
└── Browser/
```
**Structure Decision**: Use existing Laravel/Filament monolith structure. Do not create new base folders. New tests should live in existing test families with Spec 401 naming.
## Complexity Tracking
No constitution violation is planned.
| Potential Complexity | Decision | Simpler Alternative |
|---|---|---|
| Cross-domain proof map | Allowed as spec-local review evidence | One-off local notes would not cover all high-risk domains consistently |
| Focused browser smoke | Allowed because rendered high-risk flows are in scope | Feature tests alone cannot prove browser/Livewire/Filament runtime behavior |
| Minimal runtime hardening | Allowed only after failing/missing proof confirms an in-scope defect | Broad refactor or framework explicitly rejected |
## Implementation Phases
1. Safety, inventory, and proof map.
2. Restore tests and minimal hardening.
3. Backup tests and minimal hardening.
4. Provider tests and minimal hardening.
5. Cross-domain browser proof.
6. Implementation report and validation.
## Stop Conditions
Stop and update spec/plan before continuing if:
- implementation requires a new persisted entity/table/artifact;
- implementation requires a new enum/status/reason family;
- implementation requires a new route/page/navigation group/panel;
- implementation requires a broad restore, backup, provider, OperationRun, or Product Surface framework;
- a required state lacks a product contract and cannot be safely derived from repo truth;
- unrelated dirty state appears;
- browser/test fixture work expands into a broad audit;
- any completed spec would need to be rewritten to make the proof pass.
## Rollout / Deployment Considerations
- **Staging**: run focused tests and browser smoke before staging validation if runtime code changes.
- **Production**: no special production rollout expected. If existing high-impact action behavior changes, release notes should call out safer confirmation/authorization/state handling.
- **Migrations**: none expected.
- **Env vars**: none expected.
- **Queues**: existing queue workers only; no new queue class expected unless minimal hardening touches existing jobs.
- **Scheduler**: no change expected.
- **Storage**: no change expected.
- **Assets**: no new assets; `filament:assets` unchanged.
## Risk Controls
- Tests before fixes wherever feasible.
- Direct invocation tests, not only hidden/disabled UI assertions.
- Separate execution truth from backup/artifact/evidence truth.
- Treat missing product contract as finding, not implementation invitation.
- Keep browser proof focused and evidence-backed.
- Preserve historical spec close-out and validation history.

471
specs/401-high-risk-admin-action-proof-pack/spec.md Normal file
View File

@ -0,0 +1,471 @@
# Feature Specification: Spec 401 - High-risk Admin Action Proof Pack
**Feature Branch**: `401-high-risk-admin-action-proof-pack`
**Created**: 2026-06-22
**Status**: Draft / Ready for implementation preparation review
**Type**: Targeted hardening / proof / regression spec
**Runtime posture**: Existing-surface proof and minimal hardening only. No new product surfaces, no new product concepts, no broad restore, backup, or provider redesign.
**Input**: User-provided Spec 401 draft from the Codex attachment, current repo truth, Product Surface Contract, Spec 400 product-contract audit context, roadmap/spec-candidate queue, and related Specs 333, 335, 364, 390, 394, and 395-400.
## Candidate Selection Context
- **Selected candidate**: High-risk Admin Action Proof Pack.
- **Source location**: Direct user-provided Spec 401 draft attached to this request.
- **Why selected**: `docs/product/spec-candidates.md` currently reports no safe automatic next-best-prep target, but the operator supplied a direct manual candidate. The candidate follows the Spec 400 conclusion described in the draft: before broader runtime/browser audits or larger customer-facing claims, TenantPilot needs concrete proof that existing high-risk admin actions behave safely in failure, conflict, stale, partial, blocked, unauthorized, and confirmation/cancel states.
- **Roadmap relationship**: Supports the current productization and moat priorities by reducing operational and trust risk in restore, backup, and provider setup/detail flows before broader sellability or runtime-audit work proceeds.
- **Close alternatives deferred**:
- Management Report PDF staging validation remains manual follow-through for Specs 378-380 and is unrelated to high-risk admin action proof.
- Governance artifact lifecycle/retention runtime is broader product runtime work and not a proof pack for current admin actions.
- Provider readiness onboarding productization is optional productization work; this spec proves and minimally hardens existing provider setup/detail behavior first.
- Cross-domain indicator runtime follow-through is a broader semantic adoption lane, not a targeted confirmation/RBAC/audit proof package.
- Reopening Specs 333, 335, 364, 390, 394, or 395-400 is forbidden. They are read-only context and dependency evidence.
- **Completed-spec guardrail result**:
- No `specs/401-high-risk-admin-action-proof-pack/` package or `401-high-risk-admin-action-proof-pack` branch existed before this preparation.
- Specs 333, 335, 364, 390, 394, 395, 396, 397, 398, 399, and 400 are related context only. Any close-out notes, validation results, completed task markers, browser proof, smoke history, and implementation reports in completed or active historical packages must not be rewritten, normalized, unchecked, or removed.
- Existing restore/provider/backups specs prove important slices, but none replaces this cross-domain proof map for high-impact actions, direct invocation, confirmation cancel/accept, audit/evidence side effects, and focused browser proof across restore, backup, and provider setup/detail.
- **Smallest viable implementation slice**: Build a proof map for existing restore, backup, and provider flows; add or update focused Pest/Filament/Browser tests for missing proof; apply only minimal runtime hardening where tests reveal an in-scope defect; record states proven, deferred product-decision gaps, browser proof, and no-new-surface/no-completed-spec-rewrite evidence in a Spec 401 implementation report.
- **Feature description for Spec Kit**: Prove and minimally harden existing high-risk admin actions around restore, backup, and provider setup/detail flows so workspace/environment scoping, authorization, confirmation, cancellation, stale/blocked/partial/failed/conflict/expired states, audit/evidence side effects, and focused browser behavior are evidence-backed without adding new product surfaces or concepts.
## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
- **Problem**: TenantPilot has high-impact admin actions across restore, backup, and provider setup/detail flows, but current proof is spread across many specs, tests, and UI surfaces. Future agents may assume safety because pages exist, while direct invocation, cancellation, stale proof, partial outcomes, and audit/evidence side effects may not be fully proven for every critical path.
- **Today's failure**: A restore, backup, or provider setup action can appear safe from UI visibility or preview state alone, while unproven direct execution, missing confirmation, stale provider evidence, partial result handling, forbidden action behavior, or misleading audit/evidence creation remains possible.
- **User-visible improvement**: Operators and reviewers get evidence-backed confidence that high-risk actions either execute safely with audit/proof, stop honestly with clear state, or are explicitly marked as product-decision debt instead of being treated as implicitly safe.
- **Smallest enterprise-capable version**: One targeted proof pack over existing restore, backup, and provider setup/detail flows. Inventory current actions, map proof gaps, add focused tests and one bounded browser smoke, and make only minimal hardening fixes required to satisfy existing product contracts.
- **Explicit non-goals**: No new admin or customer surfaces, no new navigation, no restore architecture, no backup architecture, no provider onboarding redesign, no new status vocabulary, no JSON-to-JSONB work, no management PDF behavior, no governance lifecycle features, no broad UI redesign, no broad browser audit, no completed-spec rewrite.
- **Permanent complexity imported**: Focused tests, one browser smoke, a spec-local proof map/implementation report, and bounded fixes to existing action gates if confirmed. No new persisted truth, table, framework, enum/status family, provider integration, panel, or product vocabulary is expected.
- **Why now**: Spec 400 identified restore, backup, and provider setup as the highest-value bounded proof pack before broader runtime/UX audits. False confidence in these flows is higher risk than ordinary UI drift because the flows affect recovery, provider authority, and critical configuration evidence.
- **Why not local**: A local fix in one resource would not prove cancellation, forbidden direct invocation, stale/blocked state, audit/evidence side effects, and browser behavior across the high-risk action set. The proof must compare the three domains with the same safety criteria.
- **Approval class**: Core Enterprise.
- **Red flags triggered**: Multiple surfaces and proof categories. Defense: this is a narrow proof/hardening package, not a new framework; it uses existing surfaces, existing status vocabulary, existing capabilities, existing OperationRun/audit/evidence semantics, and focused tests.
- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 2 | **Gesamt: 12/12**
- **Decision**: approve as a bounded high-risk admin action proof pack.
## Problem Statement
TenantPilot manages critical Intune configuration. Restore execution, backup scheduling/runs, backup set actions, and provider setup/detail actions can affect recovery posture, provider authority, evidence truth, and auditability.
This spec answers:
```text
Can TenantPilot prove that existing high-risk admin actions behave safely and consistently across success, failure, stale, blocked, partial, expired, unauthorized, confirmation accepted, and confirmation cancelled states?
```
A flow is considered proven only when repo evidence exists: a focused test, browser proof, policy/action assertion, audit/evidence assertion, or a documented product-decision gap. Code that appears correct is not enough.
## Product / Business Value
The proof pack reduces false productization confidence in the highest-risk admin flows. It also gives implementation reviewers a compact evidence set before larger browser/UX/runtime audits, customer-facing claims, or broader productization work proceed.
## Primary Users / Operators
- Workspace owners/managers approving or supervising high-impact admin operations.
- Tenant/MSP operators running restore, backup, and provider setup workflows.
- Readonly or lower-capability users who must be blocked from mutation while still receiving safe read-only context where allowed.
- Engineering reviewers and future implementation agents validating high-risk action safety.
- Support/platform operators troubleshooting OperationRun, audit, provider, backup, or restore outcomes without raw-secret exposure.
## Spec Scope Fields *(mandatory)*
- **Scope**: Existing workspace/managed-environment admin surfaces for restore, backup, provider setup/detail, OperationRun proof, evidence/audit references, and focused browser verification.
- **Primary Routes / Surfaces**:
- Restore: existing RestoreRun list/create/view surfaces under `App\Filament\Resources\RestoreRunResource`.
- Backup schedules: existing BackupSchedule list/create/edit/action surfaces under `App\Filament\Resources\BackupScheduleResource`.
- Backup sets/items: existing BackupSet list/create/view and BackupItems relation surfaces under `App\Filament\Resources\BackupSetResource`.
- Provider setup/detail/readiness: existing ProviderConnection list/create/view/edit surfaces under `App\Filament\Resources\ProviderConnectionResource`, `App\Filament\Pages\EnvironmentRequiredPermissions`, and existing provider readiness/detail view entries.
- Operation/audit/evidence support: existing Monitoring Operations, OperationRun detail, Audit Log, Evidence Overview, and related resource links only where already shown by target flows.
- **Data Ownership**:
- `restore_runs` remain restore request/result truth.
- `backup_sets`, `backup_items`, and `backup_schedules` remain backup truth.
- `provider_connections`, `provider_credentials`, and `managed_environment_permissions` remain provider/readiness/permission evidence truth.
- `operation_runs` remain execution truth.
- `audit_logs` remain audit trail truth.
- `evidence_snapshots` and existing linked artifacts remain evidence truth when already repo-backed.
- No new persisted entity/table/artifact is expected by default. A spec-local proof map or implementation report is allowed as review evidence.
- **RBAC**:
- Workspace membership and managed-environment entitlement remain mandatory.
- Non-member or wrong-scope access remains deny-as-not-found.
- Member missing action capability remains 403 server-side and disabled/hidden per existing UI enforcement.
- UI visibility is not authorization. Every high-risk action must be proven through direct invocation/action tests where feasible.
For canonical-view or mixed-scope surfaces:
- **Default filter behavior when environment-context is active**: Existing workspace/environment route context and page filters remain authoritative. Proof must verify target records belong to the active workspace/environment and do not fall back to unsafe session/global context.
- **Explicit entitlement checks preventing cross-tenant leakage**: Direct action execution, related OperationRun/evidence/audit links, global search posture, and scoped record resolution must not expose or mutate records outside the actor's entitled workspace/environment.
## No Legacy / No Backward Compatibility Constraint *(mandatory)*
TenantPilot is pre-production for this spec. Clean current contract behavior is preferred over compatibility with old labels, legacy fixtures, or hidden fallback behavior.
- **Compatibility posture**: clean proof and minimal hardening over existing canonical behavior.
- **Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?**: no new compatibility path is allowed by default.
- **Why clean replacement is safe now**: The spec targets current high-risk action safety before production. If implementation discovers an existing legacy path that remains reachable, the path must be fixed or explicitly reported as out-of-scope product-decision debt; do not preserve it silently.
## UI Surface Impact *(mandatory - UI-COV-001)*
Does this spec add, remove, rename, or materially change any reachable UI surface?
- [ ] No UI surface impact
- [x] Existing page changed
- [ ] New page/route added
- [ ] Navigation changed
- [ ] Filament panel/provider surface changed
- [ ] New modal/drawer/wizard/action added
- [ ] New table/form/state added
- [ ] Customer-facing surface changed
- [x] Dangerous action changed
- [x] Status/evidence/review presentation changed
- [x] Workspace/environment context presentation changed
This spec does not intentionally add surfaces. Existing pages/actions/status presentations may be changed only where proof gaps require minimal hardening of current behavior.
## UI/Productization Coverage
- **Route/page/surface**:
- RestoreRun create wizard and view/detail proof surfaces.
- BackupSchedule list/create/edit/run action surfaces.
- BackupSet list/create/view and BackupItems relation manager action surfaces.
- ProviderConnection list/create/view/edit surfaces and EnvironmentRequiredPermissions provider-readiness surfaces.
- OperationRun, Audit Log, and Evidence links only where the target flows already expose them.
- **Current or new page archetype**:
- Restore create: Wizard Page.
- Restore detail / backup run detail / OperationRun detail: Receipt Page or Technical Annex depending on default-visible proof depth.
- Backup schedules/sets/provider connections lists: Search/Index Page.
- Provider setup/create: Settings or Wizard Page depending on current repo implementation.
- Required permissions/provider readiness: Settings Page / Decision sub-surface.
- **Design depth**: Domain Pattern Surface / Manual Review Required because the selected flows are high-risk admin action surfaces.
- **Repo-truth level**: repo-verified existing surfaces.
- **Existing pattern reused**: Filament resources/actions, `UiEnforcement` / `WorkspaceUiEnforcement`, policies/gates, OperationRun Start UX Contract, OperationRun links, BadgeCatalog/BadgeRenderer, Provider readiness resolver/guidance, Restore safety/readiness/resolution contracts, backup quality/health contracts, audit recorder patterns.
- **New pattern required**: none by default. If implementation needs a new shared pattern, stop and update this spec/plan first.
- **Screenshot required**: yes for focused browser proof of the highest-risk visible paths, stored or summarized in the implementation report.
- **Page audit required**: no broad page audit. Update UI coverage artifacts only if implementation materially changes reachable surface classification or discovers registry drift.
- **Customer-safe review required**: no new customer surface. Proof must still prevent customer-safe or operator-default views from showing raw technical proof as a calm success claim.
- **Dangerous-action review required**: yes; restore execution, backup run/retry or bulk backup mutations, provider credential/consent/setup changes, and destructive backup/restore/provider actions must be confirmation-, authorization-, and audit-safe.
- **Coverage files updated or explicitly not needed**:
- [ ] `docs/ui-ux-enterprise-audit/route-inventory.md`
- [ ] `docs/ui-ux-enterprise-audit/design-coverage-matrix.md`
- [ ] `docs/ui-ux-enterprise-audit/page-reports/...`
- [ ] `docs/ui-ux-enterprise-audit/strategic-surfaces.md`
- [ ] `docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md`
- [ ] `docs/ui-ux-enterprise-audit/unresolved-pages.md`
- [x] `N/A - no new reachable UI surface by default; existing surface coverage remains valid unless implementation discovers classification drift`
- **No-impact rationale when applicable**: N/A - existing high-risk surfaces may be materially hardened.
## Product Surface Impact *(mandatory)*
Reference: `docs/product/standards/product-surface-contract.md`.
- **Product Surface Contract applies?**: yes. The spec affects restore flows, provider state, backup actions, evidence/proof presentation, authorization, and high-impact actions.
- **Page archetype**: Existing surfaces keep their current archetypes; implementation must document each materially touched surface as Wizard, Receipt, Search/Index, Settings, Decision sub-surface, or Technical Annex.
- **Primary user question**: "Can I safely run or trust this high-risk admin action now?"
- **Primary action**: One existing next safe action per affected surface, such as `Run readiness checks`, `Regenerate preview`, `Confirm restore`, `Run backup`, `Review backup`, `Verify provider`, or `Resolve provider permissions`.
- **Surface budget result**: expected pass. Exceptions must be documented with page, violated rule, reason, and follow-up.
- **Technical Annex / deep-link demotion**: OperationRun links, raw evidence, raw provider payloads, source keys, fingerprints, detector/internal reason ownership, and technical logs must not be default product truth unless the surface is clearly technical/audit-facing.
- **Canonical status vocabulary**: Product-facing states must map to `Ready`, `Needs attention`, `Blocked`, `Running`, `Failed`, `Expired`, `Not configured`, `Unknown`, `Historical`, `Superseded`, and canonical severity labels. Existing internal/domain states may remain technical detail but must not become new product vocabulary.
- **Visible complexity impact**: neutral or decreased. Minimal hardening must not make the product louder or more ambiguous.
- **Product Surface exceptions**: none planned. Any discovered exception must be documented in the implementation report and treated as follow-up if it exceeds scope.
## Browser Verification Plan *(mandatory)*
- **Browser proof required?**: yes for implementation because existing rendered high-risk flows are in scope.
- **No-browser rationale**: N/A.
- **Focused path when required**:
- Restore preview/readiness path, including a blocked or stale/expired state and confirmation/cancel guard where feasible.
- Backup schedule or backup set high-impact action path, including blocked/missing provider or failed/partial run state where feasible.
- Provider setup/detail/readiness path, including stale/missing-permission/failed provider state.
- One unauthorized or capability-denied path for a high-impact action.
- **Primary interaction to execute**: open existing pages, inspect visible state, invoke or mount confirmation where safe, cancel/accept via test/browser layer where feasible, and verify no Livewire/Filament runtime errors.
- **Console, Livewire, Filament, network, and 500-error checks**: required in focused browser proof.
- **Full-suite failure triage**: unrelated browser-suite failures may be documented only when focused affected proof is green and no touched surface fails.
## Human Product Sanity Check *(mandatory)*
- **Required?**: yes for implementation close-out.
- **No-human-sanity rationale**: N/A.
- **Reviewer questions**: Does each touched flow clearly state purpose, one dominant next action, canonical status, demoted technical detail, and honest proof limits? Does cancellation/forbidden behavior avoid false audit/evidence? Would an operator trust the flow without assuming unproven safety?
- **Planned result location**: `specs/401-high-risk-admin-action-proof-pack/implementation-report.md` or final implementation response if no report file is created.
## Product Surface Merge Gate Checklist *(mandatory)*
- [x] No-legacy posture or approved exception recorded.
- [x] Product Surface Impact is completed for existing high-risk surfaces.
- [x] Browser proof is required for rendered high-risk flows during implementation.
- [x] Human Product Sanity is required for implementation close-out.
- [x] Product Surface exceptions are `none` unless implementation documents a bounded exception.
- [x] Implementation report must state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.
## Cross-Cutting / Shared Pattern Reuse *(mandatory)*
- **Cross-cutting feature?**: yes.
- **Interaction class(es)**: destructive/high-impact actions, confirmation modals, disabled/hidden UI enforcement, status messaging, OperationRun links, audit/evidence links, provider readiness, restore readiness, backup quality/health, notifications, browser proof.
- **Systems touched**: existing restore, backup, provider, OperationRun, audit, evidence, and Filament action systems.
- **Existing pattern(s) to extend**: `UiEnforcement` / `WorkspaceUiEnforcement`, policies/gates, `OperationRunService`, OperationRun Start UX Contract, `OperationRunLinks`, provider readiness/guidance paths, restore safety/readiness paths, backup quality/health paths, `AuditRecorder` / workspace audit logging, BadgeCatalog/BadgeRenderer.
- **Shared contract / presenter / builder / renderer to reuse**: exact class selection must follow repo inventory, but implementation must reuse existing shared paths before adding local logic.
- **Why the existing shared path is sufficient or insufficient**: Existing shared paths are sufficient by default. The proof pack should expose any gaps through tests first; new shared infrastructure is out of scope unless an existing pattern cannot safely enforce action confirmation, authorization, audit, or proof truth.
- **Allowed deviation and why**: none planned. A bounded exception may be recorded only if a current flow cannot use the shared path and the deviation is smaller than changing the shared contract.
- **Consistency impact**: restore, backup, provider, OperationRun, audit, evidence, notifications, and visible state labels must not create parallel safety language.
- **Review focus**: no hidden local authorization, no destructive URL-only actions, no false success proof, no audit/evidence on cancelled/forbidden paths, no completed-spec rewrites.
## OperationRun UX Impact *(mandatory)*
- **Touches OperationRun start/completion/link UX?**: yes, where existing restore/backup/provider actions create, queue, block, complete, reconcile, or link `OperationRun`.
- **Shared OperationRun UX contract/layer reused**: existing OperationRun Start UX Contract, `OperationUxPresenter`, `OperationRunLinks`, `OperationRunService`, and `OperationRunCompleted` terminal notification path where relevant.
- **Delegated start/completion UX behaviors**: queued toast, run link, artifact link, run-enqueued browser event, dedupe/blocked/start-failure messaging, tenant/workspace-safe URL resolution, terminal notifications, and summary count semantics remain delegated to existing shared paths.
- **Local surface-owned behavior that remains**: input collection, current action mount state, confirmation copy, and domain-specific proof display only.
- **Queued DB-notification policy**: no new queued DB notification policy. Keep existing explicit opt-in rules.
- **Terminal notification path**: central lifecycle mechanism only.
- **Exception required?**: none planned.
## Provider Boundary / Platform Core Check *(mandatory)*
- **Shared provider/platform boundary touched?**: yes, by proof and minimal hardening over provider setup/detail/readiness and provider-backed restore/backup blockers.
- **Boundary classification**: mixed.
- **Seams affected**: provider connection identity/scope, provider verification/freshness, managed-environment required permissions, provider-backed restore/backup prerequisites, provider-specific error/readiness proof, OperationRun context, audit metadata.
- **Neutral platform terms preserved or introduced**: workspace, managed environment, provider, connection, operation, execution truth, artifact truth, backup truth, evidence truth, audit trail, readiness, blocked, failed, expired.
- **Provider-specific semantics retained and why**: Microsoft/Intune and Entra terms remain provider-owned where current runtime is explicitly Microsoft-backed. They must not become new platform-core vocabulary in this spec.
- **Why this does not deepen provider coupling accidentally**: The spec proves existing Microsoft/provider-backed flows and does not add provider families, provider registries, Graph contracts, or platform-wide provider abstractions.
- **Follow-up path**: `follow-up-spec` only if proof discovers structural provider-boundary ambiguity that cannot be fixed as minimal hardening.
## UI / Surface Guardrail Impact *(mandatory)*
| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|---|---|---|---|---|---|---|
| Restore preview/readiness/create wizard | yes, if proof gap requires hardening | Mixed Filament wizard plus existing custom Blade/presenter paths | restore readiness, dangerous confirmation, OperationRun/evidence links | page, wizard, modal, detail | no planned | Existing high-risk workflow only |
| Restore run detail/result proof | yes, if result state proof changes | Filament/Infolist plus existing restore detail presenter | receipt/proof/evidence links | detail | no planned | No new route |
| Backup schedule list/create/edit/run | yes, if action proof changes | Native Filament resource/actions | backup OperationRun start UX, audit, confirmation | table, form, action modal | no planned | Existing resource only |
| Backup set list/view/items relation | yes, if action proof changes | Native Filament resource/relation manager | backup quality, backup item operations, restore linkage | table, detail, relation manager | no planned | Existing resource only |
| Provider connection create/view/edit/list | yes, if action proof changes | Native Filament resource plus provider guidance | provider readiness, required permissions, credential/consent audit | form, detail, table, action modal | no planned | Existing resource only |
| Required permissions / provider readiness | yes, if state proof changes | Filament page/view models | provider readiness/status messaging | page, detail | no planned | Existing page only |
## Decision-First Surface Role *(mandatory)*
| Surface | Decision Role | Human-in-the-loop Moment | Immediately Visible for First Decision | On-Demand Detail / Evidence | Why This Is Primary or Why Not | Workflow Alignment | Attention-load Reduction |
|---|---|---|---|---|---|---|---|
| Restore preview/readiness | Primary Decision Surface | Decide whether restore can advance safely | readiness status, blocker/reason, next safe action, confirmation requirement | raw preview payload, mapping internals, OperationRun/evidence links where authorized | Primary because restore can mutate provider configuration | follows backup source -> checks -> preview -> confirmation | removes guessing from stale/blocked states |
| Restore result/detail | Receipt Page / Secondary Context | Decide whether outcome can be trusted | result, partial/failed state, proof/evidence availability, next inspection action | diagnostics, raw item payloads, audit trail | Secondary because it verifies what happened | follows post-execution proof review | separates execution from recovery proof |
| Backup schedules/sets | Search/Index or Receipt Page | Decide whether backup basis can be created, trusted, retried, or inspected | state, reason, next backup action, provider/environment blocker | raw items, OperationRun detail, audit trail | Primary only for backup management task | follows backup basis and recovery-readiness workflow | makes missing/failed/partial backup states explicit |
| Provider setup/detail/readiness | Settings / Decision sub-surface | Decide whether provider is configured enough for downstream actions | provider state, permission/freshness blocker, next provider action | raw provider payload, credential internals, technical verification detail | Primary for setup/readiness task, secondary for diagnostics | follows setup -> verify -> resolve permissions | prevents false Ready/Healthy assumptions |
## Audience-Aware Disclosure *(mandatory)*
| Surface | Audience Modes In Scope | Decision-First Default-Visible Content | Operator Diagnostics | Support / Raw Evidence | One Dominant Next Action | Hidden / Gated By Default | Duplicate-Truth Prevention |
|---|---|---|---|---|---|---|---|
| Restore preview/readiness | operator-MSP, support-platform | readiness, blocker, impact, confirmation state | preview basis, checks, mapping summary | raw payloads, raw diffs, internal IDs | next safe restore preparation action | raw proof and provider internals | restore readiness owns top status once |
| Backup schedules/sets | operator-MSP, support-platform | backup state, run state, reason, next action | item counts, run history, failure reason | raw backup payloads, technical OperationRun context | run/review backup action | internal evidence and raw snapshot payload | backup truth separate from recovery proof |
| Provider setup/detail | operator-MSP, support-platform | connection/readiness/freshness/permission state | required permission rows, verification reports | credentials, raw provider errors, source keys | verify/resolve provider action | credentials and raw provider data | provider readiness resolver/contract owns top status |
## UI/UX Surface Classification *(mandatory)*
| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type / Justification |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RestoreRun create | Workflow / Wizard / Dangerous Action | Environment-bound restore workflow | run checks, regenerate preview, confirm restore | wizard step progression | N/A | diagnostics/proof panels | final confirmation step only | RestoreRuns list | RestoreRun detail | workspace + environment | Restore run | readiness, proof basis, blockers, confirmation | none |
| RestoreRun detail | Receipt / Technical Annex | Result/proof detail | inspect proof or resolve failed/partial outcome | detail page | N/A | technical/audit links secondary | none unless existing actions already present | RestoreRuns list | RestoreRun detail | workspace + environment | Restore run | execution outcome and evidence availability | none |
| BackupSchedule list/edit | List / Table / Settings | Scheduled backup management | run backup or inspect schedule | row click or existing inspect model | current repo pattern | More/action groups | More or confirmed action modal | BackupSchedules list | BackupSchedule edit/detail where present | workspace + environment | Backup schedule | schedule state, next run, last run/proof | none |
| BackupSet list/view | List / Table / Receipt | Backup basis review | inspect backup or manage items | row click or view page | current repo pattern | More/relation actions | More or confirmed action modal | BackupSets list | BackupSet view | workspace + environment | Backup set | backup quality/state/item proof | none |
| ProviderConnection list/view/edit | List / Settings / Decision | Provider setup/readiness | verify provider or resolve permissions | row click/view/edit per current repo | current repo pattern | More/detail header | confirmed action modal | ProviderConnections list | ProviderConnection view/edit | workspace + environment/provider | Provider connection | readiness/freshness/permission state | none |
## Operator Surface Contract *(mandatory)*
| Surface | Primary Persona | Decision / Operator Action Supported | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|---|---|---|---|---|---|---|---|---|---|---|
| Restore preview/readiness | Tenant/MSP operator | Decide whether restore can safely advance or execute | Dangerous workflow wizard | Is this restore safe to continue now? | readiness, blocker, impact, proof basis, one next action | raw preview, raw diffs, provider payloads, audit detail | readiness, execution, evidence, lifecycle | TenantPilot preview or Microsoft tenant mutation after confirmation | run checks, regenerate preview, confirm restore | execute restore |
| Backup schedules/sets | Tenant/MSP operator | Decide whether backup basis exists and can run/retry/inspect | Backup management/list/detail | Can I trust or run this backup path now? | backup state, provider/environment blocker, latest run outcome | raw backup payload, item internals, run logs | backup quality, operation outcome, lifecycle | TenantPilot backup capture and existing provider read paths | run/review backup, manage items | delete/force-delete/restore/archive/bulk actions where existing |
| Provider setup/detail | Tenant/MSP operator | Decide whether provider is ready enough for downstream operations | Settings/readiness detail | Is this provider configured and current enough? | connection/readiness/freshness/permission state, one next action | credentials, raw provider errors, technical verification | readiness, freshness, permission coverage, connection lifecycle | TenantPilot provider configuration and provider consent/verification | verify/resolve/setup provider | credential/consent/disable/delete/rotate actions where existing |
## Proportionality Review *(mandatory when structural complexity is introduced)*
- **New source of truth?**: no runtime source of truth. A proof map or implementation report is review evidence only.
- **New persisted entity/table/artifact?**: no application table/entity. Spec-local proof artifacts may be created during implementation.
- **New abstraction?**: no by default.
- **New enum/state/reason family?**: no. Existing canonical/product/domain states must be reused.
- **New cross-domain UI framework/taxonomy?**: no.
- **Current operator problem**: high-risk admin actions need concrete evidence that safety controls work across domains, not just local UI existence.
- **Existing structure is insufficient because**: proof is fragmented across specs/tests and not organized by high-risk state/action category.
- **Narrowest correct implementation**: proof map, focused tests/browser smoke, and minimal in-place hardening of existing action paths.
- **Ownership cost**: additional focused tests, browser smoke, and implementation-report maintenance for this high-risk package.
- **Alternative intentionally rejected**: a generic high-risk action framework, broad browser audit, provider onboarding redesign, restore architecture rewrite, or new status taxonomy.
- **Release truth**: current-release operational safety hardening.
### Compatibility posture
This feature assumes a pre-production environment. Backward compatibility, legacy aliases, fallback readers, hidden duplicate UI, and legacy fixtures are out of scope unless explicitly added to this spec after a blocker is discovered.
## Data / Truth Source Requirements
- Execution truth remains `OperationRun` for long-running/queued/high-impact operations.
- Restore request/result truth remains `RestoreRun` plus existing restore safety/result contracts.
- Backup truth remains `BackupSet`, `BackupItem`, `BackupSchedule`, associated jobs, and existing backup quality/health contracts.
- Provider readiness truth remains `ProviderConnection`, `ManagedEnvironmentPermission`, provider verification reports, and existing provider readiness/capability contracts.
- Audit truth remains `AuditLog` / audit services.
- Evidence truth remains existing evidence snapshots/artifacts where already linked.
- Product truth must distinguish execution truth, artifact truth, backup/snapshot truth, recovery/evidence truth, and operator next action.
## Functional Requirements
### Cross-domain Proof Requirements
- **FR-401-001**: Implementation MUST create or update a Spec 401 proof map covering target restore, backup, and provider flows before runtime edits begin.
- **FR-401-002**: The proof map MUST classify each target flow/state as `Fully proven`, `Proven except explicitly deferred state`, `Product contract missing`, `Implementation defect found and fixed`, or `Implementation defect found but out of scope`.
- **FR-401-003**: The proof map MUST record flow, state, existing proof, missing proof, fix needed, test needed, browser proof needed, and out-of-scope reason.
- **FR-401-004**: Implementation MUST add or update focused tests before runtime changes wherever feasible.
- **FR-401-005**: Implementation MUST not introduce new product status vocabulary, persisted truth, provider families, navigation, pages, panels, or broad UI frameworks.
- **FR-401-006**: Implementation MUST not change completed specs except to read them as context.
### Restore Flow Proof
- **FR-401-010**: Prove authorized users can view restore preview/readiness for scoped workspace/environment records.
- **FR-401-011**: Prove unauthorized users cannot view or execute restore actions by direct route or action invocation.
- **FR-401-012**: Prove missing required inputs produce a blocked state and do not allow execution.
- **FR-401-013**: Prove stale or expired preview/readiness data cannot execute as current.
- **FR-401-014**: Prove restore execution or equivalent high-impact restore action requires confirmation.
- **FR-401-015**: Prove cancellation does not execute restore and does not create successful OperationRun, audit, or evidence artifacts.
- **FR-401-016**: Prove confirmation acceptance executes only the intended scoped action and creates the expected audit/proof artifacts where the existing contract requires them.
- **FR-401-017**: Prove conflict, partial, and failed restore results are not represented as successful or safe.
- **FR-401-018**: Prove OperationRun/evidence links shown from restore surfaces are authorized and workspace/environment scoped.
- **FR-401-019**: If actual restore execution is simulated or preview-only for a state, the UI/tests MUST prove the current product contract says so honestly.
### Backup Flow Proof
- **FR-401-020**: Prove authorized users can view backup schedules, backup sets, backup items, and backup run/status/detail paths for scoped workspace/environment records.
- **FR-401-021**: Prove unauthorized users cannot view or execute backup actions by direct route or action invocation.
- **FR-401-022**: Prove backup create/run/retry/bulk actions require appropriate capability.
- **FR-401-023**: Prove any backup action that triggers a high-impact operation requires confirmation when the existing contract classifies it as high-impact or destructive-like; the proof map MUST list each touched backup action, its classification source, and whether confirmation is required.
- **FR-401-024**: Prove cancelled backup action does not create misleading OperationRun, audit, evidence, backup item, or success artifact.
- **FR-401-025**: Prove failed backup state is visible and not represented as successful.
- **FR-401-026**: Prove partial backup state is visible and not represented as complete.
- **FR-401-027**: Prove missing provider/environment context blocks backup action safely.
- **FR-401-028**: Prove stale provider data blocks or warns according to existing contract, and if no contract exists, records a product-decision gap.
- **FR-401-029**: Prove backup run/detail surfaces do not expose internal-only evidence in inappropriate default product surfaces.
### Provider Setup / Detail Proof
- **FR-401-030**: Prove authorized users can view provider setup/detail/readiness for scoped workspace/environment/provider records.
- **FR-401-031**: Prove unauthorized users cannot create, edit, verify, disable, inspect, or otherwise mutate provider setup/detail through direct invocation.
- **FR-401-032**: Prove missing-permission, stale/freshness, failed-connection, partial-permission, and unknown provider states use existing canonical vocabulary and do not imply readiness.
- **FR-401-033**: Prove provider detail does not expose raw source keys, credentials, raw provider payloads, or technical internals in default product paths.
- **FR-401-034**: Prove provider readiness/verification actions specifically cannot bypass authorization through direct request/action invocation, even when generic provider create/edit/disable authorization is already covered.
- **FR-401-035**: Prove provider readiness shown to operators is supported by evidence or clearly marked unavailable/unverified.
- **FR-401-036**: Prove provider-related OperationRun, audit, and evidence links remain scope-safe and authorized.
### Filament / Action / Global Search Requirements
- **FR-401-040**: Every destructive or high-impact Filament action touched by this spec MUST execute through `Action::make(...)->action(...)`, not URL-only execution.
- **FR-401-041**: Every destructive or high-impact Filament action touched by this spec MUST include `->requiresConfirmation()`, server-side authorization, audit behavior where mutating, and focused tests.
- **FR-401-042**: URL-only actions MUST remain navigation-only and must not be claimed as confirmation-protected.
- **FR-401-043**: Every globally searchable resource touched by this spec MUST either have a safe View/Edit page plus `$recordTitleAttribute` or global search disabled.
- **FR-401-044**: Table/list surfaces touched by this spec MUST keep meaningful empty states and action hierarchy.
## Non-Functional Requirements
- **NFR-401-001**: Proof and hardening MUST be deterministic and testable without external Microsoft Graph calls.
- **NFR-401-002**: Browser proof MUST be focused and not expand into a broad browser audit.
- **NFR-401-003**: Fixture/helper changes MUST stay explicit and cheap by default; no broad hidden provider/workspace/session defaults.
- **NFR-401-004**: Sensitive data, provider credentials, raw secrets, raw provider payloads, and raw tenant data MUST NOT appear in logs, audit metadata, screenshots, implementation reports, or browser artifacts.
- **NFR-401-005**: Runtime fixes MUST preserve existing route ownership and workspace/environment scoping.
- **NFR-401-006**: No new env vars, migrations, queues, scheduler entries, storage disks, assets, packages, or deployment steps are expected by default.
- **NFR-401-007**: Any implementation defect that requires a broader architecture or product decision MUST be documented as out of scope instead of silently expanded.
## Out Of Scope
- New admin surfaces, customer surfaces, navigation groups, routes, pages, panels, or widgets.
- Restore architecture rewrite, new restore execution engine, rollback system, or new restore operation family.
- Backup architecture rewrite, new scheduling product feature, or new backup retention/lifecycle system.
- Provider onboarding redesign, new provider families, provider abstraction framework, or OAuth redesign.
- New customer-facing proof/report output or management PDF behavior.
- Governance artifact lifecycle, resource-policy matrix, JSON-to-JSONB hardening, or full browser/UX/runtime audit.
- Broad copy cleanup, broad UI redesign, broad status-vocabulary cleanup, or unrelated Product Surface Contract migration.
- Completed spec artifact rewrites or removal of validation/browser/close-out history.
## User Scenarios & Testing *(mandatory)*
### User Story 1 - Restore high-risk actions are proven safe (Priority: P1)
As an authorized restore operator, I want restore preview/readiness/execution behavior to be proven across blocked, stale, partial, failed, unauthorized, and confirmation/cancel states, so that restore cannot be treated as safe by assumption.
**Independent Test**: Run focused restore Feature/Filament tests and focused browser path. The tests prove authorization, direct invocation denial, stale/blocked execution prevention, confirmation acceptance/cancellation behavior, and honest partial/failed result semantics.
**Acceptance Scenarios**:
1. **Given** a restore preview is stale or expired, **When** an operator attempts to execute or continue to final execution, **Then** the action is blocked or redirected to regenerate preview and no successful OperationRun/audit/evidence artifact is created.
2. **Given** a restore action confirmation is cancelled, **When** the page returns to the restore flow, **Then** no restore execution, success audit, success evidence, or misleading OperationRun is created.
3. **Given** a restore result is partial or failed, **When** the operator opens restore detail or Operations proof, **Then** the result is not displayed as completed/safe/recovery-verified.
### User Story 2 - Backup high-impact actions are proven safe (Priority: P1)
As an operator responsible for recovery basis, I want backup schedule, backup set, and backup run actions to prove authorization, provider/environment blockers, failed/partial states, and audit/proof side effects, so that backup health is not mistaken for recovery proof.
**Independent Test**: Run focused backup schedule/set Feature/Filament tests and one browser path that proves a high-impact backup action state, blocked state, or failed/partial state is visible and safe.
**Acceptance Scenarios**:
1. **Given** a user lacks backup run capability, **When** the user invokes a run/retry/create action directly, **Then** the server denies execution and no OperationRun/audit/success artifact is created.
2. **Given** provider or environment context is missing/stale, **When** a backup action is attempted, **Then** the action blocks or warns according to existing contract and does not create false backup success.
3. **Given** a backup run is failed or partial, **When** the operator opens backup run/detail or related OperationRun proof, **Then** the state is visible and not represented as complete.
### User Story 3 - Provider setup/detail actions are proven safe (Priority: P1)
As an operator configuring provider access, I want provider setup/detail/readiness actions to prove authorization, evidence-backed readiness, missing permissions, stale data, failed connection, partial permission, and raw-detail demotion, so downstream restore/backup readiness does not depend on false provider state.
**Independent Test**: Run focused provider Feature/Filament tests and browser proof that stale/missing-permission/failed provider state is visible, action-gated, and free from raw credentials/provider payloads in default views.
**Acceptance Scenarios**:
1. **Given** provider verification evidence is stale or permissions are missing, **When** the operator opens provider detail or required permissions, **Then** the surface shows an existing canonical non-ready state and one next safe action.
2. **Given** a user lacks provider management/run capability, **When** the user invokes setup/verify/edit/disable directly, **Then** the server denies execution and does not write misleading audit/evidence.
3. **Given** provider detail contains technical evidence, **When** the default product view renders, **Then** raw credentials, raw provider payloads, source keys, and internal technical details are hidden or gated.
### User Story 4 - Cross-flow proof report is complete and bounded (Priority: P2)
As an implementation reviewer, I want one proof map and close-out report that states what was proven, fixed, deferred, and browser-verified, so I can approve or stop the next implementation step without re-reading every related spec.
**Independent Test**: Inspect the Spec 401 implementation report and proof map. Every P0/P1 residual gap has concrete evidence, status, severity, and next action. No application implementation outside the selected scope is included.
**Acceptance Scenarios**:
1. **Given** implementation completes, **When** the reviewer opens the report, **Then** restore, backup, and provider domains each list states proven, tests added/updated, browser proof, fixes applied, deferred product decisions, and files changed.
2. **Given** a state cannot be safely proven because the product contract is missing, **When** the report is reviewed, **Then** the state is classified as product-decision debt rather than silently implemented.
3. **Given** implementation found an out-of-scope defect, **When** the report is reviewed, **Then** the defect cites repo evidence and a bounded follow-up recommendation.
## Edge Cases
- Confirmation modal is cancelled after state changed on the server or in another tab.
- Preview basis or provider verification becomes stale between mount and action execution.
- User loses capability/session context after opening a page but before action invocation.
- A record belongs to the correct workspace but wrong managed environment.
- OperationRun exists but links to a wrong-scope restore/backup/provider record.
- Backup run creates partial item results but aggregate counters are missing or misleading.
- Provider connection is disabled, failed, or stale while permission rows look granted.
- Browser proof fixture lacks a real execution path; implementation must record the limitation rather than overclaim proof.
- Existing product contract is silent about one required state; classify as product-decision gap.
## Success Criteria
- **SC-401-001**: Every target domain (restore, backup, provider) has a completed proof map row for each applicable high-risk state category or an explicit deferral reason.
- **SC-401-002**: Focused tests prove direct unauthorized invocation is blocked for at least one high-impact action in each target domain.
- **SC-401-003**: Focused tests prove confirmation accepted/cancelled behavior for restore and at least one backup or provider high-impact action where confirmation applies.
- **SC-401-004**: Focused tests prove no misleading success OperationRun/audit/evidence artifact is created for cancelled or forbidden actions where existing contracts define those artifacts.
- **SC-401-005**: Focused tests prove partial/failed/stale/blocked states are not rendered as `Ready`, successful, complete, or safe.
- **SC-401-006**: Focused browser proof covers restore, backup, provider, and one unauthorized/blocked path with no Livewire/Filament/runtime/500 errors on the tested paths.
- **SC-401-007**: Implementation report states no new surfaces, no new product concepts, no completed-spec rewrites, and all Product Surface close-out fields.
## Risks
- Browser fixture cost can grow if the spec attempts to prove every state visually. Mitigation: one focused browser path per domain plus Feature/Filament tests for matrix breadth.
- Restore/backup/provider contracts may be silent about a state. Mitigation: record product-decision debt and avoid inventing behavior.
- Existing tests may already prove parts of the matrix but under names that are hard to discover. Mitigation: inventory before edits and cite existing proof.
- High-risk actions may require minimal hardening across large Filament classes. Mitigation: keep fixes local and tests-first; stop if broad refactor is required.
- Confirmation-cancel behavior can be hard to prove in Livewire/Filament tests. Mitigation: prove "not called before confirmation" and browser modal behavior where feasible, documenting exact limitation.
## Assumptions
- Spec 400's attached conclusion is accepted as the direct product trigger for this manual candidate.
- Current route/surface names found in repo inspection are authoritative over the draft wording.
- Existing canonical status vocabulary from the Product Surface Contract governs visible product labels.
- Existing OperationRun, audit, evidence, provider readiness, restore safety, backup quality, and UI enforcement paths should be reused.
- No product owner decision is required before implementation unless proof discovers a missing product contract.
## Open Questions
None blocking preparation.
Implementation must stop and update this spec/plan if it discovers that a required proof state needs a new product concept, new persisted truth, new status family, new route/page, or broader architecture than minimal hardening.

171
specs/401-high-risk-admin-action-proof-pack/tasks.md Normal file
View File

@ -0,0 +1,171 @@
# Tasks: Spec 401 - High-risk Admin Action Proof Pack
**Input**: `specs/401-high-risk-admin-action-proof-pack/spec.md`, `plan.md`, `checklists/requirements.md`, user-provided Spec 401 draft, Product Surface Contract, related restore/backup/provider specs, and repo truth.
**Tests**: Required. This spec changes or verifies high-risk rendered/admin action behavior and must include focused Pest Feature/Filament tests plus focused Pest Browser smoke. Tests should be added before runtime hardening wherever feasible.
## Test Governance Checklist
- [x] Lane assignment is confidence + browser, with fast-feedback only for pure Unit helper tests.
- [x] New or changed tests stay in the smallest honest family; the single browser addition is explicitly named Spec 401.
- [x] Shared helpers, factories, seeds, fixtures, and workspace/provider/browser context setup stay cheap by default and opt-in.
- [x] Planned validation commands cover the selected high-risk action proof without pulling in a broad browser/runtime audit.
- [x] Surface test profiles are dangerous-workflow wizard, shared-detail-family, monitoring-state-page where needed, and standard-native-filament where enough.
- [x] Browser proof is required for rendered restore, backup, provider, and one unauthorized/blocked path.
- [x] Human Product Sanity and Product Surface implementation-report close-out are completed before implementation close-out.
- [x] Any material budget, fixture, or browser-lane escalation is recorded in `implementation-report.md`.
## Phase 1: Safety, Inventory, And Proof Map
**Purpose**: Establish current repo truth and map missing proof before runtime edits.
- [x] T001 Read `specs/401-high-risk-admin-action-proof-pack/spec.md`, `plan.md`, `tasks.md`, and `checklists/requirements.md`.
- [x] T002 Record current branch, HEAD, dirty state, and tracked/untracked files before implementation in `specs/401-high-risk-admin-action-proof-pack/implementation-report.md`.
- [x] T003 Inspect related historical/context specs 333, 335, 364, 390, 394, and 395-400 without modifying them.
- [x] T004 Inspect current restore, backup, provider, OperationRun, audit, evidence, RBAC, and browser test files named in `plan.md`.
- [x] T005 Confirm exact routes/actions/resources involved by reading Filament resources/pages and route definitions; do not invent route names from the draft.
- [x] T006 Create the Spec 401 proof map in `specs/401-high-risk-admin-action-proof-pack/implementation-report.md` or `proof-map.md` if the table is too large.
- [x] T007 Classify each target flow/state as `Fully proven`, `Proven except explicitly deferred state`, `Product contract missing`, `Implementation defect found and fixed`, or `Implementation defect found but out of scope`.
- [x] T008 Identify existing tests that already prove required states and cite them in the proof map before adding new tests.
- [x] T009 Confirm no new surface, navigation, panel, persisted truth, status family, provider family, or broad framework is required; stop and update spec/plan if this is false.
## Phase 2: Foundational Cross-domain Tests
**Purpose**: Add reusable proof structure without widening runtime architecture.
- [x] T010 [P] Add or update explicit test fixtures only where needed for Spec 401 states in existing factories/helpers; keep setup opt-in and record fixture cost in `implementation-report.md`.
- [x] T011 [P] Confirm shared OperationRun/evidence/audit link authorization coverage through existing OperationRun link helpers and related smoke/tests cited in `implementation-report.md`; no `apps/platform/tests/Feature/Operations/Spec401HighRiskAdminActionProofPackTest.php` file was created for this BackupSchedule-only hardening slice.
- [x] T012 [P] No-op after inventory: no shared Spec 401 assertion helpers were needed because the selected new tests stayed local to BackupSchedule confirmation/cancel proof.
- [x] T013 Verify touched globally searchable resources have safe View/Edit pages plus `$recordTitleAttribute` or disabled global search, and verify touched table/list surfaces keep meaningful empty states and action hierarchy; record result in `implementation-report.md`.
- [x] T014 Verify touched destructive/high-impact Filament actions are action-backed and not URL-only; record any defect before hardening.
## Phase 3: Restore Proof (P1)
**Goal**: Prove restore preview/readiness/execution safety across authorization, stale/blocked/partial/failed states, confirmation, cancellation, and audit/evidence behavior.
**Independent Test**: Run the existing focused restore Feature/Filament tests cited in the proof map plus the restore path in the Spec 401 browser smoke.
### Tests
- [x] T015 [P] [US1] Confirm missing-input and stale/expired restore preview execution-blocking proof through existing restore hardening tests cited in `implementation-report.md`; no new restore Spec 401 feature test file was created.
- [x] T016 [P] [US1] Confirm restore direct unauthorized invocation proof through existing `RestoreRunUiEnforcementTest` and execution reauthorization coverage cited in `implementation-report.md`.
- [x] T017 [P] [US1] Confirm restore confirmation/action behavior through existing restore action definitions and action tests cited in the proof map; no restore runtime hardening was needed in this slice.
- [x] T018 [P] [US1] Confirm restore audit/evidence negative proof through existing restore hardening and execution gate coverage where applicable; no new successful OperationRun/audit/evidence path was introduced.
- [x] T019 [P] [US1] Confirm restore partial/failed/conflict display proof through existing restore result/detail tests cited in the proof map; no restore display runtime change was made.
### Implementation
- [x] T020 [US1] No-op after inventory: no `RestoreRunResource` or restore page/action hardening was applied because no in-scope restore runtime defect was found.
- [x] T021 [US1] No-op after inventory: no restore presenter/view fragment hardening was applied because no misleading blocked/stale/partial/failed state was found in this slice.
- [x] T022 [US1] No-op after inventory: no restore OperationRun/evidence link hardening was applied because no unauthorized or wrong-scope link defect was found in this slice.
- [x] T023 [US1] Update the proof map with restore states proven, fixed, deferred, and out-of-scope.
## Phase 4: Backup Proof (P1)
**Goal**: Prove backup schedule/set/run actions across authorization, confirmation where applicable, provider/environment blockers, partial/failed states, and audit/proof side effects.
**Independent Test**: Run focused backup Spec 401 Feature/Filament tests plus backup path in the browser smoke.
### Tests
- [x] T024 [P] [US2] Confirm backup schedule run/retry direct authorization proof through existing `apps/platform/tests/Feature/BackupScheduling/RunNowRetryActionsTest.php`, `apps/platform/tests/Feature/RunStartAuthorizationTest.php`, and the Spec 401 proof map.
- [x] T025 [P] [US2] Add backup schedule action confirmation/cancel proof for `runNow`, `retry`, `restore`, `bulk_run_now`, and `bulk_retry` in `apps/platform/tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php`.
- [x] T026 [P] [US2] Confirm cancelled/forbidden side-effect proof for the selected BackupSchedule slice through `apps/platform/tests/Feature/BackupScheduling/Spec401HighRiskAdminActionProofPackTest.php`, `RunNowRetryActionsTest.php`, `BackupScheduleLifecycleTest.php`, and `BackupScheduleLifecycleAuthorizationTest.php`; backup item/evidence artifacts are N/A for the selected BackupSchedule-only runtime hardening.
- [x] T027 [P] [US2] Confirm environment-scope blocker proof for the selected BackupSchedule slice through existing lifecycle authorization tests and the Spec 401 browser cross-tenant denied path; broader provider-readiness blocker proof remains provider-domain evidence, not new BackupSchedule runtime work.
- [x] T028 [P] [US2] Confirm failed/partial backup state display remained existing evidence-backed behavior in the proof map; no BackupSchedule runtime display change was made in this slice.
- [x] T029 [P] [US2] Confirm BackupSet/items high-impact action proof was satisfied by existing `Spec371BackupSetProductizationTest`, `Spec371BackupSetProductizationSmokeTest`, and relation-manager RBAC tests; no new `apps/platform/tests/Feature/Filament/Spec401HighRiskAdminActionProofPackTest.php` file was created for this BackupSchedule-only hardening slice.
### Implementation
- [x] T030 [US2] Harden `apps/platform/app/Filament/Resources/BackupScheduleResource.php` and page/action classes only if tests reveal missing confirmation, authorization, or wrong side effects.
- [x] T031 [US2] No-op after inventory: no `BackupSetResource` or `BackupItemsRelationManager` hardening was applied because no high-impact action proof gap was found in the selected slice.
- [x] T032 [US2] No-op after inventory: no backup job/service hardening was applied because no misleading OperationRun/audit/proof state was found for this BackupSchedule confirmation slice.
- [x] T033 [US2] Update the proof map with backup states proven, fixed, deferred, and out-of-scope.
## Phase 5: Provider Setup / Detail Proof (P1)
**Goal**: Prove provider setup/detail/readiness actions across authorization, stale/missing permission/failed/partial states, raw-detail demotion, and audit/evidence/OperationRun scope safety.
**Independent Test**: Run existing provider Feature/Filament evidence cited in the proof map plus the provider path in the Spec 401 browser smoke; direct provider Spec 401 follow-up tests are deferred where listed below.
### Tests
- [ ] T034 [P] [US3] Deferred: provider create/edit/verify/readiness/disable direct invocation authorization needs a dedicated provider follow-up test file if this proof pack expands beyond the BackupSchedule hardening slice.
- [x] T035 [P] [US3] Confirm provider missing-permission/stale/failed/partial state display through existing Spec 394 provider freshness/permission smoke evidence and the Spec 401 browser stale-provider path; no `ProviderConnections/Spec401HighRiskAdminActionProofPackTest.php` file was created.
- [x] T036 [P] [US3] Confirm provider raw-detail demotion through existing provider/resource evidence cited in `implementation-report.md`; no new provider runtime or provider Spec 401 feature test was added in this slice.
- [ ] T037 [P] [US3] Deferred: provider audit/evidence negative tests for cancelled/forbidden actions remain follow-up because provider runtime was not changed and `ProviderConnectionsUiEnforcementTest.php` has an independent readonly visibility residual.
- [ ] T038 [P] [US3] Deferred: provider OperationRun/evidence/audit link scope tests remain follow-up for the same provider residual; this BackupSchedule hardening did not expose or alter provider proof links.
### Implementation
- [x] T039 [US3] No-op after inventory: no provider resource/page hardening was applied in this BackupSchedule slice; provider residual is recorded for follow-up.
- [x] T040 [US3] No-op after inventory: no required-permissions/readiness runtime hardening was applied in this BackupSchedule slice.
- [x] T041 [US3] No-op after inventory: no provider jobs/services/audit paths were changed in this BackupSchedule slice.
- [x] T042 [US3] Update the proof map with provider states proven, fixed, deferred, and out-of-scope.
## Phase 6: Browser Proof And Product Surface Close-out (P2)
**Goal**: Prove focused rendered behavior and complete review evidence without broad browser audit.
**Independent Test**: `apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php` passes and report records exact paths, states, and limitations.
- [x] T043 [P] [US4] Add focused browser smoke in `apps/platform/tests/Browser/Spec401HighRiskAdminActionProofPackSmokeTest.php` using existing authenticated workspace/environment browser harness patterns.
- [x] T044 [US4] Browser smoke covers restore preview/readiness critical state and confirmation/cancel or equivalent high-impact guard.
- [x] T045 [US4] Browser smoke covers backup create/view/detail or equivalent high-impact backup path.
- [x] T046 [US4] Browser smoke covers provider setup/detail readiness/freshness/permission state.
- [x] T047 [US4] Browser smoke covers one unauthorized, disabled, or blocked high-impact path.
- [x] T048 [US4] Browser smoke checks console/runtime/network/Livewire/Filament/500-error result and records unrelated full-suite failures only when focused proof is green.
- [x] T049 [US4] Complete Human Product Sanity result in `specs/401-high-risk-admin-action-proof-pack/implementation-report.md`.
- [x] T050 [US4] Record Product Surface close-out fields in `specs/401-high-risk-admin-action-proof-pack/implementation-report.md`.
## Phase 7: Final Validation And Report
**Purpose**: Prove the implementation is bounded, tested, and ready for review.
- [x] T051 Run focused Feature/Filament Spec 401 tests and record command/output summary in `implementation-report.md`.
- [x] T052 Run focused Spec 401 browser smoke and record command/output summary in `implementation-report.md`.
- [x] T053 Run affected existing restore, backup, provider, OperationRun, audit, or evidence tests identified by implementation and record command/output summary.
- [x] T054 Run `cd apps/platform && ./vendor/bin/sail pint --dirty` or justified equivalent formatting check.
- [x] T055 Run `git diff --check`.
- [x] T056 Record dirty state after implementation, tracked files changed, untracked files, and no completed-spec rewrite assertion.
- [x] T057 Record Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, deployment impact, tests, browser/no-browser, visible complexity outcome, and follow-up candidates.
- [x] T058 Confirm no migrations, env vars, queue/scheduler/storage/assets/panel provider changes, new routes/pages/navigation, new status vocabulary, new provider families, or broad runtime framework were introduced unless spec/plan were updated first.
## Dependencies And Execution Order
- Phase 1 must complete before any runtime edits.
- Phase 2 can run after proof map identifies shared gaps.
- Restore, Backup, and Provider phases may run in parallel after Phase 2 if they touch separate files.
- Browser proof waits for selected domain hardening and fixtures to stabilize.
- Final validation waits for all in-scope domain phases and browser proof.
## Parallel Execution Examples
After Phase 2:
```text
Agent A: T015-T023 restore proof and hardening.
Agent B: T024-T033 backup proof and hardening.
Agent C: T034-T042 provider proof and hardening.
```
Before merge:
```text
Run T043-T050 browser/product-surface close-out after domain changes settle.
Run T051-T058 final validation after all in-scope fixes are complete.
```
## Non-Goals Checklist
- [x] NT001 Do not add new admin/customer surfaces, routes, pages, panels, navigation, or widgets.
- [x] NT002 Do not introduce new persisted truth, migrations, status families, provider integrations, product concepts, or runtime frameworks.
- [x] NT003 Do not rewrite completed specs, remove validation evidence, normalize completed task markers, or strip close-out/browser/smoke history.
- [x] NT004 Do not perform a broad browser/UX/runtime audit.
- [x] NT005 Do not solve management-report PDF staging validation, governance artifact lifecycle, JSON-to-JSONB hardening, resource-policy matrix, or full provider onboarding productization.
- [x] NT006 Do not invent behavior where product contracts are silent; record product-decision debt.
- [x] NT007 Do not include secrets, raw provider payloads, raw tenant data, credentials, or sensitive IDs in screenshots, logs, audit metadata, or reports.
## Recommended Implementation Strategy
Start with proof, not fixes. Reuse existing tests and shared paths wherever possible. Make failing or missing proof explicit, harden only the exact defect, then record the proof evidence. Treat missing product decisions as reportable gaps instead of expanding this proof pack.