Wip Ai Devops Toolbox Private

# AI DevOps Toolbox v1.9.72 ## Promote v1.9.71-alpha series to stable Closes #256. Consolidates 21 alpha prereleases (`v1.9.71-alpha.1` through `v1.9.71-alpha.21`) into a stable v1.9.72 release. No code changes beyond the version bump in the toolbox root `package.json`; the sub-tool code has been stable and dogfooded across the alpha iterations. ## Why The root `package.json` had been sitting at `1.9.71-alpha.21` without a stable promotion. That blocked `deploy-public.sh` from syncing the private repo to the public mirror ... the script gates public release on stable root versions. Symptom during 2026-04-21: wip-branch-guard sub-tool shipped stable (v1.9.82 → v1.9.83 → v1.9.84) to npm successfully, but the public `wipcomputer/wip-ai-devops-toolbox` GitHub releases page did not show any of them because `deploy-public.sh` refused to run with an alpha root. ## What's in the diff - `package.json` - Version bump `1.9.71-alpha.21` → `1.9.72` Everything else flows from `wip-release`: - CHANGELOG.md updated - Git tag `v1.9.72` - GitHub release on private repo - npm publish to `@latest` - `deploy-public.sh` runs, syncs private code (minus `ai/`) to `wipcomputer/wip-ai-devops-toolbox` - Public GitHub release created ## Sub-tool versions at this release | Sub-tool | npm version | |---|---| | `@wipcomputer/wip-branch-guard` | 1.9.84 | | Other sub-tools | See their individual `package.json` | The sub-tool releases have their own cadence; this release is purely the toolbox root bump. ## Co-authors Parker Todd Brooks, Lēsa (oc-lesa-mini, Opus 4.7), Claude Code (cc-mini, Opus 4.7).

# Release Notes: wip-ai-devops-toolbox v1.9.68 Closes #239 ## Four-track release pipeline The release tool now supports four tracks: alpha, beta, hotfix, and stable. This replaces the single-track model where every release was public. Alpha is silent (no public release notes by default). Beta publishes prerelease notes to the public repo. Hotfix publishes to npm @latest without syncing code to public. Stable is the full deploy: npm + code sync + release notes. Developers can iterate on private, ship betas to testers, and only go public when ready. Version numbering uses standard semver prereleases: `1.9.68-alpha.1`, `1.9.68-beta.1`. The installer (`ldm install --beta` / `--alpha`) pulls the right tag from npm.

# Release Notes: wip-ai-devops-toolbox v1.9.67 **Date:** 2026-03-30 ## What changed ### Hardcoded path removal Two files in the devops toolbox had paths that assumed a specific username or iCloud layout. **ldm-jobs/backup.sh** referenced `/Users/lesa/Library/Mobile Documents/.../ldm/bin/` to find the `ldm` binary for scheduled backup jobs. This iCloud path was fragile (iCloud sync delays, different usernames). The script now uses `$HOME/.ldm/bin/` which is the standard LDM install location and works on any machine (#301). **test.sh** (the branch guard test harness) had `/Users/lesa` hardcoded for creating temp directories. It now uses `$HOME` so tests run correctly under any user account (#301). ### Earlier changes included in this release **v1.9.66** added auto-combine for release notes from batched PRs (#237). When multiple PRs are merged between releases, their individual RELEASE-NOTES files are automatically combined into a single changelog entry. **v1.9.65** fixed the scaffold-on-main issue (#223) where scaffolding left untracked files that blocked `git pull` on the main working tree. ## Why The backup job is scheduled via LaunchAgent and runs unattended. If the path to `ldm` is wrong, backups silently fail. Moving to `$HOME/.ldm/bin/` aligns with the standard LDM install path and eliminates the iCloud dependency. The test fix ensures CI and local test runs work for all contributors. ## Issues closed - #301 ## How to verify ```bash grep -r "/Users/lesa" ldm-jobs/ tools/wip-branch-guard/test.sh # Should return zero results ```

