TenantAtlas/specs/270-operationrun-progress-contract/checklists/requirements.md
ahmido ca61fa17dc 270-operationrun-progress-contract: OperationRun progress contract (#325)
Automated PR created by Copilot agent: commits workspace changes, adds specs and tests.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #325
2026-05-04 16:36:50 +00:00

60 lines
5.2 KiB
Markdown

# Specification Quality Checklist: OperationRun Progress Contract v1
**Purpose**: Validate specification completeness, boundedness, and readiness before implementation
**Created**: 2026-05-04
**Feature**: [spec.md](../spec.md)
## Content Quality
- [x] The package stays on one bounded shared progress contract over existing `OperationRun` truth instead of widening into counted writer rollout, dashboard redesign, or a second execution framework.
- [x] The spec remains product- and behavior-oriented rather than reading like a low-level implementation diff.
- [x] The package explicitly names the repo-real anchors it builds on: `SummaryCountsNormalizer`, `OperationSummaryKeys`, `ActiveRuns`, `OperationRunService`, and the current inline progress seam in `bulk-operation-progress.blade.php`.
- [x] Mandatory repo sections for scope, shared-pattern reuse, Ops-UX, testing, proportionality, and candidate rationale are completed.
## Requirement Completeness
- [x] No unresolved clarification markers remain.
- [x] Requirements are testable and bounded to current `OperationRun` truth, one shared progress contract, one visible shell adopter, and one standards update only.
- [x] The package explicitly keeps `summary_counts.processed` and `summary_counts.total` as the only v1 determinate progress source.
- [x] The package explicitly forbids `succeeded`, `failed`, and `skipped` from silently becoming progress substitutes.
- [x] The package declares `phased` and `composite` categories without inventing fake percentages, new persistence, or hidden writer rollout.
- [x] The package explains what remains in scope versus what is intentionally deferred to Specs 271, 272, and 273.
## Candidate Selection Gate
- [x] The selected candidate exists in `docs/product/spec-candidates.md` and is consistent with the broader roadmap direction.
- [x] The active queue is explicitly empty, so this package records itself as a deliberate manual promotion rather than an automatic next-best-prep target.
- [x] Repo verification explicitly excluded `269 — OperationRun Terminal Outcome Feedback` because `specs/268-operationrun-activity-feedback/` already owns that shell terminal slice.
- [x] `273 — Tenant Dashboard Active Operations Summary Card` remains conditional on visible dashboard drift after Spec 268, so it is not a safer prep target than the progress contract.
- [x] `271` and `272` remain legitimate follow-ups, but both depend on the shared contract from this package.
## Feature Readiness
- [x] The package reuses current `OperationRun` truth and current summary-count sanitization instead of introducing a second lifecycle or persisted projection.
- [x] The package forbids new panel, provider, global-search, asset-registration, queue-family, and notification-policy changes.
- [x] The package preserves the current polling posture and explicitly forbids new parallel polling loops.
- [x] The package carries current no-tenant and unauthorized shell-visibility behavior into focused feature-proof tasks instead of assuming auth semantics survive the refactor automatically.
- [x] The package names the current inline shell progress math as the concrete repo seam to remove.
- [x] The package keeps `OperationRun.status`, `OperationRun.outcome`, `OperationSummaryKeys`, and `SummaryCountsNormalizer` as the current authoritative truth owners.
- [x] The planned validation commands stay consistent across `spec.md`, `plan.md`, and `tasks.md`.
## Test Governance
- [x] Planned proof stays bounded to one new `Unit` suite plus focused `Feature` suites.
- [x] No new heavy-governance or browser family is introduced by default.
- [x] Fixture growth remains bounded to current `OperationRun` factories and current Ops-UX test helpers instead of a new matrix harness.
- [x] The review outcome, workflow outcome, and test-governance outcome are carried into the active prep package.
## Notes
- Reviewed against `.specify/memory/constitution.md`, `.specify/templates/checklist-template.md`, `docs/product/spec-candidates.md`, `docs/product/roadmap.md`, `specs/268-operationrun-activity-feedback/spec.md`, `apps/platform/app/Support/OpsUx/ActiveRuns.php`, `apps/platform/app/Support/OpsUx/SummaryCountsNormalizer.php`, `apps/platform/app/Support/OpsUx/OperationSummaryKeys.php`, `apps/platform/app/Services/OperationRunService.php`, and `apps/platform/resources/views/livewire/bulk-operation-progress.blade.php` on 2026-05-04.
- This checklist is the prep-time outcome record. If implementation widens into counted writer rollout, dashboard-specific progress work, or a persisted progress mode, the workflow outcome must change before merge.
- No application implementation was performed while preparing this package.
## Review Outcome
- **Outcome class**: `acceptable-special-case`
- **Workflow outcome**: `keep`
- **Test-governance outcome**: `keep`
- **Reason**: the package is a bounded shared-truth contract justified by multiple repo-real consumers, keeps the visible adoption limited to the current shell host, and explicitly defers the heavier rollout work to later manual-promotion specs.
- **Final note location**: This checklist during prep, and the active feature PR close-out entry only if implementation later forces `split` or `document-in-feature`.