Sprint Deploy Pm

Sprint-deploy ritual for Marcus (PM). Validates sprint complete; archives sprint.json + progress.txt with timestamp; bumps status…

mcornelison updated 29d ago
Claude CodeGeneric
View source ↗
---
name: sprint-deploy-pm
description: "Sprint-deploy ritual for Marcus (PM). Validates sprint complete; archives sprint.json + progress.txt with timestamp; bumps status fields; merges sprint to dev; bumps RELEASE_VERSION on dev; deploys Pi + server FROM dev. Does NOT merge to main -- /chain-validated does that at chain end. Per CIO 2026-05-23 directive #1 + spec 2026-05-28: main = fully validated stable; dev = integration branch. Run after Ralph finishes a sprint when CIO directs sprint-close + deploy. NEVER run mid-sprint while Ralph is working."
---

# Sprint Deploy (PM-driven, dev/main workflow per spec 2026-05-28)

End-of-sprint deployment ritual for Marcus (PM). **Replaces the prior sprint-branch-deploy pattern.** Per spec `docs/superpowers/specs/2026-05-28-dev-main-branching-workflow-design.md`: main = fully validated stable (untouched between chain merges); `dev` = integration branch carrying the active V0.X.Y chain. Sprint branches merge into `dev` on code-complete; deploy + IRL validation target `dev`. `/chain-validated` merges `dev` → `main` at chain end.

**WHEN to run**: CIO explicitly directs sprint-deploy after Ralph finishes a sprint (all stories `passes:true`).

**WHEN NOT to run**: mid-sprint (Ralph still iterating); during a SEV-1 hotfix on `main` (uses separate hotfix path per spec §8.2); when sprint contract has unresolved blockers active.

**Critical workflow rules (spec 2026-05-28)**:
- This command merges sprint → `dev` (Phase 3.5) and deploys from `dev`. It does NOT merge to `main`.
- After deploy, the sprint enters "awaiting validation" state on dev. CIO + drill runner exercise sprint.json `validation.bigDefinitionOfDone` IRL.
- `/sprint-validated` then stamps the sprint validation (no further merge).
- `/chain-validated` merges `dev` → `main` once the whole V0.X chain is whole-green.
- If a drill reveals a regression: a NEW patch sprint forks from `dev` → fix → re-run this command with V0.X.(Y+1) patch bump. Loop until validated.

---

## Phase 0 -- Pre-flight gates (HALT-EARLY)

```bash
git status --short                                   # working tree clean except known noise
git branch --show-current                            # MUST be the sprint/* branch (off dev)
git fetch origin dev                                 # refresh dev ref
test "$(git merge-base HEAD origin/dev)" = "$(git rev-parse origin/dev)" \
  || echo "WARN: sprint branched off stale dev tip"
python offices/pm/scripts/pm_status.py | head -25    # confirm stories all passes:true
python offices/pm/scripts/sprint_lint.py             # MUST be 0 errors
python offices/pm/scripts/repair_ralph_agents.py --check   # ralph_agents.json valid

Stop conditions -- abort + report to CIO if:

  • Branch is main or dev (sprint-deploy runs FROM a sprint/* branch)
  • Sprint branched off stale dev tip (merge-base ≠ current dev HEAD; ask CIO whether to rebase the sprint branch onto current dev or merge through with awareness)
  • Any story has passes: false AND status: pending (sprint not actually done)
  • sprint_lint.py shows errors (US-274 phantom-path / US-282 commit-vs-claim drift / missing validation block per Sprint 28+ requirement)
  • ralph_agents.json is corrupt (run repair_ralph_agents.py first)

Phase 1 -- Status field hygiene

python offices/pm/scripts/bump_passed_statuses.py
python offices/pm/scripts/sprint_lint.py    # re-verify 0 errors

Phase 2 -- Archive sprint.json + progress.txt

python offices/pm/scripts/archive_sprint_artifacts.py

Stop condition: exit 2 means timestamp collision (re-run within 1 sec); abort + investigate.


Phase 3 -- Update PM artifacts

3a -- offices/pm/backlog.json

Bump the active B-XXX phase entry to awaiting-validation (NEW status; was in_progress -> complete under prior workflow). Add currentVersion field tracking the version on disk.

"engine-on-critical-path": {
  "status": "awaiting-validation",        // NEW status; bumps to "complete" only on /sprint-validated
  "sprint": "Sprint 27",
  "branch": "sprint/sprint27-engine-on-fixes",
  "createdDate": "2026-05-08",
  "currentVersion": "V0.27.0",            // bumps to V0.27.1+ on each deploy iteration
  "validatedAt": null,
  ...
}

3b -- MEMORY.md

Update Current State to "Sprint X DEPLOYED V0.X.Y -- AWAITING VALIDATION (real-hardware drill pending)".

3c -- offices/pm/projectManager.md

Last Updated header + Current Phase descriptor. Insert Session narrative.


Phase 3.5 -- Merge sprint branch into dev (NEW per spec 2026-05-28)

Stage all relevant files on the sprint branch BEFORE merging, so the sprint-close commit body carries the PM artifacts (sprint-close exception to PM Rule 8 dev-only-domain):

git add -A -- offices/ src/ tests/ scripts/ deploy/ specs/
git reset HEAD -- offices/pm/.claude/ offices/ralph/.claude/ offices/tuner/.claude/   # drop drift
git commit -m "feat(sprint-N): <Sprint Name> SHIPPED N/N -- code-complete on sprint branch"
git push origin sprint/sprintN-<phase-name>

Then merge into dev:

git checkout dev
git pull origin dev                                  # confirm dev base hasn't moved unexpectedly
git merge --no-ff sprint/sprintN-<phase-name> \
  -m "Merge sprint/sprintN-<phase-name>: <Sprint Name> code-complete N/N (V0.X.Y on dev)"
git push origin dev

Stop condition: git pull brings unexpected commits onto dev (someone else pushed a hotfix or parallel sprint). Investigate before merge.

Note: this replaces the old Phase 4 "sprint-deploy commit on sprint branch" pattern. The merge commit IS the sprint-deploy record now. Do NOT merge to main here -- that's /chain-validated's job at chain end.


Phase 4 -- (RETIRED under dev/main workflow)

Phase 3.5 above absorbs the sprint-deploy commit semantics via the merge to dev. PM artifact commits (sprint.json, projectManager.md, MEMORY.md) ride on the sprint branch up to the merge ```

Maintain Sprint Deploy Pm?

Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.

[Sprint Deploy Pm on getagentictools](https://getagentictools.com/loops/mcornelison-sprint-deploy-pm-driven-dev-main-workflow-per-spec-2026-05-28?ref=badge)
npx agentictools info loops/mcornelison-sprint-deploy-pm-driven-dev-main-workflow-per-spec-2026-05-28

The second line is the CLI lookup for this page — handy in READMEs and docs.