feat: surface stale active operation runs (#269)

## Summary - keep stale active operation runs visible in the tenant progress overlay and polling state - align tenant and canonical operation surfaces around the shared stale-active presentation contract - add Spec 233 artifacts and clean the promoted-candidate backlog entries ## Validation - browser smoke: `/admin/t/18000000-0000-4000-8000-000000000180` -> stale dashboard CTA -> `/admin/operations?tenant_id=7&activeTab=active_stale_attention&problemClass=active_stale_attention` -> `/admin/operations/15` - verified healthy vs likely-stale tenant cards, canonical stale list row, and canonical run detail consistency ## Notes - local smoke fixture seeded with one fresh and one stale running `baseline_compare` operation for browser validation - Pest suite was not re-run in this session before opening this PR Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #269
2026-04-23 15:10:06 +00:00 · 2026-04-23 15:10:06 +00:00 · 6fdd45fb02
commit 6fdd45fb02
parent 2bf53f6337
16 changed files with 1410 additions and 111 deletions
--- a/.github/agents/copilot-instructions.md
+++ b/.github/agents/copilot-instructions.md
@ -242,6 +242,8 @@ ## Active Technologies
 - PostgreSQL via existing `findings`, `finding_exceptions`, `tenant_reviews`, `stored_reports`, and audit-log tables; no schema changes planned (231-finding-outcome-taxonomy)
 - PHP 8.4.15, Laravel 12, Filament v5, Livewire v4 + Filament Resources/Pages/Widgets, Pest v4, `App\Support\OperationRunLinks`, `App\Support\System\SystemOperationRunLinks`, `App\Support\Navigation\CanonicalNavigationContext`, `App\Support\Navigation\RelatedNavigationResolver`, existing workspace and tenant authorization helpers (232-operation-run-link-contract)
 - PostgreSQL-backed existing `operation_runs`, `tenants`, and `workspaces` records plus current session-backed canonical navigation state; no new persistence (232-operation-run-link-contract)
+- PHP 8.4.15, Laravel 12, Filament v5, Livewire v4 + Filament widgets/resources/pages, Pest v4, `App\Models\OperationRun`, `App\Support\Operations\OperationRunFreshnessState`, `App\Services\Operations\OperationLifecycleReconciler`, `App\Support\OpsUx\OperationUxPresenter`, `App\Support\OpsUx\ActiveRuns`, `App\Support\Badges\BadgeCatalog` / `BadgeRenderer`, `App\Support\Workspaces\WorkspaceOverviewBuilder`, `App\Support\OperationRunLinks` (233-stale-run-visibility)
+- Existing PostgreSQL `operation_runs` records and current session/query-backed monitoring navigation state; no new persistence (233-stale-run-visibility)

 - PHP 8.4.15 (feat/005-bulk-operations)

@ -276,9 +278,9 @@ ## Code Style
 PHP 8.4.15: Follow standard conventions

 ## Recent Changes
+- 233-stale-run-visibility: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4 + Filament widgets/resources/pages, Pest v4, `App\Models\OperationRun`, `App\Support\Operations\OperationRunFreshnessState`, `App\Services\Operations\OperationLifecycleReconciler`, `App\Support\OpsUx\OperationUxPresenter`, `App\Support\OpsUx\ActiveRuns`, `App\Support\Badges\BadgeCatalog` / `BadgeRenderer`, `App\Support\Workspaces\WorkspaceOverviewBuilder`, `App\Support\OperationRunLinks`
 - 232-operation-run-link-contract: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4 + Filament Resources/Pages/Widgets, Pest v4, `App\Support\OperationRunLinks`, `App\Support\System\SystemOperationRunLinks`, `App\Support\Navigation\CanonicalNavigationContext`, `App\Support\Navigation\RelatedNavigationResolver`, existing workspace and tenant authorization helpers
 - 231-finding-outcome-taxonomy: Added PHP 8.4.15, Laravel 12, Filament v5, Livewire v4, Blade + `App\Models\Finding`, `App\Filament\Resources\FindingResource`, `App\Services\Findings\FindingWorkflowService`, `App\Services\Baselines\BaselineAutoCloseService`, `App\Services\EntraAdminRoles\EntraAdminRolesFindingGenerator`, `App\Services\PermissionPosture\PermissionPostureFindingGenerator`, `App\Jobs\CompareBaselineToTenantJob`, `App\Filament\Pages\Reviews\ReviewRegister`, `App\Filament\Resources\TenantReviewResource`, `BadgeCatalog`, `BadgeRenderer`, `AuditLog` metadata via `AuditLogger`
- 226-astrodeck-inventory-planning: Added Markdown artifacts + Astro 6.0.0 + TypeScript 5.9 context for source discovery + Repository spec workflow (`.specify`), Astro website source tree under `apps/website/src`, existing component taxonomy (`primitives`, `content`, `sections`, `layout`)
 <!-- MANUAL ADDITIONS START -->

 ### Pre-production compatibility check
--- a/apps/platform/app/Livewire/BulkOperationProgress.php
+++ b/apps/platform/app/Livewire/BulkOperationProgress.php
@ -86,7 +86,7 @@ public function refreshRuns(): void

        $query = OperationRun::query()
            ->where('tenant_id', $tenantId)
-            ->healthyActive()
+            ->active()
            ->orderByDesc('created_at');

        $activeCount = (clone $query)->count();
--- a/apps/platform/app/Support/OpsUx/ActiveRuns.php
+++ b/apps/platform/app/Support/OpsUx/ActiveRuns.php
@ -22,7 +22,7 @@ public static function existForTenantId(?int $tenantId): bool

        return OperationRun::query()
            ->where('tenant_id', $tenantId)
-            ->healthyActive()
+            ->active()
            ->exists();
    }

--- a/apps/platform/resources/views/livewire/bulk-operation-progress.blade.php
+++ b/apps/platform/resources/views/livewire/bulk-operation-progress.blade.php
@ -1,6 +1,8 @@
-@php($runs = $runs ?? collect())
-@php($overflowCount = (int) ($overflowCount ?? 0))
-@php($tenant = $tenant ?? null)
+@php
+    $runs = $runs ?? collect();
+    $overflowCount = (int) ($overflowCount ?? 0);
+    $tenant = $tenant ?? null;
+@endphp

 {{-- Cleanup is delegated to the shared poller helper, which uses teardownObserver and new MutationObserver. --}}

@ -16,6 +18,17 @@
    @if($runs->isNotEmpty())
        <div class="fixed bottom-4 right-4 z-[999999] w-96 space-y-2" style="pointer-events: auto;">
            @foreach ($runs->take(5) as $run)
+                @php
+                    $statusSpec = \App\Support\Badges\BadgeRenderer::spec(
+                        \App\Support\Badges\BadgeDomain::OperationRunStatus,
+                        [
+                            'status' => (string) $run->status,
+                            'freshness_state' => $run->freshnessState()->value,
+                        ],
+                    );
+                    $lifecycleAttention = \App\Support\OpsUx\OperationUxPresenter::lifecycleAttentionSummary($run);
+                    $guidance = \App\Support\OpsUx\OperationUxPresenter::surfaceGuidance($run);
+                @endphp
                <div class="bg-white dark:bg-gray-800 rounded-lg shadow-xl border-2 border-primary-500 dark:border-primary-400 p-4 transition-all animate-in slide-in-from-right duration-300"
                    wire:key="run-{{ $run->id }}">
                    <div class="flex items-start justify-between gap-4">
@ -30,6 +43,21 @@
                                    Running • {{ ($run->started_at ?? $run->created_at)?->diffForHumans(null, true, true) }}
                                @endif
                            </p>
+                            <div class="mt-2 flex flex-wrap items-center gap-2">
+                                <x-filament::badge :color="$statusSpec->color" size="sm">
+                                    {{ $statusSpec->label }}
+                                </x-filament::badge>
+                                @if ($lifecycleAttention)
+                                    <span class="inline-flex items-center rounded-full border border-warning-200 bg-warning-50 px-2 py-0.5 text-xs font-medium text-warning-800 dark:border-warning-600/40 dark:bg-warning-500/10 dark:text-warning-100">
+                                        {{ $lifecycleAttention }}
+                                    </span>
+                                @endif
+                            </div>
+                            @if ($guidance)
+                                <p class="mt-2 text-xs leading-5 text-gray-600 dark:text-gray-300">
+                                    {{ $guidance }}
+                                </p>
+                            @endif
                        </div>

                        @if ($tenant)
--- a/apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php
+++ b/apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php
@ -76,7 +76,7 @@
        ->assertDontSee('Inventory sync');
 })->group('ops-ux');

