feat: improve system panel branding and auth experience (#467)
Automated PR created by Codex via Gitea API. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #467
This commit is contained in:
parent
4a50c6a580
commit
e95fcf5e38
@ -14,6 +14,18 @@
|
||||
|
||||
class Login extends BaseLogin
|
||||
{
|
||||
private const BRAND_TITLE = 'TenantPilot System';
|
||||
|
||||
public function getTitle(): string
|
||||
{
|
||||
return self::BRAND_TITLE;
|
||||
}
|
||||
|
||||
public function getHeading(): string
|
||||
{
|
||||
return self::BRAND_TITLE;
|
||||
}
|
||||
|
||||
/**
|
||||
* Filament's base login page uses Livewire-level rate limiting. We override it
|
||||
* to enforce the System panel policy via Laravel's RateLimiter (SR-003).
|
||||
|
||||
@ -56,7 +56,7 @@ public function getHealthData(): array
|
||||
'level' => 'warning',
|
||||
'color' => 'warning',
|
||||
'icon' => 'heroicon-o-exclamation-triangle',
|
||||
'label' => 'Attention needed',
|
||||
'label' => 'Needs attention',
|
||||
'failed' => $failedRuns,
|
||||
'stuck' => $stuckRuns,
|
||||
],
|
||||
@ -64,7 +64,7 @@ public function getHealthData(): array
|
||||
'level' => 'healthy',
|
||||
'color' => 'success',
|
||||
'icon' => 'heroicon-o-check-circle',
|
||||
'label' => 'All systems healthy',
|
||||
'label' => 'Ready',
|
||||
'failed' => 0,
|
||||
'stuck' => 0,
|
||||
],
|
||||
|
||||
@ -29,17 +29,17 @@ protected function getStats(): array
|
||||
$counts = app(WorkspaceHealthSummaryQuery::class)->healthCounts($window);
|
||||
|
||||
return [
|
||||
Stat::make('Healthy', $counts['ok'])
|
||||
Stat::make('Ready', $counts['ok'])
|
||||
->description(sprintf('Operational stability, review-pack readiness, and engagement freshness honor %s.', $windowLabel))
|
||||
->color($counts['ok'] > 0 ? 'success' : 'gray'),
|
||||
Stat::make('Warning', $counts['warn'])
|
||||
Stat::make('Needs attention', $counts['warn'])
|
||||
->description('Onboarding readiness, provider readiness, and governance pressure stay point-in-time.')
|
||||
->color($counts['warn'] > 0 ? 'warning' : 'gray'),
|
||||
Stat::make('Critical', $counts['critical'])
|
||||
->description('Overall workspace health is derived from existing system truth only.')
|
||||
->color($counts['critical'] > 0 ? 'danger' : 'gray'),
|
||||
Stat::make('Unknown', $counts['unknown'])
|
||||
->description('Missing or stale inputs stay explicit instead of silently reading healthy.')
|
||||
->description('Missing or stale inputs stay explicit instead of silently reading ready.')
|
||||
->color('gray'),
|
||||
];
|
||||
}
|
||||
|
||||
@ -36,7 +36,7 @@ protected function getStats(): array
|
||||
Stat::make('Total workspaces', $totalWorkspaces)
|
||||
->color('gray')
|
||||
->icon('heroicon-o-rectangle-stack'),
|
||||
Stat::make('Healthy (has owner)', $workspacesWithOwners)
|
||||
Stat::make('Ready (has owner)', $workspacesWithOwners)
|
||||
->color($workspacesWithOwners > 0 ? 'success' : 'gray')
|
||||
->icon('heroicon-o-check-circle'),
|
||||
Stat::make('Ownerless', $ownerlessWorkspaces)
|
||||
|
||||
@ -32,6 +32,10 @@ public function panel(Panel $panel): Panel
|
||||
->path('system')
|
||||
->authGuard('platform')
|
||||
->login(Login::class)
|
||||
->brandName('TenantPilot System')
|
||||
->brandLogo(fn () => view('filament.system.logo'))
|
||||
->brandLogoHeight('2rem')
|
||||
->favicon(asset('favicon.ico'))
|
||||
->font(null, provider: LocalFontProvider::class, preload: [])
|
||||
->colors([
|
||||
'primary' => Color::Blue,
|
||||
|
||||
@ -15,8 +15,8 @@ public function spec(mixed $value): BadgeSpec
|
||||
$state = BadgeCatalog::normalizeState($value);
|
||||
|
||||
return match ($state) {
|
||||
'ok' => new BadgeSpec('OK', 'success', 'heroicon-m-check-circle'),
|
||||
'warn' => new BadgeSpec('Warn', 'warning', 'heroicon-m-exclamation-triangle'),
|
||||
'ok' => new BadgeSpec('Ready', 'success', 'heroicon-m-check-circle'),
|
||||
'warn' => new BadgeSpec('Needs attention', 'warning', 'heroicon-m-exclamation-triangle'),
|
||||
'critical' => new BadgeSpec('Critical', 'danger', 'heroicon-m-x-circle'),
|
||||
'unknown' => BadgeSpec::unknown(),
|
||||
default => BadgeSpec::unknown(),
|
||||
|
||||
@ -112,7 +112,7 @@
|
||||
'dashboard' => [
|
||||
'tenant_title' => 'Umgebungs-Dashboard',
|
||||
'environment_title' => 'Umgebungs-Dashboard',
|
||||
'system_title' => 'System-Dashboard',
|
||||
'system_title' => 'TenantPilot-Systemübersicht',
|
||||
'more_actions' => 'Mehr',
|
||||
'request_support' => 'Support anfragen',
|
||||
'support_request_heading' => 'Support anfragen',
|
||||
|
||||
@ -112,7 +112,7 @@
|
||||
'dashboard' => [
|
||||
'tenant_title' => 'Environment dashboard',
|
||||
'environment_title' => 'Environment dashboard',
|
||||
'system_title' => 'System dashboard',
|
||||
'system_title' => 'TenantPilot System',
|
||||
'more_actions' => 'More',
|
||||
'request_support' => 'Request support',
|
||||
'support_request_heading' => 'Request support',
|
||||
|
||||
@ -16,20 +16,26 @@
|
||||
$sourceLabel = __('localization.source.'.$source);
|
||||
$user = auth()->user();
|
||||
$preferredLocale = $user instanceof User ? $user->preferred_locale : null;
|
||||
$containerClasses = $embedded
|
||||
? 'shrink-0 whitespace-nowrap border-l border-gray-200 dark:border-white/10'
|
||||
: 'inline-flex shrink-0 whitespace-nowrap';
|
||||
@endphp
|
||||
|
||||
<div class="{{ $embedded ? 'border-l border-gray-200 dark:border-white/10' : 'inline-flex rounded-lg border border-gray-200 bg-white text-sm dark:border-white/10 dark:bg-white/5' }}">
|
||||
<div class="{{ $containerClasses }}">
|
||||
<x-filament::dropdown placement="bottom-end" teleport width="sm">
|
||||
<x-slot name="trigger">
|
||||
<button
|
||||
<x-filament::button
|
||||
type="button"
|
||||
color="gray"
|
||||
size="sm"
|
||||
icon="heroicon-o-language"
|
||||
outlined
|
||||
data-testid="tenantpilot-locale-switcher-trigger"
|
||||
aria-label="{{ __('localization.shell.language') }}"
|
||||
class="inline-flex items-center gap-1.5 rounded-r-lg px-2 py-1.5 text-sm transition hover:bg-gray-50 dark:hover:bg-white/10"
|
||||
class="shrink-0"
|
||||
>
|
||||
<x-filament::icon icon="heroicon-o-language" class="h-4 w-4 text-gray-400 dark:text-gray-500" />
|
||||
<span class="font-medium text-gray-700 dark:text-gray-200">{{ strtoupper($currentLocale) }}</span>
|
||||
<x-filament::icon icon="heroicon-m-chevron-down" class="h-3.5 w-3.5 text-gray-400 dark:text-gray-500" />
|
||||
</button>
|
||||
{{ strtoupper($currentLocale) }}
|
||||
</x-filament::button>
|
||||
</x-slot>
|
||||
|
||||
<x-filament::dropdown.list>
|
||||
|
||||
29
apps/platform/resources/views/filament/system/logo.blade.php
Normal file
29
apps/platform/resources/views/filament/system/logo.blade.php
Normal file
@ -0,0 +1,29 @@
|
||||
<div class="flex items-center gap-2 text-gray-950 dark:text-white">
|
||||
<svg class="h-8 w-8 shrink-0" viewBox="0 0 40 40" role="img" aria-label="TenantPilot System">
|
||||
<rect width="40" height="40" rx="8" fill="currentColor" opacity="0.08" />
|
||||
<path
|
||||
d="M20 7.5 30 11v8.5c0 6.6-4.1 10.7-10 13-5.9-2.3-10-6.4-10-13V11l10-3.5Z"
|
||||
fill="currentColor"
|
||||
opacity="0.18"
|
||||
/>
|
||||
<path
|
||||
d="M20 10.2 27.3 12.8v6.7c0 4.9-2.8 8-7.3 10-4.5-2-7.3-5.1-7.3-10v-6.7L20 10.2Z"
|
||||
fill="none"
|
||||
stroke="currentColor"
|
||||
stroke-width="2"
|
||||
stroke-linejoin="round"
|
||||
/>
|
||||
<path
|
||||
d="m16.3 20.2 2.4 2.4 5.2-5.6"
|
||||
fill="none"
|
||||
stroke="currentColor"
|
||||
stroke-width="2.4"
|
||||
stroke-linecap="round"
|
||||
stroke-linejoin="round"
|
||||
/>
|
||||
</svg>
|
||||
|
||||
<span class="whitespace-nowrap text-sm font-semibold tracking-normal">
|
||||
TenantPilot System
|
||||
</span>
|
||||
</div>
|
||||
@ -0,0 +1,179 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
use App\Support\Auth\PlatformCapabilities;
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
|
||||
pest()->browser()->timeout(60_000);
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
it('Spec396 smokes the authenticated TenantPilot System panel surfaces', function (): void {
|
||||
$platformUser = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::CONSOLE_VIEW,
|
||||
PlatformCapabilities::OPERATIONS_VIEW,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
auth('web')->logout();
|
||||
$this->flushSession();
|
||||
$this->actingAs($platformUser, 'platform');
|
||||
|
||||
visit('/system')
|
||||
->resize(1440, 1100)
|
||||
->waitForText('TenantPilot System')
|
||||
->assertTitleContains('TenantPilot System')
|
||||
->assertSee('Ready')
|
||||
->assertScript(<<<'JS'
|
||||
() => {
|
||||
const hasVisibleDirectText = (needle) => Array.from(document.querySelectorAll('body *')).some((element) => {
|
||||
const style = window.getComputedStyle(element);
|
||||
const rect = element.getBoundingClientRect();
|
||||
const isVisible = style.display !== 'none'
|
||||
&& style.visibility !== 'hidden'
|
||||
&& Number(style.opacity) !== 0
|
||||
&& rect.width > 0
|
||||
&& rect.height > 0
|
||||
&& rect.bottom > 0
|
||||
&& rect.right > 0
|
||||
&& rect.top < window.innerHeight
|
||||
&& rect.left < window.innerWidth;
|
||||
|
||||
return isVisible
|
||||
&& Array.from(element.childNodes).some((node) => node.nodeType === Node.TEXT_NODE && node.textContent?.includes(needle));
|
||||
});
|
||||
|
||||
return ! hasVisibleDirectText('System dashboard');
|
||||
}
|
||||
JS)
|
||||
->assertDontSee('All systems healthy')
|
||||
->assertDontSee('Healthy')
|
||||
->assertDontSee('Laravel')
|
||||
->assertDontSee('Laravel Debugbar')
|
||||
->assertDontSee('Vite Error')
|
||||
->assertDontSee('Exception')
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs()
|
||||
->screenshot(true, spec396BrowserScreenshot('001-system-dashboard'));
|
||||
spec396BrowserCopyScreenshot('001-system-dashboard');
|
||||
|
||||
visit('/system')
|
||||
->resize(778, 784)
|
||||
->waitForText('TenantPilot System')
|
||||
->assertScript(<<<'JS'
|
||||
() => {
|
||||
const trigger = document.querySelector('[data-testid="tenantpilot-locale-switcher-trigger"]');
|
||||
|
||||
if (! trigger) {
|
||||
return false;
|
||||
}
|
||||
|
||||
const rect = trigger.getBoundingClientRect();
|
||||
|
||||
return trigger.textContent?.trim() === 'EN'
|
||||
&& rect.width >= 52
|
||||
&& rect.height <= 44;
|
||||
}
|
||||
JS, true)
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs();
|
||||
|
||||
visit('/system/ops/runs')
|
||||
->resize(1440, 1100)
|
||||
->waitForText('Operations')
|
||||
->assertSee('No operations yet')
|
||||
->assertDontSee('Laravel Debugbar')
|
||||
->assertDontSee('Vite Error')
|
||||
->assertDontSee('Exception')
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs()
|
||||
->screenshot(true, spec396BrowserScreenshot('002-system-operations'));
|
||||
spec396BrowserCopyScreenshot('002-system-operations');
|
||||
|
||||
visit('/system/security/access-logs')
|
||||
->resize(1440, 1100)
|
||||
->waitForText('Access logs')
|
||||
->assertSee('No access logs found')
|
||||
->assertDontSee('Laravel Debugbar')
|
||||
->assertDontSee('Vite Error')
|
||||
->assertDontSee('Exception')
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs()
|
||||
->screenshot(true, spec396BrowserScreenshot('003-system-access-logs'));
|
||||
spec396BrowserCopyScreenshot('003-system-access-logs');
|
||||
|
||||
OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
'created_at' => now()->subMinutes(10),
|
||||
]);
|
||||
|
||||
visit('/system')
|
||||
->resize(1440, 1100)
|
||||
->waitForText('Needs attention')
|
||||
->assertSee('Needs attention')
|
||||
->assertDontSee('All systems healthy')
|
||||
->assertDontSee('Warning')
|
||||
->assertDontSee('Laravel Debugbar')
|
||||
->assertDontSee('Vite Error')
|
||||
->assertDontSee('Exception')
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs();
|
||||
});
|
||||
|
||||
it('Spec396 smokes the TenantPilot System login surface without default framework branding', function (): void {
|
||||
auth('web')->logout();
|
||||
auth('platform')->logout();
|
||||
$this->flushSession();
|
||||
|
||||
visit('/system/login')
|
||||
->resize(1440, 1100)
|
||||
->waitForText('TenantPilot System')
|
||||
->assertSee('Email')
|
||||
->assertDontSee('System dashboard')
|
||||
->assertDontSee('Laravel')
|
||||
->assertDontSee('Laravel Debugbar')
|
||||
->assertDontSee('Vite Error')
|
||||
->assertDontSee('Exception')
|
||||
->assertNoJavaScriptErrors()
|
||||
->assertNoConsoleLogs()
|
||||
->screenshot(true, spec396BrowserScreenshot('004-system-login'));
|
||||
spec396BrowserCopyScreenshot('004-system-login');
|
||||
});
|
||||
|
||||
function spec396BrowserScreenshot(string $name): string
|
||||
{
|
||||
return $name;
|
||||
}
|
||||
|
||||
function spec396BrowserCopyScreenshot(string $name): void
|
||||
{
|
||||
$filename = spec396BrowserScreenshot($name).'.png';
|
||||
$source = base_path('tests/Browser/Screenshots/'.$filename);
|
||||
$targetDirectory = repo_path('specs/396-system-panel-branding/artifacts/screenshots');
|
||||
|
||||
if (! is_dir($targetDirectory)) {
|
||||
@mkdir($targetDirectory, 0755, true);
|
||||
}
|
||||
|
||||
if (! is_file($source)) {
|
||||
$source = \Pest\Browser\Support\Screenshot::path($filename);
|
||||
}
|
||||
|
||||
for ($attempt = 0; $attempt < 10 && ! is_file($source); $attempt++) {
|
||||
usleep(100_000);
|
||||
clearstatcache(true, $source);
|
||||
}
|
||||
|
||||
if (is_file($source) && is_dir($targetDirectory) && is_writable($targetDirectory)) {
|
||||
@copy($source, $targetDirectory.DIRECTORY_SEPARATOR.$filename);
|
||||
}
|
||||
}
|
||||
@ -5,18 +5,18 @@
|
||||
use App\Support\Badges\BadgeCatalog;
|
||||
use App\Support\Badges\BadgeDomain;
|
||||
|
||||
it('maps system health ok to an OK success badge', function (): void {
|
||||
it('maps system health ok to a Ready success badge', function (): void {
|
||||
$spec = BadgeCatalog::spec(BadgeDomain::SystemHealth, 'ok');
|
||||
|
||||
expect($spec->label)->toBe('OK');
|
||||
expect($spec->label)->toBe('Ready');
|
||||
expect($spec->color)->toBe('success');
|
||||
expect($spec->icon)->toBe('heroicon-m-check-circle');
|
||||
});
|
||||
|
||||
it('maps system health warn to a Warn warning badge', function (): void {
|
||||
it('maps system health warn to a Needs attention warning badge', function (): void {
|
||||
$spec = BadgeCatalog::spec(BadgeDomain::SystemHealth, 'warn');
|
||||
|
||||
expect($spec->label)->toBe('Warn');
|
||||
expect($spec->label)->toBe('Needs attention');
|
||||
expect($spec->color)->toBe('warning');
|
||||
expect($spec->icon)->toBe('heroicon-m-exclamation-triangle');
|
||||
});
|
||||
|
||||
@ -36,15 +36,15 @@
|
||||
CarbonImmutable::setTestNow();
|
||||
});
|
||||
|
||||
it('renders aggregate healthy, warning, critical, and unknown counts with a visible time-basis cue', function (): void {
|
||||
it('renders aggregate ready, needs-attention, critical, and unknown counts with a visible time-basis cue', function (): void {
|
||||
actingAsCustomerHealthSystemUser();
|
||||
|
||||
$baselineStats = customerHealthStats(Livewire::withQueryParams([
|
||||
'window' => SystemConsoleWindow::LastDay,
|
||||
])->test(CustomerHealthKpis::class));
|
||||
|
||||
seedCustomerHealthWorkspace('Healthy Workspace');
|
||||
seedCustomerHealthWorkspace('Warning Workspace', recentUsage: false, historicalUsage: true);
|
||||
seedCustomerHealthWorkspace('Ready Workspace');
|
||||
seedCustomerHealthWorkspace('Needs Attention Workspace', recentUsage: false, historicalUsage: true);
|
||||
seedCustomerHealthWorkspace('Critical Workspace', failedRun: true);
|
||||
seedCustomerHealthWorkspace('Unknown Workspace', recentRun: false, readyReviewPack: false);
|
||||
|
||||
@ -52,13 +52,13 @@
|
||||
'window' => SystemConsoleWindow::LastDay,
|
||||
])->test(CustomerHealthKpis::class));
|
||||
|
||||
expect((int) $stats['Healthy']['value'] - (int) $baselineStats['Healthy']['value'])->toBe(1)
|
||||
->and($stats['Healthy']['description'])->toBe('Operational stability, review-pack readiness, and engagement freshness honor Last 24 hours.')
|
||||
->and((int) $stats['Warning']['value'] - (int) $baselineStats['Warning']['value'])->toBe(1)
|
||||
->and($stats['Warning']['description'])->toBe('Onboarding readiness, provider readiness, and governance pressure stay point-in-time.')
|
||||
expect((int) $stats['Ready']['value'] - (int) $baselineStats['Ready']['value'])->toBe(1)
|
||||
->and($stats['Ready']['description'])->toBe('Operational stability, review-pack readiness, and engagement freshness honor Last 24 hours.')
|
||||
->and((int) $stats['Needs attention']['value'] - (int) $baselineStats['Needs attention']['value'])->toBe(1)
|
||||
->and($stats['Needs attention']['description'])->toBe('Onboarding readiness, provider readiness, and governance pressure stay point-in-time.')
|
||||
->and((int) $stats['Critical']['value'] - (int) $baselineStats['Critical']['value'])->toBe(1)
|
||||
->and((int) $stats['Unknown']['value'] - (int) $baselineStats['Unknown']['value'])->toBe(1)
|
||||
->and($stats['Unknown']['description'])->toBe('Missing or stale inputs stay explicit instead of silently reading healthy.');
|
||||
->and($stats['Unknown']['description'])->toBe('Missing or stale inputs stay explicit instead of silently reading ready.');
|
||||
});
|
||||
|
||||
it('registers the customer health widget on the system dashboard for authorized users', function (): void {
|
||||
|
||||
@ -38,13 +38,13 @@
|
||||
|
||||
$warningTenant = ManagedEnvironment::factory()->create([
|
||||
'workspace_id' => (int) $workspace->getKey(),
|
||||
'name' => 'B Warning ManagedEnvironment',
|
||||
'name' => 'B Needs Attention ManagedEnvironment',
|
||||
'status' => ManagedEnvironment::STATUS_ACTIVE,
|
||||
]);
|
||||
|
||||
$healthyTenant = ManagedEnvironment::factory()->create([
|
||||
'workspace_id' => (int) $workspace->getKey(),
|
||||
'name' => 'C Healthy ManagedEnvironment',
|
||||
'name' => 'C Ready ManagedEnvironment',
|
||||
'status' => ManagedEnvironment::STATUS_ACTIVE,
|
||||
]);
|
||||
|
||||
@ -102,10 +102,10 @@
|
||||
->assertSeeInOrder([
|
||||
'A Critical ManagedEnvironment',
|
||||
'Critical',
|
||||
'B Warning ManagedEnvironment',
|
||||
'Warn',
|
||||
'C Healthy ManagedEnvironment',
|
||||
'OK',
|
||||
'B Needs Attention ManagedEnvironment',
|
||||
'Needs attention',
|
||||
'C Ready ManagedEnvironment',
|
||||
'Ready',
|
||||
]);
|
||||
});
|
||||
|
||||
|
||||
@ -0,0 +1,118 @@
|
||||
<?php
|
||||
|
||||
declare(strict_types=1);
|
||||
|
||||
use App\Filament\System\Pages\Auth\Login;
|
||||
use App\Filament\System\Widgets\ControlTowerHealthIndicator;
|
||||
use App\Models\OperationRun;
|
||||
use App\Models\PlatformUser;
|
||||
use App\Models\User;
|
||||
use App\Models\Workspace;
|
||||
use App\Models\WorkspaceMembership;
|
||||
use App\Support\Auth\PlatformCapabilities;
|
||||
use App\Support\Auth\WorkspaceRole;
|
||||
use App\Support\OperationRunOutcome;
|
||||
use App\Support\OperationRunStatus;
|
||||
use Filament\Facades\Filament;
|
||||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||||
use Illuminate\Support\Facades\Route;
|
||||
use Livewire\Livewire;
|
||||
|
||||
uses(RefreshDatabase::class);
|
||||
|
||||
beforeEach(function (): void {
|
||||
Filament::setCurrentPanel('system');
|
||||
Filament::bootCurrentPanel();
|
||||
});
|
||||
|
||||
it('Spec396 serves a productized system login page without scaffold branding', function (): void {
|
||||
$this->get('/system/login')
|
||||
->assertSuccessful()
|
||||
->assertSee('TenantPilot System')
|
||||
->assertDontSee('System dashboard')
|
||||
->assertDontSee('Laravel');
|
||||
|
||||
Livewire::test(Login::class)
|
||||
->assertSee('TenantPilot System');
|
||||
});
|
||||
|
||||
it('Spec396 renders the system dashboard with TenantPilot system branding and canonical health copy', function (): void {
|
||||
$user = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::CONSOLE_VIEW,
|
||||
PlatformCapabilities::OPERATIONS_VIEW,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($user, 'platform')
|
||||
->get('/system')
|
||||
->assertSuccessful()
|
||||
->assertSee('TenantPilot System')
|
||||
->assertSee('Ready')
|
||||
->assertDontSee('System dashboard')
|
||||
->assertDontSee('All systems healthy')
|
||||
->assertDontSee('Healthy (has owner)');
|
||||
});
|
||||
|
||||
it('Spec396 renders the system dashboard attention state with canonical health copy', function (): void {
|
||||
OperationRun::factory()->create([
|
||||
'status' => OperationRunStatus::Completed->value,
|
||||
'outcome' => OperationRunOutcome::Failed->value,
|
||||
'created_at' => now()->subMinutes(10),
|
||||
]);
|
||||
|
||||
Livewire::test(ControlTowerHealthIndicator::class)
|
||||
->assertSee('Needs attention')
|
||||
->assertDontSee('All systems healthy')
|
||||
->assertDontSee('Warning');
|
||||
});
|
||||
|
||||
it('Spec396 renders the repair owner stats with canonical readiness copy', function (): void {
|
||||
$workspace = Workspace::factory()->create(['name' => 'Spec396 Ready Workspace']);
|
||||
$owner = User::factory()->create();
|
||||
|
||||
WorkspaceMembership::factory()->create([
|
||||
'workspace_id' => (int) $workspace->getKey(),
|
||||
'user_id' => (int) $owner->getKey(),
|
||||
'role' => WorkspaceRole::Owner->value,
|
||||
]);
|
||||
|
||||
$user = PlatformUser::factory()->create([
|
||||
'capabilities' => [
|
||||
PlatformCapabilities::ACCESS_SYSTEM_PANEL,
|
||||
PlatformCapabilities::USE_BREAK_GLASS,
|
||||
],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($user, 'platform')
|
||||
->get('/system/repair-workspace-owners')
|
||||
->assertSuccessful()
|
||||
->assertSee('Ready (has owner)')
|
||||
->assertDontSee('Healthy (has owner)');
|
||||
});
|
||||
|
||||
it('Spec396 keeps tenant web users out of the platform-guarded system panel', function (): void {
|
||||
$tenantUser = User::factory()->create();
|
||||
|
||||
$this->actingAs($tenantUser, 'web')
|
||||
->get('/system')
|
||||
->assertNotFound();
|
||||
});
|
||||
|
||||
it('Spec396 still denies platform users without the system panel capability', function (): void {
|
||||
$user = PlatformUser::factory()->create([
|
||||
'capabilities' => [],
|
||||
'is_active' => true,
|
||||
]);
|
||||
|
||||
$this->actingAs($user, 'platform')
|
||||
->get('/system')
|
||||
->assertForbidden();
|
||||
});
|
||||
|
||||
it('Spec396 reuses platform guard smoke proof without adding a system smoke helper route', function (): void {
|
||||
expect(Route::has('system.local.smoke-login'))->toBeFalse();
|
||||
});
|
||||
@ -8,7 +8,7 @@ ## Summary
|
||||
| --- | ---: | --- |
|
||||
| UI route/page inventory rows | 101 | Includes dynamic route families and utility/auth endpoints. |
|
||||
| Unique page reports | 22 | `page-reports/*.md`; some inventory rows intentionally share existing reports where routes resolve to the same surface. |
|
||||
| Desktop screenshots | 18 | Route-inventory-linked desktop evidence, including strategic runtime captures, blocker evidence screenshots, and the Spec 366 rendered-report capture. |
|
||||
| Desktop screenshots | 22 | Route-inventory-linked desktop evidence, including strategic runtime captures, blocker evidence screenshots, the Spec 366 rendered-report capture, and Spec 396 system-panel focused proof. |
|
||||
| Tablet screenshots | 0 | Deferred to later strategic mockup/implementation specs. |
|
||||
| Mobile screenshots | 3 | Spec 366 adds mobile-ish rendered-report evidence for the customer technical profile; Spec 384 adds a narrow baseline subject resolution smoke capture; Spec 386 adds a narrow publication-resolution smoke capture. |
|
||||
| Strategic Surface rows | 47 | Individual target treatment or explicit product decision required. |
|
||||
@ -48,7 +48,7 @@ ## Coverage By Area
|
||||
|
||||
| Area | Rows | Coverage Notes |
|
||||
| --- | ---: | --- |
|
||||
| Platform/system | 14 | Route-discovered; not browser-reviewed in Spec 323 because system auth/capability state needs separate fixture. |
|
||||
| Platform/system | 14 | Spec 396 adds focused browser proof for `/system`, `/system/login`, `/system/ops/runs`, and `/system/security/access-logs`; remaining directory, control, detail, and repair surfaces stay route-discovered or follow-up. |
|
||||
| Governance | 13 | Strong browser coverage for inbox, decisions, exceptions, baselines; detail/diff routes remain unresolved; Spec 384 adds a feature-tested baseline subject resolution worklist. |
|
||||
| Monitoring | 9 | Operations hub and alert delivery landing captured; record details and config forms remain pattern/manual review. |
|
||||
| Inventory | 8 | Route-discovered only; coverage, policy version detail, and raw-data exposure need later review. |
|
||||
@ -101,7 +101,7 @@ ## Coverage By Design Depth
|
||||
|
||||
## Missing Or Unclear Coverage
|
||||
|
||||
The largest open gaps are strategic detail/workflow surfaces, system-plane routes, and high-risk restore/backup flows that need seeded capability states. `unresolved-pages.md` records 28 high-priority entries.
|
||||
The largest open gaps are strategic detail/workflow surfaces, remaining system-plane control/detail/repair routes, and high-risk restore/backup flows that need seeded capability states. `unresolved-pages.md` records 28 high-priority entries.
|
||||
|
||||
Tablet and mobile coverage is intentionally absent from this baseline. Later target specs should add responsive evidence for the app shell, workspace overview, environment dashboard, customer review workspace, governance inbox, operations, evidence, backup/restore, and critical forms.
|
||||
|
||||
@ -112,7 +112,7 @@ ## Recommended Next Specs
|
||||
3. P0 backup/restore and evidence safety: backup sets, restore runs, backup schedules, review packs, audit/evidence exports.
|
||||
4. P1 provider/onboarding and access: provider connections, consent/onboarding, environment access scopes, workspace administration.
|
||||
5. P1 drift/diff and inventory: baseline compare, baseline matrix, policy version detail, inventory coverage.
|
||||
6. P2 system-plane controls: system dashboard, operational controls, system operation detail, access logs, repair workspace owners.
|
||||
6. P2 remaining system-plane controls: operational controls, system operation detail, directory detail, and repair workspace owners.
|
||||
|
||||
## Update Rule
|
||||
|
||||
|
||||
@ -93,8 +93,8 @@ # Route Inventory
|
||||
| UI-082 | `/` | route/view | Welcome | Public | public | reachable | none | Auth / Access | Utility / Internal | Design-System Cleanup Surface | repo-verified | - | - | Public Laravel welcome-style route; not admin product surface. |
|
||||
| UI-083 | `/auth/entra/redirect` and `/callback` | controller | Entra Login Flow | Auth/access | auth | route exists | external auth | Auth / Access | Provider / Integration | Domain Pattern Surface | repo-verified | - | - | External auth flow. |
|
||||
| UI-084 | `/admin/local/smoke-login`, `/admin/local/backup-health-browser-fixture-login` | local routes | Local Smoke Login | Utility | local/testing | reachable in local | local/testing only | Utility / Internal | Auth / Access | Internal / Deprecated / Hidden | repo-verified | - | - | Browser fixture utility; not product UI. |
|
||||
| UI-085 | `/system` | System panel | System Dashboard | Platform/system | platform | route exists | platform guard + capability | Overview / Dashboard | Support / Diagnostics | Strategic Surface | repo-verified | - | - | Platform control tower landing. |
|
||||
| UI-086 | `/system/login` | System auth page | System Login | Platform/system | platform | route exists | platform guard | Auth / Access | Utility / Internal | Design-System Cleanup Surface | repo-verified | - | - | Separate platform guard/session. |
|
||||
| UI-085 | `/system` | System panel | TenantPilot System Dashboard | Platform/system | platform | route exists | platform guard + capability | Overview / Dashboard | Support / Diagnostics | Strategic Surface | repo-verified | [desktop](../../specs/396-system-panel-branding/artifacts/screenshots/001-system-dashboard.png) | [report](../../specs/396-system-panel-branding/implementation-report.md) | Spec 396 productized System Admin / Technical Annex landing with focused browser proof. |
|
||||
| UI-086 | `/system/login` | System auth page | TenantPilot System Login | Platform/system | platform | route exists | platform guard | Auth / Access | Utility / Internal | Design-System Cleanup Surface | repo-verified | [desktop](../../specs/396-system-panel-branding/artifacts/screenshots/004-system-login.png) | [report](../../specs/396-system-panel-branding/implementation-report.md) | Spec 396 productized separate platform guard/session login. |
|
||||
| UI-087 | `/system/directory/tenants` | System page | System Tenant Directory | Platform/system | platform | route exists | platform capability | Settings / Admin | Support / Diagnostics | Domain Pattern Surface | repo-verified | - | - | Platform directory; terminology must stay provider-bound. |
|
||||
| UI-088 | `/system/directory/tenants/{tenant}` | System page | System Tenant Detail | Platform/system | platform record | route exists | platform capability | Settings / Admin | Support / Diagnostics | Domain Pattern Surface | repo-verified | - | - | Dynamic platform detail route. |
|
||||
| UI-089 | `/system/directory/workspaces` | System page | System Workspace Directory | Platform/system | platform | route exists | platform capability | Settings / Admin | Support / Diagnostics | Domain Pattern Surface | repo-verified | - | - | Platform workspace directory. |
|
||||
@ -102,8 +102,8 @@ # Route Inventory
|
||||
| UI-091 | `/system/ops/controls` | System page | Operational Controls | Platform/system | platform | route exists | platform capability | Support / Diagnostics | Operations / Monitoring | Strategic Surface | repo-verified | - | - | High-impact platform controls. |
|
||||
| UI-092 | `/system/ops/failures` | System page | Failed Operations | Platform/system | platform | route exists | platform capability | Operations / Monitoring | Support / Diagnostics | Domain Pattern Surface | repo-verified | - | - | Platform failure triage. |
|
||||
| UI-093 | `/system/ops/runbooks` | System page | Runbooks | Platform/system | platform | route exists | platform capability | Support / Diagnostics | Utility / Internal | Domain Pattern Surface | repo-verified | - | - | Internal runbook surface. |
|
||||
| UI-094 | `/system/ops/runs` | System page | System Operations | Platform/system | platform | route exists | platform capability | Operations / Monitoring | Support / Diagnostics | Strategic Surface | repo-verified | - | - | Platform-wide operation monitor. |
|
||||
| UI-094 | `/system/ops/runs` | System page | System Operations | Platform/system | platform | route exists | platform capability | Operations / Monitoring | Support / Diagnostics | Strategic Surface | repo-verified | [desktop](../../specs/396-system-panel-branding/artifacts/screenshots/002-system-operations.png) | [report](../../specs/396-system-panel-branding/implementation-report.md) | Spec 396 focused browser proof for the platform-wide operation monitor. |
|
||||
| UI-095 | `/system/ops/runs/{run}` | System page | System Operation Detail | Platform/system | platform record | route exists | platform capability | Operations / Monitoring | Evidence / Audit | Strategic Surface | repo-verified | - | - | Platform run detail with controls. |
|
||||
| UI-096 | `/system/ops/stuck` | System page | Stuck Operations | Platform/system | platform | route exists | platform capability | Operations / Monitoring | Support / Diagnostics | Domain Pattern Surface | repo-verified | - | - | Platform stalled-run triage. |
|
||||
| UI-097 | `/system/repair-workspace-owners` | System page | Repair Workspace Owners | Platform/system | platform | route exists | platform capability | Support / Diagnostics | Auth / Access | Strategic Surface | repo-verified | - | - | Break-glass repair surface; high-impact. |
|
||||
| UI-098 | `/system/security/access-logs` | System page | Access Logs | Platform/system | platform | route exists | platform capability | Evidence / Audit | Support / Diagnostics | Strategic Surface | repo-verified | - | - | Platform access audit surface. |
|
||||
| UI-098 | `/system/security/access-logs` | System page | Access Logs | Platform/system | platform | route exists | platform capability | Evidence / Audit | Support / Diagnostics | Strategic Surface | repo-verified | [desktop](../../specs/396-system-panel-branding/artifacts/screenshots/003-system-access-logs.png) | [report](../../specs/396-system-panel-branding/implementation-report.md) | Spec 396 focused browser proof for platform access audit. |
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
61
specs/396-system-panel-branding/checklists/requirements.md
Normal file
61
specs/396-system-panel-branding/checklists/requirements.md
Normal file
@ -0,0 +1,61 @@
|
||||
# Requirements Checklist: Spec 396 - System Panel Branding and Productization Smoke Config v1
|
||||
|
||||
**Purpose**: Validate that the preparation artifacts are complete, bounded, and ready for implementation planning review.
|
||||
**Created**: 2026-06-21
|
||||
**Feature**: [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/396-system-panel-branding/spec.md)
|
||||
|
||||
## Candidate And Scope
|
||||
|
||||
- [x] CHK001 The selected candidate is explicitly named and tied to the user-provided Spec 396 brief.
|
||||
- [x] CHK002 The candidate explains why it is suitable even though the automatic next-best-prep queue is empty.
|
||||
- [x] CHK003 Close alternatives are deferred without expanding this spec.
|
||||
- [x] CHK004 Completed Specs 376, 377, 391, and 395 are treated as read-only context.
|
||||
- [x] CHK005 The scope is bounded to existing `/system` branding, titles, navigation labels, status vocabulary, smoke/debug proof, and tests.
|
||||
- [x] CHK006 Non-goals prohibit migrations, models, Graph calls, jobs, queues, schedulers, new persisted entities, new system features, and broad `/system` IA redesign.
|
||||
|
||||
## Requirement Quality
|
||||
|
||||
- [x] CHK007 User stories are independently testable and prioritized.
|
||||
- [x] CHK008 Functional requirements are numbered and verifiable.
|
||||
- [x] CHK009 Success criteria are measurable and tied to focused browser/productization outcomes.
|
||||
- [x] CHK010 No clarification markers remain.
|
||||
- [x] CHK011 No template fill-in text remains in `spec.md`, `plan.md`, or `tasks.md`.
|
||||
- [x] CHK012 Assumptions and non-blocking implementation decisions are recorded.
|
||||
|
||||
## Product Surface Contract
|
||||
|
||||
- [x] CHK013 The spec references and applies `docs/product/standards/product-surface-contract.md`.
|
||||
- [x] CHK014 No-legacy posture is explicit and defaults to canonical replacement.
|
||||
- [x] CHK015 Product Surface Impact and UI Surface Impact are recorded.
|
||||
- [x] CHK016 The page archetype is System Admin / Technical Annex with a narrow existing-surface budget.
|
||||
- [x] CHK017 Canonical status vocabulary is defined without creating a new status family.
|
||||
- [x] CHK018 Product Surface exceptions are `none`.
|
||||
- [x] CHK019 Focused browser proof and Human Product Sanity expectations are specified.
|
||||
- [x] CHK020 Implementation-report close-out fields are listed in plan and tasks.
|
||||
- [x] CHK020A Durable UI coverage registry updates are planned for `route-inventory.md` and `design-coverage-matrix.md`.
|
||||
|
||||
## Filament, Security, And Operations
|
||||
|
||||
- [x] CHK021 Livewire v4.1.4 compliance is stated; no Livewire v3 posture is introduced.
|
||||
- [x] CHK022 Provider registration location remains `apps/platform/bootstrap/providers.php`.
|
||||
- [x] CHK023 Global search posture is stated as no resource/global-search change.
|
||||
- [x] CHK024 Destructive/high-impact action posture requires `->action(...)`, `->requiresConfirmation()`, authorization, audit, and tests if touched.
|
||||
- [x] CHK025 Asset strategy and deployment impact are stated.
|
||||
- [x] CHK026 Platform guard, capability checks, deny-as-not-found, and no production smoke bypass are represented in the requirements.
|
||||
|
||||
## Task Readiness
|
||||
|
||||
- [x] CHK027 Tasks are dependency-ordered by inventory, tests-first work, branding, status vocabulary, smoke proof, and close-out.
|
||||
- [x] CHK028 Tasks name concrete files and expected test lanes.
|
||||
- [x] CHK029 Browser proof and debug/runtime leak checks are required.
|
||||
- [x] CHK030 The implementation explicitly stops short of new product capability and records follow-up candidates instead.
|
||||
|
||||
## Review Outcome
|
||||
|
||||
- [x] CHK031 Review outcome class: `acceptable-special-case`.
|
||||
- [x] CHK032 Workflow outcome: `keep`.
|
||||
- [x] CHK033 Final note location: active feature implementation report and PR close-out.
|
||||
|
||||
## Notes
|
||||
|
||||
Preparation is ready for implementation review. Runtime application implementation has not started in this prep pass.
|
||||
79
specs/396-system-panel-branding/implementation-report.md
Normal file
79
specs/396-system-panel-branding/implementation-report.md
Normal file
@ -0,0 +1,79 @@
|
||||
# Implementation Report: Spec 396 - System Panel Branding and Productization Smoke Config v1
|
||||
|
||||
## Reviewed Inputs
|
||||
|
||||
- Reviewed before runtime UI edits: `docs/product/standards/product-surface-contract.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/filament-guidelines.md`, `docs/testing-guidelines.md`, `docs/ai-coding-rules.md`, `.specify/memory/constitution.md`, and the active Spec 396 `spec.md`, `plan.md`, and `tasks.md`.
|
||||
- Inventory covered: `SystemPanelProvider`, system auth login page, dashboard title localization, system directory/ops/security/repair page labels, system health widgets, badge mapping, smoke routes, debugbar suppression middleware, and existing Spec 376 platform-guard browser smoke.
|
||||
|
||||
## Implementation Summary
|
||||
|
||||
- Status: complete.
|
||||
- System smoke helper decision: not added. Spec 396 reuses the existing Pest Browser platform-guard approach.
|
||||
- Runtime scope: existing `/system` Filament panel branding, system logo view, login title/heading, dashboard title localization, system-health badge/widget labels, and focused tests only.
|
||||
- No runtime expansion: no migrations, models, persisted entities, Graph calls, jobs, queues, schedulers, new dashboards, new routes, or broad UI redesign were added.
|
||||
|
||||
## Product Surface Impact
|
||||
|
||||
- Product Surface Impact: visible `/system` System Admin / Technical Annex surfaces changed.
|
||||
- UI Surface Impact: panel brand/title/login/status labels and focused smoke evidence.
|
||||
- No-legacy posture: canonical replacement; scaffold/default labels are not retained in active UI.
|
||||
- Page archetype: System Admin / Technical Annex.
|
||||
- Surface budget: existing `/system` panel surfaces only; no new routes, navigation groups, cards, metrics, tables, persisted entities, jobs, queues, schedulers, Graph calls, or migrations.
|
||||
- Product Surface exceptions: none.
|
||||
|
||||
## Filament And Runtime Posture
|
||||
|
||||
- Livewire v4 compliance: Livewire 4.1.4 is in use; no Livewire v3 APIs were introduced.
|
||||
- Provider registration: unchanged in `apps/platform/bootstrap/providers.php`.
|
||||
- Global search: no Filament Resource or global-search behavior changed.
|
||||
- Destructive/high-impact actions: no break-glass or operational-control actions were changed. Existing actions remain server-side `->action(...)` handlers with confirmation, capability checks, and audit behavior.
|
||||
- Asset strategy: no new Filament registered assets. System panel reuses the existing theme asset strategy and `favicon.ico`; deployment keeps the existing `php artisan filament:assets` posture for registered Filament assets.
|
||||
- Deployment impact: no env vars, migrations, queues, schedulers, storage, workers, Graph scopes, or Dokploy runtime changes.
|
||||
|
||||
## Verification
|
||||
|
||||
- Feature tests:
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemHealthBadgeSemanticsTest` passed: 4 tests, 11 assertions.
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemPanelAuthTest` passed: 6 tests, 28 assertions.
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec396` passed: 9 tests, 64 assertions.
|
||||
- Adjacent label-dependent checks passed: `DirectoryTenantsTest` passed with 3 tests, 11 assertions; `CustomerHealthDashboardWidgetsTest` passed with 2 tests, 10 assertions.
|
||||
- Browser proof:
|
||||
- `cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec396SystemPanelProductizationSmokeTest.php` passed: 2 tests, 48 assertions.
|
||||
- Covered `/system`, `/system/ops/runs`, `/system/security/access-logs`, and `/system/login` with platform-guard fixtures.
|
||||
- Covered both the default `Ready` dashboard state and the `Needs attention` dashboard state after a failed OperationRun fixture.
|
||||
- Asserted no JavaScript errors, no console logs, no debugbar text, no Vite error text, no exception page text, and productized system branding.
|
||||
- Formatting: `cd apps/platform && ./vendor/bin/sail pint --dirty` passed with no file changes.
|
||||
- Human Product Sanity: passed from retained screenshots. The system dashboard, operations empty state, access-log empty state, and login page show TenantPilot System branding, no debugbar/exception chrome, and no visible scaffold/default branding.
|
||||
- Visible complexity outcome: neutral to decreased. The change replaces ambiguous labels with canonical copy without adding new UI surface area.
|
||||
- Browser/no-browser truth: focused browser proof required because rendered system UI changed.
|
||||
- Auth truth: platform guard and capability checks are preserved; tenant web users remain excluded from `/system`; platform users without `ACCESS_SYSTEM_PANEL` remain forbidden.
|
||||
- Debug truth: no debugbar, Vite overlay, exception page, Livewire/Filament runtime error, console error, secret, provider token, or raw credential was present in retained screenshots.
|
||||
|
||||
## Vocabulary Review
|
||||
|
||||
- Canonical visible labels: `Ready`, `Needs attention`, `Critical`, `Unknown`.
|
||||
- Old `SystemHealthBadge` presentation labels were replaced: `OK` -> `Ready`, `Warn` -> `Needs attention`.
|
||||
- Intentional remaining usage:
|
||||
- `ProviderVerificationStatusBadge`, `VerificationCheckStatusBadge`, `TenantRbacStatusBadge`, baseline-compare labels, and provider-verification fixture values keep their separate domain terminology (`Healthy`, `Degraded`, `Warn`, `OK`, `Warning`) outside the SystemHealth presentation family.
|
||||
- Spec 396 tests use old labels only as negative assertions to prevent regression (`All systems healthy`, `Healthy (has owner)`).
|
||||
- Completed-spec browser/feature fixtures retain historical names and assertions where they belong to provider, backup, dashboard, or completed-spec evidence outside this feature.
|
||||
|
||||
## Coverage Artifacts
|
||||
|
||||
- Route inventory: updated `docs/ui-ux-enterprise-audit/route-inventory.md` for UI-085, UI-086, UI-094, and UI-098.
|
||||
- Design coverage matrix: updated `docs/ui-ux-enterprise-audit/design-coverage-matrix.md` for the Spec 396 system-panel focused proof.
|
||||
- Browser screenshots retained under `specs/396-system-panel-branding/artifacts/screenshots/`:
|
||||
- `001-system-dashboard.png`
|
||||
- `002-system-operations.png`
|
||||
- `003-system-access-logs.png`
|
||||
- `004-system-login.png`
|
||||
- Artifact note: Sail's `/var/www/repo` mirror is read-only for browser tests, so generated screenshots were copied from the writable Pest Browser output into the spec artifact directory from the host workspace after the passing browser run.
|
||||
|
||||
## No Completed-Spec Rewrite Assertion
|
||||
|
||||
- Completed historical specs 376, 377, 391, and 395 remain read-only context and were not rewritten for Product Surface wording.
|
||||
|
||||
## Follow-Up Candidates
|
||||
|
||||
- Remaining system-plane productization candidates: `/system/ops/controls`, `/system/ops/runs/{run}`, directory detail surfaces, and `/system/repair-workspace-owners`.
|
||||
- Provider-verification vocabulary remains a separate domain decision and was not changed by this system-health branding slice.
|
||||
247
specs/396-system-panel-branding/plan.md
Normal file
247
specs/396-system-panel-branding/plan.md
Normal file
@ -0,0 +1,247 @@
|
||||
# Implementation Plan: Spec 396 - System Panel Branding and Productization Smoke Config v1
|
||||
|
||||
**Branch**: `396-system-panel-branding` | **Date**: 2026-06-21 | **Spec**: [spec.md](/Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/396-system-panel-branding/spec.md)
|
||||
**Input**: Feature specification from `/specs/396-system-panel-branding/spec.md`
|
||||
|
||||
## Summary
|
||||
|
||||
Productize the existing `/system` Filament panel so platform operators and reviewers see TenantPilot-branded system surfaces, canonical status labels, and deterministic focused browser proof. The implementation must stay narrow: update existing system panel configuration, labels, status vocabulary, and smoke/debug suppression only where required. It must not add system features, persisted entities, Graph calls, migrations, new dashboards, or broad Product Surface Contract enforcement.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: PHP 8.4.15, Laravel 12.52.0
|
||||
**Primary Dependencies**: Filament 5.2.1, Livewire 4.1.4, Laravel Sail 1.x, Pest 4.3.1, Tailwind CSS 4.2.2
|
||||
**Storage**: PostgreSQL is the application database; this spec requires no schema or storage change
|
||||
**Testing**: Pest feature tests, Filament/Livewire action tests where touched, Pest Browser focused smoke, Pint for formatting
|
||||
**Validation Lanes**: fast-feedback for label/status/auth tests, confidence for focused system browser smoke, no broad full-browser-suite gate unless implementation touches shared panel/provider behavior
|
||||
**Target Platform**: `apps/platform` Laravel application deployed as containerized Dokploy staging/production runtime
|
||||
**Project Type**: Laravel monolith with Filament admin and system panels plus standalone website outside this scope
|
||||
**Performance Goals**: No new query-heavy widgets or polling; smoke/helper changes must not add user-visible latency
|
||||
**Constraints**: No migrations, models, Graph calls, jobs, queues, schedulers, provider framework changes, broad IA redesign, or production smoke-login bypass
|
||||
**Scale/Scope**: Existing `/system` panel routes only; focused proof of `/system`, `/system/ops/runs`, and one security/repair/control page
|
||||
|
||||
## UI / Surface Guardrail Plan
|
||||
|
||||
- **Guardrail scope**: Changed operator-facing system panel surfaces and workflow-only browser-smoke guardrail.
|
||||
- **Affected routes/pages/actions/states/navigation/panel/provider surfaces**:
|
||||
- `/system`
|
||||
- `/system/login`
|
||||
- `/system/ops/runs`
|
||||
- `/system/ops/failures`
|
||||
- `/system/ops/stuck`
|
||||
- `/system/ops/runbooks`
|
||||
- `/system/ops/controls`
|
||||
- `/system/ops/runs/{run}`
|
||||
- `/system/directory/workspaces`
|
||||
- `/system/directory/workspaces/{workspace}`
|
||||
- `/system/directory/tenants`
|
||||
- `/system/directory/tenants/{tenant}`
|
||||
- `/system/security/access-logs`
|
||||
- `/system/repair-workspace-owners`
|
||||
- `apps/platform/app/Providers/Filament/SystemPanelProvider.php`
|
||||
- `apps/platform/app/Filament/System/Pages/**`
|
||||
- `apps/platform/app/Filament/System/Widgets/**`
|
||||
- `apps/platform/app/Support/Badges/Domains/SystemHealthBadge.php`
|
||||
- **No-impact class, if applicable**: N/A because visible labels and smoke proof are in scope.
|
||||
- **Native vs custom classification summary**: Native Filament pages, panels, widgets, notifications, and actions. Smoke helper, if required, must be a local/testing-only route helper, not a product UI surface.
|
||||
- **Shared-family relevance**: Badge/status vocabulary and system smoke/debug-suppression pattern.
|
||||
- **State layers in scope**: Shell, page, detail, navigation, and local/testing smoke request context.
|
||||
- **Audience modes in scope**: Support-platform/system operator only.
|
||||
- **Decision/diagnostic/raw hierarchy plan**: Keep `/system` intentionally technical, but make top-level labels decision-first; keep diagnostics and raw details in their existing technical pages.
|
||||
- **Raw/support gating plan**: Capability-gated platform panel remains required; no tenant session access.
|
||||
- **One-primary-action / duplicate-truth control**: Preserve existing page actions; do not add duplicate CTA cards or new dashboards.
|
||||
- **Handling modes by drift class or surface**: Existing product-surface drift on system branding/status copy is review-mandatory and fixed within this feature. Unrelated full-suite browser noise is report-only unless directly caused by this spec.
|
||||
- **Repository-signal treatment**: Existing Spec 376/377/395 evidence is context only; completed specs are not rewritten.
|
||||
- **Special surface test profiles**: Technical Annex, system-admin surface, focused browser smoke, native Filament panel.
|
||||
- **Required tests or manual smoke**: Feature/status/auth tests, action posture verification for any touched high-impact actions, focused Pest Browser smoke, human product sanity on the system panel.
|
||||
- **Exception path and spread control**: None planned. Any local/testing-only helper is explicitly not a Product Surface exception if hidden from production navigation and guarded by environment.
|
||||
- **Active feature PR close-out entry**: Must report Product Surface Impact, UI Surface Impact, no-legacy posture, browser proof, human sanity result, Livewire v4, provider registration, global search, destructive/high-impact actions, asset strategy, and deployment impact.
|
||||
- **UI/Productization coverage decision**: Durable coverage registry artifacts plus this active spec and implementation report must be updated.
|
||||
- **Coverage artifacts to update**: `docs/ui-ux-enterprise-audit/route-inventory.md`, `docs/ui-ux-enterprise-audit/design-coverage-matrix.md`, and `specs/396-system-panel-branding/implementation-report.md` during implementation.
|
||||
- **No-impact rationale**: N/A.
|
||||
- **Navigation / Filament provider-panel handling**: Provider-panel handling is in scope; registration location must remain `apps/platform/bootstrap/providers.php`.
|
||||
- **Screenshot or page-report need**: Focused browser proof and screenshots/log evidence are required because this is a visible productization spec.
|
||||
|
||||
## Product Surface Contract Plan
|
||||
|
||||
- **Product Surface Contract reference**: `docs/product/standards/product-surface-contract.md` reviewed before preparation.
|
||||
- **No-legacy posture**: Canonical replacement. Old scaffold/default labels are not preserved as compatibility aliases in active UI.
|
||||
- **Page archetype and surface budget plan**: System Admin / Technical Annex. The budget is existing system panel surfaces only; no new cards, metrics, navigation groups, or workflows.
|
||||
- **Technical Annex and deep-link demotion plan**: Existing operations, repair, control, runbook, failure, and stuck-run pages may remain technical. Raw IDs/source keys/payloads stay in existing detail/technical views and are not promoted onto primary system dashboard copy.
|
||||
- **Canonical status vocabulary plan**:
|
||||
- `ok`, healthy equivalents, and `All systems healthy`: `Ready`
|
||||
- `warn`, warning equivalents, `Degraded`, and ambiguous attention states: `Needs attention`
|
||||
- `critical`: `Critical`
|
||||
- operation/control execution states: preserve existing `Blocked`, `Running`, or `Failed` wording only where they already represent OperationRun/control truth
|
||||
- `unknown`: `Unknown`
|
||||
- Do not introduce a new status family; map existing states to canonical presentation labels.
|
||||
- **Product Surface exceptions**: None.
|
||||
- **Browser verification plan**: Focused platform-guard browser smoke for `/system`, `/system/ops/runs`, and one security/repair/control page; assert no debugbar, Vite overlay, exception page, Livewire/Filament console/runtime errors, or default framework branding.
|
||||
- **Human Product Sanity plan**: Review `/system` and `/system/ops/runs` as a platform operator and record whether visible complexity stayed neutral or decreased.
|
||||
- **Visible complexity outcome target**: Neutral or decreased.
|
||||
- **Implementation report target**: `specs/396-system-panel-branding/implementation-report.md`.
|
||||
|
||||
## Filament / Livewire / Deployment Posture
|
||||
|
||||
- **Livewire v4 compliance**: Livewire 4.1.4 confirmed; no Livewire v3 APIs or references allowed.
|
||||
- **Panel provider registration location**: Existing Laravel provider registration remains `apps/platform/bootstrap/providers.php`; no provider registration change is planned.
|
||||
- **Global search posture**: No Filament Resource or global-search behavior is changed. If implementation unexpectedly touches a globally searchable resource, it must either have Edit/View page support or disable global search.
|
||||
- **Destructive/high-impact action posture**: No new destructive action is planned. Existing break-glass and operational-control actions must retain `->action(...)`, `->requiresConfirmation()`, platform capability checks, and audit logging if touched.
|
||||
- **Asset strategy**: No new assets by default. Existing panel-only theme asset remains the strategy. `php artisan filament:assets` is not newly required unless implementation registers or changes Filament assets.
|
||||
- **Testing plan**: Cover status/badge vocabulary, system panel auth/smoke safety, touched high-impact actions, and focused browser smoke through Pest/Pest Browser.
|
||||
- **Deployment impact**: No env vars, migrations, queues, schedulers, storage, workers, Graph scopes, or Dokploy runtime changes planned.
|
||||
|
||||
## Shared Pattern & System Fit
|
||||
|
||||
- **Cross-cutting feature marker**: Yes, because status vocabulary and smoke/debug suppression are shared patterns.
|
||||
- **Systems touched**:
|
||||
- Filament system panel provider.
|
||||
- System pages and widgets.
|
||||
- Badge/status rendering.
|
||||
- Local/testing browser smoke support if required.
|
||||
- Platform auth/capability tests.
|
||||
- **Shared abstractions reused**:
|
||||
- `SystemHealthBadge` / badge-rendering patterns.
|
||||
- Existing platform guard and capability policies.
|
||||
- Existing smoke/debug-suppression middleware where possible.
|
||||
- Existing localization files.
|
||||
- **New abstraction introduced? why?**: None approved. A local/testing helper route is allowed only if existing Pest Browser platform guard is insufficient for manual in-app proof.
|
||||
- **Why the existing abstraction was sufficient or insufficient**: Existing panel/pages/widgets already own the visible surfaces; existing badge and localization layers can carry the label changes. Existing browser test evidence proves platform-guard access, so any new smoke helper must justify itself as manual proof support only.
|
||||
- **Bounded deviation / spread control**: Any smoke helper must be environment-gated, unlinked, platform-guarded, and covered by route safety tests.
|
||||
|
||||
## OperationRun UX Impact
|
||||
|
||||
- **Touches OperationRun start/completion/link UX?**: No.
|
||||
- **Central contract reused**: N/A.
|
||||
- **Monitoring/deduplication semantics preserved**: Yes. This spec only productizes visible system surfaces and smoke proof.
|
||||
- **User-facing run state copy changed?**: Only if existing system status labels on operations pages use scaffold/default copy; no OperationRun status semantics change is approved.
|
||||
- **Required tests**: Existing OperationRun authorization/listing tests continue to pass; no new run lifecycle tests unless implementation touches operation actions.
|
||||
|
||||
## Provider Boundary Impact
|
||||
|
||||
- **Touches Graph/provider identity or contract boundary?**: No.
|
||||
- **Provider-specific semantics introduced into platform-core?**: No.
|
||||
- **Governed-subject taxonomy affected?**: No.
|
||||
- **Cross-provider readiness or compare strategy affected?**: No.
|
||||
- **Contract fixtures required?**: No.
|
||||
- **Boundary note**: This is a system-panel productization and smoke-proof feature, not a provider-readiness or Graph-contract feature.
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Must pass before implementation. Re-check after implementation design.*
|
||||
|
||||
- **SPEC-GATE-001**: Passed. Candidate scored 10/12 and is direct user-provided P2 follow-up.
|
||||
- **Product Surface Contract Gate**: Passed for preparation. The spec states no-legacy posture, Product Surface Impact, UI Surface Impact, archetype, surface budget, Technical Annex stance, canonical status vocabulary, exception posture, browser proof, human sanity target, and implementation-report fields.
|
||||
- **Completed-spec guardrail**: Passed. Specs 376, 377, 391, and 395 are context only and not reopened.
|
||||
- **BLOAT-001**: Passed. No new persisted entity, enum/status family, taxonomy/framework, provider abstraction, or cross-domain UI framework is approved.
|
||||
- **RBAC/Audit**: Passed. Platform guard and capability enforcement remain required. High-impact actions retain confirmation, authorization, and audit.
|
||||
- **Data isolation**: Passed. No tenant/customer data model change.
|
||||
- **Test governance**: Passed. Tasks require focused feature/action/browser tests before implementation close-out.
|
||||
- **Deployment safety**: Passed. No runtime infrastructure change planned.
|
||||
|
||||
## Test Governance
|
||||
|
||||
- **Tests to add/update**:
|
||||
- Status/badge vocabulary tests for canonical system labels.
|
||||
- System panel auth/smoke helper safety tests if a helper is added.
|
||||
- Focused Pest Browser smoke for `/system`, `/system/ops/runs`, and one system security/repair/control page.
|
||||
- Action posture tests or reflection assertions if high-impact actions are touched.
|
||||
- `/admin` regression smoke only if a shared provider/config change can affect the tenant admin panel.
|
||||
- **Commands expected during implementation**:
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemHealthBadgeSemanticsTest`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemPanelAuthTest`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec396`
|
||||
- `cd apps/platform && ./vendor/bin/sail pint --dirty`
|
||||
- Browser command to follow the repo's Pest Browser setup for focused Spec 396 proof.
|
||||
- **No verification scripts**: Do not add ad hoc verification scripts when Pest/Pest Browser tests can prove the behavior.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/396-system-panel-branding/
|
||||
├── spec.md
|
||||
├── plan.md
|
||||
├── tasks.md
|
||||
├── checklists/
|
||||
│ └── requirements.md
|
||||
└── implementation-report.md # created during implementation
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
apps/platform/
|
||||
├── app/
|
||||
│ ├── Filament/
|
||||
│ │ └── System/
|
||||
│ │ ├── Pages/
|
||||
│ │ │ ├── Auth/Login.php
|
||||
│ │ │ ├── Dashboard.php
|
||||
│ │ │ ├── Directory/
|
||||
│ │ │ ├── Ops/
|
||||
│ │ │ ├── RepairWorkspaceOwners.php
|
||||
│ │ │ └── Security/
|
||||
│ │ └── Widgets/
|
||||
│ ├── Http/Middleware/SuppressDebugbarForSmokeRequests.php
|
||||
│ ├── Providers/Filament/SystemPanelProvider.php
|
||||
│ └── Support/Badges/Domains/SystemHealthBadge.php
|
||||
├── lang/
|
||||
│ ├── de/localization.php
|
||||
│ └── en/localization.php
|
||||
├── routes/web.php
|
||||
└── tests/
|
||||
├── Browser/
|
||||
└── Feature/
|
||||
```
|
||||
|
||||
**Structure Decision**: Use existing `apps/platform` Filament, localization, badge, route, middleware, and Pest/Pest Browser structure. No new base folders are approved.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
||||
|-----------|------------|-------------------------------------|
|
||||
| None | N/A | N/A |
|
||||
|
||||
## Proportionality Review
|
||||
|
||||
- **Current operator problem**: `/system` can still expose default/scaffold-like branding and inconsistent health labels, and focused manual browser smoke is not deterministic enough for productization review.
|
||||
- **Existing structure is insufficient because**: Labels and smoke proof are spread across provider config, localization, widgets, badge mapping, and existing browser fixtures. They need coordinated preparation, but not new product infrastructure.
|
||||
- **Narrowest correct implementation**: Update existing copy/mapping/config/tests and add only focused smoke support if existing platform-guard browser proof cannot serve manual sanity.
|
||||
- **Ownership cost created**: A few focused tests and an implementation report. No schema, model, enum family, provider contract, or new UI framework cost.
|
||||
- **Alternative intentionally rejected**: Full `/system` redesign or new system dashboard cards, because the current problem is productization and proof, not missing capability.
|
||||
- **Release truth**: Current-release follow-up from completed productization and gate specs.
|
||||
|
||||
## Implementation Phases
|
||||
|
||||
### Phase 1 - Inventory And Contract Lock
|
||||
|
||||
Inventory every visible system label/status/action in scope and record the exact current surfaces. Confirm no completed spec artifacts need rewriting.
|
||||
|
||||
### Phase 2 - Tests First
|
||||
|
||||
Add or update focused tests for canonical status vocabulary, system auth/smoke safety, action posture, and browser proof before or alongside behavior changes.
|
||||
|
||||
### Phase 3 - Productized System Branding
|
||||
|
||||
Apply TenantPilot system branding through existing provider/localization/page paths. Keep the technical system-admin character but remove default or ambiguous visible copy.
|
||||
|
||||
### Phase 4 - Canonical Status Vocabulary
|
||||
|
||||
Map existing system health/status states to canonical labels through existing badge/widget/localization paths.
|
||||
|
||||
### Phase 5 - Smoke And Debug-Safe Proof
|
||||
|
||||
Reuse the existing platform-guard browser path where possible. Add a local/testing-only smoke helper only if required for manual in-app sanity, with route safety coverage.
|
||||
|
||||
### Phase 6 - Close-Out Evidence
|
||||
|
||||
Run focused tests, capture browser proof, complete `implementation-report.md`, and document deployment impact as none unless implementation changes assets.
|
||||
|
||||
## Risk And Rollback Plan
|
||||
|
||||
- **Rollback**: Revert label/config/test changes in the feature branch. No database rollback is required.
|
||||
- **Staging validation**: Run focused test lane and browser smoke before production promotion.
|
||||
- **Production risk**: Low if no smoke helper is exposed outside local/testing and no shared provider config changes affect `/admin`.
|
||||
- **Forward fix path**: If shared branding affects `/admin`, add a focused `/admin` regression fix and proof within this spec before close-out.
|
||||
488
specs/396-system-panel-branding/spec.md
Normal file
488
specs/396-system-panel-branding/spec.md
Normal file
@ -0,0 +1,488 @@
|
||||
# Feature Specification: Spec 396 - System Panel Branding and Productization Smoke Config v1
|
||||
|
||||
**Feature Branch**: `396-system-panel-branding`
|
||||
**Created**: 2026-06-21
|
||||
**Status**: Draft / Ready for preparation review
|
||||
**Input**: Direct user-provided candidate "Spec 396 - System Panel Branding & Productization Smoke Config v1", plus repo context from Specs 368, 376, 377, 391, and 395.
|
||||
|
||||
## Candidate Selection And Completed-Spec Guardrail
|
||||
|
||||
- **Selected candidate**: System Panel Branding and Productization Smoke Config v1.
|
||||
- **Source**: Direct user-provided full candidate in `/Users/ahmeddarrazi/.codex/attachments/c71e0bc0-934c-482d-ac4d-65e86c55ca59/pasted-text.txt`.
|
||||
- **Roadmap relationship**: Matches the manual promotion item `manual-system-panel-browser-fixture-or-audit-procedure` in `docs/product/roadmap.md` and `docs/product/spec-candidates.md`, and the explicit deferred follow-up in Spec 395.
|
||||
- **Why selected**: `docs/product/spec-candidates.md` reports no safe automatic next-best-prep target, but the user supplied a concrete P2 candidate. The candidate closes the remaining system-panel proof/productization gap without reopening broad UI productization.
|
||||
- **Smallest viable slice**: Productize existing `/system` panel branding, page titles, navigation labels, top-level status vocabulary, smoke-login or smoke-auth configuration, focused `/system` browser smoke, and debug/runtime leak checks. Do not add new system features.
|
||||
- **Completed-spec check result**:
|
||||
- No `specs/396-*` package existed before this preparation run.
|
||||
- Spec 376 is completed context for platform-guard Pest Browser proof of `/system` and `/system/ops/runs`; it must not be rewritten.
|
||||
- Spec 377 is completed close-out context and leaves manual in-app `/system` access as a P2 follow-up; it must not be rewritten.
|
||||
- Spec 391 is runtime stability/debug-safe context, not reopened except for direct `/system` smoke regressions.
|
||||
- Spec 395 is completed/current workflow-gate context and explicitly defers manual system-panel browser fixture work; it must not be rewritten.
|
||||
- **Close alternatives deferred**:
|
||||
- Management Report PDF staging/runtime validation remains separate follow-through for Specs 378-380.
|
||||
- Governance Artifact Lifecycle and Retention runtime remains manual-promotion P2 scope.
|
||||
- Provider readiness/onboarding productization remains optional and evidence-triggered.
|
||||
- Cross-domain indicator runtime follow-through remains separate status/indicator scope.
|
||||
- Broad `/system` IA redesign, new dashboard cards, new metrics, and system feature expansion are out of scope.
|
||||
|
||||
## Spec Candidate Check *(mandatory - SPEC-GATE-001)*
|
||||
|
||||
- **Problem**: The `/system` surface is a platform-admin surface, but current repo truth still shows productization and smoke-proof gaps: system labels such as `System dashboard`, `Healthy`, `Warning`, `OK`, `Warn`, and `All systems healthy`; manual in-app `/system` browser access still redirects to `/system/login`; and smoke/debug suppression is centered on admin smoke routes.
|
||||
- **Today's failure**: A reviewer can prove `/system` through Pest Browser platform guard fixtures, but cannot easily perform a manual productized browser smoke. Visible system labels can still read like framework/scaffold or ambiguous health copy rather than TenantPilot system language.
|
||||
- **User-visible improvement**: Platform operators and reviewers see a TenantPilot-branded system panel with canonical status language, deterministic smoke access, and no debug/runtime artifacts on the focused `/system` smoke path.
|
||||
- **Smallest enterprise-capable version**: A narrow productization and smoke-stability pass over existing system panel config, login, dashboard, operations/security/repair surfaces, status labels, local/test smoke access, and focused browser proof.
|
||||
- **Explicit non-goals**: No new system features, no `/system` IA rebuild, no new product dashboard cards, no new readiness model, no production smoke-login route, no provider feature work, no Graph calls, no migrations, no new persisted entities, no compatibility aliases for old labels, and no broad Product Surface Contract enforcement beyond this active spec.
|
||||
- **Permanent complexity imported**: Updated copy/status mappings, focused feature/browser tests, possibly one local/testing-only system smoke helper or documented audit procedure, and implementation-report artifacts. No new product table, enum family, source of truth, provider framework, or UI framework is approved.
|
||||
- **Why now**: Spec 377 closed productization with this system-panel gap as the remaining follow-up, and Spec 395 added the Product Surface Contract gate. Preparing this spec lets the next implementation close that gap without reopening completed specs.
|
||||
- **Why not local**: Manual notes and ad hoc browser sessions do not provide repeatable smoke proof, do not test production safety of fixture routes, and do not prevent default/framework branding from returning.
|
||||
- **Approval class**: Core Enterprise.
|
||||
- **Red flags triggered**: Multiple surfaces and browser fixture work. Defense: the slice is bounded to existing `/system` surfaces and local/test smoke proof, introduces no product truth, and explicitly forbids UI expansion.
|
||||
- **Score**: Nutzen: 2 | Dringlichkeit: 1 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 1 | Wiederverwendung: 2 | **Gesamt: 10/12**
|
||||
- **Decision**: approve as a narrow system-panel productization and smoke-stability slice.
|
||||
|
||||
## Problem Statement
|
||||
|
||||
TenantPilot's `/system` panel is intentionally technical and platform-admin-only. It still must look and behave like TenantPilot, not like a Laravel/Filament scaffold or an unfinished internal console.
|
||||
|
||||
Current repo anchors show the gap:
|
||||
|
||||
- `apps/platform/app/Providers/Filament/SystemPanelProvider.php` registers the `system` panel but has no explicit product brand name in the inspected provider.
|
||||
- `apps/platform/lang/en/localization.php` and `apps/platform/lang/de/localization.php` use `System dashboard` / `System-Dashboard`.
|
||||
- `apps/platform/app/Filament/System/Widgets/ControlTowerHealthIndicator.php` returns `All systems healthy` and `Attention needed`.
|
||||
- `apps/platform/app/Filament/System/Widgets/CustomerHealthKpis.php` renders `Healthy` and `Warning`.
|
||||
- `apps/platform/app/Support/Badges/Domains/SystemHealthBadge.php` maps system health to `OK` and `Warn`.
|
||||
- `apps/platform/tests/Browser/Spec376BrowserAuditFixtureCoverageSmokeTest.php` proves `/system` with `actingAs($platformUser, 'platform')`, while Spec 377 still records manual in-app browser access as not verified.
|
||||
- `apps/platform/app/Http/Middleware/SuppressDebugbarForSmokeRequests.php` suppresses debugbar for admin smoke routes and smoke cookie/session, but the active spec must decide how `/system` smoke carries that protection.
|
||||
|
||||
This spec closes that productization and repeatable-proof gap without adding system capabilities.
|
||||
|
||||
## Product / Business Value
|
||||
|
||||
The system panel is used by platform operators and reviewers. Productized system branding, canonical status labels, deterministic smoke access, and no debug/runtime leaks improve trust in TenantPilot's operational maturity without increasing product complexity.
|
||||
|
||||
## Primary Users / Operators
|
||||
|
||||
- Platform/system operator using `/system`.
|
||||
- Maintainer running focused browser smoke and productization checks.
|
||||
- Product reviewer validating that `/system` is intentionally technical, not unfinished.
|
||||
- Implementation agent needing a bounded task list for the system-panel follow-up.
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: canonical-view / system-admin productization / browser-smoke stability.
|
||||
- **Primary Routes**:
|
||||
- `/system`
|
||||
- `/system/login`
|
||||
- `/system/ops/runs`
|
||||
- `/system/ops/failures`
|
||||
- `/system/ops/stuck`
|
||||
- `/system/ops/runbooks`
|
||||
- `/system/ops/controls`
|
||||
- `/system/directory/workspaces`
|
||||
- `/system/directory/workspaces/{workspace}`
|
||||
- `/system/directory/tenants`
|
||||
- `/system/directory/tenants/{tenant}`
|
||||
- `/system/security/access-logs`
|
||||
- `/system/ops/runs/{run}`
|
||||
- `/system/repair-workspace-owners`
|
||||
- any local/testing-only system smoke helper added or documented by the implementation
|
||||
- **Data Ownership**: No new persisted data. Existing `PlatformUser`, `OperationRun`, `Workspace`, `ManagedEnvironment`, `OperationalControlActivation`, and `AuditLog` truth remains authoritative.
|
||||
- **RBAC**: `/system` remains platform-plane only. Tenant/admin `web` users must receive deny-as-not-found behavior for system routes. Platform users without required capabilities receive 403. Smoke users must be deterministic `PlatformUser` fixtures with explicit capabilities.
|
||||
|
||||
For canonical-view specs:
|
||||
|
||||
- **Default filter behavior when tenant-context is active**: Tenant/admin context must not apply to `/system`. System pages remain platform-plane and tenantless unless a system detail page intentionally displays workspace/environment context.
|
||||
- **Explicit entitlement checks preventing cross-tenant leakage**: System routes must use the `platform` guard and existing `PlatformCapabilities`; smoke helpers must not authenticate tenant users into `/system`.
|
||||
|
||||
## No Legacy / No Backward Compatibility Constraint *(mandatory)*
|
||||
|
||||
TenantPilot is pre-production unless this spec explicitly records a compatibility exception.
|
||||
|
||||
- **Compatibility posture**: canonical replacement.
|
||||
- **Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?**: no.
|
||||
- **Why clean replacement is safe now**: No production deployment or customer data compatibility requirement exists for unfinished `/system` branding or smoke assumptions.
|
||||
|
||||
Implementation must not preserve:
|
||||
|
||||
- visible Laravel/default framework branding as product copy,
|
||||
- old standalone `Dashboard`, `Admin`, `Panel`, `OK`, `Warn`, `Healthy`, or `Warning` labels where they are top-level system product states,
|
||||
- old tests that assert unfinished branding,
|
||||
- production-like smoke-login access,
|
||||
- ambiguous system-health labels that conflict with the Product Surface Contract.
|
||||
|
||||
## UI Surface Impact *(mandatory - UI-COV-001)*
|
||||
|
||||
Does this spec add, remove, rename, or materially change any reachable UI surface?
|
||||
|
||||
- [ ] No UI surface impact
|
||||
- [x] Existing page changed
|
||||
- [ ] New page/route added
|
||||
- [x] Navigation changed
|
||||
- [x] Filament panel/provider surface changed
|
||||
- [ ] New modal/drawer/wizard/action added
|
||||
- [ ] New table/form/state added
|
||||
- [ ] Customer-facing surface changed
|
||||
- [x] Dangerous action changed
|
||||
- [x] Status/evidence/review presentation changed
|
||||
- [ ] Workspace/environment context presentation changed
|
||||
|
||||
`Dangerous action changed` means touched high-impact system actions must be reviewed for separation, confirmation, authorization, and audit behavior. This spec does not add new destructive actions. A local/testing-only smoke helper may be added only if existing Pest Browser platform-guard fixtures cannot satisfy the focused smoke and manual review need; it is tooling, not product navigation.
|
||||
|
||||
## UI/Productization Coverage *(mandatory when UI Surface Impact is not "No UI surface impact")*
|
||||
|
||||
- **Route/page/surface**: `/system`, `/system/login`, `/system/ops/runs`, `/system/ops/runs/{run}`, `/system/ops/failures`, `/system/ops/stuck`, `/system/ops/runbooks`, `/system/ops/controls`, `/system/directory/workspaces`, `/system/directory/workspaces/{workspace}`, `/system/directory/tenants`, `/system/directory/tenants/{tenant}`, `/system/security/access-logs`, `/system/repair-workspace-owners`.
|
||||
- **Current or new page archetype**: System Admin for dashboard/repair/directory/security/access-log surfaces; Technical Annex for operation detail/runbooks/diagnostics where technical detail is the point.
|
||||
- **Design depth**: Internal/System Admin productization pass; no strategic redesign.
|
||||
- **Repo-truth level**: repo-verified.
|
||||
- **Existing pattern reused**: Filament v5 panel provider/pages/widgets/actions, `PlatformUser` + `PlatformCapabilities`, `UseSystemSessionCookie`, `SuppressDebugbarForSmokeRequests`, BadgeCatalog/BadgeRenderer, Spec 376 platform-guard browser smoke pattern, existing System Spec 113/114 tests.
|
||||
- **New pattern required**: none by default. A system local/testing smoke helper is allowed only as a narrow fixture if platform-guard Pest Browser is insufficient for the selected proof path.
|
||||
- **Screenshot required**: yes, focused `/system` desktop smoke screenshot at minimum; mobile screenshot only if the changed surface is layout-sensitive.
|
||||
- **Page audit required**: no full audit. Focused smoke plus Human Product Sanity is sufficient.
|
||||
- **Customer-safe review required**: no customer-facing surface changes.
|
||||
- **Dangerous-action review required**: yes for touched break-glass and operational-control actions; no new destructive action is allowed.
|
||||
- **Coverage files to update during implementation or explicitly not needed**:
|
||||
- [x] `docs/ui-ux-enterprise-audit/route-inventory.md` (implementation task)
|
||||
- [x] `docs/ui-ux-enterprise-audit/design-coverage-matrix.md` (implementation task)
|
||||
- [ ] `docs/ui-ux-enterprise-audit/page-reports/...`
|
||||
- [ ] `docs/ui-ux-enterprise-audit/strategic-surfaces.md`
|
||||
- [ ] `docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md`
|
||||
- [ ] `docs/ui-ux-enterprise-audit/unresolved-pages.md`
|
||||
- [x] `N/A - full page reports and strategic-surface artifacts are not required; active spec plus focused browser proof provide proportional coverage`
|
||||
- **No-impact rationale when applicable**: N/A.
|
||||
|
||||
## Product Surface Impact *(mandatory for UI-affecting specs)*
|
||||
|
||||
Reference: `docs/product/standards/product-surface-contract.md`.
|
||||
|
||||
- **Product Surface Contract applies?**: yes. `/system` is a reachable product/admin surface.
|
||||
- **Page archetype**: System Admin for `/system`; Technical Annex for system operations diagnostics/detail surfaces where technical proof is the product value.
|
||||
- **Primary user question**: What is the platform/system state and what needs system-operator attention?
|
||||
- **Primary action**: Navigate to the relevant system operation, repair, or control surface; no new dominant action is introduced.
|
||||
- **Surface budget result**: pass by System Admin/Technical Annex classification, with visible complexity required to stay neutral or decrease.
|
||||
- **Technical Annex / deep-link demotion**: Raw IDs and OperationRun links may remain in system operations where that is the Technical Annex purpose, but they must not become default branding or dashboard hero content. Debugbar, Vite overlays, exception pages, stack traces, and framework branding must not appear in focused smoke.
|
||||
- **Canonical status vocabulary**: Map existing top-level system states without creating a new status family: `ok`, `healthy`, and `All systems healthy` -> `Ready`; `warn`, `warning`, `Degraded`, and ambiguous attention states -> `Needs attention`; `critical` remains `Critical`; execution-specific operation states may use `Blocked`, `Running`, or `Failed` only where they already represent OperationRun/control truth; `unknown` remains `Unknown`. Current `OK`, `Warn`, `Healthy`, `Warning`, and `All systems healthy` labels are in scope for replacement or explicit technical-detail confinement.
|
||||
- **Visible complexity impact**: neutral or decreased.
|
||||
- **Product Surface exceptions**: none. System Admin and Technical Annex allowances are classifications, not compatibility exceptions.
|
||||
|
||||
## Browser Verification Plan *(mandatory)*
|
||||
|
||||
- **Browser proof required?**: yes.
|
||||
- **No-browser rationale**: N/A.
|
||||
- **Focused path when required**:
|
||||
- `/system`
|
||||
- `/system/ops/runs`
|
||||
- at least one system operations/security/repair page selected from current accessible routes
|
||||
- `/system/login` or local/testing smoke helper safety path as appropriate
|
||||
- a basic `/admin` route smoke if shared panel/provider branding changes
|
||||
- **Primary interaction to execute**: authenticate as a deterministic platform user, load dashboard, verify navigation/sidebar/branding/status labels, open operations and one security/repair/control page, verify no debug/runtime leaks.
|
||||
- **Console, Livewire, Filament, network, and 500-error checks**: required for focused browser smoke.
|
||||
- **Full-suite failure triage**: Full browser suite failures are non-blocking only when focused `/system` and affected `/admin` proof is green, unrelated failures are listed, and no failure indicates system auth/navigation/debug leak regression.
|
||||
|
||||
## Human Product Sanity Check *(mandatory)*
|
||||
|
||||
- **Required?**: yes.
|
||||
- **No-human-sanity rationale**: N/A.
|
||||
- **Reviewer questions**: Does `/system` feel like TenantPilot, not Laravel/Filament scaffolding? Are page titles/navigation clear? Are system statuses canonical? Are technical details intentional? Are destructive/high-impact actions separated? Are debug/dev artifacts absent? Did visible complexity stay neutral or decrease?
|
||||
- **Planned result location**: `specs/396-system-panel-branding/implementation-report.md`.
|
||||
|
||||
## Product Surface Merge Gate Checklist *(mandatory)*
|
||||
|
||||
- [ ] No-legacy posture or approved exception recorded.
|
||||
- [ ] Product Surface Impact is completed.
|
||||
- [ ] Browser proof is completed for focused `/system` paths.
|
||||
- [ ] Human Product Sanity is completed.
|
||||
- [ ] Product Surface exceptions are documented as `none` or explicitly listed.
|
||||
- [ ] Implementation report states Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite.
|
||||
|
||||
## Cross-Cutting / Shared Pattern Reuse
|
||||
|
||||
- **Cross-cutting feature?**: yes.
|
||||
- **Interaction class(es)**: branding, status messaging, navigation labels, auth/session smoke fixture, browser smoke, debug/runtime leak prevention, high-impact system action review.
|
||||
- **Systems touched**: `SystemPanelProvider`, system pages/widgets/views, localization files, BadgeCatalog/SystemHealth mapper, smoke middleware/routes/tests, browser tests.
|
||||
- **Existing pattern(s) to extend**: Filament panel provider branding, localization keys, `BadgeCatalog` / `BadgeRenderer`, Spec 376 browser `actingAs(..., 'platform')`, existing admin smoke-login safety model, `SuppressDebugbarForSmokeRequests`.
|
||||
- **Shared contract / presenter / builder / renderer to reuse**: `BadgeCatalog` / `BadgeRenderer` for status-like badges; existing Filament actions and PlatformCapabilities for system actions.
|
||||
- **Why the existing shared path is sufficient or insufficient**: Existing badge and panel patterns are sufficient for labels/status. Existing Pest Browser platform-guard auth is sufficient for automated browser proof; a separate local/testing route is only allowed if manual in-app smoke cannot otherwise be made deterministic.
|
||||
- **Allowed deviation and why**: Local/testing-only system smoke helper, if needed, with environment guard, platform guard semantics, redirect safety, and no product navigation.
|
||||
- **Consistency impact**: System status labels must align with Product Surface Contract vocabulary while preserving internal diagnostic detail when intentionally technical.
|
||||
- **Review focus**: Verify no production auth weakening, no ad hoc badge/status mapping outside central badge paths, no UI expansion, no completed-spec rewrite.
|
||||
|
||||
## OperationRun UX Impact
|
||||
|
||||
- **Touches OperationRun start/completion/link UX?**: no.
|
||||
- **Shared OperationRun UX contract/layer reused**: N/A.
|
||||
- **Delegated start/completion UX behaviors**: N/A.
|
||||
- **Local surface-owned behavior that remains**: Existing system operation pages may display OperationRun rows; this spec must not create, queue, deduplicate, resume, block, complete, or alter OperationRun start UX.
|
||||
- **Queued DB-notification policy**: N/A.
|
||||
- **Terminal notification path**: N/A.
|
||||
- **Exception required?**: none.
|
||||
|
||||
## Provider Boundary / Platform Core Check
|
||||
|
||||
- **Shared provider/platform boundary touched?**: no shared provider seam changes are planned.
|
||||
- **Boundary classification**: platform-core for `/system` panel/auth/smoke; provider-owned diagnostics remain untouched if present on system pages.
|
||||
- **Seams affected**: platform panel provider, platform auth/session, system status vocabulary, smoke fixture.
|
||||
- **Neutral platform terms preserved or introduced**: system panel, platform operator, platform operations, workspace, managed environment, provider diagnostics.
|
||||
- **Provider-specific semantics retained and why**: Existing provider diagnostics may remain technical details where they are already provider-owned; no new provider semantics are introduced.
|
||||
- **Why this does not deepen provider coupling accidentally**: The spec forbids new Graph calls, provider framework changes, and provider feature work.
|
||||
- **Follow-up path**: Provider readiness/onboarding productization remains a separate manual candidate.
|
||||
|
||||
## UI / Surface Guardrail Impact
|
||||
|
||||
| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
|
||||
|---|---|---|---|---|---|---|
|
||||
| System panel branding/title | yes | Native Filament panel/provider/localization | navigation/branding | shell, page | no | canonical TenantPilot System naming |
|
||||
| System dashboard status labels | yes | Native widgets plus shared badge semantics | status messaging | page, widget | no | map top-level states to canonical labels |
|
||||
| System operations labels/empty states | yes | Native Filament table/page | operations registry | page, table | no | productize without changing behavior |
|
||||
| System smoke auth/config | no product navigation | existing test/smoke fixture patterns | auth/session/browser smoke | route, session | no if local/test-only | tooling only |
|
||||
| Debug/runtime leak checks | no product UI addition | middleware/browser assertions | smoke stability | request/session/browser | no | proof path only |
|
||||
| Touched high-impact actions | yes if labels or placement touched | Filament Actions | action hierarchy | page/action | no new action | confirm existing confirmation/authorization/audit |
|
||||
|
||||
## Decision-First Surface Role
|
||||
|
||||
| Surface | Decision Role | Human-in-the-loop Moment | Immediately Visible for First Decision | On-Demand Detail / Evidence | Why This Is Primary or Why Not | Workflow Alignment | Attention-load Reduction |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| `/system` dashboard | Secondary Context Surface / System Admin | Platform operator checks system state | TenantPilot System branding, one top-level status, attention counts | operations/detail pages | Not a customer decision page; it orients platform support | platform operations | removes scaffold/default ambiguity |
|
||||
| `/system/ops/runs` | Tertiary Evidence / Diagnostics | Platform operator inspects run truth | run status/outcome, operation label, scope | run detail | Technical Annex style registry | system operations | keeps proof in one place |
|
||||
| `/system/ops/controls` | System Admin / Controls | Platform operator pauses/resumes high-impact controls | control state, scope, confirmation | audit/history modal | high-impact platform controls | operational control | makes dangerous actions intentional |
|
||||
| `/system/login` | System Admin auth surface | Platform operator signs in | TenantPilot System login context | N/A | required entry point | platform auth | avoids framework login feel |
|
||||
|
||||
## Audience-Aware Disclosure
|
||||
|
||||
| Surface | Audience Modes In Scope | Decision-First Default-Visible Content | Operator Diagnostics | Support / Raw Evidence | One Dominant Next Action | Hidden / Gated By Default | Duplicate-Truth Prevention |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| `/system` dashboard | support-platform | system state, items needing attention | operation widgets and status summaries | raw debug/runtime artifacts forbidden | inspect relevant system area | debug/runtime overlays, stack traces | one top-level system status |
|
||||
| `/system/ops/runs` | support-platform | run list state | run status/outcome/type/scope | run detail and logs where already authorized | open run detail | unrelated product data | status/outcome remain separate |
|
||||
| `/system/ops/controls` | support-platform | control state and impact | activation history | audit trail where authorized | pause/resume selected control | raw audit detail unless requested | effective state shown once |
|
||||
|
||||
## UI/UX Surface Classification
|
||||
|
||||
| Surface | Action Surface Class | Surface Type | Likely Next Operator Action | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type / Justification |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| `/system` dashboard | Utility / System | System Admin Dashboard | Open attention area | page widgets/actions | N/A | header/nav/body links | confirmed actions only | `/system` | `/system` | System plane | TenantPilot System | system state and attention | none |
|
||||
| `/system/ops/runs` | List / Table / Bulk | Monitoring / Queue / Technical Annex | Inspect operation | clickable row | required/current | header action to runbooks | none on list | `/system/ops/runs` | `/system/ops/runs/{run}` | System plane + row scope | Platform Operations | run status/outcome/type | System Admin technical allowance |
|
||||
| `/system/ops/controls` | Utility / System | Settings / Operational Control | Pause/resume control | explicit action cards | N/A | history actions secondary | separated confirmed actions | `/system/ops/controls` | N/A | System/workspace scope | Operational Controls | effective state and scope | none |
|
||||
| `/system/login` | Auth | System Admin Login | Sign in | form submit | N/A | N/A | N/A | `/system/login` | N/A | System plane | TenantPilot System | platform auth context | none |
|
||||
|
||||
## Operator Surface Contract
|
||||
|
||||
| Surface | Primary Persona | Decision / Operator Action Supported | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| `/system` dashboard | Platform operator | decide where platform attention is needed | System Admin | Is the platform ready or does it need attention? | TenantPilot branding, status, attention widgets | run detail, raw diagnostics | readiness, operation outcome | TenantPilot system only | open relevant system area | break-glass enter/exit if enabled |
|
||||
| `/system/ops/runs` | Platform operator | inspect platform operations | Technical Annex list | Which system runs need inspection? | run state, outcome, operation, scope | run detail/logs | execution status/outcome/freshness | TenantPilot system only | open run | none |
|
||||
| `/system/ops/controls` | Platform operator | pause/resume high-impact controls | Settings/System Admin | Which control is enabled or paused? | effective control state and scope | activation/audit history | control lifecycle | TenantPilot system only | pause/resume with confirmation | pause/resume controls |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: no.
|
||||
- **New persisted entity/table/artifact?**: no database entity. The later implementation may create `specs/396-system-panel-branding/implementation-report.md` and screenshot artifacts as spec-local evidence only.
|
||||
- **New abstraction?**: no by default. A local/testing-only smoke helper must remain a route/test fixture, not a product abstraction.
|
||||
- **New enum/state/reason family?**: no. Existing system health/status values must map to canonical labels; do not create a new status family.
|
||||
- **New cross-domain UI framework/taxonomy?**: no.
|
||||
- **Current operator problem**: Platform operators and reviewers cannot rely on a productized, manually smokeable `/system` surface that is free of scaffold labels and debug/runtime leaks.
|
||||
- **Existing structure is insufficient because**: Existing automated browser proof is separate from manual in-app review, and visible system labels still use ambiguous health/scaffold vocabulary.
|
||||
- **Narrowest correct implementation**: Rename/relabel/map existing surfaces and smoke paths; reuse existing platform auth, badges, localization, smoke suppression, and browser tests.
|
||||
- **Ownership cost**: Focused tests, one browser smoke family, and possible local/testing smoke helper upkeep.
|
||||
- **Alternative intentionally rejected**: Broad `/system` redesign or a new system readiness model would add UI and semantic complexity without current operator need.
|
||||
- **Release truth**: Current-release productization follow-up.
|
||||
|
||||
### Compatibility posture
|
||||
|
||||
This feature assumes a pre-production environment. Backward compatibility, old labels, smoke aliases, and transitional UI are out of scope.
|
||||
|
||||
## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
|
||||
|
||||
- **Test purpose / classification**: Unit for badge/status mapping where changed, Feature for system auth/branding/smoke route safety, Browser for focused `/system` productization smoke.
|
||||
- **Validation lane(s)**: fast-feedback, confidence, browser.
|
||||
- **Why this classification and these lanes are sufficient**: The feature changes rendered system UI labels and smoke/runtime proof, so unit/feature tests prove mappings/auth safety and browser tests prove actual rendered behavior/no leaks.
|
||||
- **New or expanded test families**: one bounded Spec396 browser smoke and focused feature tests under existing System/Auth/Badges areas.
|
||||
- **Fixture / helper cost impact**: deterministic `PlatformUser` fixture with `PlatformCapabilities::ACCESS_SYSTEM_PANEL`, `CONSOLE_VIEW`, `OPERATIONS_VIEW`, and relevant security/repair/control capabilities. Any smoke helper must remain opt-in and local/testing-only.
|
||||
- **Heavy-family visibility / justification**: Browser coverage is explicit because the feature is smoke/productization-focused.
|
||||
- **Special surface test profile**: System Admin / Technical Annex / browser-smoke-stability.
|
||||
- **Standard-native relief or required special coverage**: Existing native Filament surfaces only; special proof is browser smoke and high-impact action review.
|
||||
- **Reviewer handoff**: Confirm label/status replacements, no production smoke route, no tenant user can access `/system`, no debugbar/Vite/exception leak, no `/admin` regression if shared panel config changes.
|
||||
- **Budget / baseline / trend impact**: bounded browser-lane addition; record runtime if material.
|
||||
- **Escalation needed**: document-in-feature.
|
||||
- **Active feature PR close-out entry**: Guardrail / Exception / Smoke Coverage.
|
||||
- **Planned validation commands**:
|
||||
- `git diff --check`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemHealthBadgeSemanticsTest`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemPanelAuthTest`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec396`
|
||||
- `cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec396SystemPanelProductizationSmokeTest.php`
|
||||
- `cd apps/platform && ./vendor/bin/sail artisan test --filter=AdminSmoke` if shared panel/provider branding changed
|
||||
- `cd apps/platform && ./vendor/bin/sail pint --dirty`
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - System Panel Reads As TenantPilot (Priority: P1)
|
||||
|
||||
As a platform operator, I want `/system` login, dashboard, navigation, and page titles to clearly identify TenantPilot System, so I can trust that I am in the platform-admin surface and not a framework scaffold.
|
||||
|
||||
**Why this priority**: Branding/title trust is the core productization gap.
|
||||
|
||||
**Independent Test**: Sign in as a platform user and open `/system`; the rendered page title/heading/branding includes TenantPilot System or equivalent and does not show standalone Laravel/Filament/default scaffold branding.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an authorized platform user, **When** `/system` loads, **Then** TenantPilot system branding is visible in the panel, page title, or heading.
|
||||
2. **Given** `/system/login` renders, **When** the login page is inspected, **Then** the system auth context is TenantPilot-specific.
|
||||
3. **Given** system navigation renders, **When** labels are scanned, **Then** labels describe system workflows such as System Overview, Platform Operations, Repair Tools, Provider Diagnostics, System Settings, or equivalent productized names.
|
||||
|
||||
### User Story 2 - System Status Vocabulary Is Canonical (Priority: P1)
|
||||
|
||||
As a platform operator, I want system-level status labels to use TenantPilot canonical vocabulary, so I do not have to interpret `Healthy`, `OK`, `Warn`, or `Warning` as separate product truths.
|
||||
|
||||
**Why this priority**: Product Surface Contract status vocabulary is mandatory and current repo anchors show divergent system-health labels.
|
||||
|
||||
**Independent Test**: Badge/status tests and focused dashboard assertions show top-level system states as Ready, Needs attention, Failed/Blocked, Unknown, or another allowed canonical state.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** no failed or stuck runs, **When** the system dashboard health widget renders, **Then** the top-level state reads `Ready` or equivalent canonical wording, not `All systems healthy`.
|
||||
2. **Given** failed or stuck system operations exist, **When** the health widget renders, **Then** the top-level state reads `Needs attention`, `Failed`, or `Blocked` according to current behavior, not `Warning`, `Warn`, or `Degraded`.
|
||||
3. **Given** `BadgeDomain::SystemHealth` renders existing `ok` or `warn` values, **When** badge mapping is tested, **Then** labels use canonical vocabulary without creating a new badge domain.
|
||||
|
||||
### User Story 3 - Focused System Smoke Is Deterministic And Debug-Safe (Priority: P1)
|
||||
|
||||
As a maintainer, I want a deterministic focused `/system` smoke that works with platform-plane auth and checks for debug/runtime leaks, so productization proof is repeatable.
|
||||
|
||||
**Why this priority**: Spec 377 left manual in-app `/system` access as the remaining follow-up, and the provided candidate specifically targets smoke config.
|
||||
|
||||
**Independent Test**: A focused browser test authenticates a deterministic platform user, visits `/system`, `/system/ops/runs`, and one security/repair/control page, and asserts no debugbar, Vite overlay, exception page, console error, Livewire error, or Filament runtime error.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a local/testing platform smoke user, **When** focused smoke opens `/system`, **Then** the dashboard loads with TenantPilot system branding and no debug/runtime leak.
|
||||
2. **Given** the same smoke user, **When** focused smoke opens `/system/ops/runs`, **Then** the operations page loads or shows a productized empty state without JS/console errors.
|
||||
3. **Given** a smoke-login/helper route is added or reused, **When** the route is requested outside local/testing, **Then** it returns 404 and does not authenticate any actor.
|
||||
4. **Given** an ordinary tenant/admin user, **When** they request `/system` or a system smoke helper, **Then** they cannot access the system panel.
|
||||
|
||||
### User Story 4 - High-Impact System Actions Stay Safe (Priority: P2)
|
||||
|
||||
As a platform operator, I want touched high-impact system actions to stay clearly separated, confirmed, authorized, and audited, so productization work does not make risky system controls casual.
|
||||
|
||||
**Why this priority**: The candidate mentions break-glass, repair, operational maintenance, and destructive/high-impact safety.
|
||||
|
||||
**Independent Test**: Existing or updated Feature/Livewire tests show touched break-glass and operational-control actions still use `->action(...)`, `->requiresConfirmation()`, platform capability checks, and audit logging where they mutate state.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a high-impact system action is touched for copy/productization, **When** action tests run, **Then** confirmation and authorization behavior still pass.
|
||||
2. **Given** a platform user lacks the required capability, **When** they open the touched surface or execute the action, **Then** access is denied according to existing 403/404 semantics.
|
||||
3. **Given** the action mutates state, **When** it succeeds, **Then** existing audit truth remains intact.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-396-001**: The system panel MUST use TenantPilot-specific branding in visible system panel context, page title, heading, or login title.
|
||||
- **FR-396-002**: The system dashboard title MUST be productized as `TenantPilot System`, `TenantPilot System Dashboard`, `System Overview`, or equivalent TenantPilot system language.
|
||||
- **FR-396-003**: System navigation labels and page titles MUST describe workflows or system areas rather than framework/resource scaffolding.
|
||||
- **FR-396-004**: Standalone visible `Laravel`, `Filament`, `Laravel Application`, `Admin`, `Panel`, and ambiguous standalone `Dashboard` MUST NOT appear as primary product branding in the focused `/system` smoke path.
|
||||
- **FR-396-005**: Top-level system status vocabulary MUST map ambiguous existing labels (`OK`, `Warn`, `Healthy`, `Warning`, `Degraded`, `All systems healthy`) to Product Surface Contract canonical labels or confine them to clearly technical detail where justified.
|
||||
- **FR-396-006**: `BadgeDomain::SystemHealth` MUST remain the central path for system-health badges; implementation MUST NOT add page-local status mappings for the same values.
|
||||
- **FR-396-007**: Focused `/system` smoke MUST authenticate a deterministic `PlatformUser` with explicit platform capabilities and MUST NOT authenticate ordinary tenant/admin users into `/system`.
|
||||
- **FR-396-008**: Any local/testing-only system smoke helper MUST be disabled outside `local` and `testing`, return 404 in production-like environments, validate redirects to local app paths, set debugbar-suppression context if needed, and be absent from product navigation.
|
||||
- **FR-396-009**: Focused browser smoke MUST cover `/system`, `/system/ops/runs`, and at least one current system security/repair/control page when the current actor has capability.
|
||||
- **FR-396-010**: Focused browser smoke MUST assert no debugbar UI, no Vite/dev overlay, no Laravel exception/debug page, no obvious Livewire/Filament runtime error, and no console errors where the harness supports it.
|
||||
- **FR-396-011**: If shared panel/provider branding is changed, focused `/admin` smoke MUST confirm the admin panel did not regress.
|
||||
- **FR-396-012**: Touched high-impact system actions MUST keep confirmation, platform capability authorization, and audit behavior where they mutate state.
|
||||
- **FR-396-013**: The implementation MUST NOT add new system cards, metrics, tables, navigation groups, OperationRun types, provider features, Graph calls, migrations, models, or product runtime behavior beyond the productization/smoke scope.
|
||||
- **FR-396-014**: Generated browser screenshots, failure snapshots, debug HTML, and temporary artifacts MUST be cleaned or intentionally retained under this spec package with an implementation-report note.
|
||||
- **FR-396-015**: The implementation report MUST include files changed, branding/title/navigation changes, smoke route/config safety verification, status vocabulary changes, tests, browser smokes, `/admin` regression status when applicable, debug/runtime leak result, visible complexity outcome, and no completed-spec rewrite assertion.
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- **NFR-396-001**: Visible complexity on `/system` MUST remain neutral or decrease.
|
||||
- **NFR-396-002**: Smoke setup MUST be deterministic, local/test-only, and independent of external provider APIs, queue workers, scheduled jobs, or live network calls.
|
||||
- **NFR-396-003**: Tests MUST avoid brittle broad string scans over vendor code or historical specs; assertions should target rendered system UI/config and changed application paths.
|
||||
- **NFR-396-004**: Any new smoke helper must be narrowly named and documented as smoke-only, not a compatibility login path.
|
||||
- **NFR-396-005**: Runtime labels should use existing localization structure where visible copy already lives in localization.
|
||||
|
||||
### RBAC / Security Requirements
|
||||
|
||||
- **SEC-396-001**: Customer/workspace/admin users authenticated on `web` MUST NOT access `/system` and must continue receiving deny-as-not-found where existing tests require it.
|
||||
- **SEC-396-002**: Platform users without required capabilities MUST receive 403 for system pages/actions according to existing semantics.
|
||||
- **SEC-396-003**: Smoke users must be deterministic `PlatformUser` records with explicit platform capabilities.
|
||||
- **SEC-396-004**: Smoke helpers must not bypass environment guards, platform guard separation, CSRF/session safety expectations, or capability checks for product pages.
|
||||
- **SEC-396-005**: No secrets, credentials, raw token payloads, or provider secrets may appear in screenshots, logs, smoke artifacts, or implementation reports.
|
||||
|
||||
### Auditability / Observability Requirements
|
||||
|
||||
- **AUD-396-001**: Touched state-changing system actions must retain existing audit logging.
|
||||
- **AUD-396-002**: Browser smoke and human sanity results must be recorded in `specs/396-system-panel-branding/implementation-report.md`.
|
||||
- **AUD-396-003**: The implementation report must distinguish execution truth, rendered UI truth, smoke/auth truth, debug/runtime leak truth, and known unrelated browser-suite failures.
|
||||
|
||||
### Data / Truth Source Requirements
|
||||
|
||||
- **DATA-396-001**: No new database truth is introduced.
|
||||
- **DATA-396-002**: System status truth remains derived from existing `OperationRun`, customer-health, control, or badge sources.
|
||||
- **DATA-396-003**: Productized labels are presentation truth only and must not create a new status family.
|
||||
|
||||
## 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 Dashboard | `apps/platform/app/Filament/System/Pages/Dashboard.php` | Time window, break-glass enter/exit if enabled | N/A | N/A | N/A | N/A | N/A | N/A | yes for break-glass | no new action; verify confirmation/authorization |
|
||||
| System Operations | `apps/platform/app/Filament/System/Pages/Ops/Runs.php` | Go to runbooks | clickable row to detail | none | none | Go to runbooks | detail page owns actions | N/A | N/A | existing technical-annex list |
|
||||
| Operational Controls | `apps/platform/app/Filament/System/Pages/Ops/Controls.php` | pause/resume/history actions | N/A | N/A | N/A | N/A | N/A | N/A | yes for mutations | verify confirmation/authorization/audit if touched |
|
||||
| System Login | `apps/platform/app/Filament/System/Pages/Auth/Login.php` | N/A | N/A | N/A | N/A | N/A | N/A | login submit | audit login attempts | productize branding only |
|
||||
|
||||
### Key Entities *(include if feature involves data)*
|
||||
|
||||
- **PlatformUser**: Existing platform-plane actor used for `/system` auth and smoke fixtures.
|
||||
- **PlatformCapabilities**: Existing platform capability registry used for system access, operations, controls, directory, and repair pages.
|
||||
- **OperationRun**: Existing operation truth displayed on system operations pages; not changed by this spec.
|
||||
- **SystemHealth badge state**: Existing badge-domain mapping that must use canonical labels without creating a new status family.
|
||||
- **Smoke context**: Local/testing-only request/session/cookie context used to suppress debugbar and make focused browser smoke deterministic.
|
||||
|
||||
## Success Criteria *(mandatory)*
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-396-001**: Focused `/system` browser smoke renders TenantPilot system branding on `/system` and no primary Laravel/Filament/default framework branding.
|
||||
- **SC-396-002**: Focused `/system` browser smoke opens `/system/ops/runs` and one security/repair/control page without 500, Livewire, Filament, console, debugbar, Vite overlay, or exception-page leaks.
|
||||
- **SC-396-003**: System health badge/status tests prove existing `ok` and `warn` states display canonical labels.
|
||||
- **SC-396-004**: Feature/auth tests prove any system smoke helper is local/testing-only and unavailable in production-like environments, or the implementation report states that no helper was added.
|
||||
- **SC-396-005**: Existing `/system` tenant-session deny-as-not-found and platform-missing-capability forbidden tests continue to pass.
|
||||
- **SC-396-006**: No new UI cards, metrics, tables, navigation groups, migrations, models, Graph calls, or system features are introduced.
|
||||
- **SC-396-007**: The implementation report confirms visible complexity stayed neutral or decreased and no completed specs were rewritten.
|
||||
|
||||
## Out Of Scope
|
||||
|
||||
- New system-admin product capabilities.
|
||||
- Full `/system` IA redesign.
|
||||
- New system dashboard widgets, metrics, status models, or readiness framework.
|
||||
- New provider diagnostics feature or provider onboarding productization.
|
||||
- Graph contract changes or Graph calls.
|
||||
- Migrations, models, jobs, OperationRun types, schedulers, or queues.
|
||||
- Customer-facing surfaces.
|
||||
- Reopening completed Specs 376, 377, 391, or 395.
|
||||
- Broad browser-suite stabilization beyond focused `/system` proof.
|
||||
|
||||
## Risks
|
||||
|
||||
- **Shared Filament branding affects `/admin`**: Mitigate with focused `/admin` smoke if shared provider/config changes.
|
||||
- **Smoke helper weakens auth**: Mitigate with local/testing environment guard, platform guard only, route tests, and no product navigation.
|
||||
- **Status label changes break existing tests**: Mitigate by updating tests to canonical vocabulary and avoiding vendor/historical-doc scans.
|
||||
- **System panel loses useful technical detail**: Mitigate by keeping Technical Annex pages intentionally technical while removing scaffold/default/debug labels from product surfaces.
|
||||
- **Browser suite remains noisy**: Mitigate by making focused `/system` smoke blocking and documenting unrelated full-suite failures separately.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Current branch `396-system-panel-branding` is created by the repository Spec Kit script from clean `platform-dev`.
|
||||
- The implementation will use Laravel Sail for PHP/Pest/Pint commands.
|
||||
- Existing Spec 376 browser platform-guard fixture is usable unless implementation proves manual smoke needs a local/testing helper.
|
||||
- The system panel remains platform-plane only and separate from `/admin`.
|
||||
- Productized labels can be adjusted through existing localization, panel provider, widget, and badge mapper paths.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- None blocking preparation.
|
||||
- Non-blocking implementation decision: use existing Pest Browser `actingAs(..., 'platform')` only, or add a local/testing-only system smoke helper if manual in-app product sanity requires one.
|
||||
|
||||
## Follow-Up Spec Candidates
|
||||
|
||||
- Manual system-panel audit procedure documentation if implementation chooses automated platform-guard proof only and product wants a manual support runbook later.
|
||||
- Provider readiness/onboarding productization if current operator evidence shows provider diagnostics still feel unfinished.
|
||||
- Cross-domain indicator runtime follow-through if status vocabulary drift remains outside `/system`.
|
||||
104
specs/396-system-panel-branding/tasks.md
Normal file
104
specs/396-system-panel-branding/tasks.md
Normal file
@ -0,0 +1,104 @@
|
||||
# Tasks: Spec 396 - System Panel Branding and Productization Smoke Config v1
|
||||
|
||||
**Input**: Design documents from `/specs/396-system-panel-branding/`
|
||||
**Prerequisites**: `spec.md`, `plan.md`
|
||||
**Branch**: `396-system-panel-branding`
|
||||
**Runtime constraint**: No migrations, models, Graph calls, jobs, queues, schedulers, new dashboards, or production smoke-login bypass.
|
||||
|
||||
## Task Format
|
||||
|
||||
- `[P]` means the task can run in parallel with other `[P]` tasks in the same phase.
|
||||
- Every runtime behavior task must have focused Pest or Pest Browser proof.
|
||||
- Do not rewrite completed Specs 376, 377, 391, or 395.
|
||||
|
||||
## Phase 1: Inventory And Gate Setup
|
||||
|
||||
**Purpose**: Lock the exact `/system` scope before implementation.
|
||||
|
||||
- [x] T001 Create `specs/396-system-panel-branding/implementation-report.md` with sections for tests, browser proof, Livewire v4, provider registration, global search, destructive/high-impact actions, asset strategy, deployment impact, Product Surface result, no completed-spec rewrite assertion, and follow-up candidates.
|
||||
- [x] T002 Record in `specs/396-system-panel-branding/implementation-report.md` that `docs/product/standards/product-surface-contract.md`, `docs/ui/tenantpilot-enterprise-ui-standards.md`, `docs/filament-guidelines.md`, and `docs/testing-guidelines.md` were reviewed before runtime UI edits.
|
||||
- [x] T003 [P] Inventory current visible branding and title copy in `apps/platform/app/Providers/Filament/SystemPanelProvider.php`, `apps/platform/app/Filament/System/Pages/Auth/Login.php`, `apps/platform/app/Filament/System/Pages/Dashboard.php`, and `apps/platform/lang/en/localization.php`.
|
||||
- [x] T004 [P] Inventory current German system-panel copy in `apps/platform/lang/de/localization.php` and record any terms that need canonical alignment.
|
||||
- [x] T005 [P] Inventory current `/system` navigation labels and page titles in `apps/platform/app/Filament/System/Pages/Directory/*.php`, `apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php`, `apps/platform/app/Filament/System/Pages/Security/AccessLogs.php`, and `apps/platform/app/Filament/System/Pages/Ops/*.php`.
|
||||
- [x] T006 [P] Inventory current system health/status vocabulary in `apps/platform/app/Filament/System/Widgets/ControlTowerHealthIndicator.php`, `apps/platform/app/Filament/System/Widgets/CustomerHealthKpis.php`, and `apps/platform/app/Support/Badges/Domains/SystemHealthBadge.php`.
|
||||
- [x] T007 [P] Inventory current smoke/debug suppression in `apps/platform/routes/web.php`, `apps/platform/app/Http/Middleware/SuppressDebugbarForSmokeRequests.php`, and `apps/platform/tests/Browser/Spec376BrowserAuditFixtureCoverageSmokeTest.php`.
|
||||
- [x] T008 Confirm the implementation will reuse existing platform guard/capability paths and record any proposed local/testing-only smoke helper decision in `implementation-report.md`.
|
||||
|
||||
## Phase 2: Tests First
|
||||
|
||||
**Purpose**: Establish failing or protective tests before behavior changes.
|
||||
|
||||
- [x] T009 Update or add Pest feature coverage for canonical system health labels in `apps/platform/tests/Feature/Badges/SystemHealthBadgeSemanticsTest.php`, covering existing `ok`, `warn`, `critical`, and `unknown` system-health values.
|
||||
- [x] T010 Add `apps/platform/tests/Feature/System/Spec396SystemPanelProductizationTest.php` to cover system panel access, productized title/label expectations, and absence of primary scaffold/default branding where server-rendered assertions are reliable.
|
||||
- [x] T011 If a local/testing-only system smoke helper is added, cover environment gating, platform guard usage, tenant-session denial, and production-like unavailability in `apps/platform/tests/Feature/System/Spec396SystemPanelProductizationTest.php`. N/A - no helper was added.
|
||||
- [x] T012 Add or update action-posture tests for any touched break-glass or operational-control action so high-impact actions still require confirmation, server-side authorization, and audit logging. N/A - no high-impact actions were touched.
|
||||
- [x] T013 Add `apps/platform/tests/Browser/Spec396SystemPanelProductizationSmokeTest.php` to visit `/system`, `/system/ops/runs`, and one security/repair/control page as a platform user with the required capabilities.
|
||||
- [x] T014 In `Spec396SystemPanelProductizationSmokeTest`, assert no debugbar, Vite overlay, exception page, Livewire/Filament runtime errors, or console errors on the focused smoke path.
|
||||
- [x] T015 If shared panel/provider branding can affect `/admin`, add a focused `/admin` regression test or browser assertion in the narrowest existing admin smoke test file. N/A - only the system panel provider was changed.
|
||||
|
||||
## Phase 3: System Branding And Navigation
|
||||
|
||||
**Purpose**: Make the existing system panel visibly TenantPilot-owned without expanding IA.
|
||||
|
||||
- [x] T016 Update `apps/platform/app/Providers/Filament/SystemPanelProvider.php` only as needed to set explicit TenantPilot system branding while preserving `id('system')`, `path('system')`, `authGuard('platform')`, middleware, and provider registration location.
|
||||
- [x] T017 Update `apps/platform/lang/en/localization.php` so `/system` dashboard/login/navigation copy reads as TenantPilot system/platform-operator copy rather than generic `System dashboard` or framework default copy.
|
||||
- [x] T018 Update `apps/platform/lang/de/localization.php` with equivalent productized German labels where existing German system-panel labels are affected.
|
||||
- [x] T019 Update `apps/platform/app/Filament/System/Pages/Auth/Login.php` only as needed to align the login page title/heading with TenantPilot system branding, without changing authentication semantics.
|
||||
- [x] T020 Update `apps/platform/app/Filament/System/Pages/Dashboard.php`, affected `apps/platform/app/Filament/System/Pages/Ops/*.php`, `apps/platform/app/Filament/System/Pages/Directory/*.php`, `apps/platform/app/Filament/System/Pages/Security/AccessLogs.php`, and `apps/platform/app/Filament/System/Pages/RepairWorkspaceOwners.php` page titles/navigation labels to use the canonical system-panel vocabulary.
|
||||
- [x] T021 Verify no new navigation groups, cards, metrics, tables, or routes were added for branding-only changes.
|
||||
|
||||
## Phase 4: Canonical Status Vocabulary
|
||||
|
||||
**Purpose**: Replace inconsistent health labels with existing-state canonical labels.
|
||||
|
||||
- [x] T022 Update `apps/platform/app/Support/Badges/Domains/SystemHealthBadge.php` so existing `ok`, `warn`, `critical`, and `unknown` states render canonical labels (`Ready`, `Needs attention`, `Critical`, `Unknown`) without introducing a new status family.
|
||||
- [x] T023 Update `apps/platform/app/Filament/System/Widgets/ControlTowerHealthIndicator.php` to use canonical system health labels and supporting copy.
|
||||
- [x] T024 Update `apps/platform/app/Filament/System/Widgets/CustomerHealthKpis.php` to use canonical system health labels while preserving existing counts and queries.
|
||||
- [x] T025 Search `apps/platform/app/Filament/System`, `apps/platform/app/Support/Badges`, `apps/platform/lang`, and affected tests for old primary labels (`OK`, `Warn`, `Healthy`, `Warning`, `Degraded`, `All systems healthy`) and either replace them in active UI or document intentional technical/test-only usage in `implementation-report.md`.
|
||||
|
||||
## Phase 5: Smoke And Debug-Safe Proof
|
||||
|
||||
**Purpose**: Make focused `/system` proof deterministic and safe.
|
||||
|
||||
- [x] T026 Reuse the existing Pest Browser platform-guard approach from `apps/platform/tests/Browser/Spec376BrowserAuditFixtureCoverageSmokeTest.php` unless manual in-app sanity requires a local/testing-only helper.
|
||||
- [x] T027 If a smoke helper is required, add it in `apps/platform/routes/web.php` with local/testing environment gating, platform guard/capability requirements, no product navigation entry, and no production availability. N/A - no helper was required.
|
||||
- [x] T028 If a smoke helper is required, extend `apps/platform/app/Http/Middleware/SuppressDebugbarForSmokeRequests.php` only enough to suppress debugbar for that safe smoke context. N/A - no helper was required.
|
||||
- [x] T029 Keep smoke fixture setup cheap by default; do not add expensive seeds, provider calls, queued work, or external network calls.
|
||||
- [x] T030 Capture focused browser proof outputs and record the result in `specs/396-system-panel-branding/implementation-report.md`.
|
||||
- [x] T031 Review browser screenshots, failure snapshots, logs, and debug HTML for secrets, provider tokens, raw credentials, debug pages, and unrelated artifacts; clean them or intentionally retain only spec-local evidence with a note in `implementation-report.md`.
|
||||
|
||||
## Phase 6: Safety, Formatting, And Close-Out
|
||||
|
||||
**Purpose**: Verify the narrow slice and document the product-surface outcome.
|
||||
|
||||
- [x] T032 Run `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemHealthBadgeSemanticsTest`.
|
||||
- [x] T033 Run `cd apps/platform && ./vendor/bin/sail artisan test --filter=SystemPanelAuthTest`.
|
||||
- [x] T034 Run `cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec396`.
|
||||
- [x] T035 Run the focused Pest Browser Spec 396 smoke command according to the repo's browser-test setup.
|
||||
- [x] T036 Run `cd apps/platform && ./vendor/bin/sail pint --dirty`.
|
||||
- [x] T037 Complete `specs/396-system-panel-branding/implementation-report.md` with Product Surface Impact, UI Surface Impact, browser proof, Human Product Sanity result, visible complexity outcome, Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, deployment impact, execution/rendered UI/smoke/auth/debug truth categories, known unrelated browser-suite failures, and no completed-spec rewrite assertion.
|
||||
- [x] T038 Confirm no application changes added migrations, models, Graph calls, jobs, queues, schedulers, new persisted entities, new system features, or broad UI redesign.
|
||||
- [x] T039 Confirm completed specs were not edited and list any follow-up candidates in `implementation-report.md`.
|
||||
- [x] T040 Update `docs/ui-ux-enterprise-audit/route-inventory.md` with the Spec 396 `/system` surface coverage decision or append the minimal existing-surface update required by the local registry format.
|
||||
- [x] T041 Update `docs/ui-ux-enterprise-audit/design-coverage-matrix.md` with the Spec 396 System Admin / Technical Annex coverage decision or append the minimal existing-surface update required by the local registry format.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- T001-T008 must complete before runtime implementation.
|
||||
- T009-T015 should be written before or alongside the corresponding behavior changes.
|
||||
- T016-T021 depend on T003-T005.
|
||||
- T022-T025 depend on T006 and T009.
|
||||
- T026-T031 depend on T007-T008 and T013-T014.
|
||||
- T032-T041 depend on all implementation tasks.
|
||||
|
||||
## Parallel Execution Examples
|
||||
|
||||
```text
|
||||
T003, T004, T005, T006, and T007 can run in parallel during inventory.
|
||||
T009 and T010 can run in parallel once the expected label vocabulary is locked.
|
||||
T022, T023, and T024 can run in parallel if the shared vocabulary is agreed.
|
||||
```
|
||||
|
||||
## MVP Scope
|
||||
|
||||
The minimum acceptable implementation is: productized `/system` brand/title copy, canonical top-level health labels, focused `/system` browser smoke, no debug/runtime leaks, preserved platform auth/capability semantics, and completed implementation report.
|
||||
Loading…
Reference in New Issue
Block a user