# Initiative Brief: First-Class Release Planning and Cutting in Orchestrator ## Desired outcome Create a release-management capability that allows an operator to: * Identify completed work that has not yet been released. * Group one or more completed initiatives into a logical release. * Determine which repositories participate in that release. * Review initiative and repository readiness before release. * Capture the exact repository state that will be released. * Assign or propose release versions/tags. * Generate editable release notes. * Explicitly cut/publish the required GitHub Releases. * Observe the outcome of the release operation. * Retry or recover from partial failures safely. * Preserve a durable record of what was included in each release. The feature should integrate naturally with Orchestrator's initiative lifecycle without making releases mandatory during initial initiative planning. ## Rejected / deferred alternatives - The initial implementation does not need to provide: - A general-purpose CI/CD platform - Full environment promotion pipelines - Release trains - Scheduled release windows - Automated production rollback orchestration - Package-registry management - Automatic semantic-version calculation from conventional commits - Public changelog publishing - Customer communication workflows - Organization-wide change-management governance - Strict transactional release across multiple repositories These may be considered future roadmap items if experience demonstrates a need. ## Expected behavior - The initiative is complete when: - Orchestrator has a first-class Release domain model. - Releases can contain multiple initiatives. - Releases can span multiple repositories. - Repository-specific versions/tags and release status are represented. - Completed/unreleased initiatives can be identified for release planning. - Initiative assessment state contributes to release readiness. - Reasonably complete initiatives with deferred roadmap work can remain releasable. - Release preparation captures immutable repository SHAs/refs. - Release notes can be generated and edited. - The UI provides release list, release detail, readiness, and explicit release actions. - Orchestrator can create/publish GitHub Releases against the intended repository refs. - Existing GitHub Release-triggered deployment workflows remain the downstream deployment mechanism. - Multi-repository partial failures are persisted accurately. - Failed release operations can be safely retried without duplicating successful releases. - Released records preserve an auditable snapshot of initiatives, repository refs, versions, actors, and timestamps. - Appropriate automated tests cover release lifecycle, readiness, snapshotting, GitHub integration, idempotency, and partial-failure recovery. - Existing initiative planning/execution behavior continues to function without requiring every initiative to be assigned to a release.