feat: align system operations surfaces (#201)
## Summary - align the system-panel Operations, Failed operations, and Stuck operations pages to the read-only registry contract by removing inline row triage and keeping row-click inspection - keep retry, cancel, and mark-investigated behavior on the canonical system operation detail page while adding the explicit `Show all operations` return path and updated `Operations / Operation` copy - add and update focused Pest and Livewire coverage for list CTA behavior, detail-owned triage, and view-only versus manage-capable platform access - add Spec 170 implementation artifacts plus the follow-on Spec 171 and Spec 172 packages ## Testing - `vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsTriageActionsTest.php` - `vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php` - `vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsFailuresViewTest.php` - `vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsStuckViewTest.php` - integrated browser smoke on `/system/ops/runs`, `/system/ops/failures`, `/system/ops/stuck`, empty states via search filter, and detail-page retry confirmation visibility ## Notes - branch pushed from `170-system-operations-surface-alignment` - latest commit: `64b4d741 feat: align system operations surfaces` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #201
This commit is contained in:
parent
37c6d0622c
commit
fdd3a85b64
4
.github/agents/copilot-instructions.md
vendored
4
.github/agents/copilot-instructions.md
vendored
@ -118,6 +118,8 @@ ## Active Technologies
|
||||
- PostgreSQL unchanged; no new persistence, cache store, or durable summary artifac (168-tenant-governance-aggregate-contract)
|
||||
- PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `ActionSurfaceDeclaration`, `ActionSurfaceValidator`, `ActionSurfaceDiscovery`, `ActionSurfaceExemptions`, and Filament Tables / Actions APIs (169-action-surface-v11)
|
||||
- PostgreSQL unchanged; no new persistence, cache store, queue payload, or durable artifac (169-action-surface-v11)
|
||||
- PHP 8.4, Laravel 12, Livewire v4, Filament v5 + `laravel/framework`, `filament/filament`, `livewire/livewire`, `pestphp/pest` (170-system-operations-surface-alignment)
|
||||
- PostgreSQL with existing `operation_runs` and `audit_logs` tables; no schema changes (170-system-operations-surface-alignment)
|
||||
|
||||
- PHP 8.4.15 (feat/005-bulk-operations)
|
||||
|
||||
@ -137,8 +139,8 @@ ## Code Style
|
||||
PHP 8.4.15: Follow standard conventions
|
||||
|
||||
## Recent Changes
|
||||
- 170-system-operations-surface-alignment: Added PHP 8.4, Laravel 12, Livewire v4, Filament v5 + `laravel/framework`, `filament/filament`, `livewire/livewire`, `pestphp/pest`
|
||||
- 169-action-surface-v11: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `ActionSurfaceDeclaration`, `ActionSurfaceValidator`, `ActionSurfaceDiscovery`, `ActionSurfaceExemptions`, and Filament Tables / Actions APIs
|
||||
- 168-tenant-governance-aggregate-contract: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `BaselineCompareStats`, `BaselineCompareSummaryAssessor`, `BaselineCompareLanding`, `BaselineCompareNow`, `NeedsAttention`, `BaselineCompareCoverageBanner`, and `RequestScopedDerivedStateStore` from Spec 167
|
||||
- 167-derived-state-memoization: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `ArtifactTruthPresenter`, `OperationUxPresenter`, `RelatedNavigationResolver`, `AppServiceProvider`, `BadgeCatalog`, `BadgeRenderer`, and current Filament resource/page seams
|
||||
<!-- MANUAL ADDITIONS START -->
|
||||
<!-- MANUAL ADDITIONS END -->
|
||||
|
||||
@ -6,14 +6,12 @@
|
||||
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
use App\Services\SystemConsole\OperationRunTriageService;
|
||||
use App\Support\Auth\PlatformCapabilities;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\OperationCatalog;
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\OpsUx\OperationUxPresenter;
|
||||
use App\Support\System\SystemOperationRunLinks;
|
||||
use App\Support\Ui\ActionSurface\ActionSurfaceDeclaration;
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceInspectAffordance;
|
||||
@ -21,8 +19,6 @@
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceSlot;
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceType;
|
||||
use Filament\Actions\Action;
|
||||
use Filament\Forms\Components\Textarea;
|
||||
use Filament\Notifications\Notification;
|
||||
use Filament\Pages\Page;
|
||||
use Filament\Tables\Columns\TextColumn;
|
||||
use Filament\Tables\Concerns\InteractsWithTable;
|
||||
@ -34,7 +30,9 @@ class Failures extends Page implements HasTable
|
||||
{
|
||||
use InteractsWithTable;
|
||||
|
||||
protected static ?string $navigationLabel = 'Failures';
|
||||
protected static ?string $navigationLabel = 'Failed operations';
|
||||
|
||||
protected static ?string $title = 'Failed operations';
|
||||
|
||||
protected static string|\BackedEnum|null $navigationIcon = 'heroicon-o-exclamation-triangle';
|
||||
|
||||
@ -47,10 +45,10 @@ class Failures extends Page implements HasTable
|
||||
public static function actionSurfaceDeclaration(): ActionSurfaceDeclaration
|
||||
{
|
||||
return ActionSurfaceDeclaration::forPage(ActionSurfaceProfile::RunLog, ActionSurfaceType::ReadOnlyRegistryReport)
|
||||
->exempt(ActionSurfaceSlot::ListHeader, 'System failures stay scan-first and rely on row triage rather than page header actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListHeader, 'The page header exposes Show all operations while row clicks remain the only inspect model.')
|
||||
->satisfy(ActionSurfaceSlot::InspectAffordance, ActionSurfaceInspectAffordance::ClickableRow->value)
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'Failed-run triage stays per run and intentionally omits bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when there are no failed runs to triage.')
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'Failed operations remain scan-first and intentionally omit bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when there are no failed operations and repeats the Show all operations CTA.')
|
||||
->exempt(ActionSurfaceSlot::DetailHeader, 'Row navigation opens the canonical system run detail page, which owns header actions.');
|
||||
}
|
||||
|
||||
@ -86,6 +84,18 @@ public function mount(): void
|
||||
$this->mountInteractsWithTable();
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array<Action>
|
||||
*/
|
||||
protected function getHeaderActions(): array
|
||||
{
|
||||
return [
|
||||
Action::make('show_all_operations')
|
||||
->label('Show all operations')
|
||||
->url(SystemOperationRunLinks::index()),
|
||||
];
|
||||
}
|
||||
|
||||
public function table(Table $table): Table
|
||||
{
|
||||
return $table
|
||||
@ -99,7 +109,7 @@ public function table(Table $table): Table
|
||||
})
|
||||
->columns([
|
||||
TextColumn::make('id')
|
||||
->label('Run')
|
||||
->label('ID')
|
||||
->state(fn (OperationRun $record): string => '#'.$record->getKey()),
|
||||
TextColumn::make('status')
|
||||
->badge()
|
||||
@ -127,80 +137,15 @@ public function table(Table $table): Table
|
||||
TextColumn::make('created_at')->label('Started')->since(),
|
||||
])
|
||||
->recordUrl(fn (OperationRun $record): string => SystemOperationRunLinks::view($record))
|
||||
->actions([
|
||||
Action::make('retry')
|
||||
->label('Retry')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canRetry($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$retryRun = $triageService->retry($record, $user);
|
||||
|
||||
OperationUxPresenter::queuedToast((string) $retryRun->type)
|
||||
->actions([
|
||||
\Filament\Actions\Action::make('view_run')
|
||||
->label('View run')
|
||||
->url(SystemOperationRunLinks::view($retryRun)),
|
||||
->actions([])
|
||||
->emptyStateHeading('No failed operations found')
|
||||
->emptyStateDescription('Failed operations will appear here when a run completes unsuccessfully.')
|
||||
->emptyStateActions([
|
||||
Action::make('show_all_operations_empty')
|
||||
->label('Show all operations')
|
||||
->url(SystemOperationRunLinks::index())
|
||||
->button(),
|
||||
])
|
||||
->send();
|
||||
}),
|
||||
Action::make('cancel')
|
||||
->label('Cancel')
|
||||
->color('danger')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canCancel($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->cancel($record, $user);
|
||||
|
||||
Notification::make()
|
||||
->title('Run cancelled')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
Action::make('mark_investigated')
|
||||
->label('Mark investigated')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (): bool => $this->canManageOperations())
|
||||
->form([
|
||||
Textarea::make('reason')
|
||||
->label('Reason')
|
||||
->required()
|
||||
->minLength(5)
|
||||
->maxLength(500)
|
||||
->rows(4),
|
||||
])
|
||||
->action(function (OperationRun $record, array $data, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->markInvestigated($record, $user, (string) ($data['reason'] ?? ''));
|
||||
|
||||
Notification::make()
|
||||
->title('Run marked as investigated')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
])
|
||||
->emptyStateHeading('No failed runs found')
|
||||
->emptyStateDescription('Failed operations will appear here for triage.')
|
||||
->bulkActions([]);
|
||||
}
|
||||
|
||||
private function canManageOperations(): bool
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
return $user instanceof PlatformUser
|
||||
&& $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE);
|
||||
}
|
||||
|
||||
private function requireManageUser(): PlatformUser
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
if (! $user instanceof PlatformUser || ! $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE)) {
|
||||
abort(403);
|
||||
}
|
||||
|
||||
return $user;
|
||||
}
|
||||
}
|
||||
|
||||
@ -6,12 +6,10 @@
|
||||
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
use App\Services\SystemConsole\OperationRunTriageService;
|
||||
use App\Support\Auth\PlatformCapabilities;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\OperationCatalog;
|
||||
use App\Support\OpsUx\OperationUxPresenter;
|
||||
use App\Support\System\SystemOperationRunLinks;
|
||||
use App\Support\Ui\ActionSurface\ActionSurfaceDeclaration;
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceInspectAffordance;
|
||||
@ -19,8 +17,6 @@
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceSlot;
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceType;
|
||||
use Filament\Actions\Action;
|
||||
use Filament\Forms\Components\Textarea;
|
||||
use Filament\Notifications\Notification;
|
||||
use Filament\Pages\Page;
|
||||
use Filament\Tables\Columns\TextColumn;
|
||||
use Filament\Tables\Concerns\InteractsWithTable;
|
||||
@ -32,7 +28,9 @@ class Runs extends Page implements HasTable
|
||||
{
|
||||
use InteractsWithTable;
|
||||
|
||||
protected static ?string $navigationLabel = 'Runs';
|
||||
protected static ?string $navigationLabel = 'Operations';
|
||||
|
||||
protected static ?string $title = 'Operations';
|
||||
|
||||
protected static string|\BackedEnum|null $navigationIcon = 'heroicon-o-queue-list';
|
||||
|
||||
@ -45,10 +43,10 @@ class Runs extends Page implements HasTable
|
||||
public static function actionSurfaceDeclaration(): ActionSurfaceDeclaration
|
||||
{
|
||||
return ActionSurfaceDeclaration::forPage(ActionSurfaceProfile::RunLog, ActionSurfaceType::ReadOnlyRegistryReport)
|
||||
->exempt(ActionSurfaceSlot::ListHeader, 'System ops runs rely on inline row triage and do not expose page header actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListHeader, 'The page header exposes Go to runbooks while row clicks remain the only inspect model.')
|
||||
->satisfy(ActionSurfaceSlot::InspectAffordance, ActionSurfaceInspectAffordance::ClickableRow->value)
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'System ops triage stays per run and intentionally omits bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when no system runs have been queued yet.')
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'System operations remain scan-first and intentionally omit bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when no operations have been queued yet and repeats the Go to runbooks CTA.')
|
||||
->exempt(ActionSurfaceSlot::DetailHeader, 'Row navigation opens the canonical system run detail page, which owns header actions.');
|
||||
}
|
||||
|
||||
@ -69,6 +67,18 @@ public function mount(): void
|
||||
$this->mountInteractsWithTable();
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array<Action>
|
||||
*/
|
||||
protected function getHeaderActions(): array
|
||||
{
|
||||
return [
|
||||
Action::make('go_to_runbooks')
|
||||
->label('Go to runbooks')
|
||||
->url(Runbooks::getUrl(panel: 'system')),
|
||||
];
|
||||
}
|
||||
|
||||
public function table(Table $table): Table
|
||||
{
|
||||
return $table
|
||||
@ -80,7 +90,7 @@ public function table(Table $table): Table
|
||||
})
|
||||
->columns([
|
||||
TextColumn::make('id')
|
||||
->label('Run')
|
||||
->label('ID')
|
||||
->state(fn (OperationRun $record): string => '#'.$record->getKey()),
|
||||
TextColumn::make('status')
|
||||
->badge()
|
||||
@ -109,80 +119,15 @@ public function table(Table $table): Table
|
||||
TextColumn::make('created_at')->label('Started')->since(),
|
||||
])
|
||||
->recordUrl(fn (OperationRun $record): string => SystemOperationRunLinks::view($record))
|
||||
->actions([
|
||||
Action::make('retry')
|
||||
->label('Retry')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canRetry($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$retryRun = $triageService->retry($record, $user);
|
||||
|
||||
OperationUxPresenter::queuedToast((string) $retryRun->type)
|
||||
->actions([
|
||||
\Filament\Actions\Action::make('view_run')
|
||||
->label('View run')
|
||||
->url(SystemOperationRunLinks::view($retryRun)),
|
||||
->actions([])
|
||||
->emptyStateHeading('No operations yet')
|
||||
->emptyStateDescription('Operations from all workspaces will appear here when they are queued.')
|
||||
->emptyStateActions([
|
||||
Action::make('go_to_runbooks_empty')
|
||||
->label('Go to runbooks')
|
||||
->url(Runbooks::getUrl(panel: 'system'))
|
||||
->button(),
|
||||
])
|
||||
->send();
|
||||
}),
|
||||
Action::make('cancel')
|
||||
->label('Cancel')
|
||||
->color('danger')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canCancel($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->cancel($record, $user);
|
||||
|
||||
Notification::make()
|
||||
->title('Run cancelled')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
Action::make('mark_investigated')
|
||||
->label('Mark investigated')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (): bool => $this->canManageOperations())
|
||||
->form([
|
||||
Textarea::make('reason')
|
||||
->label('Reason')
|
||||
->required()
|
||||
->minLength(5)
|
||||
->maxLength(500)
|
||||
->rows(4),
|
||||
])
|
||||
->action(function (OperationRun $record, array $data, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->markInvestigated($record, $user, (string) ($data['reason'] ?? ''));
|
||||
|
||||
Notification::make()
|
||||
->title('Run marked as investigated')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
])
|
||||
->emptyStateHeading('No operation runs yet')
|
||||
->emptyStateDescription('Runs from all workspaces will appear here when operations are queued.')
|
||||
->bulkActions([]);
|
||||
}
|
||||
|
||||
private function canManageOperations(): bool
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
return $user instanceof PlatformUser
|
||||
&& $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE);
|
||||
}
|
||||
|
||||
private function requireManageUser(): PlatformUser
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
if (! $user instanceof PlatformUser || ! $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE)) {
|
||||
abort(403);
|
||||
}
|
||||
|
||||
return $user;
|
||||
}
|
||||
}
|
||||
|
||||
@ -6,13 +6,11 @@
|
||||
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
use App\Services\SystemConsole\OperationRunTriageService;
|
||||
use App\Support\Auth\PlatformCapabilities;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
use App\Support\Badges\BadgeRenderer;
|
||||
use App\Support\OperationCatalog;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\OpsUx\OperationUxPresenter;
|
||||
use App\Support\System\SystemOperationRunLinks;
|
||||
use App\Support\SystemConsole\StuckRunClassifier;
|
||||
use App\Support\Ui\ActionSurface\ActionSurfaceDeclaration;
|
||||
@ -21,8 +19,6 @@
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceSlot;
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceType;
|
||||
use Filament\Actions\Action;
|
||||
use Filament\Forms\Components\Textarea;
|
||||
use Filament\Notifications\Notification;
|
||||
use Filament\Pages\Page;
|
||||
use Filament\Tables\Columns\TextColumn;
|
||||
use Filament\Tables\Concerns\InteractsWithTable;
|
||||
@ -34,7 +30,9 @@ class Stuck extends Page implements HasTable
|
||||
{
|
||||
use InteractsWithTable;
|
||||
|
||||
protected static ?string $navigationLabel = 'Stuck';
|
||||
protected static ?string $navigationLabel = 'Stuck operations';
|
||||
|
||||
protected static ?string $title = 'Stuck operations';
|
||||
|
||||
protected static string|\BackedEnum|null $navigationIcon = 'heroicon-o-clock';
|
||||
|
||||
@ -47,10 +45,10 @@ class Stuck extends Page implements HasTable
|
||||
public static function actionSurfaceDeclaration(): ActionSurfaceDeclaration
|
||||
{
|
||||
return ActionSurfaceDeclaration::forPage(ActionSurfaceProfile::RunLog, ActionSurfaceType::ReadOnlyRegistryReport)
|
||||
->exempt(ActionSurfaceSlot::ListHeader, 'System stuck-run triage relies on row actions and does not expose page header actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListHeader, 'The page header exposes Show all operations while row clicks remain the only inspect model.')
|
||||
->satisfy(ActionSurfaceSlot::InspectAffordance, ActionSurfaceInspectAffordance::ClickableRow->value)
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'Stuck-run triage stays per run and intentionally omits bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when no queued or running runs cross the stuck thresholds.')
|
||||
->exempt(ActionSurfaceSlot::ListBulkMoreGroup, 'Stuck operations remain scan-first and intentionally omit bulk actions.')
|
||||
->satisfy(ActionSurfaceSlot::ListEmptyState, 'The empty state explains when no operations cross the stuck thresholds and repeats the Show all operations CTA.')
|
||||
->exempt(ActionSurfaceSlot::DetailHeader, 'Row navigation opens the canonical system run detail page, which owns header actions.');
|
||||
}
|
||||
|
||||
@ -85,6 +83,18 @@ public function mount(): void
|
||||
$this->mountInteractsWithTable();
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array<Action>
|
||||
*/
|
||||
protected function getHeaderActions(): array
|
||||
{
|
||||
return [
|
||||
Action::make('show_all_operations')
|
||||
->label('Show all operations')
|
||||
->url(SystemOperationRunLinks::index()),
|
||||
];
|
||||
}
|
||||
|
||||
public function table(Table $table): Table
|
||||
{
|
||||
return $table
|
||||
@ -98,7 +108,7 @@ public function table(Table $table): Table
|
||||
})
|
||||
->columns([
|
||||
TextColumn::make('id')
|
||||
->label('Run')
|
||||
->label('ID')
|
||||
->state(fn (OperationRun $record): string => '#'.$record->getKey()),
|
||||
TextColumn::make('status')
|
||||
->badge()
|
||||
@ -127,80 +137,15 @@ public function table(Table $table): Table
|
||||
TextColumn::make('created_at')->label('Started')->since(),
|
||||
])
|
||||
->recordUrl(fn (OperationRun $record): string => SystemOperationRunLinks::view($record))
|
||||
->actions([
|
||||
Action::make('retry')
|
||||
->label('Retry')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canRetry($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$retryRun = $triageService->retry($record, $user);
|
||||
|
||||
OperationUxPresenter::queuedToast((string) $retryRun->type)
|
||||
->actions([
|
||||
\Filament\Actions\Action::make('view_run')
|
||||
->label('View run')
|
||||
->url(SystemOperationRunLinks::view($retryRun)),
|
||||
->actions([])
|
||||
->emptyStateHeading('No stuck operations found')
|
||||
->emptyStateDescription('Queued and running operations that exceed the thresholds will appear here.')
|
||||
->emptyStateActions([
|
||||
Action::make('show_all_operations_empty')
|
||||
->label('Show all operations')
|
||||
->url(SystemOperationRunLinks::index())
|
||||
->button(),
|
||||
])
|
||||
->send();
|
||||
}),
|
||||
Action::make('cancel')
|
||||
->label('Cancel')
|
||||
->color('danger')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (OperationRun $record): bool => $this->canManageOperations() && app(OperationRunTriageService::class)->canCancel($record))
|
||||
->action(function (OperationRun $record, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->cancel($record, $user);
|
||||
|
||||
Notification::make()
|
||||
->title('Run cancelled')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
Action::make('mark_investigated')
|
||||
->label('Mark investigated')
|
||||
->requiresConfirmation()
|
||||
->visible(fn (): bool => $this->canManageOperations())
|
||||
->form([
|
||||
Textarea::make('reason')
|
||||
->label('Reason')
|
||||
->required()
|
||||
->minLength(5)
|
||||
->maxLength(500)
|
||||
->rows(4),
|
||||
])
|
||||
->action(function (OperationRun $record, array $data, OperationRunTriageService $triageService): void {
|
||||
$user = $this->requireManageUser();
|
||||
$triageService->markInvestigated($record, $user, (string) ($data['reason'] ?? ''));
|
||||
|
||||
Notification::make()
|
||||
->title('Run marked as investigated')
|
||||
->success()
|
||||
->send();
|
||||
}),
|
||||
])
|
||||
->emptyStateHeading('No stuck runs found')
|
||||
->emptyStateDescription('Queued and running runs outside thresholds will appear here.')
|
||||
->bulkActions([]);
|
||||
}
|
||||
|
||||
private function canManageOperations(): bool
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
return $user instanceof PlatformUser
|
||||
&& $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE);
|
||||
}
|
||||
|
||||
private function requireManageUser(): PlatformUser
|
||||
{
|
||||
$user = auth('platform')->user();
|
||||
|
||||
if (! $user instanceof PlatformUser || ! $user->hasCapability(PlatformCapabilities::OPERATIONS_MANAGE)) {
|
||||
abort(403);
|
||||
}
|
||||
|
||||
return $user;
|
||||
}
|
||||
}
|
||||
|
||||
@ -14,6 +14,7 @@
|
||||
use Filament\Forms\Components\Textarea;
|
||||
use Filament\Notifications\Notification;
|
||||
use Filament\Pages\Page;
|
||||
use Illuminate\Contracts\Support\Htmlable;
|
||||
|
||||
class ViewRun extends Page
|
||||
{
|
||||
@ -44,12 +45,20 @@ public function mount(OperationRun $run): void
|
||||
$this->run = $run;
|
||||
}
|
||||
|
||||
public function getTitle(): string|Htmlable
|
||||
{
|
||||
return 'Operation #'.(int) $this->run->getKey();
|
||||
}
|
||||
|
||||
/**
|
||||
* @return array<Action>
|
||||
*/
|
||||
protected function getHeaderActions(): array
|
||||
{
|
||||
return [
|
||||
Action::make('show_all_operations')
|
||||
->label('Show all operations')
|
||||
->url(SystemOperationRunLinks::index()),
|
||||
Action::make('go_to_runbooks')
|
||||
->label('Go to runbooks')
|
||||
->url(Runbooks::getUrl(panel: 'system')),
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
<div class="space-y-6">
|
||||
<x-filament::section>
|
||||
<x-slot name="heading">
|
||||
Run #{{ (int) $run->getKey() }}
|
||||
Operation #{{ (int) $run->getKey() }}
|
||||
</x-slot>
|
||||
|
||||
<x-slot name="description">
|
||||
@ -88,11 +88,17 @@
|
||||
</div>
|
||||
|
||||
<div>
|
||||
<dt class="text-xs font-semibold uppercase tracking-wider text-gray-500 dark:text-gray-400">Runbooks</dt>
|
||||
<dt class="text-xs font-semibold uppercase tracking-wider text-gray-500 dark:text-gray-400">Navigation</dt>
|
||||
<dd class="mt-1 text-sm">
|
||||
<div class="flex flex-col gap-2">
|
||||
<x-filament::link href="{{ \App\Support\System\SystemOperationRunLinks::index() }}">
|
||||
Show all operations
|
||||
</x-filament::link>
|
||||
|
||||
<x-filament::link href="{{ \App\Filament\System\Pages\Ops\Runbooks::getUrl(panel: 'system') }}">
|
||||
Go to runbooks
|
||||
</x-filament::link>
|
||||
</div>
|
||||
</dd>
|
||||
</div>
|
||||
</dl>
|
||||
|
||||
@ -0,0 +1,35 @@
|
||||
# Specification Quality Checklist: System Operations Surface Alignment
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-03-30
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Validation pass 1: complete
|
||||
- This spec intentionally excludes naming consolidation and deferred dashboard or onboarding retrofits, which are reserved for Specs 171 and 172.
|
||||
@ -0,0 +1,192 @@
|
||||
openapi: 3.1.0
|
||||
info:
|
||||
title: System Operations Surface Alignment Contract
|
||||
version: 1.0.0
|
||||
summary: Route and UI contract for Spec 170.
|
||||
paths:
|
||||
/system/ops/runs:
|
||||
get:
|
||||
operationId: listSystemRuns
|
||||
summary: Display the platform-wide operations registry.
|
||||
responses:
|
||||
'200':
|
||||
description: System runs list rendered successfully.
|
||||
'403':
|
||||
description: Authenticated platform user lacks operations view capability.
|
||||
'404':
|
||||
description: Wrong plane or inaccessible system surface.
|
||||
x-ui-surface:
|
||||
surfaceType: read_only_registry_report
|
||||
displayLabel: Operations
|
||||
canonicalNoun:
|
||||
collection: Operations
|
||||
singular: Operation
|
||||
inspectAffordance: clickable_row
|
||||
canonicalDetailRoute: /system/ops/runs/{run}
|
||||
headerActions:
|
||||
- name: go_to_runbooks
|
||||
label: Go to runbooks
|
||||
type: navigation
|
||||
rowActions: []
|
||||
bulkActions: []
|
||||
emptyStateCta:
|
||||
name: go_to_runbooks
|
||||
label: Go to runbooks
|
||||
requiredCapabilities:
|
||||
- platform.operations.view
|
||||
defaultVisibleTruth:
|
||||
- status
|
||||
- outcome
|
||||
- operation
|
||||
- workspace
|
||||
- tenant
|
||||
- initiator
|
||||
- activity_time
|
||||
/system/ops/failures:
|
||||
get:
|
||||
operationId: listSystemFailures
|
||||
summary: Display failed operations as a read-only registry.
|
||||
responses:
|
||||
'200':
|
||||
description: Failed-runs list rendered successfully.
|
||||
'403':
|
||||
description: Authenticated platform user lacks operations view capability.
|
||||
'404':
|
||||
description: Wrong plane or inaccessible system surface.
|
||||
x-ui-surface:
|
||||
surfaceType: read_only_registry_report
|
||||
displayLabel: Failed operations
|
||||
canonicalNoun:
|
||||
collection: Operations
|
||||
singular: Operation
|
||||
inspectAffordance: clickable_row
|
||||
canonicalDetailRoute: /system/ops/runs/{run}
|
||||
headerActions:
|
||||
- name: show_all_operations
|
||||
label: Show all operations
|
||||
type: navigation
|
||||
url: /system/ops/runs
|
||||
rowActions: []
|
||||
bulkActions: []
|
||||
emptyStateCta:
|
||||
name: show_all_operations
|
||||
label: Show all operations
|
||||
requiredCapabilities:
|
||||
- platform.operations.view
|
||||
filter:
|
||||
status: completed
|
||||
outcome: failed
|
||||
defaultVisibleTruth:
|
||||
- status
|
||||
- outcome
|
||||
- operation
|
||||
- workspace
|
||||
- tenant
|
||||
- activity_time
|
||||
/system/ops/stuck:
|
||||
get:
|
||||
operationId: listSystemStuckRuns
|
||||
summary: Display queued or running operations that exceed the stuck threshold.
|
||||
responses:
|
||||
'200':
|
||||
description: Stuck-runs list rendered successfully.
|
||||
'403':
|
||||
description: Authenticated platform user lacks operations view capability.
|
||||
'404':
|
||||
description: Wrong plane or inaccessible system surface.
|
||||
x-ui-surface:
|
||||
surfaceType: read_only_registry_report
|
||||
displayLabel: Stuck operations
|
||||
canonicalNoun:
|
||||
collection: Operations
|
||||
singular: Operation
|
||||
inspectAffordance: clickable_row
|
||||
canonicalDetailRoute: /system/ops/runs/{run}
|
||||
headerActions:
|
||||
- name: show_all_operations
|
||||
label: Show all operations
|
||||
type: navigation
|
||||
url: /system/ops/runs
|
||||
rowActions: []
|
||||
bulkActions: []
|
||||
emptyStateCta:
|
||||
name: show_all_operations
|
||||
label: Show all operations
|
||||
requiredCapabilities:
|
||||
- platform.operations.view
|
||||
derivedFields:
|
||||
- stuck_class
|
||||
defaultVisibleTruth:
|
||||
- status
|
||||
- stuck_class
|
||||
- operation
|
||||
- workspace
|
||||
- tenant
|
||||
- activity_time
|
||||
/system/ops/runs/{run}:
|
||||
get:
|
||||
operationId: viewSystemRun
|
||||
summary: Display one system operation detail surface.
|
||||
parameters:
|
||||
- name: run
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: System run detail rendered successfully.
|
||||
'403':
|
||||
description: Authenticated platform user lacks operations view capability.
|
||||
'404':
|
||||
description: Wrong plane or inaccessible system surface.
|
||||
x-ui-surface:
|
||||
surfaceType: detail_first_operational
|
||||
displayLabel: Operation
|
||||
canonicalNoun:
|
||||
collection: Operations
|
||||
singular: Operation
|
||||
requiredCapabilities:
|
||||
- platform.operations.view
|
||||
headerActions:
|
||||
- name: show_all_operations
|
||||
label: Show all operations
|
||||
type: navigation
|
||||
url: /system/ops/runs
|
||||
- name: go_to_runbooks
|
||||
label: Go to runbooks
|
||||
type: navigation
|
||||
- name: retry
|
||||
label: Retry
|
||||
type: mutation
|
||||
requiredCapabilities:
|
||||
- platform.operations.manage
|
||||
confirmationRequired: true
|
||||
visibleWhen:
|
||||
status: completed
|
||||
outcome: failed
|
||||
retryableType: true
|
||||
- name: cancel
|
||||
label: Cancel
|
||||
type: destructive_mutation
|
||||
requiredCapabilities:
|
||||
- platform.operations.manage
|
||||
confirmationRequired: true
|
||||
visibleWhen:
|
||||
statusIn:
|
||||
- queued
|
||||
- running
|
||||
cancelableType: true
|
||||
- name: mark_investigated
|
||||
label: Mark investigated
|
||||
type: mutation
|
||||
requiredCapabilities:
|
||||
- platform.operations.manage
|
||||
confirmationRequired: true
|
||||
form:
|
||||
fields:
|
||||
- name: reason
|
||||
type: textarea
|
||||
required: true
|
||||
minLength: 5
|
||||
maxLength: 500
|
||||
110
specs/170-system-operations-surface-alignment/data-model.md
Normal file
110
specs/170-system-operations-surface-alignment/data-model.md
Normal file
@ -0,0 +1,110 @@
|
||||
# Data Model: System Operations Surface Alignment
|
||||
|
||||
## Overview
|
||||
|
||||
This feature introduces no new persisted entity, no new table, and no new status family. It reuses existing `OperationRun` truth and existing platform capability checks, while narrowing where triage actions are exposed in the UI.
|
||||
|
||||
## Entity: OperationRun
|
||||
|
||||
- **Type**: Existing persisted model
|
||||
- **Purpose in this feature**: Canonical record shown on the three system list pages and on the system run detail page.
|
||||
|
||||
### Relevant Fields
|
||||
|
||||
| Field | Type | Notes |
|
||||
|-------|------|-------|
|
||||
| `id` | integer | Displayed as `Operation #<id>` and used in canonical detail routing. |
|
||||
| `workspace_id` | integer | Required for platform-wide run context. |
|
||||
| `tenant_id` | integer nullable | Nullable for tenantless/platform runs; still shown on system lists and detail. |
|
||||
| `initiator_name` | string nullable | Default-visible operator truth on the all-runs list. |
|
||||
| `type` | string | Rendered through `OperationCatalog::label(...)`. |
|
||||
| `status` | string | Badge-rendered lifecycle dimension. |
|
||||
| `outcome` | string | Badge-rendered execution-outcome dimension. |
|
||||
| `context` | array/json | Stores triage metadata such as retry, cancel, and investigation context. |
|
||||
| `created_at` | timestamp | Used for default-visible list activity time and recency on all three lists. |
|
||||
| `started_at` | timestamp nullable | Supports stuck classification and detail timing. |
|
||||
| `completed_at` | timestamp nullable | Preserved for completed/failed runs and detail history. |
|
||||
|
||||
### Relationships
|
||||
|
||||
| Relationship | Target | Purpose |
|
||||
|--------------|--------|---------|
|
||||
| `workspace` | `Workspace` | Default-visible context on all system lists and on the detail page. |
|
||||
| `tenant` | `Tenant` | Default-visible context on all system lists and on the detail page. |
|
||||
|
||||
### Feature-Specific Invariants
|
||||
|
||||
- All three system lists eager-load `tenant` and `workspace`.
|
||||
- `Runs` shows the full platform-wide run set.
|
||||
- `Failures` filters to `status=completed` and `outcome=failed`.
|
||||
- `Stuck` filters through `StuckRunClassifier` and exposes a derived `stuck_class` label.
|
||||
- List inspection always resolves to `SystemOperationRunLinks::view($run)`.
|
||||
|
||||
### State Transitions Used By This Feature
|
||||
|
||||
| Transition | Preconditions | Result |
|
||||
|------------|---------------|--------|
|
||||
| Inspect list row | Operator has `platform.operations.view` | No state change; opens canonical detail page. |
|
||||
| Retry run | Run is completed, failed, and retryable | Creates a new queued `OperationRun` with `context.triage.retry_of_run_id` and audit action `platform.system_console.retry`. |
|
||||
| Cancel run | Run is queued or running and cancelable | Updates the current run to completed/failed through `OperationRunService` and logs `platform.system_console.cancel`. |
|
||||
| Mark investigated | Operator has manage capability and supplies a valid reason | Updates `context.triage.investigated` on the current run and logs `platform.system_console.mark_investigated`. |
|
||||
|
||||
## Entity: PlatformUser Capability Gate
|
||||
|
||||
- **Type**: Existing persisted/authenticated actor model
|
||||
- **Purpose in this feature**: Separates inspection access from triage access on system-panel surfaces.
|
||||
|
||||
### Relevant Capability Fields
|
||||
|
||||
| Capability | Purpose |
|
||||
|------------|---------|
|
||||
| `platform.access_system_panel` | Required to enter the system panel. |
|
||||
| `platform.operations.view` | Required to access the system runs/failures/stuck/detail surfaces. |
|
||||
| `platform.operations.manage` | Required to see and execute triage actions on the detail page. |
|
||||
|
||||
### Feature-Specific Invariants
|
||||
|
||||
- View-only users can load list and detail pages but cannot see triage actions.
|
||||
- Manage-capable users retain retry/cancel/mark-investigated on the detail header.
|
||||
- No new capability is introduced.
|
||||
|
||||
## Derived UI Contract: System Operations Lists
|
||||
|
||||
- **Type**: Derived UI surface, not persisted
|
||||
- **Routes**:
|
||||
- `/system/ops/runs`
|
||||
- `/system/ops/failures`
|
||||
- `/system/ops/stuck`
|
||||
- **Surface Type**: `ReadOnlyRegistryReport`
|
||||
- **Primary Question**: Which operation should I open next?
|
||||
|
||||
### Contract Rules
|
||||
|
||||
- Primary inspect affordance is full-row click only.
|
||||
- Row actions are empty.
|
||||
- Bulk actions are empty.
|
||||
- Visible collection naming uses `Operations` and visible singular naming uses `Operation`.
|
||||
- `/system/ops/runs` uses `Go to runbooks` as its single header and empty-state CTA.
|
||||
- `/system/ops/failures` and `/system/ops/stuck` use `Show all operations` as their single header and empty-state CTA.
|
||||
|
||||
## Derived UI Contract: System Run Detail
|
||||
|
||||
- **Type**: Derived UI surface, not persisted
|
||||
- **Route**: `/system/ops/runs/{run}`
|
||||
- **Surface Type**: Detail-first operational surface
|
||||
- **Primary Question**: What happened on this operation, and what follow-up is appropriate?
|
||||
|
||||
### Contract Rules
|
||||
|
||||
- Header actions remain the only triage location for retry, cancel, and mark investigated.
|
||||
- The detail surface exposes `Show all operations` as the canonical return path and keeps `Go to runbooks` available as secondary navigation.
|
||||
- `cancel` remains destructive and confirmation-gated.
|
||||
- `mark investigated` retains the `reason` validation rule: required, minimum 5 characters, maximum 500 characters.
|
||||
- No new page, modal surface, or alternate triage route is introduced.
|
||||
|
||||
## Persistence Impact
|
||||
|
||||
- **Schema changes**: None
|
||||
- **Data migration**: None
|
||||
- **New indexes**: None
|
||||
- **Retention impact**: None
|
||||
127
specs/170-system-operations-surface-alignment/plan.md
Normal file
127
specs/170-system-operations-surface-alignment/plan.md
Normal file
@ -0,0 +1,127 @@
|
||||
# Implementation Plan: System Operations Surface Alignment
|
||||
|
||||
**Branch**: `170-system-operations-surface-alignment` | **Date**: 2026-03-30 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/170-system-operations-surface-alignment/spec.md`
|
||||
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/170-system-operations-surface-alignment/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Align the system-panel Operations, Failed operations, and Stuck operations pages to their declared `ReadOnlyRegistryReport` surface semantics by removing inline triage from the list rows, preserving full-row navigation to the canonical system operation detail page, standardizing visible naming to `Operations` / `Operation`, and adding the required list CTA and detail return-path behavior while keeping retry/cancel/mark-investigated ownership on the existing `ViewRun` page. The implementation stays narrow: no schema, new capability, or service-model changes; only Filament page behavior, visible operator copy, and the associated Pest/Livewire guard coverage are updated.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: PHP 8.4, Laravel 12, Livewire v4, Filament v5
|
||||
**Primary Dependencies**: `laravel/framework`, `filament/filament`, `livewire/livewire`, `pestphp/pest`
|
||||
**Storage**: PostgreSQL with existing `operation_runs` and `audit_logs` tables; no schema changes
|
||||
**Testing**: Pest feature tests with Livewire component assertions, executed through Laravel Sail
|
||||
**Target Platform**: Laravel web application running in Sail locally and containerized Linux environments in staging/production
|
||||
**Project Type**: Laravel monolith with Filament panels
|
||||
**Performance Goals**: Preserve current DB-only list rendering, eager loading of `tenant` and `workspace`, and existing pagination/sort behavior with no extra remote calls
|
||||
**Constraints**: Platform plane only; no new pages/capabilities/persistence; visible naming must align to `Operations` / `Operation`; destructive triage stays confirmation-gated; existing queued-toast and audit behavior must remain intact
|
||||
**Scale/Scope**: Four existing system-panel pages, one existing detail Blade view, one existing triage service, and the focused feature/guard tests that encode current row-action behavior
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
||||
|
||||
- `PASS` Inventory-first / snapshots-second: the feature does not change inventory, backups, or snapshot truth.
|
||||
- `PASS` Read/write separation: no new writes are introduced; existing retry/cancel/mark-investigated flows remain explicit operator actions with confirmation where required.
|
||||
- `PASS` Graph contract path: no Microsoft Graph call path is touched.
|
||||
- `PASS` Deterministic capabilities: existing `PlatformCapabilities::OPERATIONS_VIEW` and `PlatformCapabilities::OPERATIONS_MANAGE` remain the canonical gates.
|
||||
- `PASS` RBAC-UX plane separation: the slice is limited to `/system` surfaces and existing platform guard semantics.
|
||||
- `PASS` Destructive confirmation standard: `cancel` remains `->requiresConfirmation()` on the detail header.
|
||||
- `PASS` Ops-UX 3-surface feedback: retry continues to use `OperationUxPresenter::queuedToast(...)`; cancel and mark-investigated remain local terminal confirmations without adding queued/running notifications.
|
||||
- `PASS` Ops lifecycle ownership: status/outcome mutation continues to flow through `OperationRunService` inside `OperationRunTriageService`; no new lifecycle path is introduced.
|
||||
- `PASS` Proportionality / bloat: the feature removes duplicated interaction semantics and adds no new persistence, abstraction, state family, or taxonomy.
|
||||
- `PASS` Badge semantics: list/detail badge rendering stays on the shared badge catalog and renderer.
|
||||
- `PASS` Filament-native UI: the change stays inside existing Filament pages, row navigation, header actions, and confirmations.
|
||||
- `PASS` UI surface taxonomy: Runs, Failures, and Stuck remain `ReadOnlyRegistryReport`; `ViewRun` remains the detail-first operational surface.
|
||||
- `PASS` UI inspect model: each list will expose exactly one primary inspect model, `recordUrl()` row click.
|
||||
- `PASS` UI action hierarchy: registry lists will have no inline triage; detail header remains the single triage owner.
|
||||
- `PASS` UI naming scope: the changed system surfaces standardize visible copy to `Operations` / `Operation` while keeping internal route stability explicit.
|
||||
- `PASS` Empty-state CTA rule: each changed list surface will define exactly one page-appropriate CTA and matching header action.
|
||||
- `PASS` Placeholder/empty-group ban: no empty groups are introduced; bulk actions remain absent because there is no real bulk use case.
|
||||
- `PASS` OPSURF page contract: the governing spec already defines persona, operator question, default truth, mutation scope, and dangerous actions.
|
||||
- `PASS` Testing truth: implementation will update behavior guards, not just declarations.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/170-system-operations-surface-alignment/
|
||||
├── plan.md
|
||||
├── research.md
|
||||
├── data-model.md
|
||||
├── quickstart.md
|
||||
├── contracts/
|
||||
│ └── system-ops-surface-contract.yaml
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
app/
|
||||
├── Filament/
|
||||
│ └── System/
|
||||
│ └── Pages/
|
||||
│ └── Ops/
|
||||
│ ├── Runs.php
|
||||
│ ├── Failures.php
|
||||
│ ├── Stuck.php
|
||||
│ └── ViewRun.php
|
||||
├── Services/
|
||||
│ └── SystemConsole/
|
||||
│ └── OperationRunTriageService.php
|
||||
├── resources/
|
||||
│ └── views/
|
||||
│ └── filament/
|
||||
│ └── system/
|
||||
│ └── pages/
|
||||
│ └── ops/
|
||||
│ └── view-run.blade.php
|
||||
└── Support/
|
||||
└── System/
|
||||
└── SystemOperationRunLinks.php
|
||||
|
||||
tests/
|
||||
└── Feature/
|
||||
├── Guards/
|
||||
│ └── ActionSurfaceContractTest.php
|
||||
└── System/
|
||||
└── Spec114/
|
||||
├── OpsTriageActionsTest.php
|
||||
├── OpsFailuresViewTest.php
|
||||
└── OpsStuckViewTest.php
|
||||
```
|
||||
|
||||
**Structure Decision**: This is a single Laravel application. The implementation is confined to existing system-panel Filament pages and existing Pest feature/guard tests. No new application layer or directory is needed.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
No constitution waiver is expected. This slice reduces surface complexity instead of introducing a new layer.
|
||||
|
||||
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
||||
|-----------|------------|-------------------------------------|
|
||||
| None | Not applicable | Not applicable |
|
||||
|
||||
## Proportionality Review
|
||||
|
||||
- **Current operator problem**: the three system list pages are declared as read-only registry surfaces but still expose direct triage actions, leave empty-state navigation underdefined, and continue to present `Runs` as a competing visible noun beside the canonical `Operations` vocabulary.
|
||||
- **Existing structure is insufficient because**: the current hybrid model forces operators to choose between acting in-row and opening the richer detail page, while the constitution requires one primary inspect model, stable nouns, and explicit CTA behavior for changed list surfaces.
|
||||
- **Narrowest correct implementation**: remove list row triage actions, keep `recordUrl()` row-click navigation, standardize visible copy to `Operations` / `Operation`, add one clear list CTA per changed surface, add a `Show all operations` return path on the detail page, and update the existing tests to assert the aligned behavior.
|
||||
- **Ownership cost created**: low. The change requires focused updates to Filament page classes and the behavior guards that currently encode list-level triage.
|
||||
- **Alternative intentionally rejected**: reclassifying the list pages as queue/review surfaces or adding new exception types was rejected because these pages are scan-first registries, not context-preserving decision queues.
|
||||
- **Release truth**: current-release truth. The canonical detail page and triage service already exist today; the feature removes duplication rather than preparing speculative future structure.
|
||||
|
||||
## Post-Design Constitution Re-check
|
||||
|
||||
- `PASS` `UI-CONST-001` / `UI-SURF-001`: the artifacts keep list pages in the registry class and the detail page as the triage owner.
|
||||
- `PASS` `UI-HARD-001`: the target design leaves each system list with exactly one primary inspect model and zero inline destructive actions.
|
||||
- `PASS` `UI-EX-001`: no new exception type or exemption is needed for this slice.
|
||||
- `PASS` `OPSURF-001`: list pages stay scan-first, while the detail page remains the context-rich operational surface.
|
||||
- `PASS` `RBAC-UX-001` to `RBAC-UX-005`: view/manage separation, server-side enforcement, and destructive confirmation rules remain unchanged.
|
||||
- `PASS` `UI-NAMING-001`: visible system-surface nomenclature now aligns to `Operations` / `Operation`.
|
||||
- `PASS` Empty-state CTA requirement: the design now defines a primary CTA for each changed list surface and a return path on the detail page.
|
||||
- `PASS` `BLOAT-001`: no new persistence, abstraction, state family, or taxonomy was introduced during design.
|
||||
- `PASS` Filament v5 / Livewire v4 guardrails: the plan keeps changes inside existing Filament pages and does not require provider or asset registration changes.
|
||||
73
specs/170-system-operations-surface-alignment/quickstart.md
Normal file
73
specs/170-system-operations-surface-alignment/quickstart.md
Normal file
@ -0,0 +1,73 @@
|
||||
# Quickstart: System Operations Surface Alignment
|
||||
|
||||
## Goal
|
||||
|
||||
Bring the system-panel Operations surfaces into conformance with the declared read-only registry contract by removing inline triage from the list rows, standardizing visible naming to `Operations` / `Operation`, adding explicit list CTAs, and keeping triage on the canonical operation detail page.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Start the local stack:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail up -d
|
||||
```
|
||||
|
||||
2. Work on branch `170-system-operations-surface-alignment`.
|
||||
|
||||
## Implementation Steps
|
||||
|
||||
1. Update the three list pages:
|
||||
- `app/Filament/System/Pages/Ops/Runs.php`
|
||||
- `app/Filament/System/Pages/Ops/Failures.php`
|
||||
- `app/Filament/System/Pages/Ops/Stuck.php`
|
||||
2. Remove the `retry`, `cancel`, and `mark_investigated` table actions from each list page.
|
||||
3. Keep `recordUrl()` row-click navigation intact for each list page.
|
||||
4. Update visible navigation labels, headings, empty-state copy, and page CTA behavior so the changed surfaces use `Operations` / `Operation` vocabulary.
|
||||
5. Update each list page's `actionSurfaceDeclaration()` explanation text so it reflects detail-owned triage rather than row-level triage.
|
||||
6. Update `app/Filament/System/Pages/Ops/ViewRun.php` and `resources/views/filament/system/pages/ops/view-run.blade.php` so the detail page keeps triage ownership, uses `Operation #...` copy, and exposes `Show all operations`.
|
||||
7. Leave `app/Services/SystemConsole/OperationRunTriageService.php` unchanged unless a small refactor is needed to support the page move without changing behavior.
|
||||
|
||||
## Tests To Update
|
||||
|
||||
1. `tests/Feature/System/Spec114/OpsTriageActionsTest.php`
|
||||
- Replace row-action execution assertions on `Runs` with detail-page action visibility/execution assertions on `ViewRun`.
|
||||
- Keep view-only versus manage-capable separation explicit.
|
||||
- Add assertions for visible `Operations` / `Operation` copy and the `Show all operations` return path.
|
||||
2. `tests/Feature/Guards/ActionSurfaceContractTest.php`
|
||||
- Replace the three expectations for direct row triage with expectations that the row action set is empty while `recordUrl()` still points to `SystemOperationRunLinks::view($run)`.
|
||||
- Assert the list CTA behavior and canonical Operations naming on the changed surfaces.
|
||||
3. Keep the existing page-access tests for failures/stuck passing.
|
||||
|
||||
## Focused Verification
|
||||
|
||||
Run the smallest relevant test set first:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsTriageActionsTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php
|
||||
```
|
||||
|
||||
If implementation touches other platform-ops behavior, add the page access tests:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsFailuresViewTest.php
|
||||
vendor/bin/sail artisan test --compact tests/Feature/System/Spec114/OpsStuckViewTest.php
|
||||
```
|
||||
|
||||
## Formatting
|
||||
|
||||
After code changes, run:
|
||||
|
||||
```bash
|
||||
vendor/bin/sail bin pint --dirty --format agent
|
||||
```
|
||||
|
||||
## Manual Review Checklist
|
||||
|
||||
1. The `Runs`, `Failures`, and `Stuck` tables still navigate by row click.
|
||||
2. None of the three lists exposes inline triage actions.
|
||||
3. The changed system surfaces use `Operations` / `Operation` as the visible noun.
|
||||
4. The Operations list exposes `Go to runbooks`, while Failed operations and Stuck operations expose `Show all operations` as the single header and empty-state CTA.
|
||||
5. The system operation detail page still shows `Retry`, `Cancel`, and `Mark investigated` only for manage-capable operators and exposes `Show all operations` as the return path.
|
||||
6. `Cancel` still requires confirmation.
|
||||
7. Retry still produces the existing queued toast with a `View run` link.
|
||||
43
specs/170-system-operations-surface-alignment/research.md
Normal file
43
specs/170-system-operations-surface-alignment/research.md
Normal file
@ -0,0 +1,43 @@
|
||||
# Research: System Operations Surface Alignment
|
||||
|
||||
## Decision 1: Keep the three system list pages as read-only registry surfaces
|
||||
|
||||
- **Decision**: `Runs`, `Failures`, and `Stuck` stay classified as `ReadOnlyRegistryReport` surfaces with `recordUrl()` full-row navigation as the only primary inspect model.
|
||||
- **Rationale**: The pages already declare `ActionSurfaceType::ReadOnlyRegistryReport`, already use clickable rows, and the constitution requires exactly one primary inspect/open model for registry surfaces. Inline triage on these lists is the specific behavior drift the spec is correcting.
|
||||
- **Alternatives considered**: Reclassify the lists as queue/review surfaces. Rejected because the pages are scan-first status registers split by run state, not in-place decision queues.
|
||||
|
||||
## Decision 2: Keep triage ownership on the existing `ViewRun` page
|
||||
|
||||
- **Decision**: `Retry`, `Cancel`, and `Mark investigated` remain on `app/Filament/System/Pages/Ops/ViewRun.php` and are removed from the list rows.
|
||||
- **Rationale**: The detail page already exposes all three actions, already loads `tenant` and `workspace`, and already provides the surrounding operational context the operator needs before acting. Repo analysis of the operation-run detail surface confirms that the page is already the rich context owner for run truth and next steps.
|
||||
- **Alternatives considered**: Add a new dedicated triage modal or keep one “safe” triage action inline on the lists. Rejected because both options preserve split ownership and weaken the single-entry operational model.
|
||||
|
||||
## Decision 3: Reuse the existing triage service and links without abstraction changes
|
||||
|
||||
- **Decision**: `OperationRunTriageService` and `SystemOperationRunLinks` remain the canonical implementation path for retry/cancel/investigate and detail navigation.
|
||||
- **Rationale**: The service already encapsulates retryability/cancelability rules, audit logging, `OperationRunService` lifecycle transitions, and triage context writes. This spec changes action placement, not domain behavior.
|
||||
- **Alternatives considered**: Introduce a new presenter, coordinator, or list-specific triage wrapper. Rejected under `ABSTR-001` and `LAYER-001` because there is only one existing triage behavior and the current service already fits it.
|
||||
|
||||
## Decision 4: Move behavior guards from “direct row triage” to “detail-owned triage”
|
||||
|
||||
- **Decision**: Update `tests/Feature/Guards/ActionSurfaceContractTest.php` and `tests/Feature/System/Spec114/OpsTriageActionsTest.php` so they assert row-click-only lists and detail-header triage ownership.
|
||||
- **Rationale**: The constitution explicitly prioritizes rendered behavior over declaration. The current guard suite still encodes the old hybrid interaction model by expecting `retry`, `cancel`, and `mark_investigated` on all three list pages.
|
||||
- **Alternatives considered**: Leave the existing guards untouched and only rely on declarations, or delete the guards. Rejected because that would preserve declaration-only conformance and remove the regression protection this slice is supposed to strengthen.
|
||||
|
||||
## Decision 5: Absorb visible Operations naming into Spec 170 while keeping route stability explicit
|
||||
|
||||
- **Decision**: The changed system surfaces standardize their visible collection and singular nouns to `Operations` and `Operation` in navigation labels, headings, empty-state copy, and return links, while existing internal class names and `/system/ops/runs` route paths may remain stable for compatibility.
|
||||
- **Rationale**: The constitution treats `Operations` as the canonical collection noun for run records. Leaving the changed system surfaces on `Runs` would keep the spec itself in conflict with the constitution.
|
||||
- **Alternatives considered**: Defer naming to Spec 171. Rejected because it leaves a known constitution conflict inside the active slice.
|
||||
|
||||
## Decision 6: Give every changed list surface one explicit CTA and the detail page one explicit return path
|
||||
|
||||
- **Decision**: The Operations list uses `Go to runbooks` as its single header and empty-state CTA. Failed operations and Stuck operations use `Show all operations` as their single header and empty-state CTA. The detail page exposes `Show all operations` as the canonical return path and keeps `Go to runbooks` as secondary navigation.
|
||||
- **Rationale**: The constitution requires changed list surfaces to define explicit empty-state CTA behavior and requires a clear canonical navigation model. These CTAs stay navigation-only and do not reintroduce inline row clutter.
|
||||
- **Alternatives considered**: Keep explanation-only empty states or add multiple list CTAs. Rejected because the first violates the constitution and the second weakens scanability.
|
||||
|
||||
## Decision 7: No new API surface; document the route/UI contract explicitly
|
||||
|
||||
- **Decision**: Capture the expected route and interaction contract in a small OpenAPI-style YAML file under `contracts/` even though the feature does not add a public JSON API.
|
||||
- **Rationale**: The implementation change is route-driven and operator-visible. A route contract that records surface type, inspect affordance, action placement, and capability boundaries gives later tasks and reviews a concrete artifact without inventing a new backend API.
|
||||
- **Alternatives considered**: Skip `contracts/` entirely. Rejected because the planning workflow expects a concrete contract artifact, and this feature benefits from a machine-readable record of its operator-visible contract.
|
||||
206
specs/170-system-operations-surface-alignment/spec.md
Normal file
206
specs/170-system-operations-surface-alignment/spec.md
Normal file
@ -0,0 +1,206 @@
|
||||
# Feature Specification: System Operations Surface Alignment
|
||||
|
||||
**Feature Branch**: `170-system-operations-surface-alignment`
|
||||
**Created**: 2026-03-30
|
||||
**Status**: Draft
|
||||
**Input**: User description: "System Operations Surface Alignment"
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: platform
|
||||
- **Primary Routes**:
|
||||
- `/system/ops/runs`
|
||||
- `/system/ops/failures`
|
||||
- `/system/ops/stuck`
|
||||
- `/system/ops/runs/{run}`
|
||||
- **Data Ownership**:
|
||||
- No new platform-owned, workspace-owned, or tenant-owned records are introduced
|
||||
- Existing `OperationRun` records remain the only source of truth for system operations list and detail surfaces
|
||||
- This feature changes only operator-facing interaction semantics for existing system operations pages
|
||||
- **RBAC**:
|
||||
- Platform plane only
|
||||
- Existing `platform.operations.view` and `platform.operations.manage` capability boundaries remain authoritative
|
||||
- Users without system access remain deny-as-not-found by existing platform routing and auth guards
|
||||
- Users with view capability but without manage capability remain able to inspect runs but unable to execute triage actions
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | 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 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| System operations list | Read-only Registry / Report | Full-row click to system operation detail | required | header CTA only | none on the list | `/system/ops/runs` | `/system/ops/runs/{run}` | Platform scope only | Operations / Operation | status, outcome, operation type, workspace, tenant, recency | none |
|
||||
| System failed operations list | Read-only Registry / Report | Full-row click to system operation detail | required | header CTA only | none on the list | `/system/ops/failures` | `/system/ops/runs/{run}` | Platform scope only | Operations / Operation | failed outcome, operation type, workspace, tenant, recency | none |
|
||||
| System stuck operations list | Read-only Registry / Report | Full-row click to system operation detail | required | header CTA only | none on the list | `/system/ops/stuck` | `/system/ops/runs/{run}` | Platform scope only | Operations / Operation | queued or running stale state, operation type, workspace, tenant, recency | none |
|
||||
| System operation detail | Detail-first Operational Surface | Dedicated detail page | forbidden | detail header groups only | detail header only | `/system/ops/runs` | `/system/ops/runs/{run}` | Platform scope only | Operations / Operation | operation truth, failure cause, context, related navigation, next actions | none |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| System operations list | Platform operator | Read-only Registry / Report | Which operation should I open next? | status, outcome, operation label, workspace, tenant, initiator, activity time | raw payloads and deeper traces stay on detail | execution outcome, recency | Read-only list | Open operation, go to runbooks | none |
|
||||
| System failed operations list | Platform operator | Read-only Registry / Report | Which failed operation needs investigation first? | failed outcome, operation label, workspace, tenant, activity time | raw payloads and deeper traces stay on detail | execution outcome, failure state, recency | Read-only list | Open operation, show all operations | none |
|
||||
| System stuck operations list | Platform operator | Read-only Registry / Report | Which queued or running operation has crossed the stuck threshold? | stuck class, operation label, workspace, tenant, activity time | raw payloads and deeper traces stay on detail | lifecycle stall state, recency | Read-only list | Open operation, show all operations | none |
|
||||
| System operation detail | Platform operator | Detail-first Operational Surface | What happened on this operation, and what follow-up is appropriate? | operation identity, status, outcome, related scope, dominant failure or stall context, related links | low-level payloads, internal traces, and extended diagnostics | execution outcome, lifecycle state, operability context | Existing platform triage only | Show all operations, go to runbooks, retry operation, mark investigated | Cancel operation when still cancellable |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: No
|
||||
- **New persisted entity/table/artifact?**: No
|
||||
- **New abstraction?**: No
|
||||
- **New enum/state/reason family?**: No
|
||||
- **New cross-domain UI framework/taxonomy?**: No
|
||||
- **Current operator problem**: The three system operations list pages currently behave like scan-first registry surfaces but also expose direct triage actions, underdefined empty states, and competing Operations versus Runs naming that duplicate or dilute the canonical detail model.
|
||||
- **Existing structure is insufficient because**: The current list surfaces split triage ownership between list and detail, which makes the lists behave like mini control centers instead of scan-first registries.
|
||||
- **Narrowest correct implementation**: Keep the existing system lists and the existing system operation detail page, but move triage ownership fully onto the detail page, align visible naming to Operations / Operation, and give each list one clear navigation CTA without changing persistence or introducing new surfaces.
|
||||
- **Ownership cost**: Existing list and guard tests need to be updated, and operators lose direct row-level triage from the lists in exchange for one consistent detail-first follow-up model.
|
||||
- **Alternative intentionally rejected**: Reclassifying the system lists into a queue or review surface was rejected because the pages are scan-first registries split by status family, not context-preserving queue workflows.
|
||||
- **Release truth**: Current-release truth. The repo already contains the canonical detail page and the duplicated list triage actions; this slice removes the duplication rather than adding new capability.
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Scan Lists Without Competing Actions (Priority: P1)
|
||||
|
||||
As a platform operator, I want the Operations, Failed operations, and Stuck operations lists to behave as scan-first registries with one obvious open path and one clear navigation CTA, so that I can inspect the right operation without row-level action clutter.
|
||||
|
||||
**Why this priority**: This is the direct constitution violation on the current system operations surfaces.
|
||||
|
||||
**Independent Test**: Can be fully tested by loading each system operations list and asserting that rows remain clickable, row-level triage actions are absent, visible labels use Operations / Operation vocabulary, and each list exposes the expected primary CTA in header and empty state.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a platform operator opens the system Operations list, **When** the table renders, **Then** each row opens the system operation detail page through row click, exposes no row-level triage actions, and keeps `Go to runbooks` as the single header and empty-state CTA.
|
||||
2. **Given** a platform operator opens the system Failed operations list, **When** the table renders, **Then** the row remains clickable, the list does not expose retry, cancel, or investigate actions inline, and `Show all operations` is the single header and empty-state CTA.
|
||||
3. **Given** a platform operator opens the system Stuck operations list, **When** the table renders, **Then** the row remains clickable, the list does not expose retry, cancel, or investigate actions inline, and `Show all operations` is the single header and empty-state CTA.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Perform Triage From The Canonical Detail Page (Priority: P1)
|
||||
|
||||
As a platform operator with manage capability, I want system operation triage to live on the canonical operation detail page, so that every follow-up action happens in the surface that already owns full context and keeps a clear return path to all operations.
|
||||
|
||||
**Why this priority**: The lists can only become constitution-compliant if the detail page becomes the single triage destination.
|
||||
|
||||
**Independent Test**: Can be fully tested by opening a system operation detail page as a manage-capable operator and asserting that retry, cancel, and mark investigated remain available there with the same audit and queued-run behavior, while `Show all operations` remains available as the return path.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a failed operation and a manage-capable platform operator, **When** the operator opens the system operation detail page, **Then** retry remains available on the detail header and still queues a replacement operation.
|
||||
2. **Given** a cancellable operation and a manage-capable platform operator, **When** the operator opens the system operation detail page, **Then** cancel remains available on the detail header and still requires confirmation.
|
||||
3. **Given** an operation that needs documentation, **When** the operator opens the system operation detail page, **Then** mark investigated remains available there, still records the investigation action, and the page keeps `Show all operations` as the canonical return link.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Preserve View-Only Access Semantics (Priority: P2)
|
||||
|
||||
As a platform operator with view-only access, I want to inspect system operations without being offered triage controls, so that the platform plane stays capability-correct while the aligned surfaces remain usable.
|
||||
|
||||
**Why this priority**: Surface alignment must not weaken the existing view/manage separation.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering list and detail surfaces for a view-only system user and asserting that inspection and navigation remain available while triage actions remain hidden.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a platform user with operations view but not operations manage, **When** the user opens any system operations list, **Then** the user can inspect rows, use the page CTA, but sees no triage actions there.
|
||||
2. **Given** a platform user with operations view but not operations manage, **When** the user opens a system operation detail page, **Then** retry, cancel, and mark investigated remain hidden while `Show all operations` and `Go to runbooks` remain available.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- A failed operation appears on both the all-operations list and the failed-operations list; both surfaces must expose the same single open model and must not diverge in row actions or naming.
|
||||
- A queued or running operation later becomes cancellable or non-cancellable; the list remains read-only while the detail page resolves whether cancel is available.
|
||||
- The system operation detail page must keep a clear return path to the canonical Operations list even when opened from Failed operations or Stuck operations.
|
||||
- Empty Operations, Failed operations, and Stuck operations states must remain explanation-first while still exposing exactly one primary CTA that matches the page contract.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
**Constitution alignment (required):** This feature introduces no Microsoft Graph calls, no new write workflow, and no new long-running work. Existing `OperationRun` and triage services remain the underlying execution model. The feature only realigns where platform operators inspect and triage existing system runs.
|
||||
|
||||
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature adds no new structure, persistence, abstraction, or state family. It reduces surface complexity by removing duplicated triage ownership from the lists.
|
||||
|
||||
**Constitution alignment (OPS-UX):** Existing retry and cancel flows continue to reuse the current queued-run UX, terminal notification rules, and service-owned `OperationRun` lifecycle. This feature does not introduce a new run type or change lifecycle ownership.
|
||||
|
||||
**Constitution alignment (RBAC-UX):** This feature stays in the platform plane only. Existing `OPERATIONS_VIEW` and `OPERATIONS_MANAGE` capability checks remain the server-side source of truth. List alignment must not weaken the current distinction between view-only inspection and manage-capable triage.
|
||||
|
||||
**Constitution alignment (OPS-EX-AUTH-001):** Not applicable.
|
||||
|
||||
**Constitution alignment (BADGE-001):** Existing status and outcome badge semantics remain unchanged and centralized.
|
||||
|
||||
**Constitution alignment (UI-FIL-001):** The feature continues to use Filament-native tables, row navigation, header actions, confirmation modals, and notifications. No custom local action framework or styling language is introduced.
|
||||
|
||||
**Constitution alignment (UI-NAMING-001):** This slice standardizes the changed system-plane surfaces to the canonical visible nouns `Operations` and `Operation`. Existing internal PHP class names and route paths may remain stable, but operator-facing labels, headings, and return links MUST stop presenting `Runs` as the primary noun.
|
||||
|
||||
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** The system Runs, Failures, and Stuck pages MUST align to the Read-only Registry / Report surface rules: one-click row open, no competing inline triage controls, and no destructive actions on the list rows. The system run detail page MUST remain the sole triage surface for retry, cancel, and mark investigated.
|
||||
|
||||
**Constitution alignment (OPSURF-001):** The lists remain operator-first scan surfaces that show only the truth needed to choose the next run to inspect. Full follow-up context and triage remain on the detail page, where diagnostic depth already exists.
|
||||
|
||||
**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** This feature does not add a new semantic layer. It removes duplicated action ownership and keeps tests focused on operator-visible behavior: list inspect model, detail triage ownership, and manage-vs-view capability behavior.
|
||||
|
||||
**Constitution alignment (Filament Action Surfaces):** The Action Surface Contract is satisfied when Operations, Failed operations, and Stuck operations expose row click only, keep bulk actions absent by explicit no-bulk need, provide one header and empty-state CTA each, and leave retry, cancel, and mark investigated to the detail header. No new exemption is introduced.
|
||||
|
||||
**Constitution alignment (UX-001 — Layout & Information Architecture):** List layouts remain scanable registry tables. The system run detail page remains the operational detail surface and continues to own richer follow-up actions. No create or edit layout changes are introduced.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-170-001**: The system Operations list MUST behave as a read-only registry surface with one primary inspect model: full-row click to the canonical system operation detail page.
|
||||
- **FR-170-002**: The system Failed operations list MUST behave as a read-only registry surface with one primary inspect model: full-row click to the canonical system operation detail page.
|
||||
- **FR-170-003**: The system Stuck operations list MUST behave as a read-only registry surface with one primary inspect model: full-row click to the canonical system operation detail page.
|
||||
- **FR-170-004**: the Operations, Failed operations, and Stuck operations lists MUST NOT render retry, cancel, or mark investigated as row actions.
|
||||
- **FR-170-005**: The canonical system operation detail page MUST remain the only system-plane surface that exposes retry, cancel, and mark investigated actions.
|
||||
- **FR-170-006**: Retry on the system operation detail page MUST preserve the current queued-run feedback behavior and the current link back to the newly queued operation.
|
||||
- **FR-170-007**: Cancel on the system operation detail page MUST remain confirmation-gated and MUST stay available only when the current operation is still cancellable.
|
||||
- **FR-170-008**: Mark investigated on the system operation detail page MUST remain confirmation-gated and MUST continue to require an operator-supplied reason.
|
||||
- **FR-170-009**: View-only platform operators MUST remain able to open list rows and detail pages while triage actions remain hidden.
|
||||
- **FR-170-010**: Manage-capable platform operators MUST retain triage capability on the system operation detail page after list row actions are removed.
|
||||
- **FR-170-011**: Existing audit behavior for retry and mark investigated MUST remain unchanged.
|
||||
- **FR-170-012**: The system operation detail page MUST provide a clear `Show all operations` return path to the canonical collection route while preserving `Go to runbooks` navigation.
|
||||
- **FR-170-013**: This feature MUST NOT introduce a new page, a new system operations capability, or a new persisted artifact.
|
||||
- **FR-170-014**: Repository guard tests for the system operations surfaces MUST be updated so they assert row-click-only lists, list CTAs, canonical Operations / Operation naming, and detail-owned triage instead of direct row triage.
|
||||
- **FR-170-015**: The changed system surfaces MUST use `Operations` as the canonical visible collection noun and `Operation` as the canonical visible singular noun.
|
||||
- **FR-170-016**: Each changed system list surface MUST expose exactly one primary empty-state CTA and the corresponding header action when records exist.
|
||||
|
||||
## UI Action Matrix *(mandatory when Filament is changed)*
|
||||
|
||||
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| System operations list | `app/Filament/System/Pages/Ops/Runs.php` | `Go to runbooks` | `recordUrl()` full-row click | none | none | `Go to runbooks` | n/a | n/a | no new audit behavior | Read-only Registry / Report; visible label becomes `Operations` |
|
||||
| System failed operations list | `app/Filament/System/Pages/Ops/Failures.php` | `Show all operations` | `recordUrl()` full-row click | none | none | `Show all operations` | n/a | n/a | no new audit behavior | Read-only Registry / Report; visible label becomes `Failed operations` |
|
||||
| System stuck operations list | `app/Filament/System/Pages/Ops/Stuck.php` | `Show all operations` | `recordUrl()` full-row click | none | none | `Show all operations` | n/a | n/a | no new audit behavior | Read-only Registry / Report; visible label becomes `Stuck operations` |
|
||||
| System operation detail | `app/Filament/System/Pages/Ops/ViewRun.php`, `resources/views/filament/system/pages/ops/view-run.blade.php` | `Show all operations`, `Go to runbooks` | n/a | n/a | n/a | n/a | `Retry`, `Cancel`, `Mark investigated` | n/a | existing retry and mark-investigated audit behavior remains | Detail-first operational owner of triage; heading and return link use `Operation` |
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **System operations list surface**: The system-panel Operations, Failed operations, and Stuck operations pages that scan existing `OperationRun` records.
|
||||
- **System operation detail surface**: The canonical system detail page for one selected `OperationRun`.
|
||||
- **System operation triage action**: Existing follow-up actions for retry, cancel, and mark investigated.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
- **SC-170-001**: Operations, Failed operations, and Stuck operations each expose exactly one primary inspect model in automated coverage: row click to the canonical system operation detail page.
|
||||
- **SC-170-002**: Automated coverage verifies that Operations, Failed operations, and Stuck operations expose zero row-level triage actions.
|
||||
- **SC-170-003**: Automated coverage verifies that the system operation detail page still exposes retry, cancel, and mark investigated for manage-capable operators when each action is legitimately available.
|
||||
- **SC-170-004**: Automated coverage verifies that view-only platform operators can inspect system operations but cannot see manage-only triage actions on the detail page.
|
||||
- **SC-170-005**: Automated coverage verifies that the changed system surfaces use the canonical visible nouns `Operations` and `Operation` and expose the expected header or empty-state CTA on each list surface.
|
||||
- **SC-170-006**: The feature ships without adding any new capability, persistence, or UI exemption.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- The current system run detail page remains the correct canonical place for triage ownership.
|
||||
- Existing audit behavior for retry and mark investigated is correct and does not need redesign in this slice.
|
||||
- Existing internal route paths under `/system/ops/runs` may remain stable while visible system-surface naming is standardized in this slice.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Renaming internal PHP class names or changing existing `/system/ops/runs` route paths
|
||||
- Retrofitting deferred dashboard, onboarding, or landing surfaces
|
||||
- Changing `OperationRun` lifecycle semantics, run creation behavior, or notification taxonomy
|
||||
- Introducing a queue/review model for the system Operations, Failed operations, or Stuck operations pages
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Existing system operations list pages: Runs, Failures, and Stuck
|
||||
- Existing system run detail page
|
||||
- Existing `OperationRunTriageService`
|
||||
- Existing platform capability and audit behavior
|
||||
- Existing action-surface and system operations guard coverage
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Spec 170 is complete when the three changed system list pages are scan-first row-click-only registry surfaces, visible system naming uses Operations / Operation, each list has one matching header and empty-state CTA, the system operation detail page is the sole owner of retry/cancel/investigate triage and exposes `Show all operations`, existing view/manage capability semantics remain intact, and guard tests reflect the aligned interaction model.
|
||||
199
specs/170-system-operations-surface-alignment/tasks.md
Normal file
199
specs/170-system-operations-surface-alignment/tasks.md
Normal file
@ -0,0 +1,199 @@
|
||||
# Tasks: System Operations Surface Alignment
|
||||
|
||||
**Input**: Design documents from `/specs/170-system-operations-surface-alignment/`
|
||||
**Prerequisites**: plan.md, spec.md, research.md, data-model.md, quickstart.md, contracts/system-ops-surface-contract.yaml
|
||||
|
||||
**Tests**: Runtime behavior changes in this repo require Pest coverage. Each story below includes test work and focused verification.
|
||||
|
||||
**Organization**: Tasks are grouped by user story so each story can be implemented and validated independently where the current surface boundaries allow it.
|
||||
|
||||
## Phase 1: Setup
|
||||
|
||||
**Purpose**: Lock the implementation targets to the generated plan artifacts before runtime edits begin.
|
||||
|
||||
- [X] T001 Reconfirm the implementation and verification targets in `specs/170-system-operations-surface-alignment/contracts/system-ops-surface-contract.yaml` and `specs/170-system-operations-surface-alignment/quickstart.md` before editing runtime files.
|
||||
- [X] T002 Inspect the current system ops touchpoints in `app/Filament/System/Pages/Ops/Runs.php`, `app/Filament/System/Pages/Ops/Failures.php`, `app/Filament/System/Pages/Ops/Stuck.php`, `app/Filament/System/Pages/Ops/ViewRun.php`, `tests/Feature/System/Spec114/OpsTriageActionsTest.php`, and `tests/Feature/Guards/ActionSurfaceContractTest.php` so every direct row-triage assertion is mapped to the aligned target behavior.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational
|
||||
|
||||
**Purpose**: Establish the shared regression baseline that all story work must satisfy.
|
||||
|
||||
**⚠️ CRITICAL**: No user story work should be considered complete until these shared assertions are updated.
|
||||
|
||||
- [X] T003 Update the shared system surface regression contract in `tests/Feature/Guards/ActionSurfaceContractTest.php` so the baseline expects clickable rows, canonical `Operations` naming, explicit list CTA behavior, and no row triage on the changed system pages.
|
||||
- [X] T004 Update the shared system triage and navigation scenario coverage in `tests/Feature/System/Spec114/OpsTriageActionsTest.php` so list-surface, detail-surface, view-only, and `Show all operations` assertions can be expressed separately.
|
||||
|
||||
**Checkpoint**: Shared contract coverage is ready; story implementation can now proceed.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 - Scan Lists Without Competing Actions (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: Make the Operations, Failed operations, and Stuck operations pages behave as scan-first registry surfaces with row-click-only inspection, stable naming, and one clear CTA each.
|
||||
|
||||
**Independent Test**: Load each list page and verify `recordUrl()` row navigation remains intact, all row-level triage actions are absent, visible copy uses `Operations` / `Operation`, and the correct single CTA appears in both header and empty state.
|
||||
|
||||
### Tests for User Story 1
|
||||
|
||||
- [X] T005 [US1] Add failing list-behavior and CTA assertions in `tests/Feature/System/Spec114/OpsTriageActionsTest.php` that require row-click-only behavior, canonical `Operations` naming, and the correct single CTA on the changed system lists.
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [X] T006 [P] [US1] Remove `retry`, `cancel`, and `mark_investigated` row actions, rename the visible label to `Operations`, add the `Go to runbooks` header and empty-state CTA, and update the action-surface declaration wording in `app/Filament/System/Pages/Ops/Runs.php`.
|
||||
- [X] T007 [P] [US1] Remove `retry`, `cancel`, and `mark_investigated` row actions, rename the visible label to `Failed operations`, add the `Show all operations` header and empty-state CTA, and update the action-surface declaration wording in `app/Filament/System/Pages/Ops/Failures.php`.
|
||||
- [X] T008 [P] [US1] Remove `retry`, `cancel`, and `mark_investigated` row actions, rename the visible label to `Stuck operations`, add the `Show all operations` header and empty-state CTA, and update the action-surface declaration wording in `app/Filament/System/Pages/Ops/Stuck.php`.
|
||||
- [X] T009 [US1] Verify the three list pages still use `recordUrl()` and expose the correct CTA behavior in `app/Filament/System/Pages/Ops/Runs.php`, `app/Filament/System/Pages/Ops/Failures.php`, and `app/Filament/System/Pages/Ops/Stuck.php`.
|
||||
- [X] T010 [US1] Run the focused list-surface regression checks in `tests/Feature/Guards/ActionSurfaceContractTest.php` and `tests/Feature/System/Spec114/OpsTriageActionsTest.php`.
|
||||
|
||||
**Checkpoint**: The three system list pages are row-click-only registry surfaces and can be validated independently.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 - Perform Triage From The Canonical Detail Page (Priority: P1)
|
||||
|
||||
**Goal**: Keep the existing `ViewRun` page as the sole triage surface for retry, cancel, and mark investigated while exposing `Show all operations` as the canonical return path.
|
||||
|
||||
**Independent Test**: Open a system operation detail page as a manage-capable platform user and verify header-based retry, cancel, and mark-investigated behavior still works with the same queued-toast, confirmation, and audit expectations, while `Show all operations` and `Go to runbooks` remain available.
|
||||
|
||||
### Tests for User Story 2
|
||||
|
||||
- [X] T011 [US2] Add failing detail-page triage and return-path assertions in `tests/Feature/System/Spec114/OpsTriageActionsTest.php` for `Retry`, `Cancel`, `Mark investigated`, `Show all operations`, and visible `Operation` copy on `app/Filament/System/Pages/Ops/ViewRun.php`.
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [X] T012 [US2] Keep `app/Filament/System/Pages/Ops/ViewRun.php` as the sole triage owner and ensure header actions expose `Show all operations`, `Go to runbooks`, and the existing manage-only triage behavior through `app/Support/System/SystemOperationRunLinks.php`.
|
||||
- [X] T013 [US2] Update the visible detail copy and return-link presentation in `resources/views/filament/system/pages/ops/view-run.blade.php` so the page uses `Operation #...` and shows `Show all operations` alongside `Go to runbooks`.
|
||||
- [X] T014 [US2] Preserve existing retry, cancel, and investigation behavior without new lifecycle or audit changes in `app/Services/SystemConsole/OperationRunTriageService.php`.
|
||||
- [X] T015 [US2] Run the focused detail-triage and return-path checks in `tests/Feature/System/Spec114/OpsTriageActionsTest.php`.
|
||||
|
||||
**Checkpoint**: Detail-page triage ownership is intact and independently verified.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 - Preserve View-Only Access Semantics (Priority: P2)
|
||||
|
||||
**Goal**: Preserve the existing view/manage capability split so view-only operators can inspect and navigate but not triage.
|
||||
|
||||
**Independent Test**: Render the aligned list and detail surfaces for a view-only platform user and verify inspection and navigation remain available while triage actions stay hidden.
|
||||
|
||||
### Tests for User Story 3
|
||||
|
||||
- [X] T016 [US3] Add failing view-only authorization assertions in `tests/Feature/System/Spec114/OpsTriageActionsTest.php` covering list inspection, visible CTA navigation, and hidden detail-header triage.
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [X] T017 [US3] Keep manage-only detail action visibility intact in `app/Filament/System/Pages/Ops/ViewRun.php` while preserving view access and list CTA visibility in `app/Filament/System/Pages/Ops/Runs.php`, `app/Filament/System/Pages/Ops/Failures.php`, and `app/Filament/System/Pages/Ops/Stuck.php`.
|
||||
- [X] T018 [US3] Reconfirm platform operations access expectations in `tests/Feature/System/Spec114/OpsFailuresViewTest.php` and `tests/Feature/System/Spec114/OpsStuckViewTest.php` after the surface alignment changes.
|
||||
- [X] T019 [US3] Run the focused authorization checks in `tests/Feature/System/Spec114/OpsTriageActionsTest.php`, `tests/Feature/System/Spec114/OpsFailuresViewTest.php`, and `tests/Feature/System/Spec114/OpsStuckViewTest.php`.
|
||||
|
||||
**Checkpoint**: View-only operators can inspect aligned system surfaces without gaining triage controls.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Final cleanup and verification across all stories.
|
||||
|
||||
- [X] T020 Run formatting with `vendor/bin/sail bin pint --dirty --format agent` for `app/Filament/System/Pages/Ops/Runs.php`, `app/Filament/System/Pages/Ops/Failures.php`, `app/Filament/System/Pages/Ops/Stuck.php`, `app/Filament/System/Pages/Ops/ViewRun.php`, `resources/views/filament/system/pages/ops/view-run.blade.php`, `tests/Feature/System/Spec114/OpsTriageActionsTest.php`, and `tests/Feature/Guards/ActionSurfaceContractTest.php`.
|
||||
- [X] T021 Run the full focused regression pack from `specs/170-system-operations-surface-alignment/quickstart.md` against `tests/Feature/Guards/ActionSurfaceContractTest.php`, `tests/Feature/System/Spec114/OpsTriageActionsTest.php`, `tests/Feature/System/Spec114/OpsFailuresViewTest.php`, and `tests/Feature/System/Spec114/OpsStuckViewTest.php`.
|
||||
- [X] T022 Validate the final behavior against `specs/170-system-operations-surface-alignment/contracts/system-ops-surface-contract.yaml` and `specs/170-system-operations-surface-alignment/quickstart.md` before handoff.
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: No dependencies.
|
||||
- **Foundational (Phase 2)**: Depends on Setup and establishes the shared regression baseline.
|
||||
- **User Story 1 (Phase 3)**: Depends on Foundational.
|
||||
- **User Story 2 (Phase 4)**: Depends on Foundational.
|
||||
- **User Story 3 (Phase 5)**: Depends on User Story 1 and User Story 2 because it validates the final aligned list-plus-detail authorization and navigation behavior.
|
||||
- **Polish (Phase 6)**: Depends on the desired user stories being complete.
|
||||
|
||||
### User Story Dependencies
|
||||
|
||||
- **US1**: Independent after Phase 2; it only changes list-surface semantics.
|
||||
- **US2**: Independent after Phase 2; it preserves existing detail-surface triage ownership.
|
||||
- **US3**: Validates the final permission split across the aligned list and detail surfaces, so it should run after US1 and US2 settle the interaction model.
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Update story-specific tests first and make them fail for the intended new behavior.
|
||||
- Apply source changes next.
|
||||
- Run the smallest focused verification pack before moving on.
|
||||
|
||||
---
|
||||
|
||||
## Parallel Opportunities
|
||||
|
||||
- T006, T007, and T008 can run in parallel because they modify different list-page files.
|
||||
- US1 and US2 can proceed in parallel after Phase 2 if test-file coordination is handled deliberately.
|
||||
- Polish verification can start as soon as the last required story is merged locally.
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 1
|
||||
|
||||
```bash
|
||||
Task: "T006 Remove row triage actions in app/Filament/System/Pages/Ops/Runs.php"
|
||||
Task: "T007 Remove row triage actions in app/Filament/System/Pages/Ops/Failures.php"
|
||||
Task: "T008 Remove row triage actions in app/Filament/System/Pages/Ops/Stuck.php"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 2
|
||||
|
||||
```bash
|
||||
Task: "T011 Add detail-page triage and return-path assertions in tests/Feature/System/Spec114/OpsTriageActionsTest.php"
|
||||
Task: "T013 Update visible detail copy in resources/views/filament/system/pages/ops/view-run.blade.php"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Parallel Example: User Story 3
|
||||
|
||||
```bash
|
||||
Task: "T016 Add view-only authorization assertions in tests/Feature/System/Spec114/OpsTriageActionsTest.php"
|
||||
Task: "T018 Reconfirm access expectations in tests/Feature/System/Spec114/OpsFailuresViewTest.php and tests/Feature/System/Spec114/OpsStuckViewTest.php"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### MVP First (User Story 1 Only)
|
||||
|
||||
1. Complete Phase 1: Setup.
|
||||
2. Complete Phase 2: Foundational.
|
||||
3. Complete Phase 3: User Story 1.
|
||||
4. Validate the row-click-only list behavior with the focused regression pack.
|
||||
5. Demo the aligned registry surfaces before touching any further hardening.
|
||||
|
||||
### Incremental Delivery
|
||||
|
||||
1. Finish Setup + Foundational to lock the shared regression baseline.
|
||||
2. Deliver US1 to normalize the list surfaces.
|
||||
3. Deliver US2 to prove detail-page triage remains the sole operational owner and preserves the canonical return path.
|
||||
4. Deliver US3 to confirm the final view/manage capability split.
|
||||
5. Run Phase 6 polish checks and hand off.
|
||||
|
||||
### Parallel Team Strategy
|
||||
|
||||
1. One engineer updates the shared regression baseline in Phase 2.
|
||||
2. After Phase 2:
|
||||
- Engineer A can take US1 list-page updates.
|
||||
- Engineer B can take US2 detail-page preservation work.
|
||||
3. Once US1 and US2 land locally, a final pass can execute US3 authorization hardening and the polish phase.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- `[P]` tasks touch different files and have no unfinished dependencies.
|
||||
- Story labels map directly to the three user stories in `spec.md`.
|
||||
- This feature intentionally avoids route renames, capability changes, schema changes, and new UI exemptions.
|
||||
- Keep `OperationRunTriageService` narrow unless a behavior-preserving tweak is genuinely required.
|
||||
@ -0,0 +1,35 @@
|
||||
# Specification Quality Checklist: Operations Naming Consolidation
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-03-30
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Validation pass 1: complete
|
||||
- This spec intentionally starts after Spec 170 and is limited to residual operator-visible naming drift outside the already-aligned system operations surfaces.
|
||||
181
specs/171-operations-naming-consolidation/spec.md
Normal file
181
specs/171-operations-naming-consolidation/spec.md
Normal file
@ -0,0 +1,181 @@
|
||||
# Feature Specification: Operations Naming Consolidation
|
||||
|
||||
**Feature Branch**: `171-operations-naming-consolidation`
|
||||
**Created**: 2026-03-30
|
||||
**Status**: Draft
|
||||
**Input**: User description: "Operations Naming Consolidation"
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: workspace + tenant + canonical-view + platform
|
||||
- **Primary Routes**:
|
||||
- `/admin/operations`
|
||||
- `/admin/operations/{run}`
|
||||
- `/admin/t/{tenant}`
|
||||
- `/system/ops/runs/{run}`
|
||||
- **Data Ownership**:
|
||||
- No new platform-owned, workspace-owned, or tenant-owned records are introduced
|
||||
- Existing `OperationRun` records remain the only source of truth for operation history, status, and deep-link destinations
|
||||
- Existing notifications, related-navigation payloads, reference summaries, and embedded report components remain derived presentation layers only
|
||||
- **RBAC**:
|
||||
- No new capability, role, or authorization plane is introduced
|
||||
- Existing admin, tenant, and platform route guards remain authoritative for whether an operator may open a given operation destination
|
||||
- This feature changes visible operator vocabulary only; it does not widen access to any operation route or action
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | 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 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Shared operation links and related navigation | Embedded related-navigation affordance | Explicit safe link to one existing operation | n/a | inline or footer placement only | none | panel-appropriate operations list | panel-appropriate operation detail | current panel and current scope remain legible | Operations / Operation | destination label, operation identity, scope cue | none |
|
||||
| Tenantless/admin operation detail viewers | Detail-first Operational Surface | Dedicated detail page | forbidden | detail header or related-links group only | detail header only | `/admin/operations` or `/system/ops/runs` | panel-appropriate operation detail route | workspace or platform context explicit | Operations / Operation | operation identity, outcome, context, next navigation | none |
|
||||
| Verification and onboarding operation report surfaces | Embedded operator detail panel | One primary CTA to the existing operation when present | forbidden | low-emphasis advanced links only when justified | none | panel-appropriate operations list when needed | panel-appropriate operation detail route | tenant/workspace context and verification context visible | Operations / Operation | verification status, operation identity, recency | none |
|
||||
| Summary and health widgets that reference operations | Embedded status summary | Explicit single CTA or passive summary with no competing link | forbidden | card footer or summary action only | none | panel-appropriate operations list | panel-appropriate operation detail route when singular | current scope stays explicit | Operations / Operation | counts, status family, scope | none |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| Shared operation links and related navigation | Workspace, tenant, or platform operator | Embedded related-navigation affordance | Which operation does this link open? | explicit `Operation` noun, stable verb, scope cue when needed | raw route names or internal type strings stay hidden | navigation context only | none | `Open operation` or route-equivalent collection navigation | none |
|
||||
| Tenantless/admin operation detail viewers | Workspace or platform operator | Detail-first Operational Surface | What happened on this operation? | operation title, `Operation #<id>`, outcome, scope, next steps | extended payloads and traces stay in diagnostics sections | execution outcome, lifecycle, operability | existing detail-owned actions only | existing detail navigation and triage actions | existing detail-owned destructive actions only |
|
||||
| Verification and onboarding operation report surfaces | Workspace or tenant operator | Embedded operator detail panel | What verification operation ran, and how do I inspect it? | verification state, operation identity, timestamp, one primary link | low-level JSON, hashes, and raw provider details stay behind explicit reveal | verification status, operation recency | none | `Open operation`, workflow-native next-step CTA such as `Start verification` | none |
|
||||
| Summary and health widgets that reference operations | Workspace, tenant, or platform operator | Embedded status summary | Are there failed, stuck, or recent operations I should inspect? | pluralized operation labels, counts, scope, one clear drill-in | raw IDs and detailed traces stay on destination surfaces | count state, health family, recency | none | collection drill-in or none | none |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: No
|
||||
- **New persisted entity/table/artifact?**: No
|
||||
- **New abstraction?**: No
|
||||
- **New enum/state/reason family?**: No
|
||||
- **New cross-domain UI framework/taxonomy?**: No
|
||||
- **Current operator problem**: Outside the system-panel surfaces already aligned by Spec 170, the repo still exposes `View run`, `Run ID`, `Run #...`, and plural `runs` wording across notifications, related links, verification reports, admin viewers, and health widgets, which makes the same `OperationRun` record look like different domain objects depending on where the operator encounters it.
|
||||
- **Existing structure is insufficient because**: Shared label catalogs, reference resolvers, and embedded components still permit local wording drift, so isolated copy fixes would keep reintroducing inconsistent nouns.
|
||||
- **Narrowest correct implementation**: Standardize only operator-visible naming for existing `OperationRun` record references outside Spec 170, reuse the existing routes and destinations, and update the shared label-producing layers that feed multiple surfaces.
|
||||
- **Ownership cost**: Existing feature and guard tests will need wording updates, and a small number of embedded report components will need representative coverage so naming drift does not return.
|
||||
- **Alternative intentionally rejected**: Renaming PHP classes, route slugs, enum values, or persistence structures was rejected because this slice is about operator-visible language, not internal refactoring.
|
||||
- **Release truth**: Current-release truth. The inconsistent labels already exist in the repo today across tenant, workspace, canonical-view, and platform surfaces.
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Shared Operation Links Use One Vocabulary (Priority: P1)
|
||||
|
||||
As an operator, I want every link to an existing operation record to use the same noun and verb pattern, so that I immediately recognize it as the same destination regardless of which page, widget, or notification I came from.
|
||||
|
||||
**Why this priority**: Shared deep-link labels are the highest-leverage root cause because they feed many surfaces at once.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering representative resources, widgets, shared related-navigation payloads, and notifications that link to existing operation records, then asserting that visible labels use `Open operation` and `Operation #<id>` or `Operation ID` rather than `View run`, `Run #`, or `Run ID`.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a resource, widget, or notification exposes a link to an existing operation, **When** the operator sees that affordance, **Then** the visible action uses `Operation` terminology rather than `run` terminology.
|
||||
2. **Given** a shared reference or related-navigation summary exposes an operation identifier, **When** it renders, **Then** the visible identifier uses `Operation #<id>` or `Operation ID` rather than `Run #<id>` or `Run ID`.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Verification Surfaces Distinguish Workflow Verbs From Operation Records (Priority: P1)
|
||||
|
||||
As a workspace or tenant operator, I want verification and onboarding surfaces to keep workflow verbs like `Start verification` while naming the resulting historical record as an operation, so that the current task and the inspectable record are not collapsed into one ambiguous `run` concept.
|
||||
|
||||
**Why this priority**: Verification widgets, modals, and onboarding reports currently mix workflow language and operation-record language most visibly.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering representative verification and onboarding report surfaces and asserting that workflow actions keep their intended verbs while record links and identifiers use `Operation` terminology.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a verification surface offers the operator a next step, **When** the action starts new work, **Then** it may continue to use a task verb such as `Start verification`.
|
||||
2. **Given** a verification surface shows a historical or in-progress operation record, **When** the operator inspects the metadata or opens the destination, **Then** the visible link and identifier use `Operation` terminology rather than `run` terminology.
|
||||
3. **Given** no verification-backed operation exists yet, **When** the empty state renders, **Then** the explanation avoids using `run` as a fallback noun for the future record.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Summary Surfaces Use Consistent Operation Plurals (Priority: P2)
|
||||
|
||||
As an operator scanning health and summary surfaces, I want counts and helper text to refer to failed, stuck, or recent operations consistently, so that summary cards and widgets reinforce the same vocabulary as detailed destinations.
|
||||
|
||||
**Why this priority**: Summary copy is lower-risk than deep-link labels, but it is high-frequency and shapes daily operator language.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering representative summary widgets or health indicators and asserting that plural copy uses `operations` instead of `runs` when referring to existing `OperationRun` records.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a summary widget describes failed or stuck execution records, **When** it renders, **Then** it uses `operations` rather than `runs` as the visible plural noun.
|
||||
2. **Given** a platform or tenant health indicator refers to recent operation history, **When** it renders, **Then** the summary reinforces the same `Operations / Operation` vocabulary used by links and details.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- Workflow verbs that describe starting new work, such as `Start verification`, remain valid when they describe the task being initiated rather than an already-created `OperationRun` record.
|
||||
- Existing internal route slugs, PHP class names, enum values, and table names may continue to use `run` terminology; this slice only governs operator-visible language.
|
||||
- Shared helper layers must not regress Spec 170 system-surface naming while this slice updates non-system surfaces.
|
||||
- A surface may link to either workspace/admin or platform detail, but the visible noun must still describe the destination record as an `Operation`.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
**Constitution alignment (required):** This feature introduces no new execution path, no new outbound work, and no new long-running process. It only standardizes visible operator-facing language for existing `OperationRun` references.
|
||||
|
||||
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature adds no new structure, persistence, abstraction, or state family. It reduces naming drift in the existing presentation layer.
|
||||
|
||||
**Constitution alignment (UI-NAMING-001):** Operator-visible references to `OperationRun` records outside Spec 170 MUST resolve to the canonical visible nouns `Operations` and `Operation`, while internal implementation names may remain stable.
|
||||
|
||||
**Constitution alignment (OPSURF-001):** Shared links, embedded reports, and summary widgets must describe existing operation records with the same vocabulary as the canonical destinations they open.
|
||||
|
||||
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-REVIEW-001):** This slice does not introduce new operator surfaces, but it must keep primary navigation labels, identifiers, and summary nouns consistent across existing surfaces so operators do not learn multiple names for the same domain object.
|
||||
|
||||
**Constitution alignment (UI-FIL-001):** Existing Filament actions, widgets, notifications, and embedded components remain the delivery mechanism. No new local UI framework or styling system is introduced.
|
||||
|
||||
**Constitution alignment (TEST-TRUTH-001):** Representative coverage must assert visible operator language on shared links and representative components so naming regressions fail in CI instead of relying on manual review.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-171-001**: Operator-visible references to existing `OperationRun` records outside Spec 170 MUST use `Operations` as the canonical visible collection noun and `Operation` as the canonical visible singular noun.
|
||||
- **FR-171-002**: Operator-visible navigation actions that open a specific existing operation record MUST use `Open operation` or a panel-appropriate equivalent rather than `View run`.
|
||||
- **FR-171-003**: Operator-visible identifier labels for existing operation records MUST use `Operation #<id>` and `Operation ID` rather than `Run #<id>` and `Run ID`.
|
||||
- **FR-171-004**: Verification and onboarding surfaces MAY keep workflow verbs such as `Start verification`, but any visible link, identifier, or helper copy that refers to the resulting historical record MUST use `operation` terminology rather than `run` terminology.
|
||||
- **FR-171-005**: Summary or helper copy that refers to multiple existing `OperationRun` records MUST use `operations` rather than `runs` when the subject is operation history, failures, or stuck work.
|
||||
- **FR-171-006**: The implementation MUST update shared label-producing layers, including catalogs, resolvers, reference presenters, or notification builders, wherever those layers are the source of visible naming drift across multiple surfaces.
|
||||
- **FR-171-007**: This feature MUST NOT rename internal PHP class names, route slugs, enum values, persistence artifacts, or operation type identifiers.
|
||||
- **FR-171-008**: Existing route destinations, authorization checks, and operation lifecycle semantics MUST remain unchanged.
|
||||
- **FR-171-009**: Representative automated coverage MUST verify that covered non-system operator surfaces no longer render `View run`, `Run ID`, or `Run #` when referring to an existing `OperationRun` record.
|
||||
|
||||
## UI Action Matrix *(mandatory when Filament is changed)*
|
||||
|
||||
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Shared related links and references | shared presenters, catalogs, and resolvers used across resources and widgets | n/a | explicit `Open operation` link when present | existing safe link only | n/a | n/a | n/a | n/a | no new audit behavior | Naming-only slice; no new action family |
|
||||
| Tenantless/admin operation viewers | `app/Filament/Pages/Operations/TenantlessOperationRunViewer.php` and shared reference summaries | existing viewer actions remain | n/a | existing related links remain | n/a | n/a | existing header actions remain | n/a | no new audit behavior | Title, secondary labels, and related links use `Operation` |
|
||||
| Verification and onboarding report surfaces | tenant widgets and onboarding report/modals under `resources/views/filament/**` and their backing widgets/pages | existing workflow actions remain | n/a | one existing safe operation link when present | n/a | existing workflow CTA remains on owning surface | n/a | n/a | no new audit behavior | Workflow verbs stay task-oriented; record links and IDs use `Operation` |
|
||||
| Summary and health widgets | representative tenant/platform widgets that describe operation history | existing page/widget actions remain | n/a | single existing drill-in or passive summary | n/a | existing surface-specific CTA behavior remains | n/a | n/a | no new audit behavior | Summary nouns use `operations` rather than `runs` |
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **Shared operation label source**: Existing catalogs, resolvers, presenters, or notifications that emit operator-facing operation labels.
|
||||
- **Embedded operation report surface**: Existing widget, modal, or Blade component that exposes one operation record inside a broader workflow.
|
||||
- **Operation summary copy**: Existing pluralized helper or status text that describes multiple `OperationRun` records.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
- **SC-171-001**: Representative automated coverage verifies that shared operation links on covered non-system surfaces use `Operation` terminology rather than `run` terminology.
|
||||
- **SC-171-002**: Representative automated coverage verifies that covered verification/onboarding surfaces use `Operation ID` or `Operation #<id>` rather than `Run ID` or `Run #<id>` for existing operation records.
|
||||
- **SC-171-003**: Representative automated coverage verifies that covered summary widgets use plural `operations` wording rather than plural `runs` wording when referring to existing `OperationRun` records.
|
||||
- **SC-171-004**: The feature ships without adding any new route, capability, persistence artifact, or internal rename requirement.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Spec 170 already owns visible Operations / Operation naming for the system-panel operations surfaces.
|
||||
- Panel-appropriate detail routes remain the correct canonical destinations for existing operation records.
|
||||
- Not every use of the English verb `run` is wrong; this slice only governs operator-visible references to `OperationRun` records.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Renaming PHP classes, routes, tables, or enum values that contain `run`
|
||||
- Reworking the action-surface behavior of deferred dashboard or onboarding surfaces beyond visible naming alignment
|
||||
- Changing operation lifecycle semantics, queued-run feedback, or notifications beyond their visible labels
|
||||
- Revisiting operation type taxonomy, `OperationCatalog` strategy, or provider-domain naming beyond the visible operator copy needed for this slice
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Spec 170 system-surface naming alignment
|
||||
- Existing operation detail routes in admin and system panels
|
||||
- Existing shared label catalogs, related-navigation resolvers, reference presenters, notifications, widgets, and verification report components
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Spec 171 is complete when representative non-system operator surfaces that refer to existing `OperationRun` records use `Operations / Operation` as the canonical visible noun family, shared deep-link labels and identifiers no longer say `View run`, `Run ID`, or `Run #`, verification surfaces keep task verbs distinct from record nouns, and automated coverage protects the updated naming without requiring route or persistence refactors.
|
||||
@ -0,0 +1,35 @@
|
||||
# Specification Quality Checklist: Deferred Operator Surfaces Retrofit
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-03-30
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Validation pass 1: complete
|
||||
- This spec intentionally targets only deferred non-table surfaces that already expose operation affordances; unrelated deferred pages remain explicit non-goals unless a later spec enrolls them.
|
||||
180
specs/172-deferred-operator-surfaces-retrofit/spec.md
Normal file
180
specs/172-deferred-operator-surfaces-retrofit/spec.md
Normal file
@ -0,0 +1,180 @@
|
||||
# Feature Specification: Deferred Operator Surfaces Retrofit
|
||||
|
||||
**Feature Branch**: `172-deferred-operator-surfaces-retrofit`
|
||||
**Created**: 2026-03-30
|
||||
**Status**: Draft
|
||||
**Input**: User description: "Deferred Operator Surfaces Retrofit"
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: workspace + tenant + canonical-view
|
||||
- **Primary Routes**:
|
||||
- `/admin/t/{tenant}`
|
||||
- `/admin/operations`
|
||||
- `/admin/operations/{run}`
|
||||
- managed-tenant onboarding flow routes that expose verification operation reports
|
||||
- **Data Ownership**:
|
||||
- No new platform-owned, workspace-owned, or tenant-owned records are introduced
|
||||
- Existing `OperationRun` records remain the only source of truth for operation status, deep-link destinations, and verification history
|
||||
- Tenant dashboard widgets, onboarding report components, and related embedded operation affordances remain derived presentation layers only
|
||||
- **RBAC**:
|
||||
- No new capability family is introduced
|
||||
- Existing tenant, workspace, and admin access rules remain authoritative for every destination that a retrofitted surface may open
|
||||
- Retrofitted surfaces must not imply broader scope than the operator can actually inspect
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | 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 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard operation cards and widgets | Embedded status summary / drill-in surface | Explicit CTA to a tenant-scoped operations destination | forbidden | card footer or secondary widget action only | none | tenant-scoped operations destination in admin panel | panel-appropriate operation detail when singular | current tenant remains explicit before navigation | Operations / Operation | active or recent operation truth, tenant context, next destination | retrofit existing deferred surface |
|
||||
| Tenant verification report widget | Embedded operator detail panel | One primary inspect CTA to the existing operation when present | forbidden | advanced admin/monitoring link only if justified and clearly secondary | none | panel-appropriate operations collection when needed | panel-appropriate operation detail route | tenant context and current verification state explicit | Operations / Operation | verification state, operation identity, recency | retrofit existing deferred surface |
|
||||
| Managed-tenant onboarding verification report and technical-details surfaces | Guided workflow sub-surface | One primary inspect CTA to the existing operation when present, otherwise one workflow-next-step CTA | forbidden | low-emphasis advanced links only when justified | none | panel-appropriate operations collection when needed | panel-appropriate operation detail route | workspace, tenant, and verification context explicit | Operations / Operation | verification status, operation identity, stale-state explanation | retrofit existing deferred surface |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard operation cards and widgets | Tenant operator | Embedded status summary / drill-in surface | What is happening in this tenant, and where do I inspect it? | tenant-scoped count or recent activity, explicit destination scope, one clear CTA | raw operation payloads and extended traces stay on destination surfaces | recency, active-state, failure/stuck summary | none | tenant-scoped operations drill-in | none |
|
||||
| Tenant verification report widget | Tenant operator | Embedded operator detail panel | What verification operation ran for this tenant, and how do I inspect it? | verification result, one primary operation link, operation identity, timestamp | raw provider diagnostics stay behind explicit reveal or destination detail | verification outcome, recency, stale-state | none | `Open operation` or current-step CTA | none |
|
||||
| Managed-tenant onboarding verification report and technical details | Workspace operator running onboarding | Guided workflow sub-surface | What verification operation supports this onboarding step, and what should I do next? | workflow state, operation identity when present, one primary CTA, scope cue | low-level payloads, hashes, and verbose traces stay in diagnostics sections or canonical detail | workflow status, verification outcome, stale-state | none | `Open operation` or `Start verification` | none |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: No
|
||||
- **New persisted entity/table/artifact?**: No
|
||||
- **New abstraction?**: No
|
||||
- **New enum/state/reason family?**: No
|
||||
- **New cross-domain UI framework/taxonomy?**: No
|
||||
- **Current operator problem**: Dashboard widgets, tenant verification widgets, and onboarding verification components still behave like deferred or exempt surfaces even though they expose meaningful operation drill-ins, which leaves CTA count, scope cues, and deep-link behavior underdefined compared with the now-aligned table and detail surfaces.
|
||||
- **Existing structure is insufficient because**: Spec 169 intentionally left these embedded surfaces out of the table-centric action-surface enforcement path, so the repo still permits tenant-context leaks, competing links, and scope-ambiguous operation affordances on high-traffic summary surfaces.
|
||||
- **Narrowest correct implementation**: Retrofit only the deferred non-table surfaces that already expose operation affordances, give them explicit operator contracts and representative coverage, and keep unrelated deferred pages out of scope.
|
||||
- **Ownership cost**: Existing dashboard and onboarding tests will need to assert CTA count, destination scope, and advanced-link visibility, and the exemption baseline or equivalent governance notes must be narrowed for the retrofitted surfaces.
|
||||
- **Alternative intentionally rejected**: Broadly enrolling every deferred dashboard, chooser, landing page, or page-class route into the main action-surface validator was rejected because this slice only needs to retrofit operation-bearing embedded surfaces, not redesign every deferred surface family.
|
||||
- **Release truth**: Current-release truth. The tenant dashboard and onboarding verification flows already expose operation links today, and current audits show scope and affordance drift on those surfaces.
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Tenant Dashboard Drill-Ins Preserve Tenant Context (Priority: P1)
|
||||
|
||||
As a tenant operator, I want dashboard operation cards and widgets to send me to a destination that clearly preserves my current tenant context, so that I am not silently dropped into a broader workspace-wide operations surface.
|
||||
|
||||
**Why this priority**: Tenant dashboard drill-ins are a frequent entry point and currently carry the clearest cross-scope surprise risk.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering the relevant tenant dashboard operation affordances and asserting that their visible destination semantics remain tenant-scoped and do not silently link to an unfiltered workspace-wide operations surface.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a tenant operator on the tenant dashboard, **When** the operator opens a dashboard operation drill-in, **Then** the destination preserves tenant context or makes the broader scope explicit before navigation.
|
||||
2. **Given** a tenant dashboard widget summarizes recent or active operations, **When** it renders, **Then** it exposes at most one primary operations drill-in rather than multiple competing operation links.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Onboarding And Verification Surfaces Expose One Clear Operation Path (Priority: P1)
|
||||
|
||||
As a workspace or tenant operator, I want verification widgets, onboarding report blocks, and technical-detail overlays to show one clear primary action for the relevant operation record, so that I know exactly where to inspect execution truth without sorting through competing links.
|
||||
|
||||
**Why this priority**: These surfaces are currently exempt yet already act like operator-facing execution summaries.
|
||||
|
||||
**Independent Test**: Can be fully tested by rendering representative tenant verification and onboarding verification surfaces in empty, in-progress, and completed states and asserting that each state has one primary CTA aligned to the operator's next step.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a verification-backed operation exists, **When** the report surface renders, **Then** exactly one primary `Open operation` affordance is visible for that record.
|
||||
2. **Given** no verification-backed operation exists yet, **When** the owning verification or onboarding surface renders, **Then** the operator sees one clear next-step CTA such as `Start verification` and no competing inline operation links.
|
||||
3. **Given** an advanced monitoring destination is still useful for some operators, **When** it is shown, **Then** it is explicitly secondary and does not compete with the primary inspect path.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Retrofitted Deferred Surfaces Gain Explicit Governance (Priority: P2)
|
||||
|
||||
As a reviewer, I want the deferred surfaces that already expose operations to stop relying on blanket exemptions, so that future regressions in CTA count, scope signals, or deep-link behavior are caught automatically.
|
||||
|
||||
**Why this priority**: Without explicit governance, the retrofitted surfaces will remain drift-prone even after a one-time UX fix.
|
||||
|
||||
**Independent Test**: Can be fully tested by proving that representative tenant dashboard and onboarding verification surfaces are covered by dedicated tests or governance checks, while unrelated deferred surfaces remain explicit non-goals.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the retrofit is complete, **When** representative tests or governance checks run, **Then** tenant dashboard and onboarding verification operation affordances are covered explicitly rather than relying on a blanket deferred exemption.
|
||||
2. **Given** unrelated deferred surfaces such as chooser pages or landing pages remain untouched, **When** the retrofit ships, **Then** they remain explicit non-goals rather than being swept in accidentally.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- A tenant verification surface may need to show no current operation, an in-progress operation, or a stale completed operation; each state still needs one primary next-step affordance.
|
||||
- Some operators may have access to the tenant-local surface but not to an advanced admin monitoring destination; advanced links must respect destination access.
|
||||
- A retrofitted surface may expose a collection drill-in or a single-operation drill-in depending on context, but the scope must remain explicit either way.
|
||||
- Unrelated deferred surfaces such as `ChooseTenant`, `ChooseWorkspace`, `ManagedTenantsLanding`, and the Monitoring Alerts page-class route remain out of scope unless they later gain operation affordances that justify a dedicated spec.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
**Constitution alignment (required):** This feature introduces no new execution path, no new long-running work, and no new persistence. It only retrofits existing embedded operator surfaces that already summarize or link to `OperationRun` records.
|
||||
|
||||
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature adds no new structure, persistence, abstraction, or state family. It narrows an existing deferred UX gap on current-release surfaces.
|
||||
|
||||
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-REVIEW-001):** Even though these are embedded or guided-flow surfaces rather than table pages, they must still expose one clear primary inspect or next-step model, keep scope truthful, and avoid competing actions.
|
||||
|
||||
**Constitution alignment (OPSURF-001):** Dashboard and onboarding verification surfaces must be operator-first summary surfaces: the default-visible content should answer what happened, what scope it affected, and where the operator should go next without exposing low-level diagnostics by default.
|
||||
|
||||
**Constitution alignment (UI-FIL-001):** Existing Filament pages, widgets, and embedded components remain the implementation shape. No local mini-framework for embedded operation actions is introduced.
|
||||
|
||||
**Constitution alignment (UI-NAMING-001):** The retrofitted surfaces use the canonical visible nouns `Operations` and `Operation`, consistent with Specs 170 and 171.
|
||||
|
||||
**Constitution alignment (TEST-TRUTH-001):** Representative automated coverage must assert CTA count, scope cues, and visibility of advanced links on the retrofitted surfaces.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-172-001**: Tenant dashboard operation-bearing widgets or cards MUST expose navigation that preserves tenant context or makes any broader scope explicit before the operator leaves the tenant dashboard.
|
||||
- **FR-172-002**: Retrofitted embedded surfaces that reference one existing operation record MUST expose exactly one primary inspect affordance for that record.
|
||||
- **FR-172-003**: Retrofitted embedded surfaces in a no-history or no-operation state MUST expose exactly one primary next-step CTA on the owning surface and MUST NOT render competing inline operation links.
|
||||
- **FR-172-004**: Any retained advanced admin or monitoring destination link MUST be clearly secondary, explicitly labeled for its scope or audience, and visible only when the operator can access that destination.
|
||||
- **FR-172-005**: Retrofitted tenant or workspace surfaces MUST keep tenant, workspace, or admin scope explicit in their visible copy or destination semantics before navigation occurs.
|
||||
- **FR-172-006**: Governance artifacts, exemption handling, or dedicated tests MUST stop treating the retrofitted operation-bearing parts of `TenantDashboard` and `ManagedTenantOnboardingWizard` as fully out of scope.
|
||||
- **FR-172-007**: Unrelated deferred surfaces that do not expose operation affordances today, including `ChooseTenant`, `ChooseWorkspace`, `ManagedTenantsLanding`, and the Monitoring Alerts page-class route, MUST remain explicit non-goals for this slice.
|
||||
- **FR-172-008**: Existing operation destinations, authorization rules, and lifecycle semantics MUST remain unchanged.
|
||||
- **FR-172-009**: Representative automated coverage MUST verify CTA count, scope-truthful navigation, and advanced-link visibility on the tenant dashboard and onboarding verification surfaces affected by this slice.
|
||||
- **FR-172-010**: This feature MUST NOT introduce a new dashboard page, a new onboarding flow, or a new operations capability.
|
||||
|
||||
## UI Action Matrix *(mandatory when Filament is changed)*
|
||||
|
||||
| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Tenant dashboard operation cards/widgets | `app/Filament/Pages/TenantDashboard.php` and its operation-bearing widgets | existing dashboard/header actions remain | n/a | one explicit operations drill-in per card/widget maximum | n/a | existing surface-specific next-step CTA remains singular | n/a | n/a | no new audit behavior | Retrofit current deferred widget/card surfaces with scope-truthful operations drill-ins |
|
||||
| Tenant verification report widget | tenant verification widget and embedded report view | existing widget actions remain | n/a | one primary `Open operation` link when a record exists | n/a | owning surface keeps one workflow CTA when no operation exists | n/a | n/a | no new audit behavior | Advanced admin/monitoring link may remain only as secondary |
|
||||
| Managed-tenant onboarding verification report and technical details | `app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php` and related onboarding report/modal views | existing workflow actions remain | n/a | one primary `Open operation` link when a record exists | n/a | `Start verification` or equivalent next-step CTA remains singular when no operation exists | n/a | n/a | no new audit behavior | Guided-flow retrofit; no new page or route family |
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **Deferred operation-bearing embedded surface**: Existing dashboard card, widget, report block, or modal that is not a table page but still exposes operation truth or navigation.
|
||||
- **Primary inspect affordance**: The one visible link or CTA that opens the canonical operation destination for the current embedded context.
|
||||
- **Advanced destination link**: A clearly secondary operation-related link that exposes a broader monitoring destination only for operators who can access it.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
- **SC-172-001**: Representative automated coverage verifies that tenant dashboard operation drill-ins preserve tenant context or make any broader scope explicit before navigation.
|
||||
- **SC-172-002**: Representative automated coverage verifies that covered verification and onboarding surfaces expose exactly one primary CTA per state.
|
||||
- **SC-172-003**: Representative automated coverage verifies that any retained advanced monitoring/admin link is secondary and access-aware.
|
||||
- **SC-172-004**: The feature ships without adding a new dashboard page, onboarding flow, operations capability, or persistence artifact.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Specs 170 and 171 establish the canonical visible noun family `Operations / Operation` for aligned and residual naming surfaces.
|
||||
- Existing admin operation list and detail destinations remain the correct canonical inspect targets for embedded tenant/workspace surfaces.
|
||||
- Retrofitting embedded operation-bearing surfaces is sufficient for this slice; not every currently exempt page needs to be enrolled.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Building a new workspace home or redesigning the tenant dashboard as a whole
|
||||
- Reworking onboarding flow mechanics or verification execution semantics
|
||||
- Enrolling chooser pages, `ManagedTenantsLanding`, or the Monitoring Alerts page-class route into this retrofit when they do not currently expose operation affordances that need the same treatment
|
||||
- Introducing a broad action-surface framework for all widgets and embedded components beyond the explicit retrofits in this slice
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Spec 169 deferred-surface exemption baseline
|
||||
- Spec 170 system operations surface alignment
|
||||
- Spec 171 operations naming consolidation
|
||||
- Existing tenant dashboard widgets, verification report widgets, onboarding verification report components, and canonical admin operation destinations
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Spec 172 is complete when the deferred non-table surfaces that already expose operations, especially tenant dashboard operation drill-ins and onboarding/verification report surfaces, provide one clear primary CTA per state, preserve or explicitly announce scope before navigation, keep any advanced monitoring/admin links secondary and access-aware, and are protected by explicit governance or representative tests instead of relying on a blanket deferred exemption.
|
||||
@ -108,6 +108,7 @@
|
||||
use App\Support\Ui\ActionSurface\Enums\ActionSurfaceType;
|
||||
use App\Support\WorkspaceIsolation\TenantOwnedModelFamilies;
|
||||
use App\Support\Workspaces\WorkspaceContext;
|
||||
use Filament\Actions\Action;
|
||||
use Filament\Actions\ActionGroup;
|
||||
use Filament\Actions\BulkActionGroup;
|
||||
use Filament\Facades\Filament;
|
||||
@ -1436,7 +1437,7 @@ function actionSurfaceSystemPanelContext(array $capabilities): PlatformUser
|
||||
->toContain('no-data');
|
||||
});
|
||||
|
||||
it('uses clickable rows with direct triage actions on the system runs list', function (): void {
|
||||
it('uses clickable rows without row triage on the system runs list', function (): void {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
@ -1449,21 +1450,25 @@ function actionSurfaceSystemPanelContext(array $capabilities): PlatformUser
|
||||
]);
|
||||
|
||||
$livewire = Livewire::test(SystemRunsPage::class)
|
||||
->assertCanSeeTableRecords([$run]);
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('go_to_runbooks')
|
||||
->assertActionExists('go_to_runbooks', fn (Action $action): bool => $action->getLabel() === 'Go to runbooks' && $action->getUrl() === \App\Filament\System\Pages\Ops\Runbooks::getUrl(panel: 'system'));
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$rowActionNames = collect($table->getActions())
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(static fn ($action): ?string => $action->getName())
|
||||
->filter()
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($rowActionNames)->toEqualCanonicalizing(['retry', 'cancel', 'mark_investigated'])
|
||||
expect($livewire->instance()->getTitle())->toBe('Operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($emptyStateActions)->toBe(['go_to_runbooks_empty'])
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run));
|
||||
});
|
||||
|
||||
it('uses clickable rows with direct triage actions on the system failures list', function (): void {
|
||||
it('uses clickable rows without row triage on the system failures list', function (): void {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
@ -1476,21 +1481,25 @@ function actionSurfaceSystemPanelContext(array $capabilities): PlatformUser
|
||||
]);
|
||||
|
||||
$livewire = Livewire::test(SystemFailuresPage::class)
|
||||
->assertCanSeeTableRecords([$run]);
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index());
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$rowActionNames = collect($table->getActions())
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(static fn ($action): ?string => $action->getName())
|
||||
->filter()
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($rowActionNames)->toEqualCanonicalizing(['retry', 'cancel', 'mark_investigated'])
|
||||
expect($livewire->instance()->getTitle())->toBe('Failed operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($emptyStateActions)->toBe(['show_all_operations_empty'])
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run));
|
||||
});
|
||||
|
||||
it('uses clickable rows with direct triage actions on the system stuck list', function (): void {
|
||||
it('uses clickable rows without row triage on the system stuck list', function (): void {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Queued->value,
|
||||
'outcome' => OperationRunOutcome::Pending->value,
|
||||
@ -1505,17 +1514,21 @@ function actionSurfaceSystemPanelContext(array $capabilities): PlatformUser
|
||||
]);
|
||||
|
||||
$livewire = Livewire::test(SystemStuckPage::class)
|
||||
->assertCanSeeTableRecords([$run]);
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index());
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$rowActionNames = collect($table->getActions())
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(static fn ($action): ?string => $action->getName())
|
||||
->filter()
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($rowActionNames)->toEqualCanonicalizing(['retry', 'cancel', 'mark_investigated'])
|
||||
expect($livewire->instance()->getTitle())->toBe('Stuck operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($emptyStateActions)->toBe(['show_all_operations_empty'])
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run));
|
||||
});
|
||||
|
||||
|
||||
@ -26,7 +26,9 @@
|
||||
$this->actingAs($platformUser, 'platform')
|
||||
->get(SystemOperationRunLinks::view($run))
|
||||
->assertSuccessful()
|
||||
->assertSee('Run #'.(int) $run->getKey());
|
||||
->assertSee('Operation #'.(int) $run->getKey())
|
||||
->assertSee('Show all operations')
|
||||
->assertSee('Go to runbooks');
|
||||
});
|
||||
|
||||
it('does not render raw context payloads in canonical run detail', function () {
|
||||
|
||||
@ -49,6 +49,8 @@
|
||||
$this->actingAs($platformUser, 'platform')
|
||||
->get('/system/ops/failures')
|
||||
->assertSuccessful()
|
||||
->assertSee('Failed operations')
|
||||
->assertSee('Show all operations')
|
||||
->assertSee(SystemOperationRunLinks::view($failedRun))
|
||||
->assertDontSee(SystemOperationRunLinks::view($succeededRun));
|
||||
});
|
||||
|
||||
@ -67,6 +67,8 @@
|
||||
$this->actingAs($platformUser, 'platform')
|
||||
->get('/system/ops/stuck')
|
||||
->assertSuccessful()
|
||||
->assertSee('Stuck operations')
|
||||
->assertSee('Show all operations')
|
||||
->assertSee('#'.(int) $stuckQueued->getKey())
|
||||
->assertSee('#'.(int) $stuckRunning->getKey())
|
||||
->assertDontSee('#'.(int) $freshQueued->getKey());
|
||||
|
||||
@ -2,7 +2,11 @@
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\System\Pages\Ops\Failures;
|
||||
use App\Filament\System\Pages\Ops\Runbooks;
|
||||
use App\Filament\System\Pages\Ops\Runs;
|
||||
use App\Filament\System\Pages\Ops\Stuck;
|
||||
use App\Filament\System\Pages\Ops\ViewRun;
|
||||
use App\Models\AuditLog;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
@ -11,6 +15,8 @@
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use App\Support\System\SystemOperationRunLinks;
|
||||
use Carbon\CarbonImmutable;
|
||||
use Filament\Actions\Action;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
use Illuminate\Notifications\DatabaseNotification;
|
||||
@ -29,7 +35,11 @@
|
||||
]);
|
||||
});
|
||||
|
||||
it('hides triage actions for operators without platform.operations.manage', function () {
|
||||
afterEach(function () {
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('keeps the operations list scan-first with one go to runbooks cta', function () {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
@ -46,13 +56,132 @@
|
||||
|
||||
$this->actingAs($viewOnlyUser, 'platform');
|
||||
|
||||
Livewire::test(Runs::class)
|
||||
->assertTableActionHidden('retry', $run)
|
||||
->assertTableActionHidden('cancel', $run)
|
||||
->assertTableActionHidden('mark_investigated', $run);
|
||||
$livewire = Livewire::test(Runs::class)
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('go_to_runbooks')
|
||||
->assertActionExists('go_to_runbooks', fn (Action $action): bool => $action->getLabel() === 'Go to runbooks' && $action->getUrl() === Runbooks::getUrl(panel: 'system'));
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(fn (Action $action): array => [
|
||||
'name' => $action->getName(),
|
||||
'label' => $action->getLabel(),
|
||||
'url' => $action->getUrl(),
|
||||
])
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($livewire->instance()->getTitle())->toBe('Operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run))
|
||||
->and($emptyStateActions)->toBe([
|
||||
[
|
||||
'name' => 'go_to_runbooks_empty',
|
||||
'label' => 'Go to runbooks',
|
||||
'url' => Runbooks::getUrl(panel: 'system'),
|
||||
],
|
||||
]);
|
||||
});
|
||||
|
||||
it('allows manage operators to run triage actions with audit logs and queued-run ux contract', function () {
|
||||
it('keeps the failed operations list scan-first with one show all operations cta', function () {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
'type' => 'inventory_sync',
|
||||
]);
|
||||
|
||||
$viewOnlyUser = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::OPERATIONS_VIEW,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($viewOnlyUser, 'platform');
|
||||
|
||||
$livewire = Livewire::test(Failures::class)
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index());
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(fn (Action $action): array => [
|
||||
'name' => $action->getName(),
|
||||
'label' => $action->getLabel(),
|
||||
'url' => $action->getUrl(),
|
||||
])
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($livewire->instance()->getTitle())->toBe('Failed operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run))
|
||||
->and($emptyStateActions)->toBe([
|
||||
[
|
||||
'name' => 'show_all_operations_empty',
|
||||
'label' => 'Show all operations',
|
||||
'url' => SystemOperationRunLinks::index(),
|
||||
],
|
||||
]);
|
||||
});
|
||||
|
||||
it('keeps the stuck operations list scan-first with one show all operations cta', function () {
|
||||
config()->set('tenantpilot.system_console.stuck_thresholds.queued_minutes', 10);
|
||||
config()->set('tenantpilot.system_console.stuck_thresholds.running_minutes', 20);
|
||||
|
||||
CarbonImmutable::setTestNow(CarbonImmutable::parse('2026-02-27 10:00:00'));
|
||||
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Queued->value,
|
||||
'outcome' => OperationRunOutcome::Pending->value,
|
||||
'type' => 'inventory_sync',
|
||||
'created_at' => now()->subMinutes(30),
|
||||
'started_at' => null,
|
||||
]);
|
||||
|
||||
$viewOnlyUser = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::OPERATIONS_VIEW,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($viewOnlyUser, 'platform');
|
||||
|
||||
$livewire = Livewire::test(Stuck::class)
|
||||
->assertCanSeeTableRecords([$run])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index());
|
||||
|
||||
$table = $livewire->instance()->getTable();
|
||||
$emptyStateActions = collect($table->getEmptyStateActions())
|
||||
->map(fn (Action $action): array => [
|
||||
'name' => $action->getName(),
|
||||
'label' => $action->getLabel(),
|
||||
'url' => $action->getUrl(),
|
||||
])
|
||||
->values()
|
||||
->all();
|
||||
|
||||
expect($livewire->instance()->getTitle())->toBe('Stuck operations')
|
||||
->and($table->getActions())->toBeEmpty()
|
||||
->and($table->getBulkActions())->toBeEmpty()
|
||||
->and($table->getRecordUrl($run))->toBe(SystemOperationRunLinks::view($run))
|
||||
->and($emptyStateActions)->toBe([
|
||||
[
|
||||
'name' => 'show_all_operations_empty',
|
||||
'label' => 'Show all operations',
|
||||
'url' => SystemOperationRunLinks::index(),
|
||||
],
|
||||
]);
|
||||
});
|
||||
|
||||
it('keeps detail-page triage, return paths, and audit behavior for manage operators', function () {
|
||||
NotificationFacade::fake();
|
||||
|
||||
$failedRun = OperationRun::factory()->create([
|
||||
@ -61,6 +190,14 @@
|
||||
'type' => 'inventory_sync',
|
||||
]);
|
||||
|
||||
$runningRun = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Running->value,
|
||||
'outcome' => OperationRunOutcome::Pending->value,
|
||||
'type' => 'inventory_sync',
|
||||
'created_at' => now()->subMinutes(15),
|
||||
'started_at' => now()->subMinutes(10),
|
||||
]);
|
||||
|
||||
$manageUser = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
@ -72,9 +209,26 @@
|
||||
|
||||
$this->actingAs($manageUser, 'platform');
|
||||
|
||||
Livewire::test(Runs::class)
|
||||
->callTableAction('retry', $failedRun)
|
||||
->assertHasNoTableActionErrors()
|
||||
$failedRunView = Livewire::test(ViewRun::class, [
|
||||
'run' => $failedRun,
|
||||
])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index())
|
||||
->assertActionVisible('go_to_runbooks')
|
||||
->assertActionExists('go_to_runbooks', fn (Action $action): bool => $action->getLabel() === 'Go to runbooks' && $action->getUrl() === Runbooks::getUrl(panel: 'system'))
|
||||
->assertActionVisible('retry')
|
||||
->assertActionExists('retry', fn (Action $action): bool => $action->getLabel() === 'Retry' && $action->isConfirmationRequired())
|
||||
->assertActionVisible('mark_investigated')
|
||||
->assertActionExists('mark_investigated', fn (Action $action): bool => $action->getLabel() === 'Mark investigated' && $action->isConfirmationRequired())
|
||||
->assertActionHidden('cancel');
|
||||
|
||||
expect($failedRunView->instance()->getTitle())->toBe('Operation #'.(int) $failedRun->getKey());
|
||||
|
||||
Livewire::test(ViewRun::class, [
|
||||
'run' => $failedRun,
|
||||
])
|
||||
->callAction('retry')
|
||||
->assertHasNoActionErrors()
|
||||
->assertNotified('Inventory sync queued');
|
||||
|
||||
NotificationFacade::assertNothingSent();
|
||||
@ -91,14 +245,73 @@
|
||||
|
||||
$this->get(SystemOperationRunLinks::view($retriedRun))
|
||||
->assertSuccessful()
|
||||
->assertSee('Run #'.(int) $retriedRun?->getKey());
|
||||
->assertSee('Operation #'.(int) $retriedRun?->getKey())
|
||||
->assertSee('Show all operations')
|
||||
->assertSee('Go to runbooks');
|
||||
|
||||
Livewire::test(Runs::class)
|
||||
->callTableAction('mark_investigated', $failedRun, data: [
|
||||
Livewire::test(ViewRun::class, [
|
||||
'run' => $failedRun,
|
||||
])
|
||||
->callAction('mark_investigated', data: [
|
||||
'reason' => 'Checked by platform operations',
|
||||
])
|
||||
->assertHasNoTableActionErrors();
|
||||
->assertHasNoActionErrors()
|
||||
->assertNotified('Run marked as investigated');
|
||||
|
||||
Livewire::test(ViewRun::class, [
|
||||
'run' => $runningRun,
|
||||
])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionVisible('go_to_runbooks')
|
||||
->assertActionHidden('retry')
|
||||
->assertActionVisible('cancel')
|
||||
->assertActionExists('cancel', fn (Action $action): bool => $action->getLabel() === 'Cancel' && $action->isConfirmationRequired())
|
||||
->assertActionVisible('mark_investigated')
|
||||
->callAction('cancel')
|
||||
->assertHasNoActionErrors()
|
||||
->assertNotified('Run cancelled');
|
||||
|
||||
expect(AuditLog::query()->where('action', 'platform.system_console.retry')->exists())->toBeTrue();
|
||||
expect(AuditLog::query()->where('action', 'platform.system_console.cancel')->exists())->toBeTrue();
|
||||
expect(AuditLog::query()->where('action', 'platform.system_console.mark_investigated')->exists())->toBeTrue();
|
||||
|
||||
$runningRun->refresh();
|
||||
|
||||
expect((string) $runningRun->status)->toBe(OperationRunStatus::Completed->value)
|
||||
->and((string) $runningRun->outcome)->toBe(OperationRunOutcome::Failed->value);
|
||||
});
|
||||
|
||||
it('keeps detail inspection and navigation available while hiding triage for view-only operators', function () {
|
||||
$run = OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
'type' => 'inventory_sync',
|
||||
]);
|
||||
|
||||
$viewOnlyUser = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::OPERATIONS_VIEW,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($viewOnlyUser, 'platform');
|
||||
|
||||
Livewire::test(ViewRun::class, [
|
||||
'run' => $run,
|
||||
])
|
||||
->assertActionVisible('show_all_operations')
|
||||
->assertActionExists('show_all_operations', fn (Action $action): bool => $action->getLabel() === 'Show all operations' && $action->getUrl() === SystemOperationRunLinks::index())
|
||||
->assertActionVisible('go_to_runbooks')
|
||||
->assertActionExists('go_to_runbooks', fn (Action $action): bool => $action->getLabel() === 'Go to runbooks' && $action->getUrl() === Runbooks::getUrl(panel: 'system'))
|
||||
->assertActionHidden('retry')
|
||||
->assertActionHidden('cancel')
|
||||
->assertActionHidden('mark_investigated');
|
||||
|
||||
$this->get(SystemOperationRunLinks::view($run))
|
||||
->assertSuccessful()
|
||||
->assertSee('Operation #'.(int) $run->getKey())
|
||||
->assertSee('Show all operations')
|
||||
->assertSee('Go to runbooks');
|
||||
});
|
||||
|
||||
Loading…
Reference in New Issue
Block a user