ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
c1f4ebaa05
TenantAtlas/specs/269-operationrun-terminal-outcome-feedback/tasks.md
Ahmed Darrazi c1f4ebaa05
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 1m31s
Details
chore: commit all changes (automated)
2026-05-05 17:20:17 +02:00

12 KiB
Raw Blame History

description
Task list for OperationRun Terminal Outcome Feedback v1

Tasks: OperationRun Terminal Outcome Feedback v1

Input: Design documents from specs/269-operationrun-terminal-outcome-feedback/
Prerequisites: specs/269-operationrun-terminal-outcome-feedback/spec.md, specs/269-operationrun-terminal-outcome-feedback/plan.md, specs/269-operationrun-terminal-outcome-feedback/checklists/requirements.md

Review Artifact: specs/269-operationrun-terminal-outcome-feedback/checklists/requirements.md is the outcome-of-record for the review outcome class, workflow outcome, and test-governance outcome. If implementation widens into dashboard work, new persistence, or notification-policy changes, update that artifact before continuing.

Tests: REQUIRED (Pest). Keep proof bounded to focused Feature coverage for terminal-outcome shell semantics plus one named browser smoke for the live shell interaction contract. Operations: No new OperationRun type, no new queue family, no new notification policy, and no new lifecycle ownership. Existing queued toasts, terminal notifications, canonical Operations drill-through routes, and browser enqueue events remain authoritative. RBAC: Reuse current OperationRun policies and tenant context guards. No tenantless leakage from tenant surfaces; the shell stays inert when no selected tenant or viewAny capability exists. Shared Pattern Reuse: Reuse BulkOperationProgress, OperationUxPresenter, OperationStatusNormalizer, OperationRunProgressContract, OperationRunLinks, OperationRunUrl, ActiveRuns, OpsUxBrowserEvents, and docs/ui/tenantpilot-enterprise-ui-standards.md. Do not create a second lifecycle, a second shell host, or a DB-backed acknowledgement model. Filament / Panel Guardrails: Filament remains v5 on Livewire v4. Provider registration remains unchanged in apps/platform/bootstrap/providers.php. No new panel, resource, or asset strategy is allowed. Organization: Tasks are grouped by user story so terminal success, unresolved follow-up, and browser-session acknowledgement remain independently reviewable.

Test Governance Notes

  • Lane mix stays Feature plus one named browser smoke for live shell interaction.
  • Prefer extending ActivityFeedbackSurfaceTest, BulkOperationProgressDbOnlyTest, and OperationActivityFeedbackSmokeTest before adding any new families.
  • Planned proving test commands must stay identical to spec.md and plan.md and run through Sail. Formatting remains a separate repo-hygiene step.

Phase 1: Setup (Shared Context)

Purpose: confirm the bounded slice, the current shell truth, and the current proof owners before runtime edits begin.

  • T001 Review specs/269-operationrun-terminal-outcome-feedback/spec.md, specs/269-operationrun-terminal-outcome-feedback/plan.md, specs/269-operationrun-terminal-outcome-feedback/checklists/requirements.md, docs/product/spec-candidates.md, docs/product/roadmap.md, and .specify/memory/constitution.md together so the slice stays on the bounded manual-promotion target.
  • T002 [P] Confirm the current terminal-outcome seams in apps/platform/app/Livewire/BulkOperationProgress.php, apps/platform/resources/views/livewire/bulk-operation-progress.blade.php, apps/platform/app/Support/OpsUx/OperationUxPresenter.php, apps/platform/app/Support/OpsUx/ActiveRuns.php, and apps/platform/public/js/tenantpilot/ops-ux-progress-widget-poller.js.
  • T003 [P] Confirm the current proof owners in apps/platform/tests/Feature/OpsUx/ActivityFeedbackSurfaceTest.php, apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php, apps/platform/tests/Browser/OpsUx/OperationActivityFeedbackSmokeTest.php, and docs/ui/tenantpilot-enterprise-ui-standards.md.

