Implements platform feature branch `358-operationrun-queue-truth-foundation`. Target branch: `platform-dev`. Follow-up integration path after merge: `platform-dev` -> `dev`. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #429
12 KiB
Implementation Plan: OperationRun Queue Truth Foundation
Branch: 358-operationrun-queue-truth-foundation | Date: 2026-06-06 | Spec: specs/358-operationrun-queue-truth-foundation/spec.md
Input: Feature specification from specs/358-operationrun-queue-truth-foundation/spec.md
Summary
Implement a narrow follow-up that aligns generic OperationRun queue truth across the existing lifecycle, freshness, progress, and monitoring-detail helpers. The slice must reuse current OperationRun persistence, current scheduled and adapter reconciliation behavior, current run links, and current authorization boundaries while removing contradictory active-work wording from shell, list, and canonical detail surfaces.
The repo already contains the foundations from Specs 149, 160, 233, 268, 270, and 272. This plan must not reopen those packages or invent a new reconciliation framework. It only corrects the remaining generic truth gap in current runtime code.
Technical Context
Language/Version: PHP 8.4.15, Laravel 12.52, Filament 5.2.1, Livewire 4.1.4
Primary Dependencies: existing OperationRun monitoring helpers, OperationRunProgressContract, RunDurationInsights, OperationUxPresenter, current Filament Monitoring pages and shared OperationRun implementation seams, Pest 4.3
Storage: PostgreSQL operation_runs; no schema change planned
Testing: Pest Unit + Feature
Validation Lanes: fast-feedback, confidence
Target Platform: Laravel monolith in apps/platform
Project Type: web application
Performance Goals: keep current polling/query posture unchanged; no new queries or background work required for render-time truth
Constraints: no new OperationRun status/outcome fields, no new adapter registry, no new queue/job commands, no Graph calls, no notification policy change
Scale/Scope: one shared derived truth path plus current shell/list/detail monitoring surfaces and focused regression coverage
Likely Affected Repo Surfaces
apps/platform/app/Support/OpsUx/OperationRunProgressContract.phpapps/platform/app/Support/OpsUx/RunDurationInsights.phpapps/platform/app/Support/OpsUx/OperationUxPresenter.phpapps/platform/app/Support/Operations/OperationRunFreshnessState.phponly if the current derivation needs a small bounded clarificationapps/platform/resources/views/livewire/bulk-operation-progress.blade.phpapps/platform/app/Filament/Pages/Monitoring/Operations.phpas the current route-backed Operations hub surfaceapps/platform/resources/views/filament/pages/monitoring/operations.blade.phponly if current workbench/list wording needs a bounded adjustmentapps/platform/app/Filament/Resources/OperationRunResource.phponly as the reused table/detail payload seam, not as a route-backed surfaceapps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php- focused tests under:
apps/platform/tests/Unit/Support/OpsUx/apps/platform/tests/Feature/OpsUx/apps/platform/tests/Feature/Monitoring/apps/platform/tests/Feature/Filament/apps/platform/tests/Feature/Operations/
UI / Surface Guardrail Plan
- Guardrail scope: existing operator-facing monitoring surfaces only
- Affected routes/pages/actions/states/navigation/panel/provider surfaces:
- tenant shell activity hint
/admin/workspaces/{workspace}/operationsviaApp\Filament\Pages\Monitoring\Operations/admin/workspaces/{workspace}/operations/{run}viaApp\Filament\Pages\Operations\TenantlessOperationRunViewer
- No-impact class, if applicable: N/A
- Native vs custom classification summary: native Filament surfaces plus one existing Livewire shell host
- Shared-family relevance: monitoring-state messaging, queue guidance, active-run hinting
- State layers in scope: shell, page, detail
- Audience modes in scope: operator-MSP, support-platform
- Decision/diagnostic/raw hierarchy plan: decision-first lifecycle truth before diagnostics; raw context remains secondary
- Raw/support gating plan: unchanged; raw/support evidence stays on current detail-only surfaces
- One-primary-action / duplicate-truth control: no new primary actions; existing row open and current shell open links remain authoritative
- Handling modes by drift class or surface:
- contradictory stale vs queue guidance is
hard-stop-candidate - wording-only cleanup with no behavioral effect is
review-mandatory
- contradictory stale vs queue guidance is
- Repository-signal treatment: review-mandatory
- Special surface test profiles: monitoring-state-page, shared-detail-family
- Required tests or manual smoke: focused unit and feature proof only
- Exception path and spread control: any move toward new persistence, new adapter abstractions, or new queue-health orchestration is
reject-or-split - Active feature PR close-out entry: Guardrail / Smoke Coverage
- Navigation / Filament provider-panel handling: unchanged; no provider registration or panel path work
Shared Pattern & System Fit
- Cross-cutting feature marker: yes
- Systems touched: lifecycle freshness, progress derivation, queue guidance, shell render, canonical monitoring detail
- Shared abstractions reused:
OperationRunFreshnessStateOperationRunProgressContractRunDurationInsightsOperationUxPresenter- existing
OperationRunLinksand detail routes
- New abstraction introduced? why?: none by default; if one tiny queue-truth helper is required, it must stay inside
App\Support\OpsUxand remain a derivation helper rather than a strategy or adapter registry - Why the existing abstraction was sufficient or insufficient: the repo already centralizes the right ingredients, but the final operator wording remains split across helpers and render sites
- Bounded deviation / spread control: do not create a new framework layer where extending the current presenter or progress contract is sufficient
OperationRun UX Impact
- Touches OperationRun start/completion/link UX?: yes, reuse-only
- Central contract reused: current shared run-link, queued-toast, terminal-notification, and detail-route contract
- Delegated UX behaviors: queued toast wording, run links, browser events, and terminal notifications remain unchanged
- Surface-owned behavior kept local: only density and render ordering for shell/list/detail
- Queued DB-notification policy: unchanged
- Terminal notification path: unchanged
- Exception path: none
Provider Boundary & Portability Fit
- Shared provider/platform boundary touched?: no
- Provider-owned seams: N/A
- Platform-core seams: platform-owned
OperationRunmonitoring truth only - Neutral platform terms / contracts preserved: queued, running, lifecycle window, active operation, review worker health
- Retained provider-specific semantics and why: none
- Bounded extraction or follow-up path: none
Constitution Check
- Inventory-first: unchanged; no new source of truth.
- Read/write separation: unchanged; this is read-only monitoring truth.
- Deterministic capabilities: unchanged.
- Proportionality / anti-bloat: pass only if the implementation extends current helpers instead of creating a new framework.
- Persisted truth: no new tables, entities, or status families.
- State discipline: derived-only; no new persisted lifecycle category.
- Shared pattern first: extend existing Ops UX helpers and current monitoring surfaces.
- Workspace / tenant isolation: unchanged and still mandatory.
- RBAC-UX: no client-side authorization expansion; server-side boundaries remain the only access control.
- Test governance: unit + feature remain the narrowest honest proof.
- Filament v5 / Livewire v4 posture: unchanged; no provider-registration or asset change.
Test Governance Check
- Test purpose / classification by changed surface:
- Unit: generic queue-truth derivation
- Feature: current shell/list/detail rendering and authorization-safe presentation
- Affected validation lanes: fast-feedback, confidence
- Why this lane mix is the narrowest sufficient proof: the slice corrects shared derivation and rendered copy on current surfaces without introducing JS-heavy or browser-only behavior
- Narrowest proving command(s):
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/OpsUx/OperationRunProgressContractTest.phpcd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/ActivityFeedbackSurfaceTest.php tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php tests/Feature/MonitoringOperationsTest.php tests/Feature/Monitoring/OperationLifecycleFreshnessPresentationTest.php tests/Feature/Monitoring/MonitoringOperationsTest.php tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php tests/Feature/Operations/TenantlessOperationRunViewerTest.phpgit diff --check
- Fixture / helper / factory / seed / context cost risks: existing
OperationRunfixtures and workspace membership helpers are sufficient; avoid widening defaults - Expensive defaults or shared helper growth introduced?: none planned
- Heavy-family additions, promotions, or visibility changes: none
- Surface-class relief / special coverage rule: monitoring-state-page and shared-detail-family coverage is explicit
- Closing validation and reviewer handoff: reviewers should compare stale-active, fresh-active, and reconciled-terminal cases across shell, list, and detail and confirm that stale-active wording does not coexist with ordinary queue/progress reassurance
- Budget / baseline / trend follow-up: none expected
- Review-stop questions: Did the change add persistence? Did it invent a new adapter framework? Does any stale-active surface still combine stale attention with ordinary
Waiting for worker.,Progress details pending., or equivalent calm queue/progress reassurance? - Escalation path:
reject-or-splitif scope widens into queue runtime redesign - Active feature PR close-out entry: Guardrail / Smoke Coverage
Implementation Phases
Phase 1 — Confirm the shared queue-truth inputs
- Inventory the exact contradictory paths in:
OperationRunProgressContractRunDurationInsightsOperationUxPresenter- current shell/list/detail renderers
- Freeze the current shared vocabulary for:
- fresh queued/running
- stale active
- reconciled terminal
- Confirm that existing scheduled and adapter reconciliation commands remain context only
Phase 2 — Align the generic queue-truth derivation
- Extend existing helpers so freshness, queue guidance, and progress availability tell one story
- Keep phase/composite/determinate progress derived-only and subordinate to stale lifecycle truth
- Ensure unsupported or low-evidence cases remain cautious rather than overclaiming orphaned state
Phase 3 — Retrofit current monitoring surfaces
- Update the current shell banner so stale active work does not read as ordinary queue wait
- Update canonical list/detail guidance so they confirm the same lifecycle meaning
- Keep existing links, filters, and diagnostics structure unchanged
Phase 4 — Validate and lock the contract
- Add or update targeted unit + feature tests
- Run the focused validation commands
- Record any remaining bounded wording choices in the active feature close-out
Risks and Mitigations
- Over-escalation of healthy work: mitigate with explicit fresh-active negative assertions.
- Residual renderer drift: mitigate by covering shell, list, and detail in the same test set.
- Accidental framework expansion: mitigate by rejecting new registries, adapters, or persisted truth in review.
Project Structure
Documentation
specs/358-operationrun-queue-truth-foundation/
|-- spec.md
|-- plan.md
|-- tasks.md
`-- checklists/
`-- requirements.md
Runtime surfaces likely to change later
apps/platform/app/Support/OpsUx/
|-- OperationRunProgressContract.php
|-- OperationUxPresenter.php
`-- RunDurationInsights.php
apps/platform/app/Support/Operations/
`-- OperationRunFreshnessState.php
apps/platform/app/Filament/
|-- Pages/Monitoring/Operations.php
|-- Pages/Operations/TenantlessOperationRunViewer.php
`-- Resources/OperationRunResource.php
apps/platform/resources/views/filament/pages/monitoring/
`-- operations.blade.php
apps/platform/resources/views/livewire/
`-- bulk-operation-progress.blade.php