160 lines
12 KiB
Markdown
160 lines
12 KiB
Markdown
---
|
|
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.
|
|
|
|
- [x] 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.
|
|
- [x] 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`.
|
|
- [x] 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.
|
|
|
|
- [x] 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.
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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
|
|
|
|
- [x] 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.
|
|
- [x] 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.
|
|
|
|
- [x] 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`.
|
|
- [x] 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`.
|
|
- [x] 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.
|
|
- [x] 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
|