Sprint Deploy Pm
Sprint-deploy ritual for Marcus (PM). Validates sprint complete; archives sprint.json + progress.txt with timestamp; bumps status…
---
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
mainordev(sprint-deploy runs FROM asprint/*branch) - Sprint branched off stale
devtip (merge-base ≠ currentdevHEAD; ask CIO whether to rebase the sprint branch onto current dev or merge through with awareness) - Any story has
passes: falseANDstatus: pending(sprint not actually done) sprint_lint.pyshows errors (US-274 phantom-path / US-282 commit-vs-claim drift / missingvalidationblock per Sprint 28+ requirement)ralph_agents.jsonis corrupt (runrepair_ralph_agents.pyfirst)
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.