diff --git a/AGENTS.md b/AGENTS.md index de5ea94..14926ea 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -16,6 +16,7 @@ - `beta` is a version-tracked prerelease channel for broader testing before stable. - `nightly` is a revision-tracked test channel and may move whenever a new development snapshot is intentionally published. - `main` is for repository integration and developer testing. It is not the default installed-user update channel. +- Release-channel branches are protected. Only an authorized maintainer should move `stable`, `beta`, or `nightly`; do not try to bypass branch protection. - Database migrations are append-only once they have shipped on a public channel. Do not rename, remove, or rewrite a migration that may already have been applied by a user. - Channel-switching must remain schema-safe. If a change adds migrations, preserve the compatibility checks and downgrade guard, update docs, and recommend a backup before users move across channels. @@ -28,5 +29,6 @@ - After a release PR is merged, publish the requested channel only when release publication is explicitly confirmed. Publishing means moving the channel branch to the merged release commit and, when requested, creating the release tag. - When asked to publish or release any revision-tracked channel, such as `nightly`, do not bump `vibestackRelease` unless the user explicitly asks for a versioned release. Move the requested channel to the requested commit or to current `main` after confirming the target commit. - When asked to promote one channel to another, for example `nightly` to `beta` or `beta` to `stable`, verify both branch heads and move the target channel branch to the exact source channel commit. Do not create a merge commit between channel branches. +- Because channel branches are protected against force pushes, publish and promote channels by fast-forwarding them to commits that descend from the current channel head. If a rollback or non-fast-forward move is required, stop and ask the maintainer to explicitly approve the temporary branch-protection change and rollback target. - If the user names an unrecognized channel such as `testing`, first check whether `origin/` exists and whether docs identify it as version-tracked or revision-tracked. If it does not exist or its tracking policy is unclear, ask whether they mean an existing channel or want a new version-tracked or revision-tracked channel. - Never move `stable`, `beta`, or `nightly` as part of an ordinary feature PR. diff --git a/docs/release-process.md b/docs/release-process.md index 184b656..32dcd65 100644 --- a/docs/release-process.md +++ b/docs/release-process.md @@ -11,6 +11,8 @@ VibeStack separates repository integration from installable releases. Do not use release-channel branches as normal pull request targets. They should move only when maintainers intentionally publish a channel update. +Release-channel branches are protected. Currently only the maintainer account `dankritz` may move `stable`, `beta`, or `nightly`; force pushes and branch deletion are disabled. As more maintainers are onboarded, add them or a release automation app to the branch protection allowlist rather than weakening the channel protections. + If someone names a channel that is not listed here, such as `testing`, first verify that `origin/` exists and whether project docs identify it as version-tracked or revision-tracked. If the branch does not exist or the tracking policy is unclear, ask whether they mean an existing channel or want a new version-tracked or revision-tracked channel. ## Versioning @@ -67,6 +69,8 @@ Do not move version-tracked channels from a release-prep branch. They move only After the release pull request is merged, publish only when explicitly confirmed. +Publish channels with fast-forward moves only. If a channel must be rolled back or moved to a commit that does not descend from the current channel head, treat that as an exceptional recovery operation: identify the exact rollback target, temporarily adjust branch protection only after explicit maintainer approval, move the branch, and restore protection immediately. + For `beta`, move the `beta` branch to the validated release commit. For `stable`, move the `stable` branch to the release commit after the release is approved for production users.