TenantAtlas/specs/268-operationrun-activity-feedback/checklists/requirements.md

Specification Quality Checklist: OperationRun Activity Feedback v1

Purpose: Validate specification completeness and repo fit before implementation
Created: 2026-05-03
Feature: spec.md

Content Quality

• The spec stays on one bounded manual-promotion slice over current OperationRun truth instead of widening into an activity center, notification rewrite, or acknowledgement workflow.
• The package is product- and behavior-oriented and does not read like a low-level implementation diff.
• The spec explicitly names the repo-real foundations it builds on: OperationUxPresenter, OperationStatusNormalizer, OperationRunLinks, the current tenant shell hint, and the verified overlap seam.
• Mandatory repo sections for scope, RBAC, Ops-UX, testing, proportionality, and candidate rationale are completed.

Requirement Completeness

• No [NEEDS CLARIFICATION] markers remain.
• Requirements are testable and stay bounded to current OperationRun truth and the current global active-ops shell widget only.
• The package explicitly requires canonical helper-generated View operation / Show all operations links instead of raw route strings.
• The package explicitly requires the shell overflow route to open Operations with the selected tenant as the initial tenant_id contextual prefilter, and any restored local filters may only narrow within that tenant scope.
• The package makes progressbar eligibility explicit and forbids fake percentages when deterministic counts are unavailable.
• The package makes the guidance contract explicit: the shell may show at most one concise next-step cue when it materially clarifies inspection and must not expand into diagnostics prose.
• The package explains what remains in scope versus what is intentionally deferred.
• Acceptance scenarios cover shell feedback, active-only/honest-progress behavior, and browser-session collapse rules.
• Edge cases cover no tenant context, no visibility, overflow ordering, terminal-run exclusion, and the non-obstructive shell contract.

Candidate Selection Gate

• The selected candidate exists in docs/product/spec-candidates.md and is consistent with the broader roadmap direction.
• The active queue is explicitly empty, so this package records itself as a deliberate manual promotion rather than an automatic next-best-prep target.
• No existing spec package already covers this bounded activity-feedback slice; the package narrows the candidate intentionally to the current global active-ops shell widget instead of re-opening unrelated dashboard productization work.
• The chosen slice is smaller and more repo-ready than deferred alternatives because the repo already contains truthful Ops-UX helpers, current host surfaces, and verified overlap tests.

Feature Readiness

• The package reuses current OperationRun truth and current Ops-UX helpers instead of introducing a second lifecycle or persisted projection.
• The package describes OperationRun ownership with tenant-bound operational semantics and preserves the existing nullable-tenant monitoring exception instead of reclassifying the model as workspace-owned.
• The spec explicitly keeps collection/detail Monitoring pages diagnostics-first and keeps the shell decision-first and active-only.
• The spec forbids new panel, provider, global-search, asset, queue, notification-policy, and persistence changes.
• The plan and tasks keep hide/collapse browser-session-only and reject DB-backed acknowledgement semantics.
• The package explicitly includes the durable UI guardrail by requiring an update to docs/ui/tenantpilot-enterprise-ui-standards.md in the same implementation slice.
• The package names the inherited Operations page state-contract seam and its existing proof owner for tenant-prefilter precedence instead of treating that behavior as shell-local.

Test Governance

• Planned proof stays bounded to focused Feature coverage plus one named browser smoke for the overlap/non-obstruction contract.
• No new heavy-governance family is introduced.
• Runtime proof commands stay consistent across spec, plan, and tasks, and all commands run through Sail with the workspace PATH workaround.

Notes

• Reviewed against docs/product/spec-candidates.md, docs/product/roadmap.md, .specify/memory/constitution.md, apps/platform/app/Support/OpsUx/OperationUxPresenter.php, apps/platform/app/Support/OpsUx/OperationStatusNormalizer.php, apps/platform/app/Livewire/BulkOperationProgress.php, apps/platform/app/Providers/Filament/TenantPanelProvider.php, and the current Ops-UX test families on 2026-05-03.
• No application implementation was performed while preparing this package.

Review Outcome

• Outcome class: acceptable-special-case
• Outcome: keep
• Reason: The queue is intentionally empty, but this manual promotion is tightly bounded, repo-real, and smaller than the full candidate group because it limits v1 to the current shell hint and one durable standards update while staying inside the Ops-UX 3-surface contract.
• Workflow result: Ready for implementation.