Skip to content

Release 2.1.53 (2026-11-01)

Documentation

  • warn that changing an existing marketplace ref needs the switching procedure (#871)
  • cover picking up a release or a v2.1 rollback in Update and Verify (#872)
  • docs(readme): cover picking up a release or a v2.1 rollback in Update and Verify

Replace the in-session marketplace-update and reload sequence with the fleet pick-up path (vrg-host plugins, vrg-vm update --all, then a new session), link the vergil-tooling rollback runbook, and verify against the release v2.1 points at with claude plugin list --json instead of the newest cached directory. Point the CLAUDE.md line at the Update section for releases and rollbacks. Ref #860

  • docs(readme): guard the v2.1 lookup, note --plugin-dir sessions and link the pick-up runbook

The expected-version lookup now stops when the v2.1 ref is not found instead of printing every tag, and says what output to trust. Verify notes that a Lima session loading a vergil tree with --plugin-dir runs that tree, and References links the runbook's pick-up section. Ref #860

  • docs(readme): say why the in-session refresh pair is not the route, read tags from the canonical repo

The Update section now says to use the fleet commands rather than the in-session marketplace-update and reload pair, which does not switch a changed ref or verify anything. The expected-version lookup reads the canonical repo URL instead of a checkout's origin, and the recovery step names vrg-vm update --all and a re-check. Ref #860

  • docs(readme): tighten the Verify steps: every install entry, branch shadowing, restart and stopped VMs

Verify now says every vergil@vergil-marketplace entry (user and project scope) must match, and the tag lookup stops if a v2.1 branch exists. Update says to end running sessions, and that vrg-vm update --all skips stopped VMs. The --plugin-dir Lima paragraph moves out of this change. Ref #860

  • sweep plugin-distribution docs for the v2.1 tag, rollback and verified refresh (#873)
  • docs(readme): note that a --plugin-dir Lima session bypasses the installed plugin

A Lima vrg-vm session that loads a vergil tree listed in plugin-dirs.toml runs that tree, so a release or rollback does not reach it. Link the vergil-tooling runbook paragraph rather than restating it. Ref #869

  • docs(site): say how a machine picks up a release or rollback

The site's install page described the v2.1 tag and switching, but not the refresh. Name vrg-host plugins and vrg-vm update --all and link the README Update section. Ref #850

  • docs(site): name vrg-promote and the refresh's verification on the install page

Say that a rollback is vrg-promote, a human-gated act, and that vrg-host plugins and vrg-vm update --all refresh and verify the registered repo and ref, refuse an agent identity, and cannot prove a move on their own. Ref #850

  • docs(site): name the stopped-VM and --plugin-dir caveats in the site's Updating section

The README section the site points to covers both; say them briefly so the summary does not overstate what the two commands reach. Ref #850

Features

  • creating an issue needs the human's approval (#870)
  • feat(skills): creating an issue needs the human's approval

State the approval default and its three exemptions once in doctrine section 1.7, and define the operational state directory for security items found by issue-validate and issue-deploy. issue-implement, epic-implement, issue-deploy, issue-validate and the operational lifecycle list follow-ups under 'Awaiting a ruling' instead of filing them; issue-implement lists a discovered operational need instead of minting it; the FAILURE fix task is listed as filed without a ruling. epic-retrospective lists untracked problems in its draft, files only approved ones, records a security-class problem only on a record ruling, and its sweep recognises the closed ruling words, the 'Ended by a recorded ruling' list, 'Awaiting a ruling' lists and the 'Filed without a ruling' list. Ref #853

  • docs(skills): define how rulings on listed items are carried out

Runs dispatched with rulings only carry them out and stop, in issue-implement and the operational lifecycle. Items are screened before they are listed, rulings come only from the human in the conversation or the dispatch, and recorded ruling lines never authorize an action. IDs continue per issue, a ruling joins an unfinished response comment, the operational fix task is filed before the result comment that lists it, kept operational files carry a Kept line, and the retrospective sweep reads the epic issue and closes items on any closing ruling. The operational directory is defined by reference to the upstream-report rules. Ref #853

  • docs(skills): tighten the order and inputs of the issue-approval steps

The operational fix task is screened, searched for and filed before the result comment that records the FAILURE outcome, and the outcome is posted even if filing fails. Rulings-only runs take each item only from their prompt, run one at a time per task, and report a ruling they could not carry out instead of recording it. Ruling lines for listed items have a fixed form, item IDs count only trusted comments, items found before the review gate do not pause it, and operational details files are named security-.md and their directory removed once empty. epic-implement confirms an operational directory's listing before any operational dispatch, and the retrospective sweep closes an item only on a ruling word that ends it, in the same comment or a later one. Ref #853

  • docs(skills): close the remaining gaps in the issue-approval steps

Record a reused or unfiled FAILURE fix task, keep a security-class failure's result to the outcome, neutral evidence and a count, and record security rulings outside a review round as a counts line only. Scope section 1.7's ruling-line form to items outside a round, give security items their own private IDs, and have a rulings-only run skip rulings already recorded, never run beside another run of the same task, record what it carried out and report what it could not. A fix ruling on a reported-ready task is ruled file instead. The operational skills point their rulings-only exit at the lifecycle. Ref #853

  • docs(epic-retrospective): treat an unfiled FAILURE fix task as untracked in the sweep

A Filed without a ruling entry marked not filed names no issue, so the retrospective sweep reports it unless a later issue tracks it. Ref #853

  • docs(skills): complete the rulings-only run rules and record each security record by ID

issue-implement's rulings-only run states the same rules as the doctrine and the lifecycle: skip rulings already recorded, never run beside another run of the task, and have the human rule file for a fix on a reported-ready task. Only a trusted author's line suppresses a ruling. Each record made outside a review round posts a Recorded line with its ID and is checked for one first, private security IDs continue past the task's private files and recorded IDs, the counts line uses section 3.5's form, a security-class FAILURE keeps its details with a Kept line, and a long lifecycle line is wrapped. Ref #853

CI Evidence: All gates passed — full audit bundle available. Download →