# Release Notes: wip-ai-devops-toolbox v1.9.66 Auto-combine release notes when batching multiple PRs into a single release. ## The story When multiple PRs merge to main before wip-release runs, the release had no good way to gather all their stories. Each PR might have its own RELEASE-NOTES file committed on the branch, but once the branch merges and the file gets trashed, the next release only sees an empty repo root. The agent had to write a new RELEASE-NOTES file from scratch, losing the narrative that was already reviewed in each PR. Now wip-release looks back through git history. It finds every merge commit since the last tag, checks each one for RELEASE-NOTES files via `git diff-tree` and `git show`, and combines them into a single document. If only one PR had notes, it uses them as-is (fully backwards compatible). If multiple PRs had notes, it wraps them with per-PR section headers, strips duplicate top-level headings, and collects all issue references into a combined list at the end. The detection sits at priority 2.5 in the release notes cascade: after the single-file check (RELEASE-NOTES-v{ver}.md on disk) but before the dev-update fallback. A file on disk always wins. The merged-PR scan only kicks in when nothing is found on disk. ## What changed - New exported function `collectMergedPRNotes()` in `core.mjs` that scans git merge history for RELEASE-NOTES files - Updated `cli.js` to call it at priority 2.5 in the notes detection cascade - Updated help text to document the new detection path - Zero breaking changes. Single-file detection still works exactly as before. ## Issues closed - Closes #237 ## How to verify ```bash # In any repo with multiple merged PRs since last tag, each having RELEASE-NOTES files: wip-release patch --dry-run # Should show: "Combined release notes from N merged PRs" ```

# Release Notes: wip-ai-devops-toolbox v1.9.65 **Fix release notes scaffold on protected branches** When `wip-release patch` runs on main without a RELEASE-NOTES file, it used to scaffold a template directly in the working tree. On repos with branch guards (pre-commit hooks that block commits to main), this scaffolded file could not be removed or committed. It would block `git pull` and leave the working tree dirty. This has happened multiple times across different repos. The fix adds a branch check before scaffolding. If the current branch is main or master, wip-release now prints a clear error telling the user to write release notes on their feature branch before merging, then exits non-zero without creating any files. The scaffold behavior still works on feature branches, where it's actually useful. ## Issues closed - Closes #223 ## How to verify ```bash # On main, without release notes: should error, NOT scaffold cd any-repo && git checkout main wip-release patch # Expected: "Release notes missing. Write RELEASE-NOTES-v*.md on your feature branch before merging." # Expected: no RELEASE-NOTES file created in working tree # On a feature branch: should scaffold as before git checkout -b test/scaffold-check wip-release patch # Expected: scaffolded template created ```

# Release Notes: wip-ai-devops-toolbox v1.9.64 Closes #295 ## Branch guard: allow extension cleanup The branch guard blocked `rm` on deployed extension directories (`~/.openclaw/extensions/` and `~/.ldm/extensions/`) because those paths live inside git repos. But deployed extensions are managed by `ldm install`, not by hand. When a stale `-private` extension needed to be removed (e.g. `wip-xai-grok-private` replaced by the public `wip-xai-grok`), the agent couldn't clean it up without asking the user to run the command manually. Added an allowlist pattern for `rm` targeting `.openclaw/extensions/` and `.ldm/extensions/` paths. Same approach as the existing `.ldm/state/` allowlist. The guard still blocks `rm` on actual repo source files.

# Release Notes: wip-ai-devops-toolbox v1.9.63 **Fix all wip-release errors: branch cleanup crashes, shell injection, stale remote refs.** ## The story Every wip-release run produced errors: "fatal: Not a valid object name +", "remote ref does not exist", and shell injection risks from branch names passed through execSync template strings. These were dismissed as "non-blocking" but they cluttered every release output and masked real problems. Root cause: branch cleanup code (sections 10 and 11) used `execSync` with template strings, which breaks on branch names with special characters and allows shell injection. Also tried to delete remote branches that GitHub already deleted during PR merge. Fix: replaced all `execSync` template strings with `execFileSync` array args (safe from injection). Added character validation to skip branches with special chars. Wrapped remote delete in try/catch since GitHub PR merge already handles deletion. ## Issues closed - #231 (continued: release pipeline reliability) ## How to verify ```bash wip-release patch --dry-run # Should show no "fatal" or "Not a valid object name" errors # Guard tests: cd tools/wip-branch-guard && bash test.sh ```

# Release Notes: wip-ai-devops-toolbox v1.9.62 **Fix wip-release leaving dirty state on main after every release.** ## The story wip-release writes to 15+ files during a release (root package.json, 12 sub-tool package.json files, SKILL.md, CHANGELOG.md, product docs, trashed release notes). But gitCommitAndTag() only staged 3 files (package.json, CHANGELOG.md, SKILL.md). The other 12+ files were left modified on disk, uncommitted. This blocked git pull on the next operation and required manual `git checkout -- .` every time. Fix: stage all files that wip-release modifies. Sub-tool package.json files, product docs (ai/product/), and trashed release notes (_trash/) are now included in the release commit. ## Issues closed - #231 (wip-release rollback version bumps on failure) ## How to verify ```bash wip-release patch git status # Should show clean working tree after release ```