Phase 2: Foundational (Blocking Prerequisites)

Purpose: settle the proof seams before runtime edits widen.

Critical: no user-story runtime work should begin until this phase is complete.

  • T004 [P] Create or extend failing Feature coverage in apps/platform/tests/Feature/OpsUx/ActivityFeedbackSurfaceTest.php for no-tenant and no-capability suppression, no inaccessible run exposure, terminal success copy, follow-up-specific Acknowledge semantics, grouped follow-up emphasis, and the absence of progress UI after terminal transition.
  • T005 [P] Extend apps/platform/tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php only as needed for single-item versus grouped primary-action wording, grouped Review operations as the label variant of the canonical collection link, and terminal tertiary-action labels.
  • T006 [P] Extend apps/platform/tests/Browser/OpsUx/OperationActivityFeedbackSmokeTest.php for browser-session-only acknowledge or dismiss behavior and shell re-open on new run-enqueue events.

Checkpoint: the success-versus-follow-up proof owner is settled before implementation begins.

Phase 3: User Story 1 - Terminal Success Feels Complete, Not Risky (Priority: P1)

Goal: keep successful terminal runs briefly visible with success-specific copy and dismissible browser-session behavior.

Independent Test: seed a recent successful terminal run, open a tenant-scoped shell surface, and verify the shell shows success-specific copy, no progress UI, and Dismiss or Close semantics.

Implementation for User Story 1

  • T007 [US1] Refine apps/platform/resources/views/livewire/bulk-operation-progress.blade.php and apps/platform/app/Support/OpsUx/OperationUxPresenter.php so successful terminal items render success-specific helper or guidance copy and keep Dismiss or Close semantics without reusing follow-up wording. Existing OperationUxPresenter success guidance was sufficient; no presenter edit was needed.
  • T008 [US1] Update apps/platform/app/Livewire/BulkOperationProgress.php and apps/platform/app/Support/OpsUx/ActiveRuns.php only as needed so recent successful terminal items remain visible for the current 30-second ActiveRuns grace window without changing active-run truth or polling ownership. Existing ActiveRuns grace-window truth remained correct; no runtime edit was needed.

Checkpoint: User Story 1 is independently functional when successful terminal rows stay calm and dismissible.

Phase 4: User Story 2 - Terminal Follow-Up Stays Explicitly Reviewable (Priority: P1)

Goal: keep unresolved terminal outcomes clearly review-worthy instead of generically dismissible.

Independent Test: seed failed, partial, or blocked terminal runs, open a tenant-scoped shell surface, and verify the shell shows follow-up-specific guidance, Acknowledge semantics, and review-oriented grouped copy when mixed with active work.

Implementation for User Story 2

  • T009 [US2] Refine apps/platform/resources/views/livewire/bulk-operation-progress.blade.php and apps/platform/app/Support/OpsUx/OperationUxPresenter.php so unresolved terminal follow-up uses explicit review-needed copy, Acknowledge tertiary wording, and review-oriented grouped helper text. Existing OperationUxPresenter follow-up guidance was sufficient; the shell view owns the label split.
  • T010 [US2] Update apps/platform/app/Support/OpsUx/ActiveRuns.php and apps/platform/app/Livewire/BulkOperationProgress.php only as needed so unresolved terminal follow-up remains shell-visible until locally acknowledged and never reuses success dismissal semantics. Existing shell-visible query and Livewire state already kept terminal follow-up visible; no edit was needed.

Checkpoint: User Story 2 is independently functional when unresolved terminal follow-up stops looking like harmless completion noise.

Phase 5: User Story 3 - Acknowledge Stays Browser-Session Only (Priority: P1)

Goal: preserve shell calmness without creating a new persisted review state.

Independent Test: acknowledge an unresolved terminal item in the current browser session, trigger a new run-enqueue event, and verify the shell reopens without any DB-backed acknowledgement state.

