/antigravity-maintainer-batch-release

name: antigravity-maintainer-batch-release
description: "Run protected AAS maintainer sweeps, PR merge batches, resumable review, immutable distribution, Core checks, and scripted releases. Use for repository maintenance, main alignment, CLI/MCP/Workbench changes, or release work; not ordinary contribution tasks."
risk: critical
source: self
date_added: "2026-07-18"

Antigravity Maintainer Batch Release

When to Use

Use for AAS maintainer sweeps, PR repairs and merge batches, runtime/catalog releases, installed maintainer-skill alignment, and public deployment verification. Ordinary contributors do not need maintainer privileges.

Operating sequence

1. Preserve dirty work. Use an isolated current-main checkout. Read the exact-base AGENTS.md, `.github/MAINTENANCE.md`, `package.json`, and [maintenance contract](references/maintenance-contract.md). Mandatory tools must exist on that base; never import retired procedures from another checkout. 2. For a source PR batch, inventory its PR numbers, start `npm run maintenance:cycle -- start` on clean current main before content analysis/review, and follow the [complete cycle](references/maintenance-cycle.md). The runner measures source maintenance without a release; finish it before release preparation. For a release-only task or a sweep with no PRs, start an explicit empty cycle with `--prs none` and verify it before preparation. Triage the full authorized scope. Repair source PRs, run the component plan, review the entire tracked `skills/<skill-id>/**` subtree, and inspect relevant advisories. Do not substitute a heuristic score for semantic review. 3. Use `maintenance:cycle merge`, which delegates to `merge:batch`, or invoke `npm run merge:batch` directly when no source cycle applies. These share the sole merge authority; do not run both for the same merge. Keep strict protected main and admin enforcement. Safe analysis may precede review; merge still requires current checks and either real Tessl review or exact-head maintainer attestation. Private signed receipts may reuse unchanged content/context review. Preserve owner-only sensitive-change and protected-base fork-ledger restrictions. 4. Use guided intake to collect all blockers, then resume with a private external `--state-dir`. Record each blocker once; after two equivalent unproductive checks, continue independent work. Re-fetch PR state and protection every time. Continue independent PRs after a blocked PR; report failures. Follow the cycle reference’s deterministic failure codes and bounded read retries. Never repeat a write with an unknown outcome, steal an active state lock, or reuse stale CI evidence. Do not rewrite PR metadata, automatically retry base drift, or use GitHub auto-merge. 5. Ordinary source merges generate ephemeral validation state only. Tracked distribution snapshots and contributor credits refresh in the protected release PR; no ordinary canonical-sync PR is required. An explicitly requested no-release dependency repair may synchronize only the existing regular lockfile replicas verified by the trusted-base owner-only contract; every other generated path stays release-owned. 6. Before an authorized publication attempt, run `release:rehearse -- X.Y.Z --state-dir /absolute/private/completed-cycle` on a clean committed descendant of verified main (including a topic branch for diagnosis). This runs the shared local candidate pipeline in a disposable clone without pushing, tagging, publishing or modifying the source/cycle state; see the full local rehearsal contract. A passing rehearsal does not authorize publication. Use the private `--candidate-dir` receipt/promotion flow in the contract to preserve the tested commit and avoid repeating local preparation when its exact source and toolchain remain current. When authorized, use `release:prepare` and `release:publish`. Preparation creates the local release commit, packs its exact sealed tree, runs the complete test suite against that candidate, and pushes only if it passes; do not duplicate its suite with diagnostic preflight. Merge the prepared release PR through protection. Create or reuse the tag, wait for the immutable candidate, then publish and verify the exact npm bytes. Create the GitHub Release only after npm succeeds; Pages then consumes the same tested bytes unchanged. Main may advance while the released commit remains protected ancestry. 7. For compatible catalog-only publication, use the independent catalog workflow and immutable revision/SRI. Preserve offline operation, rollback and agent-owned selection. Do not bump or republish runtime just to update catalog data. 8. Finish a source batch with `maintenance:cycle verify` on exact main CI/CodeQL after all other source-cycle actions. Without publication, stop there: public distribution snapshots intentionally remain at the last release. For releases, complete the full-release-alignment gate in the contract, including actual public bytes and live surfaces. Report personal MCP configuration and session reload separately. Update installed maintainer skills from the adopted canonical source, preserving unrelated installations.

Use the release entry template at the top of the repository's `CHANGELOG.md` for new runtime releases. Preparation and rehearsal validate the target entry before creating a release branch. GitHub publication and the site build use the same changelog entry.

When the user explicitly requests a GitHub release while prohibiting npm publication, `release:publish -- X.Y.Z --skip-npm` performs the same release admission and candidate checks, creates or verifies the tag, skips npm and creates a GitHub Release whose notes explicitly disclose npm unavailability. Verify this explicitly selected target with `release:verify -- --version X.Y.Z --target github-site`. GitHub/site completion is distinct from full npm distribution; excluded npm and local hosts are never reported passed. All applicable public alignment gates remain require