# Release Notes: wip-ai-devops-toolbox v1.9.61 **Add test script for branch guard. Fix node bypass regex.** ## The story Every guard bug this session (v1.9.56-59) would have been caught by running a test before merging. This release adds test.sh to the guard that pipes test JSON into guard.mjs and verifies allow/deny results. 30 test cases covering destructive commands, quoted strings (Bug 1/3), compound commands (Bug 2), safe commands, and plan files. Also fixes the node bypass regex: `require('fs').writeFileSync` wasn't caught because the regex looked for `fs.writeFile` literally. Broadened to match `writeFile` after `node -e`. ## Issues closed - #232 (guard test coverage) ## How to verify ```bash cd tools/wip-branch-guard && bash test.sh # Should show: 30 passed, 0 failed, 3 skipped ```

# Release Notes: wip-ai-devops-toolbox v1.9.60 **Fix npm package bloat: exclude worktrees and _trash from published tarball.** ## The story v1.9.59 published 869 files (3.9 MB) to npm because leftover worktree directories and _trash/ were included in the tarball. The .npmignore only excluded ai/ and .DS_Store. Added _trash/, .worktrees/, _worktrees/, .claude/, .wrangler/ to .npmignore. Also cleaned up 10 stale worktrees from previous sessions. ## Issues closed - #232 (continued cleanup) ## How to verify ```bash npm pack --dry-run 2>&1 | tail -5 # Should show ~200 files, not 869 ```

# Release Notes: wip-ai-devops-toolbox v1.9.59 **Fix three bugs in branch guard destructive command handling.** ## The story v1.9.56 added destructive command blocking but introduced three bugs because the new code was written differently from the existing guard pattern. The existing guard checks allowed patterns before blocked patterns and works per-command. The new code skipped the allowed check and matched against the entire raw command string, causing false positives on quoted text (blocking `gh issue create` when the body mentioned git commands) and false negatives on compound commands (allowing `rm -f file ; echo done` because `echo` is in the allowed list). Fix: two helper functions that strip quoted content before matching and check each command segment independently. Same pattern as the existing guard code. Also adds `~/.claude/plans/` to the shared state allowlist so plan files are editable. ## Issues closed - #232 (branch guard three bugs in v1.9.56) ## How to verify ```bash # These should now be ALLOWED (were false-positive blocked): # gh issue create --body "use git checkout -- to fix" # echo "don't run git commit on main" # These should now be DENIED (were false-negative allowed): # rm -f file ; echo done (on main) # These should still be DENIED: # git checkout -- file.txt # python3 -c "open('f').write('x')" ```

# Release Notes: wip-ai-devops-toolbox v1.9.58 **Fix deploy-public.sh losing release notes when invoked with relative path.** ## The story When deploy-public.sh was called with `.` as the private repo path (e.g. `bash scripts/deploy-public.sh . wipcomputer/repo`), the script later cd'd into a temp directory. After that, `cd "."` no longer pointed to the private repo, so `gh release view` failed silently and release notes fell back to the empty "Release vX.Y.Z" default. This has been broken since at least v1.9.51. Fix: resolve PRIVATE_REPO to an absolute path at startup before any cd happens. ## Issues closed - #228 (continued from v1.9.57) ## How to verify ```bash # From a repo directory, run with "." and check public release has real notes: cd /path/to/private-repo bash scripts/deploy-public.sh . wipcomputer/public-repo --dry-run ```

# Release Notes: wip-ai-devops-toolbox v1.9.57 **deploy-public.sh now excludes .worktrees/ and _worktrees/ from public repo syncs.** ## The story v1.9.56 accidentally deployed worktree directories (containing embedded git repos) to the public repo. The deploy script's rsync excluded ai/, .git/, _trash/, and other dev artifacts but didn't exclude worktree directories. Added both .worktrees/ (new convention) and _worktrees/ (old convention) to the exclude list. ## Issues closed - #228 (deploy-public.sh leaks .worktrees/ to public repo) ## How to verify ```bash # Run deploy-public.sh --dry-run and confirm .worktrees/ is not synced grep -n "worktrees" scripts/deploy-public.sh ```

# Release Notes: wip-ai-devops-toolbox v1.9.56 **Branch guard now blocks destructive git commands on all branches.** ## The story The branch guard blocked commits and file writes on main, but allowed destructive git commands that destroy uncommitted work. Commands like `git clean -fd`, `git checkout --`, `git stash drop`, and `git reset --hard` slipped through because they were either in the allowed list or not in the blocked list. These commands destroyed Parker's Finder aliases, other agents' uncommitted edits, and user files multiple times on Mar 28-29. The fix adds a new DESTRUCTIVE_PATTERNS list that fires on ALL branches, not just main. The guard also closes several bypass vectors: `node -e` removed from the allowed list, python/node file-write patterns detected, and `git checkout` narrowed to branch-switching only. ## What changed - Added DESTRUCTIVE_PATTERNS: git clean -f, git checkout --, git stash drop/pop/clear, git reset --hard, git restore, python/node bypasses - Removed `git checkout` blanket allow. Now only allows `git checkout <branch>` (switching) - Removed `git stash drop` from allowed list - Removed `node -e` from allowed bash patterns (bypass vector) - Added `git stash show` and `git restore --staged` as safe read-only operations - Deny message tells agent to use worktrees and safety checkpoints instead ## Issues closed - #240 (branch guard + harness directories) - #241 (python bypass detection) - PR #284 ## How to verify ```bash # These should all be BLOCKED: # git clean -fd # git checkout -- somefile # git stash drop # git stash pop # git reset --hard # python3 -c "open('f','w').write('x')" # These should still WORK: # git checkout main (branch switching) # git stash list (read-only) # git status, git log, git diff # Normal worktree workflow ```