-it('does not show likely stale runs in the progress overlay and stops polling when only stale runs remain', function () {
+it('shows likely stale runs in the progress overlay and keeps polling when only stale runs remain', function () {
    [$user, $tenant] = createUserWithTenant(role: 'owner');
    $this->actingAs($user);
    Filament::setTenant($tenant, true);
@ -94,8 +94,10 @@
    Livewire::actingAs($user)
        ->test(BulkOperationProgress::class)
        ->call('refreshRuns')
-        ->assertSet('hasActiveRuns', false)
-        ->assertDontSee('Inventory sync');
+        ->assertSet('hasActiveRuns', true)
+        ->assertSee('Inventory sync')
+        ->assertSee('Likely stale')
+        ->assertSee('This operation is past its lifecycle window.');
 })->group('ops-ux');

 it('registers Alpine cleanup for the Ops UX poller to avoid stale listeners across re-renders', function () {
--- a/apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php
+++ b/apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php
@ -46,7 +46,7 @@
    expect($runs->pluck('user_id')->all())->toContain($otherUser->id);
 })->group('ops-ux');

-it('suppresses stale backup set update runs from the progress widget', function (string $operationType): void {
+it('keeps stale backup set update runs visible in the progress widget', function (string $operationType): void {
    [$user, $tenant] = createUserWithTenant(role: 'owner');
    $this->actingAs($user);
    Filament::setTenant($tenant, true);
@ -67,8 +67,9 @@
        ->call('refreshRuns');

    expect($component->get('runs'))->toBeInstanceOf(Collection::class)
-        ->and($component->get('runs'))->toHaveCount(0)
-        ->and($component->get('hasActiveRuns'))->toBeFalse();
+        ->and($component->get('runs'))->toHaveCount(1)
+        ->and($component->get('runs')->first()->freshnessState()->value)->toBe('likely_stale')
+        ->and($component->get('hasActiveRuns'))->toBeTrue();
 })->with([
    'backup set update' => 'backup_set.update',
 ])->group('ops-ux');
--- a/apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php
+++ b/apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php
@ -10,10 +10,22 @@
    $this->actingAs($user);
    Filament::setTenant($tenant, true);

-    OperationRun::factory()->count(7)->create([
+    OperationRun::factory()->count(4)->create([
        'tenant_id' => $tenant->id,
+        'workspace_id' => (int) $tenant->workspace_id,
+        'type' => 'inventory_sync',
        'status' => 'queued',
        'outcome' => 'pending',
+        'created_at' => now(),
+    ]);
+
+    OperationRun::factory()->count(3)->create([
+        'tenant_id' => $tenant->id,
+        'workspace_id' => (int) $tenant->workspace_id,
+        'type' => 'inventory_sync',
+        'status' => 'queued',
+        'outcome' => 'pending',
+        'created_at' => now()->subHour(),
    ]);

    $component = Livewire::actingAs($user)
@ -22,4 +34,6 @@

    expect($component->get('runs'))->toHaveCount(6);
    expect($component->get('overflowCount'))->toBe(2);
+    expect($component->get('runs')->map(fn (OperationRun $run): string => $run->freshnessState()->value)->unique()->values()->all())
+        ->toEqualCanonicalizing(['fresh_active', 'likely_stale']);
 })->group('ops-ux');
--- a/docs/product/spec-candidates.md
+++ b/docs/product/spec-candidates.md
@ -5,7 +5,7 @@ # Spec Candidates
 >
 > **Flow**: Inbox → Qualified → Planned → Spec created → moved to `Promoted to Spec`

-**Last reviewed**: 2026-04-22 (promoted `Findings Notifications & Escalation v1` to Spec 224, promoted `Findings Notification Presentation Convergence` to Spec 230, added three architecture contract-enforcement candidates from the 2026-04-22 drift audit, added the repository cleanup strand from the strict read-only legacy audit, reframed the compliance-control foundation candidate into a framework-neutral canonical control catalog foundation, and aligned the control-library candidates to the S1/S2/S3 layering language)
+**Last reviewed**: 2026-04-23 (promoted `Operation Run Active-State Visibility & Stale Escalation` to Spec 233, cleaned already-promoted entries for Specs 225, 231, and 232 out of `Qualified`, and kept the remaining contract-enforcement and workflow candidates aligned with the current spec stream)

 ---

@ -47,7 +47,11 @@ ## Promoted to Spec
 - Findings Operator Inbox v1 → Spec 221 (`findings-operator-inbox`)
 - Findings Intake & Team Queue v1 -> Spec 222 (`findings-intake-team-queue`)
 - Findings Notifications & Escalation v1 → Spec 224 (`findings-notifications-escalation`)
+- Assignment Hygiene & Stale Work Detection → Spec 225 (`assignment-hygiene`)
 - Findings Notification Presentation Convergence → Spec 230 (`findings-notification-convergence`)
+- Finding Outcome Taxonomy & Verification Semantics → Spec 231 (`finding-outcome-taxonomy`)
+- Operation Run Link Contract Enforcement → Spec 232 (`operation-run-link-contract`)
+- Operation Run Active-State Visibility & Stale Escalation → Spec 233 (`stale-run-visibility`)
 - Provider-Backed Action Preflight and Dispatch Gate Unification → Spec 216 (`provider-dispatch-gate`)
 - Record Page Header Discipline & Contextual Navigation → Spec 192 (`record-header-discipline`)
 - Monitoring Surface Action Hierarchy & Workbench Semantics → Spec 193 (`monitoring-action-hierarchy`)
@ -167,81 +171,8 @@ ### Baseline Capture Truthful Outcomes and Upstream Guardrails
 >
 > **Why these are not one spec:** Each candidate has a different implementation surface, different stakeholders, and different shippability boundary. The taxonomy is a cross-cutting decision document. Reason code translation touches reason-code artifacts and notification builders. Spec 158 defines the richer artifact truth engine. The Operator Explanation Layer defines the shared interpretation semantics and explanation patterns. Governance operator outcome compression is a UI-information-architecture adoption slice across governance artifact surfaces. Humanized diagnostic summaries are an adoption slice for governance run-detail pages. Gate unification touches provider dispatch and notification plumbing across ~20 services. Merging them would create an unshippable monolith. Keeping them sequenced preserves independent delivery while still converging on one operator language.

-### Operation Run Active-State Visibility & Stale Escalation
- **Type**: hardening
- **Source**: product/operator visibility analysis 2026-03-24; operation-run lifecycle and stale-state communication review
- **Vehicle**: new standalone candidate
- **Problem**: TenantPilot already has the core lifecycle foundations for `OperationRun` records: canonical run modelling, workspace-level run viewing, per-type lifecycle policies, freshness and stale detection, overdue-run reconciliation, terminal notifications, and tenant-local active-run hints. The gap is no longer primarily lifecycle logic. The gap is that the same lifecycle truth is not communicated with enough consistency and urgency across the operator surfaces that matter. A run can be past its expected lifecycle or likely stuck while still looking like normal active work on tenant-local cards or dashboard attention surfaces. Operators then have to drill into the canonical run viewer to learn that the run is no longer healthy, which weakens monitoring trust and makes hanging work look deceptively normal.
- **Why it matters**: This is an observability and operator-trust problem in a core platform layer, not visual polish. If `queued` or `running` remains visually neutral after lifecycle expectations have been exceeded, operators receive false reassurance, support burden rises, queue or worker issues are discovered later, and the product trains users that active-state surfaces are not trustworthy without manual drill-down. As TenantPilot pushes more governance, review, drift, and evidence workflows through `OperationRun`, stale active work must never read as healthy progress anywhere in the product.
- **Proposed direction**:
-  - Reuse the existing lifecycle, freshness, and reconciliation truth to define one **cross-surface active-state presentation contract** that distinguishes at least: `active / normal`, `active / past expected lifecycle`, `stale / likely stuck`, and `terminal / no longer active`
-  - Upgrade **tenant-local active-run and progress cards** so stale or past-lifecycle runs are visibly and linguistically different from healthy active work instead of reading as neutral `Queued • 1d` or `Running • 45m`
-  - Upgrade **tenant dashboard and attention surfaces** so they distinguish between healthy activity, activity that needs attention, and activity that is likely stale or hanging
-  - Upgrade the **workspace operations list / monitoring views** so problematic active runs become scanable at row level instead of being discoverable only through subtle secondary text or by opening each run
-  - Preserve the **workspace-level canonical run viewer** as the authoritative diagnostic surface, while ensuring compact and summary surfaces do not contradict it
-  - Apply a **same meaning, different density** rule: tenant cards, dashboard signals, list rows, and run detail may vary in information density, but not in lifecycle meaning or operator implication
- **Core product principles**:
-  - Execution lifecycle, freshness, and operator attention are related but not identical dimensions
-  - Compact surfaces may compress information, but must not downplay stale or hanging work
-  - The workspace-level run viewer remains canonical; this candidate improves visibility, not source-of-truth ownership
-  - Stale or past-lifecycle work must not look like healthy progress anywhere
- **Candidate requirements**:
-  - **R1 Cross-surface lifecycle visibility**: all relevant active-run surfaces can distinguish at least normal active, past-lifecycle active, stale/likely stuck, and terminal states
-  - **R2 Tenant active-run escalation**: tenant-local active-run and progress cards visibly and linguistically escalate stale or past-lifecycle work
-  - **R3 Dashboard attention separation**: dashboard and attention surfaces distinguish healthy activity from concerning active work
-  - **R4 Operations-list scanability**: the workspace operations list makes problematic active runs quickly identifiable without requiring row-by-row interpretation or drill-in
-  - **R5 Canonical viewer preservation**: the workspace-level run viewer remains the detailed and authoritative truth surface
-  - **R6 No hidden contradiction**: a run that is clearly stale or lifecycle-problematic on the detail page must not appear as ordinary active work on tenant or monitoring surfaces
-  - **R7 Existing lifecycle logic reuse**: the candidate reuses current freshness, lifecycle, and reconciliation semantics instead of introducing parallel UI-only heuristics
-  - **R8 No new backend lifecycle semantics unless necessary**: new status values or model-level lifecycle semantics are out unless the current semantics cannot carry the presentation contract cleanly
- **Scope boundaries**:
-  - **In scope**: tenant-local active-run cards, tenant dashboard activity and attention surfaces, workspace operations list and monitoring surfaces, shared lifecycle presentation contract for active-state visibility, copy and visual semantics needed to distinguish healthy active work from stale active work
-  - **Out of scope**: retry, cancel, force-fail, or reconcile-now operator actions; queue or worker architecture changes; new scheduler or timeout engines; new notification channels; a full operations-hub redesign; cross-workspace fleet monitoring; introducing new `OperationRun` status values unless existing semantics are proven insufficient
- **Acceptance points**:
-  - An active run outside its lifecycle expectation is visibly distinct from healthy active work on tenant-local progress cards
-  - Tenant dashboard and attention surfaces clearly represent the difference between healthy activity and active work that needs attention
-  - The workspace operations list makes stale or problematic active runs quickly scanable
-  - No surface shows a run as stale/problematic while another still presents it as normal active work
-  - The canonical workspace-level run viewer remains the most detailed lifecycle and diagnosis surface
-  - Existing lifecycle and freshness logic is reused rather than duplicated into local UI-only state rules
-  - No retry, cancel, or force-fail intervention actions are introduced by this candidate
-  - Fresh active runs do not regress into false escalation
-  - Tenant and workspace scoping remain correct; no cross-tenant leakage appears in cards or monitoring views
-  - Regression coverage includes fresh and stale active runs across tenant and workspace surfaces
- **Suggested test matrix**:
-  - queued run within expected lifecycle
-  - queued run well past expected lifecycle
-  - running run within expected lifecycle
-  - running run well past expected lifecycle
-  - run becomes terminal while an operator navigates between tenant and run-detail surfaces
-  - stale state on detail surface remains semantically stale on tenant and monitoring surfaces
-  - fresh active runs do not escalate falsely
-  - tenant-scoped surfaces never show another tenant's runs
-  - operations list clearly surfaces problematic active runs for fast scan
- **Dependencies**: existing operation-run lifecycle policy and stale detection foundations, canonical run viewer work, tenant-local active-run surfaces, operations monitoring list surfaces
- **Related specs / candidates**: Spec 114 (system console / operations monitoring foundations), Spec 144 (canonical operation viewer context decoupling), Spec 149 (queued execution reauthorization and lifecycle continuity), Spec 161 (operator-explanation-layer), Spec 216 (Provider-Backed Action Preflight and Dispatch Gate Unification)
- **Strategic sequencing**: Best treated before any broader operator intervention-actions spec. First make stale or hanging work visibly truthful across all existing surfaces; only then add retry / force-fail / reconcile-now UX on top of a coherent active-state language.
- **Priority**: high
-
 > Architecture contract-enforcement cluster: these candidates come from the targeted repository drift audit on 2026-04-22. Most are intentionally narrower than naming, presentation, or IA cleanup work. The shared contracts already exist; the gap is that they are not yet treated as mandatory on every platform-owned path. The operation-type candidate is the deliberate exception because the audit found two active competing semantic contracts, not just a missing guardrail.

-### Operation Run Link Contract Enforcement
- **Type**: hardening / contract enforcement
- **Source**: targeted repository architecture/pattern-drift audit 2026-04-22; canonical operation-link drift review
- **Problem**: TenantPilot already has a real canonical navigation contract in `OperationRunLinks` and `SystemOperationRunLinks`, but platform-owned UI and shared layers can still build `OperationRun` links through raw `route('admin.operations...')` calls. The same navigation class is therefore emitted through two parallel paths, including in shared navigation layers that otherwise already know the canonical link contract.
- **Why it matters**: This is not a missing-helper problem. It is a shared-contract bypass on a cross-cutting operator path. If it keeps spreading, tenant/workspace context, filter continuity, deep-link stability, and future operations IA changes all become more expensive because each surface can choose raw routes instead of the contract.
- **Proposed direction**:
-  - inventory platform-owned `OperationRun` collection/detail link producers and classify legitimate infrastructure exceptions
-  - move platform-owned UI and shared navigation layers to `OperationRunLinks` or `SystemOperationRunLinks`
-  - make collection/detail/context semantics part of the helper contract rather than repeated local route assembly
-  - add a lightweight guardrail that catches new raw `route('admin.operations...')` calls outside an explicit allowlist
- **Explicit non-goals**: Not a new operations IA, not a redesign of the operations pages, not a broad routing refactor for the whole repo, and not a change to `OperationRun` page content.
- **Boundary with Operation Run Active-State Visibility & Stale Escalation**: Active-state visibility owns lifecycle communication on compact and detail surfaces. This candidate owns canonical link generation and context continuity.
- **Boundary with Operator Presentation & Lifecycle Action Hardening**: Presentation hardening owns labels, badges, and action-visibility conventions. This candidate owns deep-link and collection-link contract enforcement.
- **Dependencies**: `OperationRunLinks`, `SystemOperationRunLinks`, canonical operations pages, and any repository signal or review guardrail infrastructure introduced by Spec 201.
- **Strategic sequencing**: First of this cluster. The leverage is high because the shared contract already exists and the surface area is concrete.
- **Priority**: high
-
 ### Canonical Operation Type Source of Truth
 - **Type**: hardening / source-of-truth decision
 - **Source**: strict read-only legacy / compatibility audit 2026-04-22; operation-type drift review
@ -432,30 +363,6 @@ ### Tenant Operational Readiness & Status Truth Hierarchy

 > Findings execution layer cluster: complementary to existing Spec 154 (`finding-risk-acceptance`). Keep these split so prioritization can pull workflow semantics, operator work surfaces, alerts, external handoff, and later portfolio operating slices independently instead of collapsing them into one oversized "Findings v2" spec.

-### Assignment Hygiene & Stale Work Detection
- **Type**: workflow hardening / operations hygiene
- **Source**: findings execution layer candidate pack 2026-04-17; assignment lifecycle hygiene gap analysis
- **Problem**: Assignments can silently rot when memberships change, assignees lose access, or findings remain stuck in `in_progress` indefinitely.
- **Why it matters**: Stale and orphaned assignments erode trust in queues and create hidden backlog. Hygiene reporting is a prerequisite for later auto-reassign logic.
- **Proposed direction**: Detect orphaned assignments, invalid or inactive assignees, and stale `in_progress` work; provide an admin/operator hygiene report; define what counts as stale versus active; stop short of automatic redistribution in v1.
- **Explicit non-goals**: Full reassignment workflows, automatic load distribution, and absence management.
- **Dependencies**: Tenant membership / RBAC model, scheduler or job layer, ownership semantics, open status logic.
- **Roadmap fit**: Findings Workflow v2 hardening.
- **Strategic sequencing**: Shortly after ownership semantics, ideally alongside or immediately after notifications.
- **Priority**: high
-
-### Finding Outcome Taxonomy & Verification Semantics
- **Type**: workflow semantics / reporting hardening
- **Source**: findings execution layer candidate pack 2026-04-17; status/outcome reporting gap analysis
- **Problem**: Resolve and close reasoning is too free-form, and the product does not cleanly separate operator-resolved from system-verified or confirmed-cleared states.
- **Why it matters**: Reporting, audit, reopening logic, and governance review packs need structured outcomes rather than ad hoc prose. Otherwise outcome meaning drifts between operators and surfaces.
- **Proposed direction**: Define structured reason codes for resolve, close, and reopen transitions; distinguish resolved, verified or confirmed cleared, closed, false positive, duplicate, and no-longer-applicable semantics; make reporting and filter UI consume the taxonomy instead of relying on free text.
- **Explicit non-goals**: Comments, full narrative case notes, and complex multi-reason models.
- **Dependencies**: Finding status transitions, audit payloads, reporting and filter UI.
- **Roadmap fit**: Findings Workflow v2 hardening and downstream review/reporting quality.
- **Strategic sequencing**: After the first operator work surfaces unless reporting pressure pulls it earlier.
- **Priority**: high
-
 ### Finding Comments & Decision Log v1
 - **Type**: collaboration / audit depth
 - **Source**: findings execution layer candidate pack 2026-04-17; operator handoff and context gap analysis
--- a/specs/233-stale-run-visibility/checklists/requirements.md
+++ b/specs/233-stale-run-visibility/checklists/requirements.md
@ -0,0 +1,36 @@
+# Specification Quality Checklist: Operation Run Active-State Visibility & Stale Escalation
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-04-23
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- Validated after initial draft creation.
+- No clarification markers remain.
+- Candidate promoted and removed from the open `Qualified` list in `docs/product/spec-candidates.md`.
--- a/specs/233-stale-run-visibility/contracts/operation-run-active-state-visibility.logical.openapi.yaml
+++ b/specs/233-stale-run-visibility/contracts/operation-run-active-state-visibility.logical.openapi.yaml
@ -0,0 +1,317 @@
+openapi: 3.1.0
+info:
+  title: Operation Run Active-State Visibility Logical Contract
+  version: 1.0.0
+  description: |
+    Internal logical contract for Spec 233. This does not introduce a new public API.
+    It documents the operator-visible active-state payload semantics that existing
+    Filament and Livewire surfaces derive from current OperationRun lifecycle truth.
+servers:
+  - url: https://logical.tenantpilot.internal
+    description: Logical contract namespace only
+tags:
+  - name: TenantActivity
+  - name: WorkspaceMonitoring
+  - name: CanonicalRunDetail
+paths:
+  /admin/t/{tenant}/dashboard:
+    get:
+      tags: [TenantActivity]
+      summary: Logical tenant activity summary contract
+      description: |
+        Represents the active-state payload that tenant dashboard activity and attention
+        surfaces must expose. Actual implementation is HTML/Filament, not JSON.
+      operationId: getTenantDashboardOperationActivitySummary
+      x-logical-contract: true
+      parameters:
+        - $ref: '#/components/parameters/TenantId'
+      responses:
+        '200':
+          description: Active-state summary for tenant-visible runs
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/TenantActivityOperationsSummary'
+        '404':
+          description: Tenant not visible to the current operator
+  /admin/t/{tenant}/operations/progress:
+    get:
+      tags: [TenantActivity]
+      summary: Logical tenant active-progress overlay contract
+      description: |
+        Represents the visible-active payload used by the tenant-local progress overlay.
+        Stale-active runs remain active for visibility and polling purposes, and
+        their compact elevation is rendered through the shared badge and Ops UX presenter path.
+      operationId: getTenantOperationProgressOverlay
+      x-logical-contract: true
+      parameters:
+        - $ref: '#/components/parameters/TenantId'
+      responses:
+        '200':
+          description: Active progress payload for tenant-scoped runs
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/TenantOperationProgressOverlay'
+        '403':
+          description: Operator is a member but lacks capability to view operation runs
+        '404':
+          description: Tenant not visible to the current operator
+  /admin/operations:
+    get:
+      tags: [WorkspaceMonitoring]
+      summary: Logical canonical operations list contract
+      description: |
+        Represents the row-level semantics required by the canonical operations list.
+        Existing tenant prefilter continuity may be preserved, but active-state meaning
+        must match the unfiltered list.
+      operationId: listWorkspaceOperationsWithActiveStateMeaning
+      x-logical-contract: true
+      parameters:
+        - $ref: '#/components/parameters/TenantFilter'
+        - $ref: '#/components/parameters/ActiveTab'
+        - $ref: '#/components/parameters/ProblemClass'
+      responses:
+        '200':
+          description: Workspace operations list row contract
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/OperationRunCollectionContract'
+        '404':
+          description: Workspace scope not visible to the current operator
+  /admin/operations/{run}:
+    get:
+      tags: [CanonicalRunDetail]
+      summary: Logical canonical run-detail contract
+      description: |
+        Represents the top-level summary semantics for a canonical operation-run detail page.
+        The page remains diagnostic-first while preserving the same active-state meaning seen
+        on compact tenant and workspace surfaces.
+      operationId: getCanonicalOperationRunDetailActiveStateSummary
+      x-logical-contract: true
+      parameters:
+        - $ref: '#/components/parameters/RunId'
+      responses:
+        '200':
+          description: Canonical operation-run detail summary contract
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/OperationRunDetailContract'
+        '403':
+          description: Operator is a member of scope but lacks required capability
+        '404':
+          description: Run not visible to the current operator or tenant scope
+components:
+  parameters:
+    TenantId:
+      name: tenant
+      in: path
+      required: true
+      schema:
+        type: integer
+        minimum: 1
+    RunId:
+      name: run
+      in: path
+      required: true
+      schema:
+        type: integer
+        minimum: 1
+    TenantFilter:
+      name: tenant
+      in: query
+      required: false
+      schema:
+        type: integer
+        minimum: 1
+      description: Optional tenant prefilter preserved from tenant-context navigation
+    ActiveTab:
+      name: activeTab
+      in: query
+      required: false
+      schema:
+        type: string
+      description: Existing canonical monitoring tab selection
+    ProblemClass:
+      name: problemClass
+      in: query
+      required: false
+      schema:
+        type: string
+        enum:
+          - none
+          - active_stale_attention
+          - terminal_follow_up
+  schemas:
+    OperationRunActiveStateProjection:
+      type: object
+      additionalProperties: false
+      required:
+        - freshness_state
+        - problem_class
+        - surface_category
+        - is_currently_active
+        - is_reconciled
+        - show_in_active_progress
+        - keep_active_polling
+      properties:
+        freshness_state:
+          type: string
+          enum:
+            - fresh_active
+            - likely_stale
+            - reconciled_failed
+            - terminal_normal
+            - unknown
+        problem_class:
+          type: string
+          enum:
+            - none
+            - active_stale_attention
+            - terminal_follow_up
+        surface_category:
+          type: string
+          enum:
+            - healthy_active
+            - past_expected_lifecycle
+            - likely_stale
+            - no_longer_active
+            - unknown
+          description: |
+            Derived operator-facing category. Compact surfaces may use
+            `past_expected_lifecycle` where canonical detail uses `likely_stale`
+            over the same stale truth.
+        compact_label:
+          type: string
+          nullable: true
+        diagnostic_label:
+          type: string
+          nullable: true
+        lifecycle_label:
+          type: string
+          nullable: true
+        guidance:
+          type: string
+          nullable: true
+        stale_lineage_note:
+          type: string
+          nullable: true
+        is_currently_active:
+          type: boolean
+        is_reconciled:
+          type: boolean
+        show_in_active_progress:
+          type: boolean
+        keep_active_polling:
+          type: boolean
+    OperationRunSurfaceItem:
+      type: object
+      additionalProperties: false
+      required:
+        - run_id
+        - operation_label
+        - active_state
+      properties:
+        run_id:
+          type: integer
+          minimum: 1
+        tenant_id:
+          type: integer
+          minimum: 1
+          nullable: true
+        tenant_label:
+          type: string
+          nullable: true
+        operation_label:
+          type: string
+        status_label:
+          type: string
+          nullable: true
+        outcome_label:
+          type: string
+          nullable: true
+        active_state:
+          $ref: '#/components/schemas/OperationRunActiveStateProjection'
+        detail_url:
+          type: string
+          nullable: true
+    TenantActivityOperationsSummary:
+      type: object
+      additionalProperties: false
+      required:
+        - tenant_id
+        - items
+      properties:
+        tenant_id:
+          type: integer
+          minimum: 1
+        items:
+          type: array
+          items:
+            $ref: '#/components/schemas/OperationRunSurfaceItem'
+    TenantOperationProgressOverlay:
+      type: object
+      additionalProperties: false
+      required:
+        - tenant_id
+        - has_visible_active_runs
+        - poll_interval
+        - items
+      properties:
+        tenant_id:
+          type: integer
+          minimum: 1
+        has_visible_active_runs:
+          type: boolean
+        poll_interval:
+          type: string
+          nullable: true
+          enum:
+            - 10s
+        items:
+          type: array
+          items:
+            $ref: '#/components/schemas/OperationRunSurfaceItem'
+    OperationRunCollectionContract:
+      type: object
+      additionalProperties: false
+      required:
+        - items
+      properties:
+        tenant_filter:
+          type: integer
+          minimum: 1
+          nullable: true
+        active_tab:
+          type: string
+          nullable: true
+        problem_class:
+          type: string
+          nullable: true
+        items:
+          type: array
+          items:
+            $ref: '#/components/schemas/OperationRunSurfaceItem'
+    OperationRunDetailContract:
+      type: object
+      additionalProperties: false
+      required:
+        - run_id
+        - operation_label
+        - active_state
+      properties:
+        run_id:
+          type: integer
+          minimum: 1
+        operation_label:
+          type: string
+        active_state:
+          $ref: '#/components/schemas/OperationRunActiveStateProjection'
+        top_summary:
+          type: string
+          nullable: true
+        diagnostics_visible_after_summary:
+          type: boolean
+          const: true
--- a/specs/233-stale-run-visibility/data-model.md
+++ b/specs/233-stale-run-visibility/data-model.md
@ -0,0 +1,147 @@
+# Data Model: Operation Run Active-State Visibility & Stale Escalation
+
+## Overview
+
+This feature introduces no new persisted entity, table, or stored projection. It formalizes one derived active-state presentation contract over existing `OperationRun` lifecycle truth so tenant and workspace monitoring surfaces present the same meaning.
+
+## Source Entity: OperationRun
+
+- **Purpose**: Canonical lifecycle and outcome record for long-running admin-plane work.
+- **Existing fields used by this feature**:
+  - `id`
+  - `workspace_id`
+  - `tenant_id`
+  - `type`
+  - `status`
+  - `outcome`
+  - `created_at`
+  - `started_at`
+  - `completed_at`
+  - `context`
+  - `failure_summary`
+- **Existing relationships used by this feature**:
+  - `tenant`
+  - `user` where available for initiator context
+- **Existing invariants**:
+  - Lifecycle status and outcome remain service-owned.
+  - Reconciliation metadata stays inside `context.reconciliation`.
+  - No new persisted status or outcome values are introduced for visibility purposes.
+
+## Derived Truth: OperationRunFreshnessState
+
+- **Type**: Existing enum `App\Support\Operations\OperationRunFreshnessState`
+- **Values**:
+  - `fresh_active`
+  - `likely_stale`
+  - `reconciled_failed`
+  - `terminal_normal`
+  - `unknown`
+- **Inputs**:
+  - `status`
+  - `created_at`
+  - `started_at`
+  - `context.reconciliation`
+  - existing `OperationLifecyclePolicy`
+- **Behavioral rule**:
+  - This remains the only stale/late truth input for surface rendering.
+  - No widget, page, or Livewire component may introduce its own threshold logic.
+
+## Derived Truth: OperationRun Problem Class
+
+- **Type**: Existing derived string on `OperationRun`
+- **Values**:
+  - `none`
+  - `active_stale_attention`
+  - `terminal_follow_up`
+- **Purpose**:
+  - Separates active stale attention from terminal follow-up while keeping both distinct from calm/no-action runs.
+- **Relationship to freshness**:
+  - `likely_stale` freshness yields `active_stale_attention`.
+  - `reconciled_failed` freshness yields `terminal_follow_up`.
+  - Completed blocked/partial/failed runs may also yield `terminal_follow_up` without stale lineage.
+
+## Derived View Model: Active-State Presentation Contract
+
+- **Type**: Derived, request-scoped presentation payload. Prefer reuse of `OperationUxPresenter::decisionZoneTruth()` and existing badge/presenter outputs before adding any new helper.
+- **Required fields across covered surfaces**:
+  - `freshness_state`
+  - `problem_class`
+  - `is_currently_active`
+  - `is_reconciled`
+  - `compact_label`
+  - `diagnostic_label`
+  - `guidance`
+  - `stale_lineage_note`
+  - `show_in_active_progress`
+  - `keep_active_polling`
+- **Presentation categories**:
+  - `healthy_active`
+  - `past_expected_lifecycle`
+  - `likely_stale`
+  - `no_longer_active`
+  - `unknown` fallback
+- **Category mapping rules**:
+  - `fresh_active` + active run -> `healthy_active`
+  - `likely_stale` on compact summary surfaces -> `past_expected_lifecycle`
+  - `likely_stale` on canonical or stronger diagnostic surfaces -> `likely_stale`
+  - `terminal_normal` or `reconciled_failed` -> `no_longer_active`
+  - `unknown` -> fallback copy without false stale escalation
+- **Important constraint**:
+  - `past_expected_lifecycle` and `likely_stale` are density variants over the same stale truth, not separate persisted states.
+
+## Derived Surface Policy: Tenant Active Progress Visibility
+
+- **Current consumers**:
+  - `App\Livewire\BulkOperationProgress`
+  - `App\Support\OpsUx\ActiveRuns`
+- **Former issue**:
+  - Both used `healthyActive()` and therefore suppressed stale-active runs from the tenant progress overlay and polling decision.
+- **Implemented rule**:
+  - Fresh and stale active runs remain visible as active work.
+  - Terminal runs disappear on the next refresh cycle.
+  - Polling continues while any visible active work remains, including stale-active runs.
+  - Overlay rendering uses the existing status badge and `OperationUxPresenter` guidance path so stale-active elevation stays derived from shared freshness truth.
+
+## Covered Surface Consumers
+
+| Consumer | Current Truth Inputs | Required Change |
+|---|---|---|
+| `BulkOperationProgress` | Active run query, `healthyActive()`, `ActiveRuns` | Include stale-active work in visibility and polling semantics while keeping terminal runs excluded |
+| `RecentOperationsSummary` | Raw recent runs for tenant | Ensure active-state emphasis and copy stay aligned with canonical freshness meaning |
+| `Dashboard\RecentOperations` | Badge rendering + `OperationUxPresenter` | Preserve and tighten existing freshness-aware row semantics |
+| `Dashboard\NeedsAttention` / `DashboardKpis` | Problem-class counts + links | Keep stale-active counts and linked monitoring semantics aligned |
+| `WorkspaceOverviewBuilder` / `WorkspaceRecentOperations` | Badge rendering + `OperationUxPresenter` | Preserve workspace summary consistency and diagnostic separation |
+| `OperationRunResource` | Status/outcome badges + lifecycle summaries | Keep canonical list/detail authoritative and consistent with compact surfaces |
+| `TenantlessOperationRunViewer` | Canonical detail page around resource truth | Preserve diagnostic-first explanation of stale versus terminal meaning |
+
+## State Transitions Relevant To This Feature
+
+1. `queued` or `running` within lifecycle threshold
+   - Freshness: `fresh_active`
+   - Presentation: `healthy_active`
+   - Visible on active-only compact surfaces: yes
+
+2. `queued` or `running` beyond lifecycle threshold
+   - Freshness: `likely_stale`
+   - Presentation: `past_expected_lifecycle` on compact surfaces, `likely_stale` on diagnostic surfaces
+   - Visible on active-only compact surfaces: yes
+
+3. `completed` without reconciliation
+   - Freshness: `terminal_normal`
+   - Presentation: `no_longer_active`
+   - Visible on active-only compact surfaces: no
+
+4. `completed` with reconciliation metadata
+   - Freshness: `reconciled_failed`
+   - Presentation: `no_longer_active` with stale-lineage diagnostics
+   - Visible on active-only compact surfaces: no
+
+## Validation Rules And Invariants
+
+- No new `OperationRun.status` or `OperationRun.outcome` values may be added.
+- No new persisted `operation_runs` summary or mirror table may be added.
+- All stale/late meaning must derive from existing freshness truth.
+- Tenant-scoped surfaces must only reflect runs already visible to the current tenant-entitled operator.
+- Workspace summaries must stay limited to entitled tenant slices.
+- Healthy queued/running work must not inherit stale emphasis.
+- Terminal runs must stop appearing in active-only surfaces on the next refresh cycle.
--- a/specs/233-stale-run-visibility/plan.md
+++ b/specs/233-stale-run-visibility/plan.md
@ -0,0 +1,237 @@
+# Implementation Plan: Operation Run Active-State Visibility & Stale Escalation
+
+**Branch**: `233-stale-run-visibility` | **Date**: 2026-04-23 | **Spec**: [spec.md](./spec.md)
+**Input**: Feature specification from `/specs/233-stale-run-visibility/spec.md`
+
+## Summary
+
+Complete one shared active-state presentation contract on top of the already-existing `OperationRun` lifecycle freshness truth by converging tenant dashboard activity signals, tenant-local active-run progress cards, workspace recent-operations summaries, the canonical operations list, and canonical run detail on the same fresh-versus-past-expected-versus-likely-stale semantics without introducing new persisted run state, new status values, or page-local heuristics.
+
+## Technical Context
+
+**Language/Version**: PHP 8.4.15, Laravel 12, Filament v5, Livewire v4  
+**Primary Dependencies**: Filament widgets/resources/pages, Pest v4, `App\Models\OperationRun`, `App\Support\Operations\OperationRunFreshnessState`, `App\Services\Operations\OperationLifecycleReconciler`, `App\Support\OpsUx\OperationUxPresenter`, `App\Support\OpsUx\ActiveRuns`, `App\Support\Badges\BadgeCatalog` / `BadgeRenderer`, `App\Support\Workspaces\WorkspaceOverviewBuilder`, `App\Support\OperationRunLinks`  
+**Storage**: Existing PostgreSQL `operation_runs` records and current session/query-backed monitoring navigation state; no new persistence  
+**Testing**: Focused Pest feature tests over tenant dashboard widgets, tenant active-run progress surfaces, workspace overview operations summaries, canonical operations list/detail pages, and stale-reconciliation semantics  
+**Validation Lanes**: `fast-feedback`, `confidence`  
+**Target Platform**: Laravel admin web application in Sail containers with workspace routes under `/admin` and tenant routes under `/admin/t/{tenant}`  
+**Project Type**: Monorepo with one Laravel runtime in `apps/platform` and spec artifacts at repository root  
+**Performance Goals**: Preserve existing query shape and request-local presenter work; no additional remote calls, no background-process changes, and no new persisted summary projections  
+**Constraints**: No new `OperationRun.status` or `OperationRun.outcome` values, no retry/cancel/reconcile-now UX, no new notification channel, no page-local stale heuristics, no cross-tenant leakage, and no second presentation framework beyond the existing badge/presenter path  
+**Scale/Scope**: Existing tenant dashboard and tenant resource widgets, one Livewire active-progress slice, workspace overview builders/widgets, canonical operations list/detail pages, and their focused feature-test families
+
+## Filament v5 Implementation Contract
+
+- **Livewire v4.0+ compliance**: Preserved. The feature extends existing Filament v5 pages/widgets/resources and Livewire components without introducing legacy Livewire v3 patterns.
+- **Provider registration location**: Unchanged. Panel providers remain registered in `bootstrap/providers.php`, not `bootstrap/app.php`.
+- **Global search coverage**: `OperationRunResource` already keeps global search disabled via `$isGloballySearchable = false`, so this feature adds no new global-search exposure and does not depend on Edit/View global-search rules.
+- **Destructive actions**: No destructive actions are introduced. Existing monitoring/detail actions remain read-only, and this feature must not add retry, cancel, or force-fail controls.
+- **Asset strategy**: No new Filament assets are planned. Deployment expectations remain unchanged, including `cd apps/platform && php artisan filament:assets` only if a future implementation adds registered assets.
+- **Testing plan**: Prove semantics with focused feature tests for tenant dashboard activity, tenant progress summaries, workspace recent operations, canonical operations list/detail consistency, and stale-versus-fresh boundary cases. No browser or heavy-governance lane is required for this slice.
+
+## UI / Surface Guardrail Plan
+
+- **Guardrail scope**: Changed surfaces across tenant dashboard activity, tenant-local active-run progress, workspace recent operations summaries, canonical monitoring list rows, and canonical run detail summary
+- **Native vs custom classification summary**: Mixed shared-family change using native Filament widgets/resources/pages plus one existing Livewire progress component
+- **Shared-family relevance**: Status messaging, dashboard signals/cards, monitoring list presentation, canonical drill-through, and run-detail summary semantics
+- **State layers in scope**: `page`, `detail`, and one request-scoped/Livewire compact-progress slice; no new URL-state layer beyond existing monitoring continuity
+- **Handling modes by drift class or surface**: Review-mandatory because meaning must stay aligned across multiple existing surfaces and one existing hidden gap (`healthyActive()`-only progress) must be closed without widening scope
+- **Repository-signal treatment**: Review-mandatory; the feature changes operator-visible semantics but does not need a hard-stop repo guard
+- **Special surface test profiles**: `standard-native-filament`, `monitoring-state-page`, `shared-detail-family`
+- **Required tests or manual smoke**: `functional-core`, `state-contract`
+- **Exception path and spread control**: None planned. All covered surfaces should consume existing freshness truth and shared presenter/badge paths rather than diverging locally.
+- **Active feature PR close-out entry**: `Guardrail`
+
+## Shared Pattern & System Fit
+
+- **Cross-cutting feature marker**: yes
+- **Systems touched**: `OperationRunFreshnessState`, `OperationLifecycleReconciler`, `OperationRun` problem-class helpers, `OperationUxPresenter`, centralized badge rendering, `BulkOperationProgress`, `RecentOperationsSummary`, `RecentOperations`, `DashboardKpis`, `NeedsAttention`, `WorkspaceOverviewBuilder`, `WorkspaceRecentOperations`, `OperationRunResource`, and `TenantlessOperationRunViewer`
+- **Shared abstractions reused**: `OperationRun::freshnessState()`, `OperationRun::problemClass()`, `OperationRunFreshnessState`, `OperationUxPresenter::decisionZoneTruth()`, `OperationUxPresenter::lifecycleAttentionSummary()`, `OperationUxPresenter::surfaceGuidance()`, `ActiveRuns`, `BadgeCatalog` / `BadgeRenderer`, `OperationRunLinks`, and existing workspace/tenant authorization helpers
+- **New abstraction introduced? why?**: One bounded derived active-state presentation contract is intentionally made explicit through the existing presenter and active-run helpers so compact and canonical surfaces can stay aligned without introducing a standalone semantic framework.
+- **Why the existing abstraction was sufficient or insufficient**: Existing lifecycle truth is sufficient and authoritative. Existing compact-surface adoption is insufficient because some slices already honor freshness (`OperationRunResource`, `RecentOperations`, `WorkspaceOverviewBuilder`) while others still filter to `healthyActive()` or under-communicate stale active work.
+- **Bounded deviation / spread control**: Same meaning, different density only. Surface-specific copy may vary by density, but all covered surfaces must consume the same freshness/problem-class truth and must not invent local stale logic.
+
+## Constitution Check
+
+*GATE: Passed before Phase 0 research. Re-checked after Phase 1 design: still passed with one bounded derived presentation contract and no new persisted truth.*
+
+| Gate | Status | Plan Notes |
+|------|--------|------------|
+| Inventory-first / read-write separation | PASS | The feature is read-only presentation hardening over existing `operation_runs`; no restore, preview, or write-path change is introduced. |
+| RBAC, workspace isolation, tenant isolation | PASS | Existing tenant-scoped widgets and canonical workspace monitoring routes remain on current entitlement checks; no new visibility surface is added. |
+| Run observability / Ops-UX lifecycle | PASS | `OperationRunService`, lifecycle reconciliation, queued/running/terminal notifications, and run ownership remain unchanged; the plan only changes interpretation and visibility of existing run truth. |
+| Shared pattern first | PASS | The plan explicitly reuses existing freshness, problem-class, presenter, and badge paths rather than adding a second semantic layer or local mapping family. |
+| Proportionality / no premature abstraction | PASS | The narrowest credible change is one derived presentation contract over current truth plus convergence of existing surfaces. No new persistence, registry, or workflow framework is planned. |
+| Badge semantics / Filament-native discipline | PASS | Status-like emphasis stays on centralized badge rendering and existing Filament widgets/resources/pages; no ad-hoc surface-local color system is introduced. |
+| Decision-first / operator surfaces | PASS | The operations list remains the primary triage surface, tenant widgets stay secondary context, and canonical run detail stays diagnostic-first. |
+| Test governance | PASS | Proof stays in focused feature lanes and existing surface families, with no browser-lane promotion and no heavy shared test infrastructure growth. |
+
+## Test Governance Check
+
+- **Test purpose / classification by changed surface**: `Feature` for tenant dashboard activity, tenant progress surfaces, workspace recent operations summaries, canonical operations list/detail consistency, and stale boundary semantics
+- **Affected validation lanes**: `fast-feedback`, `confidence`
+- **Why this lane mix is the narrowest sufficient proof**: The business truth is cross-surface semantic consistency over existing `OperationRun` freshness state. That is fully provable with focused feature tests against the touched widgets/pages and existing reconciliation truth; browser coverage would add cost without validating additional domain behavior.
+- **Narrowest proving command(s)**:
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php tests/Feature/OpsUx/ProgressWidgetFiltersTest.php tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php tests/Feature/Filament/DashboardKpisWidgetTest.php tests/Feature/Filament/NeedsAttentionWidgetTest.php tests/Feature/Filament/WorkspaceOverviewOperationsTest.php tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php tests/Feature/Monitoring/MonitoringOperationsTest.php tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php tests/Feature/Operations/TenantlessOperationRunViewerTest.php`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/RunAuthorizationTenantIsolationTest.php tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`
+- **Fixture / helper / factory / seed / context cost risks**: Moderate. Tests need representative fresh queued/running runs, likely stale runs, reconciled terminal runs, tenant membership context, workspace overview payloads, and hidden-tenant/non-member isolation boundaries, but existing factories and operation-run helpers already cover most of that setup.
+- **Expensive defaults or shared helper growth introduced?**: No. Existing `OperationRun` factories and workspace/tenant test helpers should stay opt-in and sufficient.
+- **Heavy-family additions, promotions, or visibility changes**: none
+- **Surface-class relief / special coverage rule**: Standard native-Filament relief plus the existing `monitoring-state-page` proving profile for canonical monitoring pages and summaries
+- **Closing validation and reviewer handoff**: Re-run `pint`, then the focused feature command above. Reviewers should verify that stale active work is visible on every covered compact surface, healthy active work is not falsely escalated, and drill-through into canonical detail preserves the same active-state meaning.
+- **Budget / baseline / trend follow-up**: none
+- **Review-stop questions**: Did any surface invent its own stale threshold? Did `healthyActive()` filtering remain in a surface that should show stale-active attention? Did any test rely on status strings alone instead of freshness truth? Did any change accidentally widen visibility beyond entitled tenant/workspace scope?
+- **Escalation path**: `document-in-feature`
+- **Active feature PR close-out entry**: `Guardrail`
+- **Why no dedicated follow-up spec is needed**: This is bounded current-release convergence of an existing truth family. A separate follow-up spec is only needed if later work tries to add intervention actions or a broader operations workbench.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/233-stale-run-visibility/
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+│   └── operation-run-active-state-visibility.logical.openapi.yaml
+└── tasks.md
+```
+
+### Source Code (repository root)
+
+```text
+apps/platform/
+├── app/
+│   ├── Filament/
+│   │   ├── Pages/
+│   │   │   └── Operations/TenantlessOperationRunViewer.php
+│   │   ├── Resources/
+│   │   │   └── OperationRunResource.php
+│   │   └── Widgets/
+│   │       ├── Dashboard/
+│   │       │   ├── DashboardKpis.php
+│   │       │   ├── NeedsAttention.php
+│   │       │   └── RecentOperations.php
+│   │       ├── Tenant/
+│   │       │   └── RecentOperationsSummary.php
+│   │       └── Workspace/
+│   │           └── WorkspaceRecentOperations.php
+│   ├── Livewire/
+│   │   └── BulkOperationProgress.php
+│   ├── Models/
+│   │   └── OperationRun.php
+│   ├── Services/Operations/
+│   │   └── OperationLifecycleReconciler.php
+│   └── Support/
+│       ├── Badges/Domains/OperationRunStatusBadge.php
+│       ├── OperationRunLinks.php
+│       ├── OpsUx/
+│       │   ├── ActiveRuns.php
+│       │   └── OperationUxPresenter.php
+│       ├── Operations/OperationRunFreshnessState.php
+│       └── Workspaces/WorkspaceOverviewBuilder.php
+├── resources/views/
+│   ├── filament/widgets/
+│   │   ├── tenant/recent-operations-summary.blade.php
+│   │   └── workspace/workspace-recent-operations.blade.php
+│   └── livewire/
+│       ├── bulk-operation-progress.blade.php
+│       └── bulk-operation-progress-wrapper.blade.php
+└── tests/
+  └── Feature/
+    ├── Filament/
+    │   ├── DashboardKpisWidgetTest.php
+    │   ├── NeedsAttentionWidgetTest.php
+    │   ├── OperationRunEnterpriseDetailPageTest.php
+    │   ├── RecentOperationsSummaryWidgetTest.php
+    │   └── WorkspaceOverviewOperationsTest.php
+    ├── Monitoring/
+    │   ├── MonitoringOperationsTest.php
+    │   ├── OperationLifecycleFreshnessPresentationTest.php
+    │   └── OperationsDashboardDrillthroughTest.php
+    └── Operations/
+      └── TenantlessOperationRunViewerTest.php
+    ├── OpsUx/
+    │   ├── BulkOperationProgressDbOnlyTest.php
+    │   ├── NonLeakageWorkspaceOperationsTest.php
+    │   ├── ProgressWidgetFiltersTest.php
+    │   └── ProgressWidgetOverflowTest.php
+    └── RunAuthorizationTenantIsolationTest.php
+```
+
+**Structure Decision**: Single Laravel application inside `apps/platform`. Runtime work stays in existing monitoring widgets/resources/pages and one existing Livewire progress slice; planning artifacts stay under `specs/233-stale-run-visibility`.
+
+## Complexity Tracking
+
+No constitutional violation is planned. One bounded derived presentation contract is intentionally tracked because the spec introduces a small new semantic family over existing truth.
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| BLOAT-001 derived category family | Compact surfaces currently disagree in practice about whether stale active work is still ordinary progress. One small derived contract keeps surface meaning aligned without changing persisted run state. | Leaving each widget to infer meaning from raw `status` or local heuristics would preserve drift and make future regressions likely. |
+
+## Proportionality Review
+
+- **Current operator problem**: Compact operator surfaces can still hide or understate that active work is already past its expected lifecycle, so operators get false reassurance until they drill into monitoring detail.
+- **Existing structure is insufficient because**: Existing freshness truth and presenter helpers already exist, but they are not applied consistently across tenant progress and summary surfaces, and one slice (`BulkOperationProgress`) still intentionally filters stale active work out.
+- **Narrowest correct implementation**: Reuse current freshness/problem-class truth, introduce at most one small derived active-state presentation contract, and retrofit only the existing tenant/workspace/canonical monitoring surfaces that already summarize active work.
+- **Ownership cost created**: Small ongoing maintenance of one derived category family, shared copy alignment, and focused regression tests across covered surfaces.
+- **Alternative intentionally rejected**: Adding new persisted `OperationRun` statuses or separate page-local stale heuristics. Both would widen lifecycle scope or create contradictory truth.
+- **Release truth**: Current-release truth and operator-trust hardening.
+
+## Phase 0 Research Summary
+
+- Existing lifecycle and freshness truth already live in `OperationRunFreshnessState`, `OperationRun::problemClass()`, and `OperationLifecycleReconciler`; the feature should consume them rather than create new thresholds.
+- Canonical monitoring surfaces already partially honor stale-active semantics: `OperationRunResource`, `Dashboard\RecentOperations`, and `WorkspaceOverviewBuilder` all feed badge/presenter state with `freshness_state` or lifecycle summaries.
+- The clearest gap was tenant-local active-progress visibility: `BulkOperationProgress` scoped to `healthyActive()`, which hid stale active work from a high-frequency tenant surface and created exactly the cross-surface contradiction the spec describes.
+- `OperationUxPresenter::surfaceGuidance()` already differentiates likely stale, reconciled failed, and ordinary queued/running work, so Phase 1 should extend adoption before inventing new presentation machinery.
+- Existing focused tests already cover parts of the semantics (`OperationLifecycleFreshnessPresentationTest`, `MonitoringOperationsTest`, `RecentOperationsSummaryWidgetTest`, `WorkspaceOverviewOperationsTest`, `OperationRunEnterpriseDetailPageTest`, `TenantlessOperationRunViewerTest`), so implementation should prefer extending those families over introducing new broad suites.
+
+## Phase 1 Design Summary
+
+- `data-model.md` defines the derived active-state presentation model over existing `OperationRun`, freshness state, problem class, and covered surface consumers.
+- `contracts/operation-run-active-state-visibility.logical.openapi.yaml` documents the internal logical contract for how covered surfaces derive and display active-state meaning from existing run truth.
+- `quickstart.md` gives the narrow validation path for fresh-versus-stale fixtures, compact-surface rendering, canonical drill-through, and regression checks.
+
+## Implementation Strategy
+
+1. **Converge on one freshness-to-surface contract**
+  - Reuse `OperationUxPresenter::decisionZoneTruth()`, `lifecycleAttentionSummary()`, current badge helpers, and `ActiveRuns` as the default convergence path.
+  - Keep all thresholds and lifecycle windows owned by existing freshness truth.
+
+2. **Fix the tenant-local active-progress blind spot**
+  - Update `BulkOperationProgress` so stale active runs are not silently excluded from tenant-local progress visibility.
+  - Preserve calm presentation for healthy active work while allowing stale/late work to escalate visibly.
+
+3. **Align tenant dashboard and tenant-summary surfaces**
+  - Reconcile `DashboardKpis`, `NeedsAttention`, `RecentOperationsSummary`, and any shared tenant activity slices so they expose the same active-state meaning and drill-through expectations.
+  - Ensure mixed tenant activity does not over-generalize one stale run into “all activity is stale.”
+
+4. **Keep workspace and canonical monitoring surfaces authoritative**
+  - Reuse existing freshness-aware row/detail rendering in `OperationRunResource`, `TenantlessOperationRunViewer`, and `WorkspaceOverviewBuilder`, tightening copy and top-level summary semantics only where necessary.
+  - Preserve canonical list/detail roles and existing filter continuity from tenant context.
+
+5. **Regression-protect fresh versus stale boundaries**
+  - Extend the existing monitoring and Filament feature tests to prove fresh active, likely stale, reconciled terminal, and terminal-transition cases across covered surfaces.
+  - Explicitly assert that healthy queued/running runs do not inherit stale emphasis and that terminal runs disappear from active-only compact surfaces after refresh.
+
+## Risks and Mitigations
+
+- **Surface drift survives in one slice**: A compact surface may continue to rely on `status` only. Mitigation: inventory and update every covered surface in this plan, with tests tied to each family.
+- **Over-escalation of healthy active work**: Copy or badge reuse could make all queued/running work feel unhealthy. Mitigation: keep the proving fixtures split between fresh and stale runs and assert negative cases explicitly.
+- **Tenant progress regression**: Broadening `BulkOperationProgress` could accidentally turn a calm progress bar into a noisy problem board. Mitigation: keep one bounded active-state distinction and preserve existing density expectations.
+- **New semantic layer grows too far**: It would be easy to invent a broader taxonomy. Mitigation: constrain the plan to one derived presentation contract backed entirely by existing freshness/problem-class truth.
+
+## Implementation Close-Out
+
+- **Finalized affected surfaces**: Tenant active progress overlay and polling now include all active `OperationRun` records, including stale-active runs. Tenant summary, dashboard KPI/attention, workspace overview, canonical operations list, and canonical detail surfaces already consume shared freshness, badge, and presenter paths and were validated without widening the runtime change.
+- **Density-specific copy retained**: Compact surfaces use shared badge copy such as `Likely stale` plus `OperationUxPresenter::surfaceGuidance()` text about being past the lifecycle window. Canonical detail keeps the stronger `Likely stale operation` diagnostic banner.
+- **Test-governance disposition**: `document-in-feature`. Coverage stayed inside existing feature-test families and the focused `fast-feedback` / `confidence` lanes; no browser lane, heavy-governance family, shared fixture widening, or new test infrastructure was introduced.
+
+## Post-Design Re-check
+
+Phase 0 and Phase 1 outputs keep the feature within existing `OperationRun` lifecycle truth, existing Filament/Livewire surfaces, and focused feature-test families. The plan remains constitution-compliant, Livewire v4 / Filament v5 compliant, and ready for `/speckit.tasks`.
--- a/specs/233-stale-run-visibility/quickstart.md
+++ b/specs/233-stale-run-visibility/quickstart.md
@ -0,0 +1,79 @@
+# Quickstart: Operation Run Active-State Visibility & Stale Escalation
+
+## Preconditions
+
+1. Start the application stack:
+   - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail up -d`
+2. Work from branch `233-stale-run-visibility`.
+3. Keep the scope bounded to existing admin-plane monitoring and progress surfaces.
+
+## Primary Files To Review First
+
+- `apps/platform/app/Models/OperationRun.php`
+- `apps/platform/app/Support/Operations/OperationRunFreshnessState.php`
+- `apps/platform/app/Support/OpsUx/OperationUxPresenter.php`
+- `apps/platform/app/Support/OpsUx/ActiveRuns.php`
+- `apps/platform/app/Livewire/BulkOperationProgress.php`
+- `apps/platform/app/Filament/Widgets/Tenant/RecentOperationsSummary.php`
+- `apps/platform/app/Filament/Widgets/Dashboard/RecentOperations.php`
+- `apps/platform/app/Filament/Resources/OperationRunResource.php`
+- `apps/platform/app/Support/Workspaces/WorkspaceOverviewBuilder.php`
+- `apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php`
+
+## Recommended Implementation Order
+
+1. **Lock the truth source**
+   - Confirm no surface-local stale thresholds exist outside `OperationRunFreshnessState` and `OperationRun::problemClass()`.
+   - Reuse `OperationUxPresenter::decisionZoneTruth()`, `lifecycleAttentionSummary()`, and `surfaceGuidance()` wherever possible.
+
+2. **Fix tenant progress visibility first**
+   - Update `ActiveRuns` and `BulkOperationProgress` so stale-active runs still count as active work for visibility and polling.
+   - Keep terminal runs disappearing on the next refresh cycle.
+   - Render stale-active elevation through the shared operation status badge and `OperationUxPresenter` guidance path.
+
+3. **Converge tenant and workspace summary surfaces**
+   - Align `RecentOperationsSummary`, `Dashboard\RecentOperations`, `Dashboard\NeedsAttention`, `DashboardKpis`, and `WorkspaceOverviewBuilder` on the same compact/detailed stale-active semantics.
+   - Do not create a new dashboard surface family.
+
+4. **Tighten canonical monitoring consistency last**
+   - Preserve `OperationRunResource` and `TenantlessOperationRunViewer` as the authoritative diagnostic surfaces.
+   - Adjust top-level explanation or row emphasis only where it improves consistency with the compact surfaces.
+
+5. **Update focused tests in the same slice**
+   - Flip stale-hidden assertions in the tenant progress tests.
+   - Extend monitoring, widget, and visibility-safety tests to prove fresh versus stale boundaries, terminal transitions, and hidden-tenant/non-member isolation.
+
+## Focused Test Matrix
+
+| Scenario | Expected Result | Likely Test Family |
+|---|---|---|
+| Fresh queued/running run on tenant surface | Visible as healthy active work, no stale escalation | `tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php` |
+| Stale queued/running run on tenant surface | Still visible as active work, but clearly elevated | `tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `tests/Feature/OpsUx/ProgressWidgetFiltersTest.php` |
+| Stale run on workspace summaries | Scanable as attention-worthy, not collapsed into calm recency | `tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `tests/Feature/Monitoring/MonitoringOperationsTest.php` |
+| Stale run on canonical list/detail | Same active-state meaning preserved after drill-through | `tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php`, `tests/Feature/Operations/TenantlessOperationRunViewerTest.php`, `tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php` |
+| Terminal transition after refresh | Removed from active-only overlays and no longer presented as active | `tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php` |
+| Hidden or out-of-scope runs during summary rendering | Remain invisible and do not alter visible active-state summaries | `tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`, `tests/Feature/RunAuthorizationTenantIsolationTest.php` |
+
+## Minimum Validation Commands
+
+```bash
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php tests/Feature/OpsUx/ProgressWidgetFiltersTest.php tests/Feature/OpsUx/ProgressWidgetOverflowTest.php
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php tests/Feature/Filament/DashboardKpisWidgetTest.php tests/Feature/Filament/NeedsAttentionWidgetTest.php tests/Feature/Filament/WorkspaceOverviewOperationsTest.php tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php tests/Feature/Monitoring/MonitoringOperationsTest.php tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php tests/Feature/Operations/TenantlessOperationRunViewerTest.php
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/RunAuthorizationTenantIsolationTest.php tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php
+export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
+```
+
+## Manual Smoke Checklist
+
+1. Seed one fresh running run and one stale queued/running run for the same tenant.
+2. Open the tenant dashboard and confirm the stale run is visible and clearly elevated without making the fresh run look unhealthy.
+3. Confirm the tenant progress surface keeps polling while only stale-active work remains.
+4. Open `/admin/operations` and verify the same run is distinguishable at row level.
+5. Drill into `/admin/operations/{run}` and confirm the top summary preserves the same active-state meaning before raw diagnostics.
+
+## Out Of Scope Guardrails
+
+- Do not add retry, cancel, reconcile-now, or worker-control actions.
+- Do not add new notifications or queued/running DB notifications.
+- Do not add new persisted run summary data or new `OperationRun` status values.
+- Do not widen the work into a new operations workbench or cross-workspace fleet view.
--- a/specs/233-stale-run-visibility/research.md
+++ b/specs/233-stale-run-visibility/research.md
@ -0,0 +1,49 @@
+# Research: Operation Run Active-State Visibility & Stale Escalation
+
+## Decision 1: Keep lifecycle freshness truth in the existing run model and reconciler
+
+- **Decision**: Use `OperationRunFreshnessState`, `OperationRun::freshnessState()`, `OperationRun::problemClass()`, and `OperationLifecycleReconciler` as the only lifecycle-truth inputs for this feature.
+- **Rationale**: The application already computes `fresh_active`, `likely_stale`, `reconciled_failed`, `terminal_normal`, and `unknown` from the run record plus `OperationLifecyclePolicy`. Canonical monitoring surfaces already rely on that truth, so adding a second stale heuristic would immediately recreate the drift this spec is trying to remove.
+- **Alternatives considered**:
+  - Add new `OperationRun.status` values such as `stale` or `late`: rejected because the distinction is presentation and triage-oriented, not a new persisted lifecycle state.
+  - Add page-local thresholds per widget: rejected because it would create conflicting meaning across tenant, workspace, and canonical monitoring surfaces.
+
+## Decision 2: Reuse the existing Ops UX presenter path before introducing a new helper
+
+- **Decision**: Prefer `OperationUxPresenter::decisionZoneTruth()`, `lifecycleAttentionSummary()`, `surfaceGuidance()`, and centralized badge rendering as the presentation backbone.
+- **Rationale**: The code already exposes a derived decision-zone payload and shared stale/reconciled copy. `OperationRunStatusBadge` already renders `Likely stale` when queued/running work carries `freshness_state=likely_stale`, and `OperationUxPresenter` already provides compact and diagnostic explanations off the same truth.
+- **Alternatives considered**:
+  - New dedicated presenter family for active-state visibility: rejected unless the existing presenter path proves insufficient during implementation.
+  - Widget-local copy branches: rejected because they would increase semantic spread and regression risk.
+
+## Decision 3: Treat stale-active runs as still active for tenant progress visibility
+
+- **Decision**: Change tenant-local active-progress visibility to include freshness-elevated active runs rather than suppressing them via `healthyActive()`.
+- **Rationale**: `BulkOperationProgress` and `ActiveRuns::existForTenantId()` previously used `healthyActive()`, which caused stale queued/running work to disappear from the tenant progress overlay and stopped polling when only stale runs remained. That was the clearest concrete contradiction with the canonical monitoring surfaces.
+- **Alternatives considered**:
+  - Keep stale runs hidden in the progress overlay and rely on dashboard/list only: rejected because the spec explicitly covers tenant-local active-run cards and progress summaries.
+  - Add a separate stale-only overlay: rejected because it would create a second active-work surface family instead of fixing the existing one.
+
+## Decision 4: Preserve current surface roles and drill-through flow
+
+- **Decision**: Keep the current route and surface model: tenant dashboard and tenant progress remain secondary context, `/admin/operations` remains the primary triage list, and `/admin/operations/{run}` remains diagnostic-first.
+- **Rationale**: Existing links already converge through `OperationRunLinks`, and current pages/widgets match the constitution's decision-first model. The gap is the honesty of compact active-state messaging, not missing routes.
+- **Alternatives considered**:
+  - New operations hub or new tenant-local detail page: rejected as unnecessary workflow expansion.
+  - New notification channel for stale active work: rejected because the spec explicitly excludes new notification behavior.
+
+## Decision 5: Extend existing focused tests and invert stale-hidden assumptions where necessary
+
+- **Decision**: Update existing monitoring, Filament, and Ops UX tests rather than creating a new broad suite.
+- **Rationale**: The repository already has focused coverage for lifecycle presentation and tenant progress behavior. In particular, `BulkOperationProgressDbOnlyTest` and `ProgressWidgetFiltersTest` currently codify the stale-hidden behavior that this feature must deliberately replace.
+- **Alternatives considered**:
+  - Add a brand-new browser suite: rejected because feature tests already cover the underlying business truth and UI copy.
+  - Leave old progress-widget tests untouched and add parallel tests: rejected because the old assertions would preserve the wrong contract.
+
+## Decision 6: Keep “past expected lifecycle” and “likely stale” as density-specific labels over the same stale truth
+
+- **Decision**: Model compact “past expected lifecycle” phrasing and stronger “likely stale” diagnostic phrasing as different density outputs over the same `likely_stale` freshness truth rather than as separate persisted states.
+- **Rationale**: The spec allows same meaning, different density. The current code already points in that direction: `OperationUxPresenter::surfaceGuidance()` says the run is “past its lifecycle window,” while `OperationRunStatusBadge` can label the same run `Likely stale`.
+- **Alternatives considered**:
+  - Create two separate freshness states for “late” and “likely stale”: rejected because existing lifecycle truth has only one stale boundary and no additional behavioral consequence.
+  - Collapse all stale-active copy to a single label everywhere: rejected because compact surfaces and canonical detail need different density without changing meaning.
--- a/specs/233-stale-run-visibility/spec.md
+++ b/specs/233-stale-run-visibility/spec.md
@ -0,0 +1,252 @@
+# Feature Specification: Operation Run Active-State Visibility & Stale Escalation
+
+**Feature Branch**: `233-stale-run-visibility`  
+**Created**: 2026-04-23  
+**Status**: Draft  
+**Input**: User description: "Operation Run Active-State Visibility & Stale Escalation"
+
+## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
+
+- **Problem**: `OperationRun` lifecycle truth already exists, but compact operator surfaces still under-communicate when active work is past expectation or likely stuck.
+- **Today's failure**: A run can be visibly stale on the canonical monitoring detail yet still read like ordinary `Queued` or `Running` work on tenant cards, dashboard attention surfaces, or list rows. Operators then receive false reassurance until they drill into monitoring.
+- **User-visible improvement**: Active runs that are healthy, late, or likely stuck become visibly distinct across tenant and workspace surfaces, so operators can see unhealthy work in one scan without losing the canonical run detail as the diagnostic source of truth.
+- **Smallest enterprise-capable version**: Add one bounded active-state presentation contract derived from existing lifecycle, freshness, and reconciliation truth, then apply it consistently to tenant dashboard activity surfaces, tenant-local active-run cards, the workspace operations list, and the canonical run detail summary.
+- **Explicit non-goals**: No new `OperationRun` status values, no retry or cancel actions, no queue or worker redesign, no new notification channel, no full operations hub redesign, no cross-workspace fleet monitoring, and no parallel UI-only stale heuristic that bypasses existing lifecycle truth.
+- **Permanent complexity imported**: One bounded derived active-state category family over existing run truth, one shared cross-surface presentation contract, focused operator copy updates on existing monitoring surfaces, and regression coverage for fresh versus stale semantics across tenant and workspace entry points.
+- **Why now**: This is an active near-term operator-trust hardening item in the roadmap, and it becomes more urgent as more governance, evidence, and review workflows depend on `OperationRun`. Spec 232 now hardens link continuity into canonical monitoring, so the next high-leverage gap is what those linked surfaces actually communicate about unhealthy active work.
+- **Why not local**: Fixing one widget or one row badge would still leave contradictory lifecycle meaning across cards, list rows, dashboard attention, and run detail. The problem is cross-surface truth drift, not one local rendering bug.
+- **Approval class**: Core Enterprise
+- **Red flags triggered**: Cross-cutting interaction-class scope plus one new derived presentation category family. Defense: the feature derives entirely from existing lifecycle and freshness truth, avoids persistence or backend-state expansion, and stays bounded to existing admin-plane surfaces.
+- **Score**: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 2 | **Gesamt: 11/12**
+- **Decision**: approve
+
+## Spec Scope Fields *(mandatory)*
+
+- **Scope**: workspace, tenant, canonical-view
+- **Primary Routes**:
+  - `/admin/t/{tenant}` for tenant dashboard activity and attention surfaces
+  - Existing tenant-local active-run cards linked from tenant-scoped admin surfaces that already summarize active work
+  - `/admin/operations` as the canonical workspace monitoring list
+  - `/admin/operations/{run}` as the canonical run detail surface
+- **Data Ownership**: `operation_runs` remain the only source of lifecycle and freshness truth. Tenant-local cards, dashboard signals, and workspace monitoring rows remain derived read models over existing run records, lifecycle policy, and stale-detection truth. No new persisted visibility flag, summary mirror, or auxiliary active-run table is introduced.
+- **RBAC**: Admin-plane workspace membership remains required for `/admin/operations` and run detail visibility. Tenant-scoped surfaces remain constrained by current tenant entitlement. Non-members and out-of-scope tenant requests remain deny-as-not-found. This feature does not introduce new capability strings, new roles, or new mutation permissions.
+
+For canonical-view specs, the spec MUST define:
+
+- **Default filter behavior when tenant-context is active**: When operators enter `/admin/operations` from a tenant-scoped surface, the canonical monitoring list may preserve the active tenant as a default prefilter while retaining the same workspace-level route and clearing behavior used by existing canonical monitoring links.
+- **Explicit entitlement checks preventing cross-tenant leakage**: Tenant-local cards and dashboard signals may summarize only runs already visible to the current operator within that tenant. The canonical operations list and run detail continue to re-check workspace membership and tenant entitlement before rendering. No stale or past-lifecycle signal may reveal the existence of hidden runs or tenants.
+
+## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write `N/A - no shared interaction family touched`)*
+
+- **Cross-cutting feature?**: yes
+- **Interaction class(es)**: status messaging, dashboard signals/cards, monitoring list presentation, canonical run detail summary
+- **Systems touched**: tenant dashboard activity surfaces, tenant-local active-run cards, workspace monitoring list rows, canonical monitoring detail, and existing canonical drill-through links into `/admin/operations`
+- **Existing pattern(s) to extend**: current `OperationRun` lifecycle policies, freshness/stale detection, canonical monitoring pages, shared badge semantics, and existing tenant-to-monitoring drill-through patterns
+- **Shared contract / presenter / builder / renderer to reuse**: `OperationRunService` remains the sole owner of lifecycle transitions; `App\Support\OperationCatalog` remains the canonical operation label source; existing central badge rendering remains the status-like rendering path; existing canonical operations links remain the navigation path into `/admin/operations`
+- **Why the existing shared path is sufficient or insufficient**: Existing lifecycle, freshness, and reconciliation truth are sufficient and must remain authoritative. Existing compact-surface presentation is insufficient because it compresses unhealthy active work too aggressively and can contradict the canonical run detail.
+- **Allowed deviation and why**: Same meaning, different density is allowed. Tenant cards, dashboard signals, list rows, and run detail may vary in information density, but they may not disagree about whether active work is healthy, late, or likely stuck.
+- **Consistency impact**: Active-state language, status emphasis, badge meaning, next-step cues, and drill-through expectations must stay aligned across tenant dashboards, tenant cards, monitoring rows, and canonical detail.
+- **Review focus**: Reviewers must verify that no compact surface presents a run as ordinary active work when the canonical monitoring detail presents it as past expectation or likely stuck, and that no new page-local stale heuristic bypasses the shared lifecycle truth.
+
+## UI / Surface Guardrail Impact *(mandatory when operator-facing surfaces are changed; otherwise write `N/A`)*
+
+| Surface / Change | Operator-facing surface change? | Native vs Custom | Shared-Family Relevance | State Layers Touched | Exception Needed? | Low-Impact / `N/A` Note |
+|---|---|---|---|---|---|---|
+| Tenant dashboard activity and attention surfaces | yes | Native Filament dashboard widgets and shared summary primitives | Same tenant-home signal family as existing attention and activity summaries | summary, attention cues, drill-through links | no | Existing surfaces only; no new dashboard page |
+| Tenant-local active-run cards and progress summaries | yes | Native Filament widgets/cards and shared run primitives | Same tenant-scoped activity family as existing recent-run and progress hints | compact active-state presentation, drill-through links | no | Existing cards only; no new card family |
+| Workspace operations list / monitoring rows | yes | Native Filament table and shared run presentation primitives | Same canonical monitoring family as existing `/admin/operations` list | row-level active-state emphasis, filter continuity, list scanability | no | Existing registry surface only |
+| Canonical operation run detail summary | yes | Native Filament detail surface and shared run summary primitives | Same canonical monitoring detail family | top-level active-state explanation, diagnostics separation | no | Detail remains diagnostic-first, not a new page |
+
+## Decision-First Surface Role *(mandatory when operator-facing surfaces are changed)*
+
+| 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 |
+|---|---|---|---|---|---|---|---|
+| Tenant dashboard activity and attention surfaces | Secondary Context Surface | An operator lands on the tenant dashboard and decides whether current tenant activity needs immediate follow-up | Whether active work is healthy, needs attention, or likely stuck, plus one drill-through into monitoring | Full run history, raw run context, and extended diagnostics on the canonical monitoring surfaces | Secondary because the dashboard signals attention but should not replace the monitoring register | Follows tenant-home to monitoring workflow instead of creating a second workbench | Removes the need to open monitoring just to learn that active work is already stale or late |
+| Tenant-local active-run cards and progress summaries | Secondary Context Surface | An operator inspects one tenant-scoped active-work summary and decides whether to open monitoring now | Current run identity, active-state category, and whether the work is merely active or needs attention | Full lifecycle history, stale-cause detail, and related diagnostics on run detail | Secondary because the card summarizes active work inside a broader tenant workflow | Follows tenant-scoped operational follow-up without duplicating monitoring detail | Prevents misleading neutral `Queued` or `Running` summaries from hiding unhealthy work |
+| Workspace operations list / monitoring rows | Primary Decision Surface | A workspace operator scans the active operations register and decides which run needs inspection first | Whether active runs are normal, past expectation, or likely stuck, together with run identity and scope context | Full run diagnostics, raw context, and related artifacts on run detail | Primary because this is the canonical list where operators prioritize run follow-up | Follows monitoring and triage workflow instead of forcing row-by-row drill-in | Makes unhealthy active runs scanable without opening every row |
+| Canonical operation run detail summary | Tertiary Evidence / Diagnostics Surface | After choosing one run, the operator confirms what kind of active-state problem exists and what it means | Clear top-level explanation of active-state category, lifecycle expectation status, and why diagnostics matter | Raw payloads, stack traces, reconciliation context, and deep technical detail | Tertiary because the operator first decides to inspect the run elsewhere; this page then provides the authoritative diagnosis | Preserves the existing monitoring-detail workflow | Reduces back-and-forth between list rows and diagnostics to understand whether the run is merely active or likely stuck |
+
+## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
+
+| 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 |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| Tenant dashboard activity and attention surfaces | Monitoring / Queue / Workbench | Read-only Registry / Report Surface | Open the tenant-scoped monitoring slice or the highlighted run | Explicit drill-through CTA or linked run summary | forbidden | Dashboard CTAs remain limited to monitoring follow-up | none | `/admin/t/{tenant}` | `/admin/operations/{run}` | Tenant context, activity state, attention weighting | Operations / Operation | Whether tenant-visible active work is healthy, late, or likely stuck | Embedded summary drill-in only |
+| Tenant-local active-run cards and progress summaries | Monitoring / Queue / Workbench | Read-only Registry / Report Surface | Open the run detail or canonical monitoring list | Explicit linked run summary | forbidden | Card CTA stays secondary to the active-state summary | none | `/admin/t/{tenant}` | `/admin/operations/{run}` | Tenant context, active work scope, active-state emphasis | Active operations / Operation | Whether the highlighted active work is ordinary progress or already needs attention | Embedded compact summary; no new surface family |
+| Workspace operations list / monitoring rows | List / Table / Bulk | Read-only Registry / Report Surface | Open the run most likely to need follow-up | Full-row open to canonical run detail | required | Existing filters and list controls stay in table chrome, not row noise | none | `/admin/operations` | `/admin/operations/{run}` | Workspace scope, optional tenant prefilter, active-state emphasis | Operations / Operation | Which active runs are healthy versus problematic without opening every row | none |
+| Canonical operation run detail summary | Record / Detail / Edit | Detail-first Operational Surface | Inspect one run's active-state explanation and diagnostics | Canonical run detail page | n/a | Related links and secondary diagnostics stay below the top-level summary | Existing dangerous follow-up actions remain wherever already governed; none are added here | `/admin/operations` | `/admin/operations/{run}` | Workspace scope, tenant context when applicable, active-state explanation | Operation run | Why the run is healthy, late, or likely stuck before raw diagnostics appear | canonical evidence detail |
+
+## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
+
+| 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 |
+|---|---|---|---|---|---|---|---|---|---|---|
+| Tenant dashboard activity and attention surfaces | Tenant operator | Decide whether tenant-visible activity already needs monitoring follow-up | Summary drill-in | Is anything actively happening on this tenant that is already late or likely stuck? | Active-state category, tenant-visible run identity, and one drill-through path | Full run diagnostics and raw lifecycle context remain in monitoring | execution lifecycle, freshness, attention state | none | Open monitoring or run detail | none |
+| Tenant-local active-run cards and progress summaries | Tenant operator | Decide whether the highlighted active run is still ordinary progress | Compact run summary | Is this active work still healthy, or does it already need attention? | Run identity, active-state category, elapsed-state emphasis | Deep diagnostics, raw context, and reconciliation detail remain on run detail | execution lifecycle, freshness, active-state interpretation | none | Open run detail | none |
+| Workspace operations list / monitoring rows | Workspace operator | Prioritize which active run deserves inspection first | Read-only monitoring registry | Which active runs are normal, and which are already late or likely stuck? | Run identity, scope, high-level lifecycle, and active-state emphasis | Raw payloads and detailed run history remain on run detail | lifecycle, freshness, problem emphasis | none | Open run detail, apply filters | none |
+| Canonical operation run detail summary | Workspace operator | Confirm the meaning of the active-state issue before deeper diagnosis | Diagnostic detail surface | Why does this active run read as late or likely stuck, and what should I inspect next? | Top-level active-state explanation, scope, and summary guidance | Raw payloads, stack traces, and extended technical details | lifecycle, freshness, diagnostic readiness | none | Open related context or diagnostics | none |
+
+## Proportionality Review *(mandatory when structural complexity is introduced)*
+
+- **New source of truth?**: no
+- **New persisted entity/table/artifact?**: no
+- **New abstraction?**: yes — one bounded derived active-state presentation contract expressed through existing presenter and active-run helpers rather than a standalone framework
+- **New enum/state/reason family?**: yes — one derived operator-facing category family for `active / normal`, `active / past expectation`, `stale / likely stuck`, and `terminal / no longer active`, composed from existing freshness and problem-class truth
+- **New cross-domain UI framework/taxonomy?**: no
+- **Current operator problem**: Operators cannot trust compact active-work surfaces because they can understate or hide the difference between healthy progress and likely stuck work.
+- **Existing structure is insufficient because**: Existing lifecycle truth lives in monitoring detail and backend services, but compact surfaces can still render active work as neutral `Queued` or `Running` states without exposing that the lifecycle expectation has already been exceeded.
+- **Narrowest correct implementation**: Keep all backend lifecycle truth as-is, add one derived presentation contract, and retrofit only the existing tenant/dashboard/monitoring surfaces that already summarize active work.
+- **Ownership cost**: Ongoing maintenance for one small presentation category family, cross-surface wording alignment, and regression coverage for fresh versus stale semantics.
+- **Alternative intentionally rejected**: Introducing new `OperationRun` statuses or page-local stale heuristics was rejected because both would either widen persistence and lifecycle scope or create contradictory truth outside the existing lifecycle policy.
+- **Release truth**: Current-release truth. This feature makes existing active-run observability honest now rather than preparing a future intervention framework.
+
+### Compatibility posture
+
+This feature assumes a pre-production environment.
+
+Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.
+
+Canonical replacement is preferred over preservation.
+
+## Testing / Lane / Runtime Impact *(mandatory for runtime behavior changes)*
+
+- **Test purpose / classification**: Feature
+- **Validation lane(s)**: fast-feedback, confidence
+- **Why this classification and these lanes are sufficient**: The proof burden is operator-visible active-state semantics across existing admin surfaces. Focused feature coverage is sufficient to prove fresh versus stale differentiation, tenant/workspace visibility boundaries, cross-surface consistency, and no false escalation without needing browser or heavy-governance lanes.
+- **New or expanded test families**: Extend `tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `tests/Feature/OpsUx/ProgressWidgetFiltersTest.php`, `tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`, `tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `tests/Feature/Filament/DashboardKpisWidgetTest.php`, `tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php`, `tests/Feature/Monitoring/MonitoringOperationsTest.php`, `tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`, `tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php`, `tests/Feature/Operations/TenantlessOperationRunViewerTest.php`, `tests/Feature/RunAuthorizationTenantIsolationTest.php`, and `tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`.
+- **Fixture / helper cost impact**: Moderate. Tests need representative `OperationRun` fixtures for healthy queued/running work, past-expectation work, likely stuck work, terminal transitions during navigation, mixed tenant visibility, and hidden-tenant/non-member isolation boundaries.
+- **Heavy-family visibility / justification**: none
+- **Special surface test profile**: monitoring-state-page
+- **Standard-native relief or required special coverage**: Ordinary feature coverage is sufficient, plus explicit proof that healthy active runs do not escalate falsely and that stale semantics remain consistent after drill-through from tenant surfaces into canonical monitoring.
+- **Reviewer handoff**: Reviewers must confirm that the same active-state meaning appears on tenant cards, dashboard attention, operations rows, and canonical run detail; that no new backend status values or UI-only stale heuristics are introduced; and that hidden or out-of-scope runs do not influence visible summaries.
+- **Budget / baseline / trend impact**: none
+- **Escalation needed**: none
+- **Active feature PR close-out entry**: Guardrail
+- **Planned validation commands**:
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php tests/Feature/OpsUx/ProgressWidgetFiltersTest.php tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php tests/Feature/Filament/DashboardKpisWidgetTest.php tests/Feature/Filament/NeedsAttentionWidgetTest.php tests/Feature/Filament/WorkspaceOverviewOperationsTest.php tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php tests/Feature/Monitoring/MonitoringOperationsTest.php tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php tests/Feature/Operations/TenantlessOperationRunViewerTest.php`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/RunAuthorizationTenantIsolationTest.php tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`
+  - `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - See unhealthy tenant activity without opening monitoring first (Priority: P1)
+
+As a tenant operator, I want tenant-scoped activity surfaces to distinguish healthy active work from late or likely stuck work, so that I can notice unhealthy runs before manually opening the monitoring register.
+
+**Why this priority**: Tenant cards and dashboard attention surfaces are the highest-frequency compact summaries for active work. If they remain misleading, the rest of the monitoring model is harder to trust.
+
+**Independent Test**: Can be fully tested by seeding healthy and stale tenant-visible active runs, rendering the tenant dashboard and active-run cards, and verifying that only late or likely stuck work escalates while healthy work stays calm.
+
+**Acceptance Scenarios**:
+
+1. **Given** a tenant-visible run is queued or running within its expected lifecycle, **When** the tenant dashboard or active-run card renders, **Then** the run appears as healthy active work and does not escalate as stale or likely stuck.
+2. **Given** a tenant-visible run is queued or running well past its expected lifecycle, **When** the same compact surfaces render, **Then** the run is visibly and linguistically distinct from healthy active work.
+3. **Given** a run becomes terminal, **When** the tenant-scoped compact surfaces refresh, **Then** the run no longer appears as active work.
+
+---
+
+### User Story 2 - Scan problematic active runs in the canonical operations list (Priority: P1)
+
+As a workspace operator, I want the canonical operations list to make problematic active runs obvious at row level, so that I can prioritize follow-up without opening each run.
+
+**Why this priority**: The canonical operations list is the primary monitoring surface for run triage. If unhealthy active runs are not scanable there, operators lose the central prioritization surface.
+
+**Independent Test**: Can be fully tested by seeding a mix of fresh and stale active runs across visible tenants and verifying that the operations list highlights problematic rows without falsely escalating healthy rows.
+
+**Acceptance Scenarios**:
+
+1. **Given** the operations list contains a mix of healthy active runs and likely stuck runs, **When** the workspace operator opens `/admin/operations`, **Then** the problematic active runs are immediately distinguishable at row level.
+2. **Given** the operator enters `/admin/operations` from a tenant-scoped surface, **When** the canonical list opens with tenant context preserved, **Then** the same active-state semantics remain visible within that filtered monitoring slice.
+3. **Given** an active run is fresh, **When** the operations list renders, **Then** it does not inherit the same escalation treatment as a late or likely stuck run.
+
+---
+
+### User Story 3 - Keep compact surfaces aligned with canonical run detail (Priority: P2)
+
+As a workspace operator, I want canonical run detail to confirm the same active-state meaning that I saw on tenant and list surfaces, so that I can trust compact summaries without losing diagnostic depth.
+
+**Why this priority**: The canonical detail page is the authoritative diagnostic surface. It must confirm, not contradict, the meaning shown elsewhere.
+
+**Independent Test**: Can be fully tested by navigating from tenant-scoped or list surfaces into run detail for both healthy and stale runs and verifying that the same active-state meaning holds after drill-through.
+
+**Acceptance Scenarios**:
+
+1. **Given** a run reads as likely stuck on a tenant surface or list row, **When** the operator opens canonical run detail, **Then** the detail summary confirms that the run is past expectation or likely stuck before exposing raw diagnostics.
+2. **Given** a run changes from active to terminal while the operator navigates between surfaces, **When** the compact surface and run detail refresh, **Then** neither surface continues to present the run as active.
+3. **Given** a scheduled or initiator-null run becomes late, **When** the operator inspects it through monitoring, **Then** the active-state semantics remain truthful without implying a new notification channel or mutation behavior.
+
+### Edge Cases
+
+- A run may move from healthy to late or likely stuck between two page loads; the presentation contract must tolerate state changes without requiring a manual semantic reset.
+- An operator may open the canonical run detail from a tenant-filtered monitoring slice; the run detail must remain authoritative while preserving scope context where already allowed.
+- Multiple active runs may exist for one tenant; compact surfaces must not imply that all tenant activity is stale because one run is problematic.
+- A run may become terminal while the operator is on a tenant dashboard or monitoring list; compact surfaces and run detail must converge on non-active presentation after refresh.
+- Initiator-null scheduled work may become stale without producing a terminal DB notification; monitoring semantics must remain truthful without inventing a new scheduled-run notification contract.
+
+## Requirements *(mandatory)*
+
+**Constitution alignment (required):** This feature adds no Microsoft Graph calls, no new write flow, and no new `OperationRun`. It changes only how existing run lifecycle and freshness truth are interpreted on admin-plane operator surfaces.
+
+**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The feature introduces one derived active-state presentation contract because current-release operator trust requires it now. A narrower local patch is insufficient because the same truth must remain aligned across tenant cards, dashboard signals, list rows, and canonical detail. The addition stays derived, not persisted.
+
+**Constitution alignment (XCUT-001):** This feature is cross-cutting across status messaging and dashboard/monitoring surfaces. It reuses the existing lifecycle, freshness, badge, and canonical monitoring paths, and it allows only one bounded deviation: same meaning, different density.
+
+**Constitution alignment (TEST-GOV-001):** Focused feature tests on tenant dashboard surfaces, tenant active-run cards, monitoring rows, and run detail are the narrowest sufficient proof. No browser or heavy-governance lane is required.
+
+**Constitution alignment (OPS-UX):** Existing Ops-UX 3-surface feedback remains unchanged. Toasts stay intent-only, progress surfaces remain the existing active-work surfaces, and terminal DB notifications stay unchanged. `OperationRun.status` and `OperationRun.outcome` transitions remain service-owned exclusively through `OperationRunService`. This feature must not introduce new `summary_counts` keys or any new scheduled-run notification semantics.
+
+**Constitution alignment (RBAC-UX):** The feature operates only in the admin plane (`/admin` and `/admin/t/{tenant}/...`). Tenant-scoped compact surfaces remain tenant-entitlement safe, while canonical monitoring routes continue to enforce workspace membership and tenant entitlement on tenant-owned runs. No cross-plane visibility or raw capability checks may be added.
+
+**Constitution alignment (BADGE-001):** Any changed status-like emphasis must continue to use centralized badge or status rendering. No page-local mapping from stale-detection inputs to color or label semantics is allowed.
+
+**Constitution alignment (UI-FIL-001):** Touched surfaces must use native Filament widgets, tables, summaries, and existing shared status primitives. No custom local status markup or page-local color systems may replace shared run presentation.
+
+**Constitution alignment (UI-NAMING-001):** Operator-facing language must use one canonical vocabulary for active-state meaning: healthy active work, past expected lifecycle, likely stuck, and no longer active. Implementation-first phrases or raw stale heuristics must not become primary labels.
+
+**Constitution alignment (DECIDE-001):** The operations list remains the primary decision surface for run triage. Tenant dashboard surfaces remain secondary context surfaces, and canonical run detail remains the diagnostic surface. This feature must make those roles calmer and clearer, not create a new workbench.
+
+**Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001):** No new route, no new inspect model, and no new destructive action family are introduced. The canonical inspect model remains the run detail page. Compact surfaces may add emphasis and drill-through clarity only.
+
+**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** Direct mapping from `queued` and `running` alone is insufficient because lifecycle expectation and freshness change the operator meaning of active work. The feature adds one bounded derived interpretation layer and must prove business consequences across surfaces rather than only unit-testing one presenter.
+
+### Functional Requirements
+
+- **FR-001**: The system MUST derive one active-state presentation category for visible runs using existing lifecycle, freshness, and reconciliation truth.
+- **FR-002**: The derived presentation contract MUST distinguish at least `active / normal`, `active / past expected lifecycle`, `stale / likely stuck`, and `terminal / no longer active`.
+- **FR-003**: The feature MUST NOT introduce new `OperationRun.status` or `OperationRun.outcome` values to express those categories.
+- **FR-004**: Tenant dashboard activity and attention surfaces MUST visibly and linguistically distinguish healthy active work from active work that is late or likely stuck.
+- **FR-005**: Tenant-local active-run cards and progress summaries MUST surface the same active-state meaning as the tenant dashboard attention layer for the same run.
+- **FR-006**: The workspace operations list MUST make late or likely stuck active runs distinguishable at row level without requiring drill-in.
+- **FR-007**: Canonical run detail MUST explain the active-state category before exposing raw diagnostics, and that explanation MUST remain consistent with the compact surfaces that linked into it.
+- **FR-008**: A run that is presented as late or likely stuck on canonical run detail MUST NOT appear as ordinary healthy active work on any covered tenant or monitoring surface.
+- **FR-009**: Healthy active runs MUST NOT inherit stale or likely-stuck emphasis solely because they are `queued` or `running`.
+- **FR-010**: When a run becomes terminal, covered compact surfaces MUST stop presenting it as active work on the next refresh cycle.
+- **FR-011**: Existing lifecycle, freshness, and reconciliation logic MUST remain the source of truth; covered surfaces MUST NOT implement separate page-local stale heuristics.
+- **FR-012**: When operators enter canonical monitoring from tenant context, existing tenant-prefilter continuity MAY be preserved, but the active-state semantics MUST remain identical to the unfiltered canonical list.
+- **FR-013**: Covered surfaces MUST remain tenant-safe and workspace-safe; hidden runs or hidden tenants MUST NOT influence visible active-state summaries.
+- **FR-014**: Scheduled or initiator-null runs MUST use the same active-state presentation rules as user-initiated runs where lifecycle and freshness truth are comparable.
+- **FR-015**: This feature MUST NOT add retry, cancel, force-fail, reconcile-now, or other intervention actions to any covered surface.
+- **FR-016**: Existing Ops-UX toast, progress-surface, and terminal-notification behavior MUST remain unchanged.
+
+## UI Action Matrix *(mandatory when Filament is changed)*
+
+| Surface | Location | Header Actions | Inspect Affordance (List/Table) | Row Actions (max 2 visible) | Bulk Actions (grouped) | Empty-State CTA(s) | View Header Actions | Create/Edit Save+Cancel | Audit log? | Notes / Exemptions |
+|---|---|---|---|---|---|---|---|---|---|---|
+| Tenant dashboard activity and attention surfaces | `/admin/t/{tenant}` | none added by this feature | Explicit dashboard CTA or linked run summary | none | none | none | n/a | n/a | No new mutation audit because the surface remains read-only | Action Surface Contract satisfied. Dashboard remains a signal surface, not a second workbench. UI-FIL-001 satisfied through native widgets and shared status primitives. |
+| Tenant-local active-run cards and progress summaries | Tenant-scoped admin surfaces that already summarize active work | none added by this feature | Explicit linked run summary | none | none | none | n/a | n/a | No new mutation audit because the surface remains read-only | One primary inspect model remains the run detail. No redundant View action is added. |
+| Workspace operations list | `/admin/operations` | Existing filters only; none added by this feature | Full-row open to run detail | none added by this feature | none | Existing list empty state unchanged | n/a | n/a | No new mutation audit because the surface remains read-only | Action Surface Contract satisfied. Row click stays the only primary inspect model. |
+| Canonical operation run detail summary | `/admin/operations/{run}` | Existing safe/context actions unchanged | n/a | n/a | n/a | n/a | Existing detail/header actions unchanged | n/a | No new mutation audit because the feature changes summary semantics only | No exemption needed. This feature changes top-level explanation, not the action layout. |
+
+### Key Entities *(include if feature involves data)*
+
+- **Active-state presentation category**: A derived operator-facing category that explains whether visible active work is healthy, late, likely stuck, or no longer active.
+- **Lifecycle expectation window**: The existing timing and policy truth that determines when active work has exceeded its normal expected lifecycle.
+- **Stale active run**: An existing `OperationRun` whose lifecycle and freshness truth indicate that active work is likely stuck rather than merely still in progress.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: In acceptance review, an operator can distinguish healthy tenant-visible active work from likely stuck work in one scan of the covered tenant surfaces.
+- **SC-002**: 100% of covered fresh-versus-stale automated scenarios show the correct active-state category on the tenant dashboard, tenant active-run cards, and workspace operations list.
+- **SC-003**: 100% of covered drill-through scenarios preserve the same active-state meaning between compact surfaces and canonical run detail.
+- **SC-004**: 100% of covered healthy-active scenarios avoid false escalation when lifecycle expectation has not yet been exceeded.
--- a/specs/233-stale-run-visibility/tasks.md
+++ b/specs/233-stale-run-visibility/tasks.md
@ -0,0 +1,228 @@
+# Tasks: Operation Run Active-State Visibility & Stale Escalation
+
+**Input**: Design documents from `/specs/233-stale-run-visibility/`  
+**Prerequisites**: `plan.md` (required), `spec.md` (required for user stories), `research.md`, `data-model.md`, `contracts/operation-run-active-state-visibility.logical.openapi.yaml`, `quickstart.md`
+
+**Tests**: Required. This feature changes runtime behavior across tenant progress surfaces, tenant dashboard summaries, workspace summaries, and canonical monitoring detail, so Pest coverage must be added or updated in `apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`, `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/Filament/DashboardKpisWidgetTest.php`, `apps/platform/tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `apps/platform/tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php`, `apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`, `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php`, `apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php`, `apps/platform/tests/Feature/RunAuthorizationTenantIsolationTest.php`, and `apps/platform/tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`.
+**Operations**: No new `OperationRun` is introduced. Existing lifecycle truth, reconciliation, toast/progress/terminal notification behavior, and service-owned status/outcome transitions must remain unchanged.
+**RBAC**: The feature stays in the admin plane (`/admin` and `/admin/t/{tenant}/...`). It must preserve current tenant-entitlement and workspace-entitlement behavior, including non-member `404`, in-scope capability denial semantics, and tenant-safe summaries with no cross-tenant leakage.
+**UI / Surface Guardrails**: The changed surfaces are native Filament widgets/resources/pages plus one existing Livewire progress component. The feature keeps `monitoring-state-page` coverage for canonical monitoring surfaces, uses `standard-native-filament` relief elsewhere, and remains `review-mandatory` because multiple existing operator surfaces must converge on the same truth.
+**Filament UI Action Surfaces**: `RecentOperationsSummary`, tenant dashboard widgets, `OperationRunResource`, and `TenantlessOperationRunViewer` keep their existing inspect/open model. No new header, row, bulk, retry, cancel, or destructive actions are introduced.
+**Badges**: Status-like semantics must stay on `BadgeCatalog` / `BadgeRenderer` and existing shared `OperationRun` presenter paths. No page-local stale badge mapping is allowed.
+
+**Organization**: Tasks are grouped by user story so each slice is independently implementable and testable. Recommended delivery order is `US1 -> US2 -> US3` because tenant-surface honesty is the most urgent gap, canonical list scanability builds on the same truth, and detail-surface confirmation should close last against the final compact-surface semantics.
+
+## Test Governance Checklist
+
+- [X] Lane assignment is named and is the narrowest sufficient proof for the changed behavior.
+- [X] New or changed tests stay in the smallest honest family, and any heavy-governance or browser addition is explicit.
+- [X] Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is isolated or documented.
+- [X] Planned validation commands cover the change without pulling in unrelated lane cost.
+- [X] The declared surface test profile or `standard-native-filament` relief is explicit.
+- [X] Any material budget, baseline, trend, or escalation note is recorded in the active spec or PR.
+
+## Phase 1: Setup (Shared Surface Scaffolding)
+
+**Purpose**: Prepare the focused regression surfaces that will prove fresh-versus-stale semantics before runtime files are edited.
+
+- [X] T001 [P] Extend stale-versus-fresh progress-overlay scaffolding in `apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php`, and `apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`
+- [X] T002 [P] Extend tenant dashboard and tenant-summary semantics scaffolding in `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/Filament/DashboardKpisWidgetTest.php`, `apps/platform/tests/Feature/Filament/NeedsAttentionWidgetTest.php`, and `apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`
+- [X] T003 [P] Extend workspace monitoring and visibility-safety scaffolding in `apps/platform/tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php`, `apps/platform/tests/Feature/RunAuthorizationTenantIsolationTest.php`, and `apps/platform/tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`
+- [X] T004 [P] Extend canonical detail and drill-through continuity scaffolding in `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php` and `apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php`
+
+**Checkpoint**: Focused tenant, workspace, and canonical test surfaces are ready to fail on stale-hidden regressions before implementation begins.
+
+---
+
+## Phase 2: Foundational (Blocking Truth And Shared Contract)
+
+**Purpose**: Stabilize the one freshness-to-surface contract before any individual surface is changed.
+
+**Critical**: No user story work should begin until this phase is complete.
+
+- [X] T005 Freeze the canonical stale/fresh truth inputs and any needed thin derived adapter boundaries in `apps/platform/app/Models/OperationRun.php`, `apps/platform/app/Support/Operations/OperationRunFreshnessState.php`, `apps/platform/app/Support/OpsUx/OperationUxPresenter.php`, and `apps/platform/app/Support/OpsUx/ActiveRuns.php`
+- [X] T006 [P] Refresh the feature contract artifacts in `specs/233-stale-run-visibility/contracts/operation-run-active-state-visibility.logical.openapi.yaml` and `specs/233-stale-run-visibility/quickstart.md` so implementation and review language stay aligned with the finalized shared truth path
+
+**Checkpoint**: The feature has one agreed freshness/problem-class/presenter contract and the docs match that contract before surface-by-surface retrofits begin.
+
+---
+
+## Phase 3: User Story 1 - See unhealthy tenant activity without opening monitoring first (Priority: P1) 🎯 MVP
+
+**Goal**: Tenant-scoped dashboard and progress surfaces distinguish healthy active work from late or likely stuck work without inventing a second stale heuristic.
+
+**Independent Test**: Seed fresh and stale tenant-visible queued/running runs, render tenant dashboard and progress surfaces, and verify that healthy work stays calm while stale-active work remains visible and elevated until the run becomes terminal.
+
+### Tests for User Story 1
+
+- [X] T007 [P] [US1] Add fresh-versus-stale tenant progress assertions, including polling continuity while only stale-active runs remain, in `apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php`, and `apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`
+- [X] T008 [P] [US1] Add tenant summary and tenant dashboard copy/assertion coverage for calm-versus-elevated active work in `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/Filament/DashboardKpisWidgetTest.php`, `apps/platform/tests/Feature/Filament/NeedsAttentionWidgetTest.php`, and `apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`
+
+### Implementation for User Story 1
+
+- [X] T009 [P] [US1] Update stale-active visibility and polling semantics in `apps/platform/app/Support/OpsUx/ActiveRuns.php`, `apps/platform/app/Livewire/BulkOperationProgress.php`, `apps/platform/resources/views/livewire/bulk-operation-progress.blade.php`, and `apps/platform/resources/views/livewire/bulk-operation-progress-wrapper.blade.php`
+- [X] T010 [P] [US1] Align tenant activity summaries with the shared presenter/badge truth in `apps/platform/app/Filament/Widgets/Tenant/RecentOperationsSummary.php`, `apps/platform/resources/views/filament/widgets/tenant/recent-operations-summary.blade.php`, `apps/platform/app/Filament/Widgets/Dashboard/DashboardKpis.php`, and `apps/platform/app/Filament/Widgets/Dashboard/NeedsAttention.php`
+- [X] T011 [US1] Tighten tenant-surface copy and density handling in `apps/platform/app/Support/OpsUx/OperationUxPresenter.php` and any touched shared badge mappings in `apps/platform/app/Support/Badges/Domains/OperationRunStatusBadge.php` without adding a second semantic framework
+- [X] T012 [US1] Run the US1 tenant-surface verification flow from `specs/233-stale-run-visibility/quickstart.md`
+
+**Checkpoint**: User Story 1 is independently functional and tenant operators can see unhealthy active work before opening canonical monitoring.
+
+---
+
+## Phase 4: User Story 2 - Scan problematic active runs in the canonical operations list (Priority: P1)
+
+**Goal**: Workspace monitoring rows and workspace recent-operation summaries make problematic active runs obvious at scan time without falsely escalating fresh work.
+
+**Independent Test**: Seed a mixed slice of fresh and stale active runs across visible tenants, open workspace summaries and `/admin/operations`, and verify that stale-active rows are immediately distinguishable while fresh active rows remain calm.
+
+### Tests for User Story 2
+
+- [X] T013 [P] [US2] Add workspace summary, recency, and visibility-safety assertions for fresh-versus-stale active work in `apps/platform/tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php`, `apps/platform/tests/Feature/RunAuthorizationTenantIsolationTest.php`, and `apps/platform/tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`
+- [X] T014 [P] [US2] Add canonical operations-list assertions for row-level stale-active scanability and tenant-prefilter continuity in `apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php` and `apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`
+
+### Implementation for User Story 2
+
+- [X] T015 [P] [US2] Align workspace summary payloads and view rendering in `apps/platform/app/Support/Workspaces/WorkspaceOverviewBuilder.php`, `apps/platform/app/Filament/Widgets/Workspace/WorkspaceRecentOperations.php`, and `apps/platform/resources/views/filament/widgets/workspace/workspace-recent-operations.blade.php`
+- [X] T016 [P] [US2] Tighten canonical list scanability and stale-active row semantics in `apps/platform/app/Filament/Widgets/Dashboard/RecentOperations.php` and `apps/platform/app/Filament/Resources/OperationRunResource.php`
+- [X] T017 [US2] Reconcile any remaining stale-active badge/copy differences across workspace and canonical list surfaces in `apps/platform/app/Support/OpsUx/OperationUxPresenter.php` and `apps/platform/app/Support/Badges/Domains/OperationRunStatusBadge.php`
+- [X] T018 [US2] Run the US2 workspace-list verification flow from `specs/233-stale-run-visibility/quickstart.md`
+
+**Checkpoint**: User Story 2 is independently functional and workspace operators can scan the canonical monitoring list for unhealthy active work without opening every row.
+
+---
+
+## Phase 5: User Story 3 - Keep compact surfaces aligned with canonical run detail (Priority: P2)
+
+**Goal**: Canonical run detail confirms the same active-state meaning that compact tenant and workspace surfaces already communicate, including terminal transitions and stale lineage.
+
+**Independent Test**: Navigate from compact tenant/workspace surfaces into canonical run detail for fresh, stale, and reconciled-terminal runs, then verify that the top summary preserves the same meaning before deeper diagnostics render.
+
+### Tests for User Story 3
+
+- [X] T019 [P] [US3] Add canonical detail summary and stale-lineage assertions in `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php` and `apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php`
+- [X] T020 [P] [US3] Add refresh-boundary and terminal-transition consistency assertions spanning compact-to-detail flows in `apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php` and `apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php`
+
+### Implementation for User Story 3
+
+- [X] T021 [P] [US3] Align canonical detail summary copy and decision-zone truth in `apps/platform/app/Filament/Resources/OperationRunResource.php` and `apps/platform/app/Support/OpsUx/OperationUxPresenter.php`
+- [X] T022 [US3] Align tenantless canonical viewer summary behavior and drill-through continuity in `apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php` and any touched related monitoring helpers under `apps/platform/app/Support/OperationRunLinks.php`
+- [X] T023 [US3] Run the US3 compact-to-detail verification flow from `specs/233-stale-run-visibility/quickstart.md`
+
+**Checkpoint**: User Story 3 is independently functional and canonical run detail confirms, rather than contradicts, the compact active-state meaning.
+
+---
+
+## Phase 6: Polish & Cross-Cutting Concerns
+
+**Purpose**: Finalize documentation, formatting, and focused validation for the whole feature without widening scope.
+
+- [X] T024 [P] Refresh `specs/233-stale-run-visibility/plan.md`, `specs/233-stale-run-visibility/research.md`, and `specs/233-stale-run-visibility/data-model.md` if implementation proves a thinner shared contract or adjusts touched file scope
+- [X] T025 Run formatting on touched application and test files with `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
+- [X] T026 Run the focused Pest suite from `specs/233-stale-run-visibility/quickstart.md` against `apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php`, `apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php`, `apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php`, `apps/platform/tests/Feature/Filament/DashboardKpisWidgetTest.php`, `apps/platform/tests/Feature/Filament/NeedsAttentionWidgetTest.php`, `apps/platform/tests/Feature/Filament/WorkspaceOverviewOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php`, `apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php`, `apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`, `apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php`, `apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php`, `apps/platform/tests/Feature/RunAuthorizationTenantIsolationTest.php`, and `apps/platform/tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php`
+- [X] T027 Record the finalized affected surfaces, any retained density-specific copy decisions, and the `document-in-feature` test-governance disposition in `specs/233-stale-run-visibility/plan.md`
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Setup (Phase 1)**: No dependencies; can start immediately.
+- **Foundational (Phase 2)**: Depends on Setup completion and blocks all user story work.
+- **User Story 1 (Phase 3)**: Depends on Foundational completion and is the recommended first implementation increment.
+- **User Story 2 (Phase 4)**: Depends on Foundational completion and can begin after the shared truth contract is stable.
+- **User Story 3 (Phase 5)**: Depends on User Stories 1 and 2 because canonical detail should be aligned against the final compact-surface semantics.
+- **Polish (Phase 6)**: Depends on all desired user stories being complete.
+
+### User Story Dependencies
+
+- **US1 (P1)**: Starts immediately after Foundational and delivers the highest-value tenant-surface honesty fix.
+- **US2 (P1)**: Can begin after Foundational, but is easiest to complete after US1 settles the compact stale-active vocabulary.
+- **US3 (P2)**: Starts after US1 and US2 stabilize because canonical detail should confirm the final compact-surface contract, not compete with an in-progress one.
+
+### Within Each User Story
+
+- Story tests should be written and fail before the corresponding implementation tasks are considered complete.
+- Shared files such as `apps/platform/app/Support/OpsUx/OperationUxPresenter.php`, `apps/platform/app/Support/OpsUx/ActiveRuns.php`, and `apps/platform/app/Filament/Resources/OperationRunResource.php` should be edited sequentially even when surrounding tasks are otherwise parallelizable.
+- Each story's verification task should complete before moving to the next priority slice when working sequentially.
+
+### Parallel Opportunities
+
+- **Setup**: `T001`, `T002`, `T003`, and `T004` can run in parallel.
+- **Foundational**: `T006` can run in parallel with the tail end of `T005` once the shared contract is clear.
+- **US1 tests**: `T007` and `T008` can run in parallel.
+- **US1 implementation**: `T009` and `T010` can run in parallel; `T011` should follow once the touched surface outputs are visible.
+- **US2 tests**: `T013` and `T014` can run in parallel.
+- **US2 implementation**: `T015` and `T016` can run in parallel; `T017` should follow once both summary and canonical list semantics are visible.
+- **US3 tests**: `T019` and `T020` can run in parallel.
+- **Polish**: `T024` can run in parallel with `T025` after runtime implementation is stable.
+
+---
+
+## Parallel Example: User Story 1
+
+```bash
+# Run tenant-surface test work in parallel:
+T007 apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php, apps/platform/tests/Feature/OpsUx/ProgressWidgetFiltersTest.php, apps/platform/tests/Feature/OpsUx/ProgressWidgetOverflowTest.php
+T008 apps/platform/tests/Feature/Filament/RecentOperationsSummaryWidgetTest.php, apps/platform/tests/Feature/Filament/DashboardKpisWidgetTest.php, apps/platform/tests/Feature/Filament/NeedsAttentionWidgetTest.php, apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php
+
+# Then split the non-overlapping implementation work:
+T009 apps/platform/app/Support/OpsUx/ActiveRuns.php, apps/platform/app/Livewire/BulkOperationProgress.php, apps/platform/resources/views/livewire/bulk-operation-progress.blade.php, apps/platform/resources/views/livewire/bulk-operation-progress-wrapper.blade.php
+T010 apps/platform/app/Filament/Widgets/Tenant/RecentOperationsSummary.php, apps/platform/resources/views/filament/widgets/tenant/recent-operations-summary.blade.php, apps/platform/app/Filament/Widgets/Dashboard/DashboardKpis.php, apps/platform/app/Filament/Widgets/Dashboard/NeedsAttention.php
+```
+
+---
+
+## Parallel Example: User Story 2
+
+```bash
+# Run workspace-summary, visibility-safety, and canonical-list assertions in parallel:
+T013 apps/platform/tests/Feature/Filament/WorkspaceOverviewOperationsTest.php, apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php, apps/platform/tests/Feature/RunAuthorizationTenantIsolationTest.php, and apps/platform/tests/Feature/OpsUx/NonLeakageWorkspaceOperationsTest.php
+T014 apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php and apps/platform/tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php
+```
+
+---
+
+## Parallel Example: User Story 3
+
+```bash
+# Run canonical-detail and transition-consistency assertions in parallel:
+T019 apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php and apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php
+T020 apps/platform/tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php and apps/platform/tests/Feature/Monitoring/MonitoringOperationsTest.php
+```
+
+---
+
+## Implementation Strategy
+
+### First Implementation Increment (User Story 1 Only)
+
+1. Complete Phase 1: Setup.
+2. Complete Phase 2: Foundational.
+3. Complete Phase 3: User Story 1.
+4. Validate the feature with `T012` before widening the slice.
+
+### Incremental Delivery
+
+1. Stabilize the shared freshness/problem-class contract and docs.
+2. Ship US1 to fix the tenant-surface blind spot and stale-hidden progress behavior.
+3. Ship US2 to make workspace summaries and the canonical list scanable.
+4. Ship US3 to ensure canonical detail confirms the same meaning after drill-through.
+5. Finish with formatting, focused tests, and close-out notes.
+
+### Parallel Team Strategy
+
+With multiple developers:
+
+1. One contributor can own Ops UX progress visibility while another extends tenant dashboard/widget assertions.
+2. After Phase 2, one contributor can update workspace summary builders while another adjusts canonical list/detail semantics.
+3. Keep `OperationUxPresenter.php`, `ActiveRuns.php`, and `OperationRunResource.php` serialized because they anchor the shared truth and surface contract.
+
+---
+
+## Notes
+
+- `[P]` marks tasks that can run in parallel once prerequisites are satisfied and touched files do not overlap.
+- `[US1]`, `[US2]`, and `[US3]` map directly to the feature specification user stories.
+- The first working increment is Phase 1 through Phase 3, but the feature-complete approved scope remains Phase 1 through Phase 5 because canonical list and detail alignment are part of the accepted problem statement.
+- All tasks above use exact repository paths and keep the work bounded to the existing admin-plane monitoring and progress surfaces.