Releases: opencue/gitguardex
Releases · opencue/gitguardex
v7.0.26
GitGuardex v7.0.26
Changes since v7.0.25.
v7.0.26
- Bumped
@imdeadpool/guardexfrom7.0.25to7.0.26so npm can publish a fresh version afterv7.0.25reached GitHub Releases while the registry stayed on7.0.24. - README now documents both
npx skills add recodeee/andnpx skills add recodeee/gitguardex, and explains why the picker showsgitguardexinstead of a separateguardexskill. - Keep the release scoped to version metadata plus the already-merged README installer guidance on
main; no additional CLI/runtime behavior changed in this lane.
v7.0.25
GitGuardex v7.0.25
Changes since v7.0.24.
v7.0.25
- Bumped
@imdeadpool/guardexfrom7.0.24to7.0.25so npm and GitHub Releases can ship the currentmainpayload. - The bundled
GitGuardex Active AgentsVS Code companion now self-heals stale repo-scan ignore settings in older repos, keeps plain managed sandboxes visible in Source Control, and preserves cleanup truth so the tree matches actual sandbox state. - Bumped the shipped Active Agents companion manifests from
0.0.8to0.0.9so local VS Code installs can pick up the newer workspace build and show the refreshed extension version from this release.
v7.0.24
GitGuardex v7.0.24
Changes since v7.0.23.
v7.0.24
- Bumped
@imdeadpool/guardexfrom7.0.23to7.0.24so GitHub Releases and the npm publish retry can advance together afterv7.0.23landed on GitHub but not on npm. - Release verification no longer loses its base ref on tag-triggered runs, so the publish workflow keeps the history it needs before packing and publish checks.
- Keep the release scoped to version and release automation metadata only; the packaged Guardex CLI payload stays aligned with the already-verified
mainbranch contents.
v7.0.23
GitGuardex v7.0.23
Changes since v7.0.21.
v7.0.23
- Bumped
@imdeadpool/guardexfrom7.0.22to7.0.23so GitHub release and npm can advance together after7.0.22reached npm without a matching published GitHub release. - Active Agents stays easier to scan and more truthful: the package repo remains the canonical source, inspect/install paths stay loadable across VS Code churn, and session rows group under worktrees with clearer merged-cleanup truth.
- Guardex prompt and finish guidance now pushes faster phase-based execution, keeps helper behavior single-sourced, and avoids fragmented probe loops when cleanup or branch-deletion races appear.
v7.0.22
- Bumped
@imdeadpool/guardexfrom7.0.21to7.0.22so npm can publish the next release from the current merged mainline. - The shipped
mainpayload already includes lower-token prompt slices, SCM-selected lane visibility, truthful merged-cleanup evidence, the Active Agents brand/icon refresh, and the remaining CLI extraction cleanups without changing Guardex behavior. - Keep the release scoped to version and release metadata only; the package payload stays the same as the verified
mainbranch contents.
v7.0.21
GitGuardex v7.0.21
Changes since v7.0.20.
v7.0.21
- Bumped
@imdeadpool/guardexfrom7.0.20to7.0.21so npm can publish the next release from the current merged mainline. - Keep the release scoped to version and release metadata only; the package payload stays the same as the verified
mainbranch contents. - Published-release automation will pick up this new package version once the matching GitHub release is created.
v7.0.20
GitGuardex v7.0.20
Changes since v7.0.16.
v7.0.20
- The VS Code Active Agents tree now exposes worktree-owned SCM changes and lock ownership directly, so operators can see which sandbox owns a dirty file before they act.
- Guardex now keeps merged cleanup evidence truthful by recording final cleanup proof only after the merge and cleanup state is actually available.
- Install-surface verification cleanup on
mainis easier to maintain without changing the shipped CLI surface. - Bumped the release from
7.0.19→7.0.20so the shipped Active Agents visibility and cleanup-evidence refinements land on a fresh publishable npm version.
v7.0.19
gx setupandgx doctornow accept targeted managed-file recovery after--force, sogx doctor --force scripts/review-bot-watch.shrepairs the named managed file instead of failing on an unknown argument.- Managed-file conflict output now teaches both recovery forms directly:
--force <managed-path>for one file and plain--forcefor whole-surface rewrites. - GitGuardex now keeps small-task routing caveman-only by default and makes working VS Code agent lanes easier to spot at a glance while keeping the CLI-owned install-surface rollout intact.
- Bumped the release from
7.0.18→7.0.19so the shipped setup/doctor recovery and UX refinements land on a fresh publishable npm version.
v7.0.18
- GitGuardex now keeps the install workflow in
gxitself:gx branch ...,gx locks ...,gx worktree prune,gx migrate, and user-level agent-skill install now own the agent lifecycle instead of teaching pasted repo scripts as the primary surface. - Fresh installs switch repo hooks to tiny
gx hook run ...shims, stop copying repo-local workflow implementations and repo-local skills, and stop injecting Guardex-managedagent:*package scripts into consumer repos. gx migratecan move older repos onto the smaller CLI-owned install surface while preserving the managed AGENTS block, lock registry state, hook shims, required gitignore entries, and the repo-local helper assets that still carry local state.- Bumped the release from
7.0.17→7.0.18so the shipped CLI-owned install-surface changes land on a fresh publishable npm version.
v7.0.17
- Restored the published npm package name to
@imdeadpool/guardexafter the@imdeadpool/gitguardexrename only changed the package identity locally and could not rename the existing npm registry entry. - README/install/tutorial/self-update surfaces now point back at
@imdeadpool/guardexwhile keeping GitGuardex as the product/repo brand andgitguardexas the long-form command. - Bumped the release from
7.0.16→7.0.17because@imdeadpool/guardex@7.0.16is already published on npm.
v7.0.16
GitGuardex v7.0.16
Changes since v7.0.15.
v7.0.16
gx doctornow keeps nested repo repair runs visibly progressing, and overlapping integration work stays off the protected base branch instead of trying to merge back onmain.- Cleanup and finish flows are less brittle:
codex-agentno longer waits on PRs that can never exist, and prune cleanup now walks both managed worktree roots so stale sandboxes get removed consistently. - Mirror-sync diagnostics are quieter: when the mirror PAT is unset, Guardex now skips the sync path instead of marking the run red, and shared
ralplanlanes stay easier to identify during handoff/debugging. - Bumped
@imdeadpool/guardexfrom7.0.15→7.0.16after npm rejected a republish over the already-published7.0.15.
v7.0.15
GitGuardex v7.0.15
Changes since v7.0.12.
v7.0.15
gx doctorno longer blocks recursive nested protected-repo repairs on child PR merge waits; nested sandboxes now force--no-wait-for-mergeso the parent repair loop can continue.gx setupcan now refresh managed files from protectedmainthrough a temporary sandbox branch/worktree, sync the managed outputs back to the visible base checkout, and prune the sandbox afterward.- Bumped
@imdeadpool/guardexfrom7.0.14→7.0.15after npm rejected a republish over the already-published7.0.14.
v7.0.14
- Bumped
@imdeadpool/guardexfrom7.0.13→7.0.14after npm rejected a republish over the already-published7.0.13. - No package payload changes beyond the release metadata bump; this release exists so
npm publishcan proceed with a fresh semver.
v7.0.13
gx statusandgx setupnow present the Claude companion asoh-my-claudecodewhile still installing the published npm packageoh-my-claude-sisyphus.- When that dependency is inactive or the user declines the optional install, Guardex now prints the upstream repo URL so the missing dependency is explicit instead of hidden behind the npm package name.
- Bumped
@imdeadpool/guardexfrom7.0.12→7.0.13after npm rejected a republish over the already-published7.0.12.
v7.0.12
GitGuardex v7.0.12
- restart into the installed CLI after a successful self-update so the same gx invocation no longer prints a stale pre-update version
- keep the existing pinned retry guard when npm reports success but leaves old bytes on disk
- bump @imdeadpool/guardex from 7.0.11 to 7.0.12
v7.0.11
GitGuardex v7.0.11
- fix the npm publish workflow trigger so releases run from the published release event or manual dispatch only
- remove the duplicate tag-push publish path that was leaving extra cancelled deployment cards in the npm environment
- bump @imdeadpool/guardex from 7.0.10 to 7.0.11 so the replacement release can publish cleanly after 7.0.10 already landed on npm