SOP-DEV-release-readiness-v1.0¶

1. Purpose¶

Define the gate between "feature complete" and "released to production." Release readiness is not the same as QA signoff — it is the broader check that everything surrounding a release is in order: open bugs, documentation, stakeholder notification, and rollback readiness.

Applies to: Any production deployment to a customer-facing or agent-operational system (ecomonetize.com, eco-monetize.github.io, Monday.com integrations, pipeline automations, agent tools). Does not apply to development-only deployments to non-production environments.

2. Release Readiness Checklist¶

CDO (or delegate) verifies all items before authorizing a production deploy:

Technical Gate¶

[ ] All QA signoffs complete (SOP-DEV-qa-signoff-v1.0) — no open FAIL criteria
[ ] No open SEV1 or SEV2 bugs in the affected codebase (SOP-DEV-bug-triage-v1.0)
[ ] Feature branch merged to main per SOP-DEV-implementation-workflow-v1.0 Phase 7
[ ] Branch deleted, no dangling feature branches associated with this release
[ ] Credential check passed — no plaintext secrets in changed files (per SOP-OPS-credential-management-v1.0 Section 6)

Documentation Gate¶

[ ] Documentation completion confirmed (SOP-DEV-documentation-completion-v1.0 signoff)
[ ] Agent contracts updated if agent capabilities changed
[ ] SOPs updated if workflows changed
[ ] README or integration guide updated if external surface changed

Operational Gate¶

[ ] Monday.com items for all features in this release marked Done with completion notes
[ ] Rollback plan documented (git revert commit reference, estimated revert time, who executes)
[ ] Post-release monitoring window defined (who watches what for how long)

3. Release Authorization¶

Scenario	Authorization required
Routine feature release (single feature, no SEV1/2 open)	CDO approval
Multi-feature release or architectural change	CDO + CEO awareness (brief message in `#exec-checkins`)
Hotfix release (SEV1 bug in production)	CDO approves; CEO notified simultaneously
Release affecting customer-facing offer page or pricing	CMO + CEO must confirm before deploy

Authorization is logged in the release commit message and the relevant Monday.com item as a completion note.

4. Release Communication¶

When a production release completes:

code.platform confirms live state and runs a smoke test (5-min check of primary user paths)
code.platform posts to #agent-handoffs: ✅ RELEASE LIVE — {feature name/s} — {date/time} — smoke test: PASS/FAIL
If release changes agent capabilities: CDO notifies the affected agent via session-dir drop per Section 9
If release is customer-facing: CRO is notified so they can reference it in prospect or customer conversations

5. Post-Release Monitoring Window¶

For any production release: - Standard releases: 24-hour monitoring window. code.platform watches for errors, broken integrations, or unexpected behavior. Any SEV1/2 finding triggers immediate rollback. - Hotfix releases: 4-hour monitoring window with heightened attention. - Architecture releases: 48-hour monitoring window with CDO on call.

Monitoring results logged as a Status Report update in the associated Monday.com item.

6. Rollback Procedure¶

If a production release causes a regression or SEV1/2 incident:

git revert {commit} — do not force-push
Deploy reverted version immediately (no QA gate required for emergency rollback)
File SEV2 Incident Report per SOP-EXEC-escalation-incident-handling-v1.0
Notify CDO and chief.staff via #agent-handoffs
Root cause analysis before re-release

Change Log¶

Version	Date	Change
v1.0	2026-04-21	Initial draft — sop.manager.

Owner: cdo Executive sponsor: cdo Drafted by: sop.manager Status: Draft — pending CDO review + approval Version: v1.0