Implementation for User Story 3

  • T011 [US3] Update apps/platform/public/js/tenantpilot/ops-ux-progress-widget-poller.js, apps/platform/app/Livewire/BulkOperationProgress.php, and the shell view only as needed so Hide activity, Dismiss or Close, and Acknowledge remain browser-session-only and new work reopens the shell. Existing poller sessionStorage and ops-ux:run-enqueued reopen behavior covered the renamed tertiary semantics; browser smoke verified no JS edit was needed.
  • T012 [US3] Update docs/ui/tenantpilot-enterprise-ui-standards.md with the shell terminal-outcome contract, including success dismissal, follow-up acknowledgement, and the ban on generic dismiss semantics for unresolved follow-up.

Checkpoint: User Story 3 is independently functional when terminal-outcome calmness stays local to the browser session and the standards document records the durable rule.

Phase 6: Polish & Cross-Cutting Validation

Purpose: validate the bounded slice, stop drift, and hand off a clean implementation path.

  • T013 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/OpsUx/ActivityFeedbackSurfaceTest.php tests/Feature/OpsUx/BulkOperationProgressDbOnlyTest.php.
  • T014 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/OpsUx/OperationActivityFeedbackSmokeTest.php.
  • T015 [P] Run export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent for touched platform files.
  • T016 [P] Review touched code to confirm Filament stays on Livewire v4, provider registration remains unchanged in apps/platform/bootstrap/providers.php, no new globally searchable resource was introduced, and no asset registration or notification-policy change slipped into the slice.

Dependencies & Execution Order

Phase Dependencies

  • Phase 1 (Setup): no dependencies; start immediately.
  • Phase 2 (Foundational): depends on Phase 1 and blocks user-story work.
  • Phase 3 (US1): depends on Phase 2 and establishes success-specific terminal semantics.
  • Phase 4 (US2): depends on Phase 2 and should ship with US1 so terminal outcomes stay honest across both no-action-needed and follow-up-needed cases.
  • Phase 5 (US3): depends on Phase 2 and hardens browser-session-only calmness after terminal semantics exist.
  • Phase 6 (Polish): depends on all desired user stories being complete.

User Story Dependencies

  • US1 (P1): independently testable after Phase 2 and delivers the no-action-needed terminal success contract.
  • US2 (P1): independently testable after Phase 2 and should ship with US1 so unresolved follow-up never inherits success semantics.
  • US3 (P1): independently testable after Phase 2 and is required to keep the slice presentation-only instead of inventing a persisted workflow state.

Within Each User Story

  • Write or extend the listed Pest coverage first and make it fail for the intended gap.
  • Land shell-host runtime changes before widening browser-session action behavior.
  • Re-run the narrowest affected validation command after each story checkpoint before moving on.

Implementation Strategy

Suggested MVP Scope

  • MVP = US1 + US2 + US3 together. The manual-promotion target is only complete when terminal success is calm, unresolved follow-up is explicitly reviewable, and acknowledgement stays browser-session-only.

Incremental Delivery

  1. Complete Phase 1 and Phase 2.
  2. Deliver US1.
  3. Deliver US2 on top of the same shell host.
  4. Add US3 browser-session-only action hardening and the standards update.
  5. Finish with the focused Feature proof and the named browser smoke.

Team Strategy

  1. Settle the shell proof owner first.
  2. Parallelize Feature and browser proof updates while keeping the runtime change local to the existing shell component.
  3. Serialize merges around BulkOperationProgress and the standards document so the terminal-outcome contract stays coherent.

Deferred Follow-Ups / Non-Goals

  • Tenant dashboard active-operations summary card
  • New OperationRun progress-contract or rollout work
  • Phase or composite progress modeling
  • Persistent reviewed, investigated, or acknowledged semantics over unresolved terminal runs
  • Activity center or tray v2
  • Notification-policy changes for queued or terminal lifecycle events