Delivery Management
Translate product intent into safe Git/release actions aligned with production facts and rollback. Routine commits do not activate.
Route by Outcome
- Batches, worktrees, hotfixes, merges, multi-agent Git: Code/Merges.
- Cross-session ownership or parallel lines: Change Units.
- Repository topology, projections, release units: Repositories.
- Work/version logs and handoffs: Logs.
- Versions, tags, archives, artifacts: Artifacts.
- Authorization, environments, production, rollback: Authorization.
- Deployment, secrets, security, post-release: Security.
Read-only advice never merges, tags, or deploys. A release entrypoint must be executable. Use Assurance only for disputes/hard gates.
Core Contract
- Recover authority, lines, batch, release unit, authorization, and recovery from owners/Git. Ask only about outcome-changing ambiguity.
- Reuse
in_progress for shared version/acceptance/release/rollback. Isolate real parallel work. Never write integration, reopen sealed work, or chain branches.
- Agent/session changes do not change the Change Unit. Resume it; use recoverable Release Control.
- One item does not complete a batch. Freeze after test/closeout intent; perform authorized local builds/checks; distribute, deploy, verify production changes, and tag under release authority.
- Require
main as integration or release_ready; stack only on sealed parents.
- Keep one mutable release source; verify identity before tags/artifacts.
- Separate candidate, build, deployment, production verification, and version. Tag established facts; preserve rollback.
- No release intent means no release; “do not release yet” persists. Behavior changes require Product; new commits require candidate re-review, not automatic renewal of unchanged task authority.
Handoff implementation to Engineering, scope to Product, and state defects to Workflow.
1---2name: senmu-build-delivery3description: Govern development batches, non-routine Git, repository and release units, artifacts, deployment, rollback, and production state. Not for ordinary implementation.4---56# Delivery Management78Translate product intent into safe Git/release actions aligned with production facts and rollback. Routine commits do not activate.910## Route by Outcome1112- Batches, worktrees, hotfixes, merges, multi-agent Git: [Code/Merges](references/code-management-and-integration.md).13- Cross-session ownership or parallel lines: [Change Units](references/multi-agent-change-units-and-version-line-closeout.md).14- Repository topology, projections, release units: [Repositories](references/repository-boundaries-and-release-units.md).15- Work/version logs and handoffs: [Logs](references/collaboration-and-version-logs.md).16- Versions, tags, archives, artifacts: [Artifacts](references/version-artifacts-and-release.md).17- Authorization, environments, production, rollback: [Authorization](references/release-authorization-and-production-truth.md).18- Deployment, secrets, security, post-release: [Security](references/deployment-testing-and-security.md).1920Read-only advice never merges, tags, or deploys. A release entrypoint must be executable. Use Assurance only for disputes/hard gates.2122## Core Contract2324- Recover authority, lines, batch, release unit, authorization, and recovery from owners/Git. Ask only about outcome-changing ambiguity.25- Reuse `in_progress` for shared version/acceptance/release/rollback. Isolate real parallel work. Never write integration, reopen sealed work, or chain branches.26- Agent/session changes do not change the Change Unit. Resume it; use recoverable Release Control.27- One item does not complete a batch. Freeze after test/closeout intent; perform authorized local builds/checks; distribute, deploy, verify production changes, and tag under release authority.28- Require `main` as `integration` or `release_ready`; stack only on sealed parents.29- Keep one mutable release source; verify identity before tags/artifacts.30- Separate candidate, build, deployment, production verification, and version. Tag established facts; preserve rollback.31- No release intent means no release; “do not release yet” persists. Behavior changes require Product; new commits require candidate re-review, not automatic renewal of unchanged task authority.3233Handoff implementation to Engineering, scope to Product, and state defects to Workflow.
SenMuShare