Skip to content

Release 2.1.185 (2026-08-10)

Bug fixes

  • stop treating CWD as authoritative for clone target and resume state (#2719) vrg-github-repo-init derived two things from the current working directory, and both were wrong when run from inside an existing Vergil repo. The resume symptom is the dangerous one: run_wizard read CWD's git log, so an unrelated repo's 'chore(init): step N -' commits were misread as the new repo's progress, silently skipping vergil.toml, config, and CI steps and reporting success. The clone symptom cloned into CWD/ and collided with a legitimate same-named directory, leaving an empty remote behind.

Fixes (all four from the issue): - Resume state is now trusted only when CWD is the target's own clone (or an adopt run); a foreign repo's log is ignored. Removes the silent-misconfiguration path. - step_clone refuses to clone into an occupied, non-clone path and names the resolved path instead of letting git clone raise. - New --target-dir names the clone's parent explicitly (validated: existing dir, not with --adopt). - main refuses a new-repo run launched from inside a different repo before any side effect (notably before the remote is created), unless --target-dir is given.

New helpers cwd_repo_slug() and foreign_repo_refusal() centralize the CWD-vs-target comparison.

  • scope App token to --repo org (also epic-create) (#2723) vrg-triage-create computed the target repo correctly but called github.create_issue without wrapping it in target_org(owner), so _gh_env() fell back to the cwd repo's org and minted the App installation token for the wrong org. A cross-org create then misrouted or misreported the issue's location, and because target_org was unset the require_installation fail-loud guard never fired.

Wrap the create in target_org(owner) derived from the resolved --repo, mirroring vrg-issue-create. Auditing the other create paths surfaced the same gap in vrg-epic-create (repo_visibility + create_issue), which is fixed the same way. Add regression tests asserting target_org is entered with the --repo owner for both commands.

  • emit docs/docs on PR and guard required-context parity (#2726) The CI-gates ruleset and the generated ci.yml are derived from the same identity along two independent paths, and they disagreed about what reports on pull_request. A publish-docs repo required the docs / docs context, but ci.yml never invoked ci-docs.yml (the docs job lived only in the push-triggered cd.yml), so every merge blocked with green checks. render_ci_workflow now emits a docs job calling ci-docs.yml@v2.1 on pull_request whenever publish_docs is set, so the required context actually reports.

Add an init/adopt cross-check (_assert_ci_gates_producible) that fails loudly at step 8 when the CI-gates ruleset requires any status check the generated ci.yml cannot emit on a pull_request, instead of shipping a repository that cannot merge its first PR. The check naturally refuses integration-tests = true, whose test / integration context has no producing job, pointing at #2721 until integration tests are first-class.

Documentation

  • note archiving targets only canonical per-repo ad-hoc epics (#2706) (#2716) Documentation-review bookend of epic #266. Adds a bullet stating that both the batch drain and the on-close event path archive a closed child into its own repo's quarter bucket (keyed on the Epic (ad hoc): title, including public repos homed in .github), and that a special-purpose ad-hoc-labelled epic whose title bare-name is not a real repo is left untouched — reflecting the #2709 hook repo-derivation + non-repo guard fix.

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