Campaign_Tracker/_bmad-output/implementation-artifacts/2-5-election-cycle-readiness-status-publication.md

Story 2.5: Election-Cycle Readiness Status & Publication

Status: ready-for-dev

Story

As a client services staff member, I want to see required-field readiness status for my election-cycle job and publish it to production readiness through a pre-commit validation rail, so that I can confirm the plan is complete and provide the team with a verified production-ready job.

Acceptance Criteria

1. Given an election-cycle job has missing required fields (as defined by seeded rules from Story 1.9) When a client services user views readiness status Then each missing required field is identified by name with a jump-link that navigates directly to the field
2. Given all required fields are complete When readiness status is evaluated Then the job shows a “Ready to Publish” state and the Publish action becomes enabled
3. Given a user initiates the Publish action When the SafeCommitRail activates Then it runs dependency and policy checks and displays: overall pass/fail status, a list of any blocking reasons with one-click corrective action links, and a reason-code selector where audit policy requires it (UX-DR4)
4. Given the SafeCommitRail shows all checks passed When the user confirms the publish with a required reason code Then the job status transitions to “Production Ready” and actor, timestamp, and reason code are captured in the audit log
5. Given the SafeCommitRail shows one or more blocking issues When displayed Then the Publish confirm button remains disabled until all blocking issues are resolved
6. Given the publish action succeeds When the confirmation is shown Then a “Next Best Action” prompt guides the user to the recommended following step (e.g., configure services) (UX-DR11)
7. And the SafeCommitRail is built as a reusable shared module — it is independently consumable by Epic 3 service configuration commits and Epic 5 production status commits without duplication or modification

Tasks / Subtasks

• Backend: readiness evaluation (AC: #1, #2)
  • Implement a readiness evaluator that consumes the seeded required-field rules from Story 1.9 and returns the list of missing required fields with stable field identifiers usable for jump-links
  • Expose readiness state and a derived "Ready to Publish" indicator on the cycle job read model
• Backend: SafeCommitRail shared module (AC: #3, #4, #5, #7)
  • Build SafeCommitRail as a reusable module with a clearly defined extension point for pluggable check providers (dependency checks, policy checks, reason-code requirements)
  • Provide a check provider for the election-cycle publish flow that registers required dependency/policy checks and the reason-code requirement
  • Module API must be consumable as-is by Epic 3 (service configuration commits) and Epic 5 (production status commits) — no fork, no copy
  • Publish endpoint runs SafeCommitRail; on full pass + reason code, transitions job status to "Production Ready" and writes an audit entry with actor, timestamp, and reason code via the shared audit logger
• Frontend: readiness panel and publish flow (AC: #1, #2, #3, #5, #6)
  • Render readiness panel listing missing required fields as jump-links that scroll/focus the target field
  • Enable the Publish action only when readiness is "Ready to Publish"
  • Build a SafeCommitRail UI component (shared, not feature-specific) that displays overall status, blocking reasons with one-click corrective action links, and a reason-code selector when required (UX-DR4)
  • Keep the confirm button disabled while any blocking issue remains
  • On success, surface a Next Best Action prompt steering the user to service configuration (UX-DR11)
• Tests & evidence (AC: #1–#7)
  • Backend tests for readiness evaluation across missing/complete states, SafeCommitRail check execution, reason-code requirement, audit emission, status transition
  • Reusability proof: an integration test wires the SafeCommitRail module to a non-cycle dummy commit context to confirm Epic 3/5 can consume it without modification
  • Frontend tests for jump-links, enabled/disabled Publish button, SafeCommitRail UI states, Next Best Action rendering
  • Document changed files and any config notes

Dev Notes

• SafeCommitRail must ship as a shared, reusable module from day one. Epics 3 and 5 will consume it; if it lands as election-cycle-specific code it will need to be rewritten.
• The reason-code selector is conditional — only required when audit policy demands it. Do not hardcode it as always-required.
• Jump-links must reference field identifiers stable enough to survive UI restructuring. Avoid CSS selectors as the contract.
• Required-field rules come from the Story 1.9 seed; do not duplicate the rule set inside this story's code.
• “Production Ready” is a status transition out of “In Setup” (Story 2.2). The audit log entry is mandatory for the transition.
• Next Best Action (UX-DR11) is an in-app prompt, not a redirect — keep it as part of the post-publish confirmation surface.

Project Structure Notes

• Backend: Campaign_Tracker.Server/ — place SafeCommitRail under a shared/cross-feature folder (e.g., SafeCommit/) rather than inside the election-cycle feature, to make Epic 3/5 reuse explicit
• Frontend: campaign-tracker-client/ — SafeCommitRail UI lives in a shared component folder consumable by future commits; readiness panel lives with the cycle job detail view
• Story artifacts: _bmad-output/implementation-artifacts/

References

• Story source: _bmad-output/planning-artifacts/epics.md (Epic 2 / Story 2.5)
• Architecture constraints: _bmad-output/planning-artifacts/architecture.md (SafeCommitRail invariants — no bypass for publish-sensitive updates)
• UX patterns: _bmad-output/planning-artifacts/ux-design-specification.md (UX-DR4 reason code, UX-DR11 next best action)
• Prior stories: Story 1.5 — shared audit logging; Story 1.9 — seed system reference values & rule defaults; Stories 2.2–2.4 — cycle job entity, key dates, prior-cycle defaults

Dev Agent Record

Agent Model Used

{{agent_model_name_version}}

Debug Log References

• Story generated from epic source and architecture/UX planning artifacts.

Completion Notes List

• Story context created and marked ready-for-dev.

File List

Change Log