elsa-release

# Elsa Release “Release Elsa <version>” means release **elsa-core**: one tag, one GitHub release and one set of release notes. Studio, Extensions and Apps are folded into elsa-core and have no stages of their own. The only separate package stage is `Elsa.Templates`, which keeps its own repository, source policy and release. After that, complete the configured post-release website/documentation refresh and announcements. Read [the runbook](references/runbook.md) and [post-release site guidance](references/post-release-sites.md) before execution. They contain the commands, repository profile, prerequisites, content audit, validation and recovery procedure. Read [release-note guidance](references/release-notes.md) when preparing notes. ## Standing order: folded repositories are off limits `elsa-workflows/elsa-studio`, `elsa-workflows/elsa-extensions` and `elsa-workflows/elsa-apps` are folded into `elsa-core`. Never open PRs, issues, branches, comments or releases there, never push, merge, review or clone them, and never dispatch their workflows. All release work goes through `elsa-workflows/elsa-core`. `elsa-gitbook` and `elsa-templates` are not folded and keep their current role. ## What core publishes today (verify against `origin/main` before relying on it) - `.github/workflows/packages.yml` runs on `release: published`, pushes to `main` and `release/*`, and `workflow_dispatch`. A release or push only tests, builds and uploads the `elsa-nuget-packages` artifact. It never publishes. Publication needs an approved `workflow_dispatch` with `publish_preview_feedz` (Feedz: a branch, or a `3.10.x` tag) or `publish_nuget` (nuget.org: a release tag that is not `3.10.x`). `3.10.x` tags are Feedz only. - The workflow's `./build.sh Compile+Pack` packs Core only. The Studio and Extensions projects are in `Elsa.sln` but stay `IsPackable=false` unless the consolidated proof or release-candidate switch is set. The full set including Extensions and Studio (225 IDs in the reviewed inventory baseline; 233 in an evaluation of `origin/main` at 6ba8e063f) comes only from the consolidated candidate pipeline; the runbook says how to reconcile the two. The whole-product 3.10.0 candidate is prepared by `prepare-consolidated-release-candidate.yml` and published, behind native approval, by `publish-consolidated-original-candidate.yml`. Neither is part of the ordinary release-train helper. - `studio-npm-pair.yml` only proves that the two Studio npm archives can be built and consumed locally. Nothing in core publishes them to npm or Feedz yet. Packing Studio and Extensions through `packages.yml`, publishing the npm pair, and the pack guards are tracked in [#8725](https://github.com/elsa-workflows/elsa-core/issues/8725). Do not claim that they work; report them as pending #8725. - The Apps container workflow lived in `elsa-apps` and core has no replacement yet. The container stage is blocked until it is re-homed in core. ## Interpret the request - A plain version such as `3.10.0` means stable. `3.10.0-rc1` means RC; `3.10.0-preview.1` means preview. RC and preview are both GitHub prereleases; an unspecified “prerelease” channel means preview. Reject contradictory version/kind combinations. If a prerelease number is omitted, inspect existing tags and use the next unused number for the named series; record the exact choice before mutations. - Default scope is Core, then Templates. Honor a named subset; verify any upstream packages it needs without publishing anything outside the requested scope. Templates verifies the published Core packages it embeds. - Default source for Core is the freshly fetched `origin/release/<base-version>`, or `origin/main` for a line that has not branched. Templates follows its documented repository policy: stable releases use freshly fetched `origin/main`, while RC/preview releases use `origin/release/<base-version>` or an explicit source override. Never use the caller's checkout HEAD as an accidental source or silently publish a preview from Templates `main`. - Default to curated notes against the previous stable version for stable releases; for RC/preview use the previous release in that version's series, or the previous stable if this is the first. One set of notes covers everything in the Core release, including the Studio and Extensions changes. Do not write separate Studio or Extensions notes. - Container images: the container stage is blocked (see above). Do not dispatch anything in `elsa-apps`. Record the limitation instead of claiming images were released, unless the user explicitly asks to skip containers (`--no-containers`). - The default post-release scope is both the official Elsa Hub website and the Elsa GitBook documentation. A subset limits the content claims and receipt scope to the selected packages; it does not silently publish an unselected package. Use `--no-post-refresh` only when the user explicitly excludes this phase. For an existing completed checkpoint, use explicit `adopt-post-refresh --targets website` for a website-only follow-up. - A specific prerequisite such as “after PR #123 merges” is part of this release plan. Check that it is merged and included in the selected source. Do not infer that every open PR is a prerequisite or merge unrelated PRs. “Wait for” does not by itself request implementation of the prerequisite. - Maintenance releases for 3.9 and earlier Studio, Extensions and Apps packages came from the original repositories. Those repositories are now off limits. Do not run them. A request for such a release needs a new decision from the user about where it can be built. ## Authorization and defaults An explicit end-to-end release instruction authorizes the defined release operations: required dependency edits, validation and integration into the intended release branches, immutable tags, GitHub publication, routine content updates and deployment or normal documentation PR integration, and the standard release announcements. It does not authorize an unrelated redesign, promotion of unrelated pre-existing Lovable drafts, or a protection bypass. Present the concrete source/version/notes and dry-run result as a progress update; do not ask again for authorization already supplied by that instruction. Never interpret a request to assess, plan, or dry-run as authorization to publish. Honor overrides such as “Core only”, “without announcements”, “without the website/docs refresh”, “draft announcements”, or a different source/channel. `--no-post-refresh` and `--no-announcements` are independent. For a standalone announcements request, use the authorization rules in the announcement skill. Ask only for missing intent that materially affects the release, a genuine new scope decision, or access that prevents completion. Do not weaken checks to avoid a question. ## Execution invariant **Core release (one tag, one GitHub release, one set of notes) → verify its configured feeds → align and validate Templates → release it and install and smoke-test the published Templates package → container stage (blocked, see above) → refresh and live-verify the website and documentation → announce and verify posts.** The runbook's checkpoint helper, `release_train.py`, still defaults to the retired four-repository maintenance profile (`references/elsa-profile.json`). It has not been reworked for a core-only train. Use it for the Core stage only, never for Studio, Extensions or Apps, and treat its container, Studio and Extensions gates as retired. Do not select `templates` in it yet: the profile declares `studio` as a Templates upstream, so the helper would read the `elsa-studio` repository. Run the Templates stage by hand per the runbook until the profile gets a core-only upstream for it. Codex performs the indicated step, using `release.py` for publication and connectors for social posts. Keep only one owner for mutations. Preparation and independent review can run in parallel; dependency publication cannot. ## Completion and recovery - A green upload job is insufficient: verify the expected package inventory, versions, source commits, dependencies, and actual feed content. Studio npm artifacts and `latest`/`next` are not yet published by core; report that as pending #8725 rather than as verified. Container images need their own exact workflow/artifact, package-version, live registry digest/platform, and per-platform smoke verification, and no core workflow produces them yet, so report that as a limitation. - Bind exact source commits and reviewed manifests/notes before publication. Preserve existing tags; matching releases are reusable, conflicting releases require investigation. - If the original run has exactly one configured NuGet publishing failure, use only the runbook's validated `record-recovery` receipt plus the downloaded machine-readable recovery evidence from the reviewed workflow source. Independently anchor the recovery workflow tree to an approved commit in the live canonical default-branch history. Preserve the failed run and tag; reject any other failed job, unknown or renamed recovery job, retag, rebuild, artifact mismatch, forged evidence, or blanket skip, and then perform normal package verification against the recovery run. - Resume by inspecting live GitHub state and recorded package/post evidence. Do not recreate tags or repost after an uncertain result. Retain run and message IDs; wait on concrete jobs with bounded polling and backoff. - Assess advisory findings during preflight. Record severity, relevant usage, and disposition. Existing warnings are not automatically blockers or automatically accepted forever. Never insert an unvalidated dependency upgrade into a release to suppress a warning; a new material unresolved risk requires a concrete scope decision. - After package verification, invoke [Elsa Release Announcements](../elsa-release-announcements/SKILL.md). Default to publishing now on Discord, LinkedIn, and X. Draft-only is an explicit override, not completion of a request to announce. - Before announcements, complete the post-release site phase using receipts that identify the exact target, version, selected scope, changed public URLs, deployment/commit, and live production evidence with a timestamp. A queued Lovable operation or merged docs PR alone is not completion. Stable updates must preserve current stable guidance; prereleases must remain visibly labelled and never replace the latest stable recommendation. - Complete only after every selected release and required feed, every container image once a core workflow exists for them (until then, state that none was released), every enabled post-release target, and the requested announcements are verified sent (and Discord crossposted). Never retag a generic image as `latest` or `4`. State limitations accurately. Stop any follow-up monitor when finished.