# Release Notes: wip-ai-devops-toolbox v1.9.55 Force redeploy: .worktrees guard fix. ## The story v1.9.53 had the guard fix but deploy-public was missed. v1.9.54 force-redeployed but installer had already cached v1.9.54. This version ensures the public repo and npm are in sync so ldm install deploys the correct guard.mjs with .worktrees convention. ## Issues closed - #240 (partial)

# Release Notes: wip-ai-devops-toolbox v1.9.54 Force redeploy: guard files were stale after v1.9.53. ## The story v1.9.53 published the .worktrees guard fix to npm but ldm install saw the version as current and skipped redeploying the files. The deployed guard.mjs was still the old version. This release forces a version bump so the installer re-deploys. This is a bug in the installer: it checks version numbers but not file contents. Filed for future fix. ## Issues closed - #240 (partial: .worktrees convention)

# Release Notes: wip-ai-devops-toolbox v1.9.53 **One-line summary of what this release does** Tell the story. What was broken or missing? What did we build? Why does the user care? Write at least one real paragraph of prose. Not just bullets. The release notes gate will block if there is no narrative. Bullets are fine for details, but the story comes first. ## The story (Write a paragraph here. What was the problem? What does this release fix? Why does it matter? This is what users read. Make it worth reading.) ## Issues closed - #282 ## How to verify ```bash # Commands to test the changes ```

# Release Notes: wip-ai-devops-toolbox v1.9.52 **Fix branch guard false-blocking bash commands targeting worktree paths** ## What changed - Branch guard now extracts absolute paths from any bash command (mkdir, cp, mv, touch, etc.) and resolves the git branch from the target path's repo, not the CWD - `findRepoRoot()` improved to walk up to existing directories for paths that don't exist yet (handles mkdir for new directories) - Added `.ldm/worktrees` to allowed worktree locations alongside `_worktrees/` and `.claude/worktrees` ## Why When Claude Code launches from `~/wipcomputerinc/` (on main) and runs bash commands targeting files inside a worktree (e.g., `mkdir -p /path/to/_worktrees/repo--branch/new-dir/`), the guard only knew how to extract paths from `cd` and `git -C` patterns. Any other command fell back to CWD resolution, saw "main", and blocked incorrectly. This caused minutes of wasted time every session. ## Issues closed - wipcomputer/wip-ldm-os#187 ## How to verify ```bash # From CWD on main, this should no longer be blocked: # mkdir -p /path/to/_worktrees/repo--branch/new-directory/ # cp file.txt /path/to/_worktrees/repo--branch/ ```

# Release Notes: wip-ai-devops-toolbox v1.9.51 ## Branch Guard: Workspace Files Allowlist (#185) Added TOOLS.md, MEMORY.md, IDENTITY.md, SOUL.md, WHERE-TO-WRITE.md, HEARTBEAT.md to the shared state allowlist. Both agents can now write to workspace files on main without being blocked. Previously only SHARED-CONTEXT.md was allowed. This broke Lesa's ability to edit her own workspace files during the migration to ~/wipcomputerinc/. ## TECHNICAL.md: Backup Documentation Updated LDM Dev Tools.app backup section to reflect the unified backup system. backup.sh now calls `~/.ldm/bin/ldm-backup.sh` (deployed by ldm install from wip-ldm-os-private/scripts/).

# Release Notes: wip-ai-devops-toolbox v1.9.50 **wip-release: require product update doc on every release.** ## What changed New quality gate in wip-release: checks that `ai/dev-updates/product-update/*-product-update.md` was modified since the last release tag. Same pattern as dev-updates, roadmap, and readme-first checks. The product update doc is a human-readable test guide. Each release entry has: what changed, how it's supposed to work, and how to test. New entries go at the top. Additive only. ## Why Three repos now have product update docs but nothing enforced keeping them current. Without the gate, the docs will drift immediately (same problem we had with TECHNICAL.md). ## Issues closed - #220 ## How to verify ```bash wip-release patch --dry-run # Should warn if product update doc not modified since last release ```