TenantAtlas/specs/272-operationrun-phase-composite-progress/checklists/requirements.md

Specification Quality Checklist: OperationRun Phase & Composite Progress v1

Purpose: Validate specification completeness, boundedness, and readiness before implementation
Created: 2026-05-05
Feature: spec.md

Content Quality

• The package stays on one bounded non-counted progress extension over existing OperationRun truth instead of widening into a workflow engine, dashboard redesign, child-run graph, or a second progress framework.
• The spec remains product- and behavior-oriented rather than reading like a low-level implementation diff.
• The package explicitly names the repo-real anchors it builds on: OperationRunProgressContract, OperationUxPresenter, OperationStatusNormalizer, current baseline phase context, and tenant.review.compose aggregate operation truth.
• Mandatory repo sections for scope, shared-pattern reuse, Ops-UX, testing, proportionality, and candidate rationale are completed.

Requirement Completeness

• No unresolved clarification markers remain.
• Requirements are testable and bounded to selected current phase/composite run families plus one standards update.
• The package explicitly keeps processed and total as the only determinate progress source and keeps phase/composite v1 explicitly non-counted.
• The package explicitly forbids fake percentages, raw technical phase labels, new summary_counts keys, a child-run graph, and a workflow engine.
• The package explicitly records the candidate narrowing: review-pack and evidence-snapshot overlap remain with Spec 271, while provider health and support diagnostics remain deferred until repo-real queued progress truth exists.
• The package keeps provider, panel, global-search, asset, queue-family, notification-policy, and persistence changes out of scope.

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.
• Repo verification confirmed specs/270-operationrun-progress-contract/ is the immediate prerequisite context for this package.
• Repo verification confirmed specs/271-counted-progress-rollout/ remains the adjacent counted boundary and must not be silently reopened here.
• Repo verification confirmed baseline capture and baseline compare already persist phase-shaped context that currently terminates in generic fallback labels.
• Repo verification confirmed tenant.review.compose already has repo-real aggregate operation truth suitable for a bounded composite summary without adding a child-run graph.
• Repo verification confirmed provider health and support diagnostics do not currently expose equivalent queued phase/composite OperationRun truth and therefore remain deferred.

Feature Readiness

• The package reuses current OperationRun truth and the current shared progress contract instead of introducing a second lifecycle or persisted projection.
• The package names both the selected in-scope run families and the excluded candidate families.
• The package forbids new panel, provider, global-search, asset-registration, dashboard, workflow-engine, and persistence changes.
• The package preserves the current polling posture, current terminal-outcome contract, and current counted precedence.
• The planned validation commands stay consistent across spec.md, plan.md, and tasks.md.
• No application implementation was performed while preparing this package.

Test Governance

• Planned proof stays bounded to existing Unit plus Feature families for Ops-UX, Baselines, TenantReview, and current run-detail compatibility.
• No new heavy-governance or browser family is introduced by default.
• Fixture growth remains bounded to current tenant context helpers, current baseline helpers, current OperationRun factories, and current tenant-review fixtures.
• 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, specs/270-operationrun-progress-contract/spec.md, specs/271-counted-progress-rollout/spec.md, apps/platform/app/Support/OpsUx/OperationRunProgressContract.php, apps/platform/app/Support/OpsUx/OperationUxPresenter.php, apps/platform/app/Support/OpsUx/OperationStatusNormalizer.php, apps/platform/app/Services/Baselines/BaselineCaptureService.php, apps/platform/app/Jobs/CaptureBaselineSnapshotJob.php, apps/platform/app/Jobs/CompareBaselineToTenantJob.php, apps/platform/app/Services/TenantReviews/TenantReviewService.php, apps/platform/app/Jobs/ComposeTenantReviewJob.php, apps/platform/app/Services/TenantReviews/TenantReviewSectionFactory.php, and docs/ui/tenantpilot-enterprise-ui-standards.md on 2026-05-05.
• This checklist is the prep-time outcome record. If implementation widens into provider health/support progress, review-pack overlap, dashboard work, child-run graph persistence, or a workflow engine, 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 manual-promotion follow-up to Spec 270 that reuses current shared truth, preserves the counted boundary from Spec 271, and explicitly documents the candidate narrowing required by current repo reality.
• 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.