ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
277-stored-reports-surface
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

5.2 KiB
Raw Permalink Blame History

Specification Quality Checklist: OperationRun Progress Contract v1

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

Content Quality

  • 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.
  • 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: SummaryCountsNormalizer, OperationSummaryKeys, ActiveRuns, OperationRunService, and the current inline progress seam in bulk-operation-progress.blade.php.
  • 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 current OperationRun truth, one shared progress contract, one visible shell adopter, and one standards update only.
  • The package explicitly keeps summary_counts.processed and summary_counts.total as the only v1 determinate progress source.
  • The package explicitly forbids succeeded, failed, and skipped from silently becoming progress substitutes.
  • The package declares phased and composite categories without inventing fake percentages, new persistence, or hidden writer rollout.
  • The package explains what remains in scope versus what is intentionally deferred to Specs 271, 272, and 273.

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 explicitly excluded 269 — OperationRun Terminal Outcome Feedback because specs/268-operationrun-activity-feedback/ already owns that shell terminal slice.
  • 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.
  • 271 and 272 remain legitimate follow-ups, but both depend on the shared contract from this package.

Feature Readiness

  • The package reuses current OperationRun truth and current summary-count sanitization instead of introducing a second lifecycle or persisted projection.
  • The package forbids new panel, provider, global-search, asset-registration, queue-family, and notification-policy changes.
  • The package preserves the current polling posture and explicitly forbids new parallel polling loops.
  • 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.
  • The package names the current inline shell progress math as the concrete repo seam to remove.
  • The package keeps OperationRun.status, OperationRun.outcome, OperationSummaryKeys, and SummaryCountsNormalizer as the current authoritative truth owners.
  • The planned validation commands stay consistent across spec.md, plan.md, and tasks.md.

Test Governance

  • Planned proof stays bounded to one new Unit suite plus focused Feature suites.
  • No new heavy-governance or browser family is introduced by default.
  • Fixture growth remains bounded to current OperationRun factories and current Ops-UX test helpers instead of a new matrix harness.
  • 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.