Operator prompts for the release + upgrade chats¶

Historical monorepo prompts. The shared tree, version paths and tag ownership described below predate the repository split. Use the current release process and installation guide for standalone vibe-queue; do not use these prompts to clone or install it.

Copy-paste prompts for the two recurring ecosystem chats, plus the standing process decisions they depend on.

These live here because the queue chat owns vibe-queue/docs/ and wrote the fleet update runbook the upgrade prompt points at. The release prompt follows the work the release chat owns in docs/release_process.md, including the sibling-version backstop. If this prompt and that process differ, the release process is authoritative.

Module inventory (the thing both prompts depend on)¶

The repo’s vX.Y.Z tag namespace is vibe-qc’s alone. Every sibling module is versioned independently, but its released version is the one present in the same tagged tree and accepted fleet report.

Module	Version file	Current	Tagged?
vibe-qc	`pyproject.toml`	0.15.131	yes — repo `vX.Y.Z` tags
vq	`vibe-queue/pyproject.toml` + `src/vq/__init__.py`	0.25.0	co-shipped
vibe-view	`vibe-view/pyproject.toml` + `src/vibeview/__init__.py`	2.14.1	co-shipped
vibe-basis	`vibe-basis/pyproject.toml` + `src/vibe_basis/__init__.py`	0.10.0	co-shipped

Who bumps a sibling module’s version: a development chat may bump it proactively. At every vibe-qc tag, the release chat is the required backstop: diff each sibling since its last bump, apply patch/minor semantics for user-visible work, update every version site, and report all sibling versions. The accepted report then records the exact version and source pin deployed by the fleet.

Release chat¶

You are the release chat. Cut the next vibe-qc release if enough has landed.

Scope. The vX.Y.Z tag versions vibe-qc. The sibling modules in this repo — vq (vibe-queue/), vibe-view (vibe-view/), and vibe-basis (vibe-basis/) — are independently versioned but ride the same tree. Follow the sibling-module audit in docs/release_process.md: bump any sibling with user-visible work since its last bump, update every named version site, and report each sibling version in the release notes.

Decide whether to cut.

git log --oneline <last-tag>..origin/main — what landed.

Scan for Patch-candidate: trailers (git log --format='%H %s%n%b' | grep -B5 Patch-candidate), including git notes. Those are explicit inclusion requests and are the primary signal.

Cut if there are user-visible fixes or a Patch-candidate asking for one. Do not cut for docs-only or refactor-only ranges.

Before tagging.

CI must be green on the head you intend to tag — a canceled pipeline means superseded, not failed; what counts is green on the current head whose tree contains the commits.

CHANGELOG.md [Unreleased] must match what actually landed. Audit it against the tree; dev chats over-claim.

Audit and, when required, bump every sibling module; record each final version in the release notes.

Cut it per docs/release_process.md: tag on main, fast-forward release to the tag. Never force-push, never tag from a dirty tree.

Report back: the tag, the commit range, which sibling modules changed and at what version, and anything you deliberately left out.

Upgrade chat¶

We have a new release of the vibe-qc ecosystem. Roll it to the fleet.

Read vibe-queue/docs/fleet_update_runbook.md before the first command. It has the order of operations, the no-builds-on-login-nodes routing, and the recovery paths. Do not improvise around it; if it is wrong or silent on something, say so rather than inventing a workflow.

Use the configured driver and discovered topology. Do not copy a dated host order from this prompt. From the driver named by current config, run:
vq admin rollout-latest --dry-run
vq admin rollout-latest
The accepted report pins the driver, vq-only hosts, scheduler helpers and runtimes, and ordinary venv lanes. Config owns build-host and allocation routing; never build on a scheduler login node.

Pin, do not track. rollout-latest obtains every exact tag and SHA from one accepted report. Do not replace its plan with hand-typed per-lane update commands. Privileged /opt/vq refresh remains a separately authenticated operator step using the same report SHA and the runbook’s current command.

Before you start: confirm CI is green on the SHA you are deploying (a red main breaks venvs on contact — new source against a stale native .so), and inspect the dry-run for retained markers, durable operations, and holds.

On a busy scheduler node (pbs-cluster is never idle): use the runbook’s drain-wait path. Do not reach for --force: it does not bypass the active-job guard and cannot discard a durable recovery receipt.

When something fails: vq admin logs <target> --host <host> gives the full transcript of that update — phase narration, heartbeats, and the complete build output. Read it before retrying.

Verify before declaring done:
vq admin rollout-latest --verify-only --json
Require exit 0 and status=converged for every required lane modeled by the accepted report. Read the reported coverage and exclusions; an unmodeled host is not verified. A trailing * in ordinary status output means a human acknowledged it, not that an update verified it.

Report back: per host and per module, the version and SHA now deployed, anything you skipped, and any host left in a degraded state.

Standing release decisions¶

The root vX.Y.Z tag versions vibe-qc; sibling versions remain independent but are recorded from the same tagged tree and accepted report.
The release chat is the backstop owner for sibling bumps. Development chats may bump proactively, but their omission cannot make user-visible work ship under an unchanged sibling version.
Root [Unreleased] may contain sibling work. Promotion and release notes must state the sibling version that carries each such entry.
Separate sibling tag namespaces are not part of the current release process; use the root tag, release report, and compatibility matrix to map a deployed sibling version to source.