@wipcomputer/wip-ai-devops-toolbox 1.9.55 → 1.9.57

package/.worktrees/toolbox--release-notes/CHANGELOG.md

@@ -0,0 +1,1875 @@
+# Changelog
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## 1.9.55 (2026-03-28)
+
+# 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)
+
+## 1.9.54 (2026-03-28)
+
+# 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)
+
+## 1.9.53 (2026-03-28)
+
+# 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
+```
+
+## 1.9.52 (2026-03-27)
+
+# 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/
+```
+
+## 1.9.51 (2026-03-24)
+
+# 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/).
+
+## 1.9.50 (2026-03-20)
+
+# 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
+```
+
+## 1.9.49 (2026-03-20)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.49
+
+**TECHNICAL.md audit: 2 weeks of undocumented features now documented.**
+
+## What changed
+
+Full TECHNICAL.md audit covering v1.9.15 through v1.9.48. Two passes. Key additions:
+
+- **wip-release quality gates:** Technical docs gate, interface coverage gate, product docs auto-sync, all skip flags documented.
+- **deploy-public.sh:** Full 8-step pipeline including GitHub Packages publishing, repo URL rewrite, co-author sync.
+- **wip-license-guard:** Now documented as both CLI and Claude Code PreToolUse hook (guard.mjs). Enforcement details.
+- **wip-branch-guard:** Worktree requirement on branches, non-repo file passthrough, workflow teaching messages.
+- **wip-repos claude:** Cross-repo CLAUDE.md ecosystem generator fully documented.
+- **Source code table:** Missing files added (guard.mjs, claude.mjs, mcp-server.mjs).
+- **Log paths:** Fixed stale /tmp/ references to ~/.ldm/logs/.
+
+## Why
+
+15 releases shipped without TECHNICAL.md updates. Agents reading the docs were missing critical features: release gates, license enforcement hooks, deploy pipeline details.
+
+## Issues closed
+
+- #218
+
+## How to verify
+
+```bash
+grep "Interface coverage" TECHNICAL.md    # new gate
+grep "guard.mjs" TECHNICAL.md             # license-guard hook
+grep "GitHub Packages" TECHNICAL.md       # deploy pipeline
+```
+
+## 1.9.48 (2026-03-20)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.48
+
+**Document wip-repos claude command in SKILL.md and TECHNICAL.md.**
+
+## What changed
+
+- SKILL.md: added `wip-repos claude` commands to the wip-repos section
+- TECHNICAL.md: full documentation of how the ecosystem generator works, template locations, delimiter convention
+
+## Why
+
+v1.9.47 shipped the `wip-repos claude` command without updating technical docs. Now documented.
+
+## Issues closed
+
+- #212 (docs portion)
+
+## How to verify
+
+```bash
+grep "wip-repos claude" SKILL.md TECHNICAL.md
+```
+
+## 1.9.47 (2026-03-20)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.47
+
+**New: `wip-repos claude` command + CLAUDE.md templates.**
+
+## What changed
+
+### `wip-repos claude` (Phases 1-3 of the CLAUDE.md plan)
+
+New subcommand that generates cross-repo ecosystem sections in CLAUDE.md files. When an agent opens repo-A, it can't read repo-B. This command pre-generates the context.
+
+```bash
+wip-repos claude              # regenerate all repos
+wip-repos claude my-repo      # regenerate one repo
+wip-repos claude --init       # create CLAUDE.md for repos missing one
+wip-repos claude --dry-run    # preview changes
+```
+
+Features:
+- Reads all repos from manifest, extracts metadata (package.json, SKILL.md, directory structure)
+- Generates `## Ecosystem` sections with delimiter comments (`<!-- wip-repos:start/end -->`)
+- Hand-written sections are never overwritten
+- Relevance filtering: only related repos shown (same category + core repos)
+- `--init` creates starter CLAUDE.md from template for repos missing one
+
+### Templates
+
+- `templates/global-claude-md.md` ... universal CLAUDE.md for ~/.claude/CLAUDE.md
+- `templates/repo-claude-md.template` ... per-repo starter with ecosystem placeholder
+
+## Why
+
+Agents lose context across repos. They can't read sibling repos at runtime. Pre-generating cross-repo maps into CLAUDE.md solves this without requiring runtime access.
+
+## Issues closed
+
+- #212 (partial: Phases 1-3 of 6)
+
+## How to verify
+
+```bash
+wip-repos claude --dry-run
+```
+
+## 1.9.46 (2026-03-18)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.46
+
+**Centralized worktree management: guard rule, wip-release prune, Dev Guide convention.**
+
+## What changed
+
+### Guard: worktree path warning (#212)
+Branch guard now warns when `git worktree add` creates a worktree outside `_worktrees/`. Shows the convention and suggests `ldm worktree add`. Warning only, not a hard block.
+
+### wip-release: worktree prune (#212)
+New step 12 in the release pipeline. After branch cleanup, prunes stale worktrees from `_worktrees/` whose branches are merged into main. Automatic cleanup after every release.
+
+### Dev Guide: _worktrees/ convention (#212)
+Documents the centralized worktree convention:
+- All worktrees go in `_worktrees/<repo-name>--<branch-suffix>/`
+- Use `ldm worktree add` (auto-detects repo, creates in the right place)
+- Guard warns about worktrees outside the convention
+- `wip-release` auto-prunes merged worktrees
+
+## Why
+
+Worktrees created as repo siblings confused iCloud sync, looked like real repos in directory listings, and were never cleaned up. This session alone created 10+ stale worktrees. The convention keeps them organized and the release pipeline cleans them automatically.
+
+## Issues closed
+
+- #212
+- #213
+
+## How to verify
+
+```bash
+# Guard warning:
+cd /path/to/repo
+git worktree add ../my-worktree -b test   # should warn about _worktrees/
+
+# Correct path:
+ldm worktree add cc-mini/test             # creates _worktrees/<repo>--cc-mini--test/
+```
+
+## 1.9.45 (2026-03-18)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.45
+
+**Guard now teaches the workflow instead of just blocking.**
+
+## What changed
+
+- **Branch guard error messages overhauled (#213).** When the guard blocks a write on main, it now shows the full 8-step process: worktree, branch, commit, push, PR, merge, wip-release, deploy-public. Includes the lesson that release notes go on the feature branch, not as a separate PR.
+- **Separate error for "on branch but not in worktree."** Tells the agent to go back to main and create a worktree properly.
+- **CLAUDE.md added to shared state allowlist.** Was patched in the deployed guard but missing from source. Now in sync.
+
+## Why
+
+Agents kept getting blocked by the guard and then trying workarounds instead of following the process. The error message said "Use a worktree" but didn't explain the full workflow. Today's session hit this 5+ times. The guard works. The gap was agent knowledge.
+
+## Issues closed
+
+- #213
+- #256
+
+## How to verify
+
+```bash
+# In any repo on main, try to edit a file. The error should show the full workflow.
+# In any repo on a branch (not worktree), try to edit. Should show worktree instructions.
+```
+
+## 1.9.44 (2026-03-17)
+
+# Guard non-repo files fix + UTC date fix
+
+Two bugs fixed in one PR.
+
+## Bug 1: Guard blocks files outside git repos (#77)
+
+**Problem:** When Write/Edit targets a file outside any git repo (e.g. `~/.claude/plans/`), `findRepoRoot()` returns null. The guard fell back to CWD (`~/.openclaw` on main) and blocked the operation. Files outside repos aren't the guard's concern.
+
+**Fix:** If `findRepoRoot(filePath)` returns null for Write/Edit operations, allow immediately. The guard only protects git repos from direct-on-main edits.
+
+**File:** `tools/wip-branch-guard/guard.mjs`
+
+## Bug 2: UTC date mismatch in wip-release
+
+**Problem:** Dev-update files are named with local date (e.g. `2026-03-16--cc-mini--...md`). But `new Date().toISOString().split('T')[0]` returns UTC date. After midnight UTC (4 PM PST), the dates diverge. Release notes gate fails to find today's dev-update.
+
+**Fix:** Replaced all three instances of `toISOString()` date extraction with explicit local date construction using `getFullYear()/getMonth()/getDate()`.
+
+**Files:**
+- `tools/wip-release/cli.js` (line 80, dev-update detection)
+- `tools/wip-release/core.mjs` (line 92, CHANGELOG date)
+- `tools/wip-release/core.mjs` (line 582, product docs sync date)
+
+## 1.9.43 (2026-03-17)
+
+# Guard non-repo files fix + UTC date fix
+
+Two bugs fixed in one PR.
+
+## Bug 1: Guard blocks files outside git repos (#77)
+
+**Problem:** When Write/Edit targets a file outside any git repo (e.g. `~/.claude/plans/`), `findRepoRoot()` returns null. The guard fell back to CWD (`~/.openclaw` on main) and blocked the operation. Files outside repos aren't the guard's concern.
+
+**Fix:** If `findRepoRoot(filePath)` returns null for Write/Edit operations, allow immediately. The guard only protects git repos from direct-on-main edits.
+
+**File:** `tools/wip-branch-guard/guard.mjs`
+
+## Bug 2: UTC date mismatch in wip-release
+
+**Problem:** Dev-update files are named with local date (e.g. `2026-03-16--cc-mini--...md`). But `new Date().toISOString().split('T')[0]` returns UTC date. After midnight UTC (4 PM PST), the dates diverge. Release notes gate fails to find today's dev-update.
+
+**Fix:** Replaced all three instances of `toISOString()` date extraction with explicit local date construction using `getFullYear()/getMonth()/getDate()`.
+
+**Files:**
+- `tools/wip-release/cli.js` (line 80, dev-update detection)
+- `tools/wip-release/core.mjs` (line 92, CHANGELOG date)
+- `tools/wip-release/core.mjs` (line 582, product docs sync date)
+
+## 1.9.42 (2026-03-17)
+
+# Guard non-repo files fix + UTC date fix
+
+Two bugs fixed in one PR.
+
+## Bug 1: Guard blocks files outside git repos (#77)
+
+**Problem:** When Write/Edit targets a file outside any git repo (e.g. `~/.claude/plans/`), `findRepoRoot()` returns null. The guard fell back to CWD (`~/.openclaw` on main) and blocked the operation. Files outside repos aren't the guard's concern.
+
+**Fix:** If `findRepoRoot(filePath)` returns null for Write/Edit operations, allow immediately. The guard only protects git repos from direct-on-main edits.
+
+**File:** `tools/wip-branch-guard/guard.mjs`
+
+## Bug 2: UTC date mismatch in wip-release
+
+**Problem:** Dev-update files are named with local date (e.g. `2026-03-16--cc-mini--...md`). But `new Date().toISOString().split('T')[0]` returns UTC date. After midnight UTC (4 PM PST), the dates diverge. Release notes gate fails to find today's dev-update.
+
+**Fix:** Replaced all three instances of `toISOString()` date extraction with explicit local date construction using `getFullYear()/getMonth()/getDate()`.
+
+**Files:**
+- `tools/wip-release/cli.js` (line 80, dev-update detection)
+- `tools/wip-release/core.mjs` (line 92, CHANGELOG date)
+- `tools/wip-release/core.mjs` (line 582, product docs sync date)
+
+## 1.9.41 (2026-03-17)
+
+# Doc enforcement gates for wip-release
+
+**Date:** 2026-03-16
+**Closes:** #117, #128
+
+## What changed
+
+Two new pre-release gates in wip-release:
+
+**Technical Docs Gate (#117):** When source code (*.mjs, *.js, *.ts) changed since the last release tag, checks that SKILL.md or TECHNICAL.md was also modified. Catches code shipping without doc updates. Warns on patch, blocks on minor/major. Skip with `--skip-tech-docs-check`.
+
+**Interface Coverage Gate (#128):** For toolbox repos, scans each tool in tools/*/ for actual interfaces (CLI, Module, MCP, OC Plugin, Skill, CC Hook) and compares to the coverage table in README.md and SKILL.md. Reports: tools missing from table, interfaces detected but not marked Y, interfaces marked Y but not detected, tool count mismatches. Warns on patch, blocks on minor/major. Skip with `--skip-coverage-check`.
+
+Both follow the same pattern as existing gates (checkProductDocs, checkStaleBranches). Both run in real and dry-run modes.
+
+## Why
+
+Source code was shipping without doc updates constantly. SKILL.md and TECHNICAL.md fell behind the code. Interface coverage tables drifted from reality. These gates catch it before release instead of after.
+
+## 1.9.40 (2026-03-16)
+
+# Auto-sync product docs version/date on release
+
+**Date:** 2026-03-16
+**Closes:** #202
+
+## What changed
+
+wip-release now auto-updates version and date lines in product docs before the release commit. No more stale "Current version: v1.9.1" when you're shipping v1.9.39.
+
+Files updated automatically:
+- `ai/product/plans-prds/roadmap.md`: "Current version" and "Last updated"
+- `ai/product/readme-first-product.md`: "Last updated" and "What's Built (as of vX.Y.Z)"
+
+Runs between changelog update and git commit (step 3.75). Only touches files that exist. Only updates lines that match the expected patterns.
+
+## Why
+
+These files were stale from v1.9.1 through v1.9.39 (8 days, 38 releases). Nobody remembered to update them. The existing product docs gate warned about it but couldn't fix it. Now it fixes itself.
+
+## 1.9.39 (2026-03-16)
+
+# Wire license-guard as Claude Code PreToolUse hook
+
+**Date:** 2026-03-16
+**Closes:** #130
+
+## What changed
+
+license-guard now registers as a Claude Code PreToolUse hook on install. Previously the hook code existed (hook.mjs) but was never wired into the deploy system. Now:
+
+- Renamed hook.mjs to guard.mjs (matches file-guard/branch-guard convention that LDM OS deploy.mjs expects)
+- Added `claudeCode.hook` config to package.json (event: PreToolUse, matcher: Bash, timeout: 5)
+- On next `ldm install`, the hook auto-registers in ~/.claude/settings.json
+
+The hook blocks git commit and git push when license compliance fails:
+- LICENSE file missing
+- Copyright doesn't match .license-guard.json config
+- CLA.md missing
+- README.md missing ## License section
+- MIT+AGPL config but LICENSE or README only mentions MIT
+
+Repos without .license-guard.json are not affected (the hook silently passes).
+
+## Also done
+
+- Updated plan statuses: license guard Phase 1 complete, bootstrap LDM OS complete
+- Bootstrap LDM OS was already shipped in install.js (lines 740-812)
+
+## 1.9.38 (2026-03-16)
+
+# GitHub Packages publish from public repo
+
+**Date:** 2026-03-16
+**Closes:** #193
+
+## What changed
+
+`deploy-public.sh` now publishes to GitHub Packages from the public repo clone after the npm publish step. Previously, GitHub Packages were only published from the private repo during `wip-release`, so they showed on the private repo's Packages tab. Users couldn't see them.
+
+Now packages show on the public repo's Packages tab where users expect to find them. Uses `gh auth token` for authentication (already available from the gh CLI).
+
+## Why
+
+The Packages tab on public repos was empty. Users visiting wipcomputer/wip-ldm-os or wipcomputer/wip-ai-devops-toolbox saw no packages even though they were published. The packages existed but were linked to the private repo.
+
+## 1.9.37 (2026-03-16)
+
+# GitHub Packages publish from public repo
+
+**Date:** 2026-03-16
+**Closes:** #193
+
+## What changed
+
+`deploy-public.sh` now publishes to GitHub Packages from the public repo clone after the npm publish step. Previously, GitHub Packages were only published from the private repo during `wip-release`, so they showed on the private repo's Packages tab. Users couldn't see them.
+
+Now packages show on the public repo's Packages tab where users expect to find them. Uses `gh auth token` for authentication (already available from the gh CLI).
+
+## Why
+
+The Packages tab on public repos was empty. Users visiting wipcomputer/wip-ldm-os or wipcomputer/wip-ai-devops-toolbox saw no packages even though they were published. The packages existed but were linked to the private repo.
+
+## 1.9.36 (2026-03-16)
+
+# GitHub Packages publish from public repo
+
+**Date:** 2026-03-16
+**Closes:** #193
+
+## What changed
+
+`deploy-public.sh` now publishes to GitHub Packages from the public repo clone after the npm publish step. Previously, GitHub Packages were only published from the private repo during `wip-release`, so they showed on the private repo's Packages tab. Users couldn't see them.
+
+Now packages show on the public repo's Packages tab where users expect to find them. Uses `gh auth token` for authentication (already available from the gh CLI).
+
+## Why
+
+The Packages tab on public repos was empty. Users visiting wipcomputer/wip-ldm-os or wipcomputer/wip-ai-devops-toolbox saw no packages even though they were published. The packages existed but were linked to the private repo.
+
+## 1.9.35 (2026-03-16)
+
+# GitHub Packages publish from public repo
+
+**Date:** 2026-03-16
+**Closes:** #193
+
+## What changed
+
+`deploy-public.sh` now publishes to GitHub Packages from the public repo clone after the npm publish step. Previously, GitHub Packages were only published from the private repo during `wip-release`, so they showed on the private repo's Packages tab. Users couldn't see them.
+
+Now packages show on the public repo's Packages tab where users expect to find them. Uses `gh auth token` for authentication (already available from the gh CLI).
+
+## Why
+
+The Packages tab on public repos was empty. Users visiting wipcomputer/wip-ldm-os or wipcomputer/wip-ai-devops-toolbox saw no packages even though they were published. The packages existed but were linked to the private repo.
+
+## 1.9.34 (2026-03-16)
+
+# GitHub Packages publish from public repo
+
+**Date:** 2026-03-16
+**Closes:** #193
+
+## What changed
+
+`deploy-public.sh` now publishes to GitHub Packages from the public repo clone after the npm publish step. Previously, GitHub Packages were only published from the private repo during `wip-release`, so they showed on the private repo's Packages tab. Users couldn't see them.
+
+Now packages show on the public repo's Packages tab where users expect to find them. Uses `gh auth token` for authentication (already available from the gh CLI).
+
+## Why
+
+The Packages tab on public repos was empty. Users visiting wipcomputer/wip-ldm-os or wipcomputer/wip-ai-devops-toolbox saw no packages even though they were published. The packages existed but were linked to the private repo.
+
+## 1.9.33 (2026-03-15)
+
+# --version on all CLIs + issue cleanup
+
+**Date:** 2026-03-15
+**Closes:** #190, #191, #169, #123, #119
+
+## What changed
+
+All 7 CLI tools now support `--version` and `-v`. Each reads its own `package.json` and prints the version. Previously, `wip-release --version` printed the help text instead of a version number.
+
+Tools updated: wip-release, wip-repos, wip-license-guard, wip-repo-permissions, wip-repo-init, wip-readme-format, wip-file-guard, wip-branch-guard.
+
+wip-license-guard also got a proper README (#169) with all commands, config format, and integration docs.
+
+## Issues closed
+
+- #190: wip-release --version should work
+- #191: enforce --version on all CLI tools
+- #169: wip-license-guard needs its own README
+- #123: Merge/Deploy/Install conflated (enforced across v1.9.25-v1.9.30)
+- #119: All destructive tools must have --dry-run (all confirmed)
+
+## 1.9.32 (2026-03-15)
+
+# --version on all CLIs + issue cleanup
+
+**Date:** 2026-03-15
+**Closes:** #190, #191, #169, #123, #119
+
+## What changed
+
+All 7 CLI tools now support `--version` and `-v`. Each reads its own `package.json` and prints the version. Previously, `wip-release --version` printed the help text instead of a version number.
+
+Tools updated: wip-release, wip-repos, wip-license-guard, wip-repo-permissions, wip-repo-init, wip-readme-format, wip-file-guard, wip-branch-guard.
+
+wip-license-guard also got a proper README (#169) with all commands, config format, and integration docs.
+
+## Issues closed
+
+- #190: wip-release --version should work
+- #191: enforce --version on all CLI tools
+- #169: wip-license-guard needs its own README
+- #123: Merge/Deploy/Install conflated (enforced across v1.9.25-v1.9.30)
+- #119: All destructive tools must have --dry-run (all confirmed)
+
+## 1.9.31 (2026-03-15)
+
+# Release Notes: wip-ai-devops-toolbox v1.9.31
+
+Branch guard no longer blocks global npm operations on main.
+
+## What changed
+
+Moved `npm install -g` and `npm link` from BLOCKED_BASH_PATTERNS to ALLOWED_BASH_PATTERNS in `wip-branch-guard/guard.mjs`. Global npm operations modify `/opt/homebrew/`, not the repo. Local `npm install` (no -g flag) remains blocked.
+
+## Why
+
+During LDM OS v0.4.0 dogfood, a CC session couldn't run `npm install -g @wipcomputer/wip-ldm-os@0.4.0` even after Parker explicitly said "install." The guard was too aggressive. Original intent (issue #137) was to block repo writes on main, not system-level package installs.
+
+## Issues closed
+
+- Closes #188 (branch guard blocks npm install -g)
+- Cross-ref: wipcomputer/wip-ldm-os#44
+
+## How to verify
+
+```bash
+# On main branch, these should now succeed:
+npm install -g @wipcomputer/wip-ldm-os@0.4.0
+npm link
+# This should still be blocked on main:
+npm install
+```
+
+## 1.9.30 (2026-03-15)
+
+# Release notes must be a file on disk
+
+**Date:** 2026-03-15
+
+## What changed
+
+wip-release no longer accepts the `--notes` flag. Release notes MUST come from a file on disk:
+
+1. `RELEASE-NOTES-v{version}.md` in repo root (auto-detected)
+2. `ai/dev-updates/YYYY-MM-DD--description.md` (auto-detected)
+3. `--notes-file=path` (explicit file path)
+
+If no file exists, the release is blocked. The gate scaffolds a template (`RELEASE-NOTES-v{version}.md`) so the agent has something to fill in.
+
+## Why
+
+The `--notes` flag was the root cause of every bad release note. Agents passed one-liners like `--notes="fix bug"` and the gate let them through. Even after we added length checks and changelog detection, agents found ways around it. The flag was an escape hatch that undermined the entire system.
+
+The file-on-disk requirement solves three problems:
+1. **Reviewability.** The file is on the branch. It shows up in the PR diff. Parker can read and approve the release notes before merge.
+2. **Quality.** Writing a file forces the agent to think about what changed and why. A flag encourages one-liners.
+3. **History.** The file is committed to git. The release notes are part of the repo history, not a transient CLI argument.
+
+## What agents need to do
+
+Before running `wip-release`:
+1. Write `RELEASE-NOTES-v{version}.md` or `ai/dev-updates/YYYY-MM-DD--description.md`
+2. Commit it on the branch
+3. The file shows up in the PR for review
+4. After merge to main, `wip-release` auto-detects it
+
+If the agent forgets, `wip-release` blocks and scaffolds a template.
+
+## 1.9.29 (2026-03-15)
+
+# Release notes must be a file on disk
+
+**Date:** 2026-03-15
+
+## What changed
+
+wip-release no longer accepts the `--notes` flag. Release notes MUST come from a file on disk:
+
+1. `RELEASE-NOTES-v{version}.md` in repo root (auto-detected)
+2. `ai/dev-updates/YYYY-MM-DD--description.md` (auto-detected)
+3. `--notes-file=path` (explicit file path)
+
+If no file exists, the release is blocked. The gate scaffolds a template (`RELEASE-NOTES-v{version}.md`) so the agent has something to fill in.
+
+## Why
+
+The `--notes` flag was the root cause of every bad release note. Agents passed one-liners like `--notes="fix bug"` and the gate let them through. Even after we added length checks and changelog detection, agents found ways around it. The flag was an escape hatch that undermined the entire system.
+
+The file-on-disk requirement solves three problems:
+1. **Reviewability.** The file is on the branch. It shows up in the PR diff. Parker can read and approve the release notes before merge.
+2. **Quality.** Writing a file forces the agent to think about what changed and why. A flag encourages one-liners.
+3. **History.** The file is committed to git. The release notes are part of the repo history, not a transient CLI argument.
+
+## What agents need to do
+
+Before running `wip-release`:
+1. Write `RELEASE-NOTES-v{version}.md` or `ai/dev-updates/YYYY-MM-DD--description.md`
+2. Commit it on the branch
+3. The file shows up in the PR for review
+4. After merge to main, `wip-release` auto-detects it
+
+If the agent forgets, `wip-release` blocks and scaffolds a template.
+
+## 1.9.28 (2026-03-15)
+
+# Release Notes Quality Gate
+
+**Date:** 2026-03-15
+
+## What changed
+
+wip-release now blocks ALL releases (patch, minor, major) if the release notes are bad. Previously, patch releases only warned. Now they block.
+
+The gate checks:
+- Notes must be at least 50 characters
+- Notes can't look like a changelog entry ("fix: ...", "add: ...", "update: ...")
+- Minor/major still require a file (not --notes flag)
+
+If the gate blocks, it tells you exactly how to fix it: write a RELEASE-NOTES file, write a dev update, or use --notes with at least 50 chars of real description.
+
+## Why
+
+Release notes were consistently garbage. One-liner --notes flags like "Fix bug" or "Update docs" sailed through on patch releases. The warnings were ignored by both humans and agents. Every release page on GitHub had thin, useless notes that didn't explain what changed or why.
+
+## Also in this release
+
+- wip-repo-init templates renamed from ai/ to templates/ so they ship with npm install (deploy-public.sh was stripping them)
+- SKILL.md restart notice after install (hooks need session restart)
+- SPEC.md and TECHNICAL.md updated with all 17 tools and LDM OS links
+- Branch guard matcher fix (catches Bash + NotebookEdit)
+- Forced Git Worktrees and Branch Guard sections added to SKILL.md
+
+## 1.9.27 (2026-03-15)
+
+# Release Notes Quality Gate
+
+**Date:** 2026-03-15
+
+## What changed
+
+wip-release now blocks ALL releases (patch, minor, major) if the release notes are bad. Previously, patch releases only warned. Now they block.
+
+The gate checks:
+- Notes must be at least 50 characters
+- Notes can't look like a changelog entry ("fix: ...", "add: ...", "update: ...")
+- Minor/major still require a file (not --notes flag)
+
+If the gate blocks, it tells you exactly how to fix it: write a RELEASE-NOTES file, write a dev update, or use --notes with at least 50 chars of real description.
+
+## Why
+
+Release notes were consistently garbage. One-liner --notes flags like "Fix bug" or "Update docs" sailed through on patch releases. The warnings were ignored by both humans and agents. Every release page on GitHub had thin, useless notes that didn't explain what changed or why.
+
+## Also in this release
+
+- wip-repo-init templates renamed from ai/ to templates/ so they ship with npm install (deploy-public.sh was stripping them)
+- SKILL.md restart notice after install (hooks need session restart)
+- SPEC.md and TECHNICAL.md updated with all 17 tools and LDM OS links
+- Branch guard matcher fix (catches Bash + NotebookEdit)
+- Forced Git Worktrees and Branch Guard sections added to SKILL.md
+
+## 1.9.26 (2026-03-15)
+
+Add restart notice after install/update. Hooks need session restart to take effect.
+
+## 1.9.25 (2026-03-14)
+
+Fix branch guard matcher (catches Bash + NotebookEdit). Add Forced Git Worktrees and Branch Guard sections to SKILL.md. Update SPEC.md and TECHNICAL.md with all 17 tools and LDM OS links.
+
+## 1.9.24 (2026-03-14)
+
+Number tools in dry run and already-installed lists. Dogfood iteration.
+
+## 1.9.23 (2026-03-14)
+
+Force verbatim tool list display. AI must show all 17 tools with descriptions, never summarize.
+
+## 1.9.22 (2026-03-14)
+
+All 17 tools listed with descriptions. New section order: Setup, Infrastructure, Repo Management, License, Release. Conversational prompt.
+
+## 1.9.21 (2026-03-14)
+
+Add Already Installed section with tool descriptions. Dogfood fix.
+
+## 1.9.20 (2026-03-14)
+
+Make root package publishable. npm install -g @wipcomputer/wip-ai-devops-toolbox now installs all 12 CLI tools.
+
+## 1.9.19 (2026-03-14)
+
+Add websiteRepo to .publish-skill.json. Auto-publish SKILL.md to website on release. Fix install prompt URLs to use wip- prefix.
+
+## 1.9.18 (2026-03-14)
+
+Rewrite SKILL.md install flow to use ldm install. Conversational AI-guided pattern matching Memory Crystal.
+
+## 1.9.17 (2026-03-14)
+
+Add wip-branch-guard: PreToolUse hook that blocks all writes on main branch. Resolves repo from file path so it works from any CWD. Forces agents to branch or worktree before editing.
+
+## 1.9.16 (2026-03-14)
+
+Add wip-branch-guard: PreToolUse hook that blocks all writes on main branch. Resolves repo from file path so it works from any CWD. Forces agents to branch or worktree before editing.
+
+## 1.9.15 (2026-03-14)
+
+Fix all 5 root causes of truncated release notes (#121). Add --dry-run to readme-license. Update SKILL.md docs for wip-release and wip-license-guard.
+
+## 1.9.14 (2026-03-14)
+
+Add readme-license command to wip-license-guard. Scans all repos, applies standard license block, removes from sub-tools. License Guard now Stable.
+
+## 1.9.13 (2026-03-14)
+
+Release.
+
+## 1.9.12 (2026-03-13)
+
+Add skill publish to website: after every release, SKILL.md is auto-copied to yoursite.com/install/{name}.txt and deployed. Configured per repo with .publish-skill.json. Non-blocking.
+
+## 1.9.11 (2026-03-13)
+
+wip-install bootstraps LDM OS silently when not on PATH
+
+## 1.9.10 (2026-03-13)
+
+# Release Notes: AI DevOps Toolbox v1.9.10
+
+**Fix: Release notes files on disk always beat --notes flag**
+
+v1.9.9 shipped with a one-liner on the GitHub release instead of the full narrative release notes. The RELEASE-NOTES-v1-9-9.md file was sitting right there on disk, but `--notes="short text"` took priority because the auto-detect only ran when `--notes` was absent.
+
+This is exactly the kind of bug that happens when a rule exists in documentation but not in code. "Write release notes on the branch" is in the Dev Guide. The tool ignored them.
+
+## What changed
+
+### Notes priority is now enforced (highest wins):
+
+1. `--notes-file=path` ... explicit file path (always wins)
+2. `RELEASE-NOTES-v{ver}.md` ... in repo root (always wins over `--notes` flag)
+3. `ai/dev-updates/YYYY-MM-DD*` ... today's dev update (wins over `--notes` flag if longer)
+4. `--notes="text"` ... fallback only. Use for repos without release notes files.
+
+If a RELEASE-NOTES file exists on disk, `--notes` is ignored and a warning is printed:
+
+```
+! --notes flag ignored: RELEASE-NOTES-v1-9-10.md takes priority
+```
+
+Written notes on disk always take priority over a CLI one-liner. The agent wrote the file. The tool should use it.
+
+## Files changed
+
+```
+ tools/wip-release/cli.js | ~40 lines rewritten (notes cascade logic)
+```
+
+## Install
+
+```bash
+git pull origin main
+```
+
+## Attribution
+
+Built by Parker Todd Brooks, Lesa, and Claude Opus 4.6 at WIP.computer.
+
+## 1.9.9 (2026-03-13)
+
+Enforce git worktrees as default workflow. wip-release blocks from worktrees, wip-install auto-adds .claude/worktrees/ to .gitignore, Dev Guide worktree section added.
+
+## 1.9.8 (2026-03-13)
+
+wip-install delegates to ldm install when available
+
+## 1.9.7 (2026-03-13)
+
+# Release Notes: AI DevOps Toolbox v1.9.7
+
+## LDM OS Integration
+
+AI DevOps Toolbox now works with LDM OS when it's available.
+
+### wip-install delegates to ldm install
+
+When the `ldm` CLI exists on PATH, `wip-install` delegates to `ldm install`. LDM OS handles the scaffold, interface detection, and extension deployment. The Toolbox's standalone behavior is preserved as a fallback when `ldm` isn't available.
+
+Supports `--dry-run` and `--json` passthrough to `ldm install`.
+
+### LDM OS tip
+
+After standalone installs, the Toolbox prints a tip: "Run `ldm install` to see more skills you can add."
+
+### Universal Installer link
+
+The "Read more about Universal Installer" link now points to the LDM OS docs page. The Universal Installer engine moved to LDM OS. The Toolbox keeps `wip-install` as an entry point that delegates.
+
+### Part of LDM OS
+
+README includes a "Part of LDM OS" section linking back to the LDM OS repo.
+
+## 1.9.6 (2026-03-12)
+
+# v1.9.6 ... Enforcement Gates
+
+Three fixes that move the release pipeline from "suggestions agents forget" to "gates that block."
+
+---
+
+## syncSkillVersion corrupted quoted versions (#71)
+
+Every release was appending the old version instead of replacing it. SKILL.md went from `"1.9.5"` to `"1.9.5".9.4".9.3".9.2".9.1"` over five releases.
+
+Root cause: the regex `"?\S+?"?` used non-greedy matching. For quoted values, it consumed only part of the string, leaving the rest as trailing garbage.
+
+Fix: replaced with `(?:"[^\n]*|\S+)`. Quoted values now match through end of line. Unquoted values use greedy `\S+`. Also fixed the staleness-check regex to extract clean semver from corrupted strings.
+
+**Files changed:**
+- `tools/wip-release/core.mjs` ... `syncSkillVersion()` regex fix
+- `SKILL.md` ... repaired corrupted version back to `"1.9.5"`
+
+---
+
+## gh pr merge now always deletes branch (#74)
+
+Every `gh pr merge` call in the codebase now includes `--delete-branch`. Previously, deploy-public.sh had a manual 3-line `gh api -X DELETE` cleanup block. That's gone. The flag handles it.
+
+Also verified every merge uses `--merge` (never squash). Dev Guide updated with the new convention.
+
+**Files changed:**
+- `scripts/deploy-public.sh` ... added `--delete-branch`, removed manual cleanup
+- `tools/deploy-public/deploy-public.sh` ... same
+- `DEV-GUIDE-GENERAL-PUBLIC.md` ... updated merge examples
+- `ai/DEV-GUIDE-FOR-WIP-ONLY-PRIVATE.md` ... updated merge rules
+- `ai/_trash/DEV-GUIDE-private.md` ... updated
+- `ai/_sort/_trash/ai_old/_trash/DEV-GUIDE-private.md` ... updated
+
+---
+
+## wip-release blocks on stale remote branches (#75)
+
+New gate in the release pipeline. Before releasing, wip-release checks for remote branches that are fully merged into main but haven't been cleaned up.
+
+- **Patch:** warns with the list of stale branches (non-blocking)
+- **Minor/major:** blocks the release. Clean up first.
+- **`--skip-stale-check`:** override flag for emergencies
+
+Follows the existing gate pattern: fetches with `--prune`, filters out `origin/main`, `origin/HEAD`, and `--merged-` branches. Fails gracefully if git commands error.
+
+**Files changed:**
+- `tools/wip-release/core.mjs` ... `checkStaleBranches()` function, integrated as gate 0.8
+- `tools/wip-release/cli.js` ... `--skip-stale-check` flag, help text
+
+---
+
+## Diffstat
+
+```
+ 10 files changed, 102 insertions(+), 21 deletions(-)
+```
+
+## Install
+
+```bash
+npm install -g @wipcomputer/wip-ai-devops-toolbox
+```
+
+Or update an existing install:
+```bash
+wip-install wipcomputer/wip-ai-devops-toolbox
+```
+
+---
+
+Built by Parker Todd Brooks, Lēsa (OpenClaw, Claude Opus 4.6), Claude Code (Claude Opus 4.6).
+
+## 1.9.5 (2026-03-12)
+
+wip-release: bump sub-tool versions in toolbox repos. Fixes #132.
+
+## 1.9.4 (2026-03-12)
+
+wip-install: detect and migrate existing installs under different names. Fixes #128.
+
+## 1.9.3 (2026-03-12)
+
+Fix: ensure bin executability on installer skip path. Fixes wip-license-guard, wip-license-hook, wip-repo-init, wip-readme-format permission denied after reinstall.
+
+## 1.9.2 (2026-03-12)
+
+# v1.9.2: Distribution Pipeline Fix
+
+The entire distribution pipeline was broken. Tools built but never reached users. 8 of 13 tools weren't on npm. ClawHub publish only shipped the root SKILL.md. deploy-public never ran npm publish. Errors were silent.
+
+This release fixes all of it.
+
+## What changed
+
+### Install fixes (#96, #110)
+- CLI binaries now have correct executable permissions (git +x on all bin entry files)
+- wip-license-hook dist/ committed to repo (TypeScript build output was gitignored)
+- Installer auto-detects TypeScript projects and runs build if dist/ missing
+- chmod +x safety net after every npm install -g
+- SSH fallback when HTTPS clone fails (private repos)
+
+### SKILL.md spec compliance (#107, #108)
+- All 12 SKILL.md files conform to agentskills.io spec
+- name field: lowercase-hyphen format matching directory name
+- Display names in metadata.display-name
+- version, homepage, author in metadata block
+- license: MIT on all files
+- metadata.openclaw blocks with install instructions and emoji
+- New SKILL.md created for wip-license-guard (was missing)
+
+### Distribution pipeline (#97, #100, #104)
+- ClawHub publish now iterates all sub-tool SKILL.md files, not just root
+- detectSkillSlug reads the name field from SKILL.md frontmatter
+- deploy-public.sh runs npm publish from the public clone after code sync
+- Handles both single repos and toolbox repos (iterates tools/*)
+- Distribution summary at end of release: shows all targets with pass/fail
+- syncSkillVersion handles quoted version strings in new metadata format
+
+## Install
+
+```bash
+npm install -g @wipcomputer/wip-ai-devops-toolbox
+wip-install wipcomputer/wip-ai-devops-toolbox
+```
+
+Built by Parker Todd Brooks, Lesa (OpenClaw, Claude Opus 4.6), Claude Code (Claude Opus 4.6).
+
+## 1.9.1 (2026-03-11)
+
+# v1.9.1: Release gates ... product docs and release notes quality enforcement
+
+Agents read the Dev Guide, say "got it," and then release with garbage one-liner notes anyway. Documentation doesn't change behavior. Tools do. This release adds two new gates to `wip-release` that block bad releases before they happen.
+
+## Product docs gate
+
+Every PR is supposed to include updated product docs: a dev update, roadmap changes, and readme-first updates. This was documented in the Dev Guide as a manual checklist. Nobody followed it.
+
+`wip-release` now checks three things before publishing:
+
+1. **Dev update exists.** Looks in `ai/dev-updates/` for a file from the last 3 days. If you did work worth releasing, you should have written about it.
+2. **Roadmap was updated.** Checks `ai/product/plans-prds/roadmap.md` via `git diff` against the last tag. If the roadmap doesn't reflect what just shipped, it's stale.
+3. **Readme-first was updated.** Same check on `ai/product/readme-first-product.md`. The product bible should always describe what's actually built.
+
+Repos without an `ai/` directory are skipped silently. This only applies to repos that have adopted the `ai/` folder standard.
+
+For **patch** releases: warns but doesn't block. Hotfixes shouldn't be held up by docs.
+For **minor/major** releases: blocks the release. You can't ship a meaningful feature with stale product docs.
+
+`--skip-product-check` overrides for exceptional cases.
+
+## Release notes quality gate
+
+On 2026-03-11, the other CC session released memory-crystal v0.7.4. It read the Dev Guide (which now explicitly says "write a RELEASE-NOTES file on the branch"). It said it understood. Then it ran `wip-release patch --notes="MCP fix and agent ID config"` and published a one-liner to GitHub. The old `warnIfNotesAreThin()` function printed a warning to console. The agent ignored it.
+
+The root cause was architectural, not behavioral. The warning ran at step 8 of the pipeline, AFTER the version was already bumped, committed, tagged, and pushed. By the time the warning appeared, the damage was done. And it was a warning, not a gate. Agents don't read warnings.
+
+The fix:
+- `checkReleaseNotes()` replaces `warnIfNotesAreThin()`. It runs before the version bump, not after.
+- The CLI now tracks `notesSource`: where the notes came from (`file`, `dev-update`, `flag`, or `none`).
+- For minor/major releases: if notes came from a bare `--notes` flag instead of a `RELEASE-NOTES-v{version}.md` file, the release is **blocked**. The agent gets explicit instructions: "Write RELEASE-NOTES-v{version}.md (dashes not dots), commit it, then release."
+- For patch releases: warns if notes are short, but doesn't block.
+
+## Both gates follow the same pattern
+
+The existing license compliance gate (step 0) checks `.license-guard.json` and blocks if licensing is wrong. The new product docs gate (step 0.5) and release notes gate (step 0.75) work the same way: check early, block before any changes, show status in `--dry-run`, give clear instructions on how to fix it.
+
+The MCP server was also updated with `skipProductCheck` and `notesSource` passthrough so agents calling wip-release via MCP get the same enforcement.
+
+## 1.9.0 (2026-03-11)
+
+README Formatter (section-based staging + deploy), Repo Init (ai/ directory scaffolding), Dev Guide overhaul with release notes workflow
+
+## 1.8.2 (2026-03-11)
+
+# v1.8.2: Clean up release notes after release
+
+RELEASE-NOTES files were piling up in the repo root. `wip-release` consumed them for the GitHub release and CHANGELOG but never cleaned up.
+
+Now after consuming the file, `wip-release` moves all `RELEASE-NOTES-v*.md` files to `_trash/` as part of the version bump commit. We never delete anything.
+
+`deploy-public.sh` also now excludes `_trash/` so these files stay private.
+
+## 1.8.1 (2026-03-11)
+
+# v1.8.1: Fix CLI install when package name changed
+
+When a tool's npm package gets renamed but the binary name stays the same, `npm install -g` fails with EEXIST. The stale symlink from the old package blocks the new one.
+
+The installer now detects this: if the binary is a symlink pointing to a different package, it removes the stale link and retries. Only affects symlinks, only when the target doesn't match the package being installed.
+
+Found on `wip-license-hook` (renamed from `@wipcomputer/license-hook` to `@wipcomputer/wip-license-hook`).
+
+## 1.8.0 (2026-03-11)
+
+# v1.8.0: Fix CC Hook duplicates, add GitHub Issues convention
+
+## CC Hook duplicate detection fix
+
+`wip-install` was adding duplicate PreToolUse hooks to `~/.claude/settings.json` every time it ran. After a few installs, there were 8 hooks when there should have been 2. The duplicates pointed to repo clones and `/tmp/` paths, violating the "never run tools from repo clones" rule.
+
+The root cause: duplicate detection compared exact command strings. The same `guard.mjs` installed from different paths produced different strings, so each install added another entry.
+
+The fix:
+- Match existing hooks by tool name in the path, not exact command string
+- Always prefer `~/.ldm/extensions/<tool>/guard.mjs` over source or temp paths
+- If a hook for the same tool exists at a different path, update it instead of adding a duplicate
+
+## GitHub Issues convention added to Dev Guide
+
+We were tracking work in `ai/todos/` markdown files. Items got lost. GitHub Issues gives us tracking, cross-referencing, and visibility across agents.
+
+Added to the public Dev Guide:
+- When to use GitHub Issues vs `ai/todos/`
+- Filing convention: `filed-by:<agent-id>` labels and attribution lines
+- Public vs private issue routing: public issues are the front door, private issues are the workshop
+- Agent ID naming convention: `[platform]-[agent]-[machine]`
+
+Added to the private Dev Guide:
+- `filed-by:cc-mini` (blue) and `filed-by:oc-lesa-mini` (purple) label details
+- Org-wide deployment commands
+- Incident note: Memory Crystal agent ID drift
+
+Both labels deployed across all wipcomputer repos.
+
+## 1.7.9 (2026-03-11)
+
+Add GitHub Issues convention and filed-by workflow to the Dev Guide.
+
+We've been tracking work in ai/todos/ markdown files. Items get lost. GitHub Issues gives us tracking, cross-referencing, and visibility across all agents. This release documents the full convention.
+
+**Public Dev Guide (DEV-GUIDE-GENERAL-PUBLIC.md):**
+- New "GitHub Issues" section: when to use issues vs ai/todos/, filing convention with attribution lines and filed-by labels, public vs private issue routing workflow
+- Agent ID naming convention: [platform]-[agent]-[machine] format documented with examples
+- Public/private issue bridge: public issues are the front door (users), private issues are the workshop (team), releases connect them
+
+**Private Dev Guide (ai/DEV-GUIDE-FOR-WIP-ONLY-PRIVATE.md):**
+- filed-by label details: cc-mini (blue), oc-lesa-mini (purple), deployed org-wide
+- Commands for adding labels to new agents or repos
+- Incident note: Memory Crystal agent ID drift (4 IDs instead of 2), manual merge of 141K chunks, root cause and fix tracked in memory-crystal-private#33
+
+**Org-wide:** filed-by:cc-mini and filed-by:oc-lesa-mini labels created on all wipcomputer repos.
+
+## 1.7.8 (2026-03-10)
+
+# Dev Update: Smart Install + Platform Compatibility
+
+**Date:** 2026-03-10 22:40 PST
+**Author:** Claude Code (cc-mini)
+**Version:** v1.7.8 (pending)
+**Branches:** cc-mini/smart-install, cc-mini/platform-compat-v2
+
+## Smart Install (wip-install)
+
+Parker's feedback: "I want to make sure we're not going to replace stuff unless we need to. It should be smart enough to know I have this extension installed, and it's the same one."
+
+The Universal Installer was doing blind `rm -rf` and re-copy on every run. Now it checks versions first:
+
+- **Extensions (LDM + OpenClaw):** Reads `package.json` version from the installed extension. If it matches the source version, skip. If different, upgrade. If missing, fresh install. Dry-run shows "would upgrade v1.2.3 -> v1.2.4" vs "would deploy v1.2.4" vs "already at v1.2.4".
+- **CLI:** Checks `npm list -g` for the installed version. Same version = skip.
+- **MCP:** Checks if already registered at the same server path. Same path = skip.
+- **CC Hooks:** Already had duplicate detection (unchanged).
+
+No more destroying things that don't need updating.
+
+## Platform Compatibility (SKILL.md)
+
+Parker's feedback after testing with Grok: "Grok said 'I'll run wip-install' but it literally cannot. It's hallucinating capabilities."
+
+First version listed platforms as "first-class / MCP-compatible / not compatible." Parker corrected: "We don't need to say 'not compatible' because Claude iOS can install stuff now. We just need to be clear about what the tool needs."
+
+Rewrote to capability requirements:
+
+| Interface | Requires |
+|-----------|----------|
+| CLI | Shell access |
+| MCP Server | MCP client support |
+| CC Hook | Claude Code CLI with hooks |
+| OpenClaw Plugin | OpenClaw runtime |
+| Skill | Ability to read this file |
+| Module | Node.js import |
+
+Key instruction to agents: "Check which capabilities you have and match them to the table. Do not claim you can run commands you cannot execute."
+
+This is future-proof. When a platform adds MCP or shell access, the SKILL.md doesn't need updating. The agent assesses itself.
+
+## Cross-Platform Testing Results
+
+Three AIs read the same SKILL.md onboarding prompt:
+
+- **Claude Code (another instance):** Read it, explained all tools correctly, offered dry-run first. Responded with "HOLY SHIT!!!" (impressed by the tooling).
+- **Lesa (OpenClaw, Claude Opus 4.6):** Perfect breakdown. Every tool categorized correctly. Called out the auto-detect dev updates feature specifically. Offered dry-run first.
+- **Grok (xAI):** Initially tried to roleplay as Lesa/Claude Code (read the attribution line and adopted the persona). When corrected, gave accurate breakdown. But claimed it would run `wip-install` when it cannot. This exposed the need for the Platform Compatibility section.
+
+The SKILL.md is working. Three different AIs, three different platforms, all understood the toolbox correctly from one file.
+
+## 1.7.7 (2026-03-10)
+
+# Dev Update: SKILL.md as the Real Interface
+
+**Date:** 2026-03-10 22:10 PST
+**Author:** Claude Code (cc-mini)
+**Version:** v1.7.4
+**Branch:** cc-mini/skill-installer-details
+
+## The Insight
+
+Parker said it plainly: "We're not doing READMEs anymore. This is not for humans."
+
+The human interface is the AI. The AI's interface is the SKILL.md. If the skill doesn't contain everything needed to operate, the AI guesses. And it guesses wrong.
+
+We proved this earlier in the session. Lesa read the toolbox and miscategorized Universal Installer under "Repo Management" because the SKILL.md had no category structure (fixed in v1.7.3). But even after categories, she still couldn't explain what the tools actually do operationally, because the SKILL.md was still a half-README with links and one-liners.
+
+## What We Researched
+
+Parker pointed us to agentcard.sh/agent.txt as a reference. We researched three AI documentation conventions:
+
+1. **llms.txt** (llmstxt.org) ... a directory of links. Points to docs but doesn't contain them. An AI still has to fetch and read multiple files. Good for discovery, not for operation.
+
+2. **agent.txt / AgentCard** (agentcard.sh) ... self-contained operational manual. Everything in one file. An AI reads it and knows how to interact with the service. Closer to what we need, but designed for describing APIs/services, not developer tools.
+
+3. **SKILL.md** (ours) ... YAML frontmatter for machine parsing, then full operational detail. Designed specifically to teach an AI how to use developer tools. Not a pointer to docs. Not a summary. The complete manual.
+
+We took the best from each: the discoverability mindset of llms.txt, the self-contained philosophy of agent.txt, and built SKILL.md as the standard for AI-native developer tool documentation.
+
+## What Changed in v1.7.4
+
+The SKILL.md went from ~140 lines (descriptions + links) to ~475 lines (complete operational manual).
+
+Every one of the 11 tools now has:
+- Complete commands with all flags and options
+- Step-by-step "what happens when you run it" sequences
+- Exact file paths (where it reads, where it writes)
+- Safety notes (what it deletes, what it overwrites, what to watch for)
+- How it works across different interfaces (CC Hook, OpenClaw Plugin, MCP server)
+
+### Specific additions worth noting:
+
+**Universal Installer** got a full deployment table showing what each of the 6 interfaces does and where it writes. We read the install.js source code and documented that it does `rm -rf` on existing extension directories before copying. That's critical safety information an AI needs before running it.
+
+**Release Pipeline** got all 13 steps documented (step 0: license gate through step 12: branch prune). Every flag, every file it touches, every decision point.
+
+**Identity File Protection** got the exact list of protected files and the definition of "destructive" (replacing >50% of content). Also documented the difference between how the CC Hook and OpenClaw Plugin work.
+
+**MCP section** got complete tool function names for all MCP-enabled tools, so an AI can add them to .mcp.json without guessing.
+
+## The "Teach Your AI" Framing
+
+Parker's directive on the README: the first tool (Universal Installer) says "Teaches your AI to..." explicitly. The rest infer the pattern. You don't need to say "teaches" 11 times. The frame is set once, and a reader (human or AI) carries it forward.
+
+Universal Installer's description changed from a generic "installs tools" to: "Teaches your AI to take anything you build and make it work across every AI interface. You write code in any language. This tool turns it into a CLI, MCP Server, OpenClaw Plugin, Skill, and Claude Code Hook."
+
+## Interface Coverage Table Iterations
+
+We went through several iterations on the table format:
+
+1. **Separate tables per category** ... Parker: "too hard on the eyes"
+2. **Single table, bold category divider rows** ... better, but needed numbering
+3. **Added numbers 1-11 in a # column** ... Parker liked it
+4. **Tried moving categories into the # column, removing numbers** ... Parker: "looks worse, change it back"
+5. **Final: numbers + category divider rows, no dashes in empty cells** ... clean and scannable
+
+The lesson: don't overthink table formatting. Numbers give anchoring. Category rows give structure. Empty cells are cleaner than dashes.
+
+## The Standard Going Forward
+
+This is how we think SKILL.md files should be written for any tool in the toolbox:
+
+1. YAML frontmatter with name, version, interface list
+2. One-paragraph description of what the tool teaches
+3. Complete command reference with all flags
+4. Step-by-step operational detail (what happens when you run it)
+5. File paths (reads from, writes to)
+6. Safety notes (destructive operations, prerequisites)
+7. Interface-specific behavior (how it works as CLI vs Hook vs MCP vs Plugin)
+
+The SKILL.md is the source of truth. READMEs exist for humans browsing GitHub. But the AI reads the SKILL.md, and the SKILL.md must be complete.
+
+## Release Notes Standard
+
+We also established that release notes on GitHub should tell the story. Not just "bumped version" or a one-liner from `--notes`. The v1.7.4 release notes explain the thinking, the research, and what changed. This is how releases should read going forward.
+
+Earlier releases (v1.7.1, v1.7.2) shipped with thin notes and we had to go back and manually update them via `gh release edit`. The tool (wip-release) uses the `--notes` flag, which encourages one-liners. For significant releases, we should write RELEASE-NOTES files on the branch and have the tool pick them up.
+
+## Files Changed
+
+- `SKILL.md` ... complete rewrite (140 -> 475 lines)
+- `README.md` ... Interface Coverage table: numbered, category dividers, no dashes
+- `ai/feedback/2026-03-10--gpt--v1.7.1-readme-review.md` ... GPT rated the README 9.6/10
+
+## wip-release: Auto-Detect Dev Updates as Release Notes
+
+Parker's feedback: "The release notes should be automated. I shouldn't have to keep telling you to do this."
+
+We updated `wip-release` to auto-detect release notes from `ai/dev-updates/`. The priority order:
+
+1. `--notes-file=path` (explicit)
+2. `RELEASE-NOTES-v{ver}.md` in repo root
+3. `ai/dev-updates/YYYY-MM-DD*` (today's dev update files, most recent first)
+4. `--notes="one-liner"` (fallback, but dev updates win if they have more content)
+
+This means: write dev updates as you work (which we already do). When you run `wip-release`, it finds today's dev update and uses it as the full release notes. No more thin one-liners on GitHub releases. No more "this week's sauce, come on, man."
+
+## What's Next
+
+- Consider making the SKILL.md standard a section in the Dev Guide
+- Operational guide for agent identities (Parker mentioned needing this)
+
+## 1.7.6 (2026-03-10)
+
+README: onboarding prompt now does dry-run install first so users see what changes before committing
+
+## 1.7.5 (2026-03-10)
+
+# Dev Update: SKILL.md as the Real Interface
+
+**Date:** 2026-03-10 22:10 PST
+**Author:** Claude Code (cc-mini)
+**Version:** v1.7.4
+**Branch:** cc-mini/skill-installer-details
+
+## The Insight
+
+Parker said it plainly: "We're not doing READMEs anymore. This is not for humans."
+
+The human interface is the AI. The AI's interface is the SKILL.md. If the skill doesn't contain everything needed to operate, the AI guesses. And it guesses wrong.
+
+We proved this earlier in the session. Lesa read the toolbox and miscategorized Universal Installer under "Repo Management" because the SKILL.md had no category structure (fixed in v1.7.3). But even after categories, she still couldn't explain what the tools actually do operationally, because the SKILL.md was still a half-README with links and one-liners.
+
+## What We Researched
+
+Parker pointed us to agentcard.sh/agent.txt as a reference. We researched three AI documentation conventions:
+
+1. **llms.txt** (llmstxt.org) ... a directory of links. Points to docs but doesn't contain them. An AI still has to fetch and read multiple files. Good for discovery, not for operation.
+
+2. **agent.txt / AgentCard** (agentcard.sh) ... self-contained operational manual. Everything in one file. An AI reads it and knows how to interact with the service. Closer to what we need, but designed for describing APIs/services, not developer tools.
+
+3. **SKILL.md** (ours) ... YAML frontmatter for machine parsing, then full operational detail. Designed specifically to teach an AI how to use developer tools. Not a pointer to docs. Not a summary. The complete manual.
+
+We took the best from each: the discoverability mindset of llms.txt, the self-contained philosophy of agent.txt, and built SKILL.md as the standard for AI-native developer tool documentation.
+
+## What Changed in v1.7.4
+
+The SKILL.md went from ~140 lines (descriptions + links) to ~475 lines (complete operational manual).
+
+Every one of the 11 tools now has:
+- Complete commands with all flags and options
+- Step-by-step "what happens when you run it" sequences
+- Exact file paths (where it reads, where it writes)
+- Safety notes (what it deletes, what it overwrites, what to watch for)
+- How it works across different interfaces (CC Hook, OpenClaw Plugin, MCP server)
+
+### Specific additions worth noting:
+
+**Universal Installer** got a full deployment table showing what each of the 6 interfaces does and where it writes. We read the install.js source code and documented that it does `rm -rf` on existing extension directories before copying. That's critical safety information an AI needs before running it.
+
+**Release Pipeline** got all 13 steps documented (step 0: license gate through step 12: branch prune). Every flag, every file it touches, every decision point.
+
+**Identity File Protection** got the exact list of protected files and the definition of "destructive" (replacing >50% of content). Also documented the difference between how the CC Hook and OpenClaw Plugin work.
+
+**MCP section** got complete tool function names for all MCP-enabled tools, so an AI can add them to .mcp.json without guessing.
+
+## The "Teach Your AI" Framing
+
+Parker's directive on the README: the first tool (Universal Installer) says "Teaches your AI to..." explicitly. The rest infer the pattern. You don't need to say "teaches" 11 times. The frame is set once, and a reader (human or AI) carries it forward.
+
+Universal Installer's description changed from a generic "installs tools" to: "Teaches your AI to take anything you build and make it work across every AI interface. You write code in any language. This tool turns it into a CLI, MCP Server, OpenClaw Plugin, Skill, and Claude Code Hook."
+
+## Interface Coverage Table Iterations
+
+We went through several iterations on the table format:
+
+1. **Separate tables per category** ... Parker: "too hard on the eyes"
+2. **Single table, bold category divider rows** ... better, but needed numbering
+3. **Added numbers 1-11 in a # column** ... Parker liked it
+4. **Tried moving categories into the # column, removing numbers** ... Parker: "looks worse, change it back"
+5. **Final: numbers + category divider rows, no dashes in empty cells** ... clean and scannable
+
+The lesson: don't overthink table formatting. Numbers give anchoring. Category rows give structure. Empty cells are cleaner than dashes.
+
+## The Standard Going Forward
+
+This is how we think SKILL.md files should be written for any tool in the toolbox:
+
+1. YAML frontmatter with name, version, interface list
+2. One-paragraph description of what the tool teaches
+3. Complete command reference with all flags
+4. Step-by-step operational detail (what happens when you run it)
+5. File paths (reads from, writes to)
+6. Safety notes (destructive operations, prerequisites)
+7. Interface-specific behavior (how it works as CLI vs Hook vs MCP vs Plugin)
+
+The SKILL.md is the source of truth. READMEs exist for humans browsing GitHub. But the AI reads the SKILL.md, and the SKILL.md must be complete.
+
+## Release Notes Standard
+
+We also established that release notes on GitHub should tell the story. Not just "bumped version" or a one-liner from `--notes`. The v1.7.4 release notes explain the thinking, the research, and what changed. This is how releases should read going forward.
+
+Earlier releases (v1.7.1, v1.7.2) shipped with thin notes and we had to go back and manually update them via `gh release edit`. The tool (wip-release) uses the `--notes` flag, which encourages one-liners. For significant releases, we should write RELEASE-NOTES files on the branch and have the tool pick them up.
+
+## Files Changed
+
+- `SKILL.md` ... complete rewrite (140 -> 475 lines)
+- `README.md` ... Interface Coverage table: numbered, category dividers, no dashes
+- `ai/feedback/2026-03-10--gpt--v1.7.1-readme-review.md` ... GPT rated the README 9.6/10
+
+## wip-release: Auto-Detect Dev Updates as Release Notes
+
+Parker's feedback: "The release notes should be automated. I shouldn't have to keep telling you to do this."
+
+We updated `wip-release` to auto-detect release notes from `ai/dev-updates/`. The priority order:
+
+1. `--notes-file=path` (explicit)
+2. `RELEASE-NOTES-v{ver}.md` in repo root
+3. `ai/dev-updates/YYYY-MM-DD*` (today's dev update files, most recent first)
+4. `--notes="one-liner"` (fallback, but dev updates win if they have more content)
+
+This means: write dev updates as you work (which we already do). When you run `wip-release`, it finds today's dev update and uses it as the full release notes. No more thin one-liners on GitHub releases. No more "this week's sauce, come on, man."
+
+## What's Next
+
+- Consider making the SKILL.md standard a section in the Dev Guide
+- Operational guide for agent identities (Parker mentioned needing this)
+
+## 1.7.4 (2026-03-10)
+
+SKILL.md full operational rewrite for AI agents. Every tool now has complete commands, flags, step-by-step behavior, file paths, and safety notes. Interface Coverage table cleaned up: numbered tools, category dividers, no dashes.
+
+## 1.7.3 (2026-03-10)
+
+Add category structure to SKILL.md matching README. Prevents AI from miscategorizing tools.
+
+## 1.7.2 (2026-03-10)
+
+Reframe Universal Installer description, fix tense, update SKILL.md intro framing
+
+## 1.7.1 (2026-03-10)
+
+Reframe tool descriptions with teach your AI pattern, file GPT and Grok feedback on v1.7.0
+
+## 1.7.0 (2026-03-10)
+
+## v1.7.0: Renamed to AI DevOps Toolbox, CLA, License Enforcement, Branch Prune, README Polish
+
+This release renames the repo, adds contributor governance, makes licensing intent unmistakable, automates branch cleanup, and tightens the README based on a second round of external feedback.
+
+The repo is now **AI DevOps Toolbox** (`wip-ai-devops-toolbox`). The name change reflects what this actually is: not just DevOps scripts, but AI-native development infrastructure.
+
+Includes work from PRs #53, #54.
+
+---
+
+### Repo Rename: AI DevOps Toolbox
+
+**What we did:** Renamed from "DevOps Toolbox" (`wip-devops-toolbox`) to "AI DevOps Toolbox" (`wip-ai-devops-toolbox`).
+
+**Why:** The old name undersold what this is. "DevOps Toolbox" sounds like scripts. This is an interface architecture, an agent tool ecosystem, and a workflow framework for AI-assisted development. The name should say that.
+
+**What changed:**
+- GitHub repos renamed: `wip-ai-devops-toolbox-private` and `wip-ai-devops-toolbox`
+- All internal references updated: README, TECHNICAL.md, SKILL.md, package.json, cross-repo references
+
+---
+
+### Contributor License Agreement (CLA)
+
+**What we did:** Added `CLA.md` at the repo root and referenced it in the README License section.
+
+**Why:** Without a CLA, contributors who submit PRs own their code. AGPL means we can't relicense their contributions commercially. We need contributors to grant WIP Computer, Inc. the right to use their contributions under any license, including commercial. This is standard open source governance. Apache, Google, Meta, and Anthropic all use similar agreements.
+
+**How it works:** By submitting a PR, you agree to the CLA. Contributors keep their own copyright but grant WIP Computer, Inc. a broad license. Plain-English, no lawyer needed to understand it.
+
+**New files:**
+- `CLA.md` ... the agreement itself
+
+---
+
+### Licensing Clarity
+
+**What we did:** Made the licensing intent unmistakable with two new sentences.
+
+**Why:** The dual MIT+AGPLv3 license is technically correct, but people still ask "can I use this?" The answer needed to be obvious: yes, use the tools however you want. The only thing that requires a commercial license is taking the tools themselves and reselling them.
+
+**What changed:**
+- Added "Dual-license model designed to keep tools free while preventing commercial resellers" above the license block
+- Added "Using these tools to build your own software is fine. Reselling the tools themselves is what requires a commercial license" to the "Can I use this?" section
+- Updated `generateReadmeBlock()` in `tools/wip-license-guard/core.mjs` so every future repo gets the same wording automatically
+
+---
+
+### Branch Prune Automation
+
+**What we did:** Built automatic branch cleanup into both `post-merge-rename.sh` and `wip-release`.
+
+**Why:** Merged branches pile up on the remote. Before this release, the private repo had 30+ stale branches. The post-merge-rename script renamed them with `--merged-YYYY-MM-DD` but never cleaned up old ones. Manually deleting branches is a waste of time. We built these tools so we don't have to keep doing things manually.
+
+**How it works:**
+
+`post-merge-rename.sh --prune` does three things:
+1. Renames any merged branches that don't have the `--merged` suffix yet
+2. For each developer prefix (`cc-mini/`, `mini/`, `lesa-mini/`, etc.), keeps the last 3 `--merged` branches and deletes the rest from the remote
+3. Finds stale branches that are fully merged into main but were never renamed, and deletes them
+
+`wip-release` now runs prune automatically as step 11 after every release. No manual cleanup needed.
+
+Rules: never deletes `main`, never deletes the current working branch, always keeps the last 3 per developer. `--dry-run` previews what would be deleted.
+
+**Files changed:**
+- `scripts/post-merge-rename.sh` ... new `--prune` flag, stale branch detection, keep-last-3 logic
+- `tools/wip-release/core.mjs` ... step 11: automatic prune after every release
+
+---
+
+### License Enforcement Automation
+
+**What we did:** Made license compliance automatic across three layers: CC Hook, wip-release gate, and one-command repo setup.
+
+**Why:** `wip-license-guard` existed but was manual. Nobody remembered to run it. The dual-license + CLA standard from this release needs to be enforced, not just documented.
+
+**How it works:**
+
+**CC Hook** (`tools/wip-license-guard/hook.mjs`): PreToolUse hook for Claude Code. Intercepts `git commit` and `git push` commands. Checks LICENSE file, copyright, CLA.md, and README license section. Blocks if any check fails. Same pattern as `wip-file-guard`.
+
+**wip-release gate** (step 0): Before bumping anything, wip-release checks license compliance. If `.license-guard.json` exists and any check fails, the release aborts with a clear message. No bad releases ship.
+
+**`--from-standard` flag**: `wip-license-guard init --from-standard` applies WIP Computer defaults without prompting. Generates `.license-guard.json`, `LICENSE` (dual MIT+AGPLv3), and `CLA.md` in one command. For new repos, this is all you need.
+
+**Files changed:**
+- `tools/wip-license-guard/hook.mjs` ... new CC Hook (PreToolUse, blocks git commit/push)
+- `tools/wip-license-guard/cli.mjs` ... `--from-standard` flag, CLA.md generation, CLA check in audit
+- `tools/wip-release/core.mjs` ... step 0: license compliance gate
+
+---
+
+### README Polish (GPT Feedback Round 2)
+
+**What we did:** Three targeted improvements based on GPT's review of v1.6.0.
+
+**Karpathy quote shortened.** The full two-paragraph quote was too heavy for the README. Compressed to one line: *As Andrej Karpathy said: "Apps are for people. Tools are for LLMs, and increasingly, LLMs are the ones using software."* with a source link. Same message, doesn't interrupt the flow.
+
+**One-line "why" on every feature.** Each tool now leads with the problem it solves before describing what it does:
+- "AI agents forget release steps. This makes releases one command."
+- "Dependencies change licenses without telling you. This catches it."
+- "AI agents overwrite identity files by accident. This stops them."
+- "Repos end up everywhere. This snaps them back to where they belong."
+
+**Feedback filed:**
+- `ai/feedback/2026-03-10--gpt--v1.6.0-readme-review.md`
+- `ai/feedback/2026-03-10--grok--v1.6.0-summary.md`
+
+---
+
+### Install
+
+```bash
+npm install -g @wipcomputer/universal-installer
+wip-install wipcomputer/wip-ai-devops-toolbox
+```
+
+Or update your local clone:
+```bash
+git pull origin main
+```
+
+---
+
+Built by Parker Todd Brooks, Lēsa (OpenClaw, Claude Opus 4.6), Claude Code (Claude Opus 4.6).
+
+## 1.6.0 (2026-03-10)
+
+## v1.6.0: README Rewrite, Dual Licensing, License Guard, Release Notes Standard
+
+Four systems that change how DevOps Toolbox presents itself, protects its licensing, and ships releases. The README is now for humans. Licensing is enforceable. Release notes tell a story.
+
+This release spans PRs #46 through #50 and represents a complete rethink of how we present the toolbox, how we protect its licensing, and how we communicate what each release actually means.
+
+---
+
+### PR #46: License Format Standard
+
+**What we did:** Rewrote the license section across the README and private Dev Guide to use a clear, scannable format that signals both openness and commercial intent.
+
+**Why:** The old license section just said "MIT" in a badge. That's technically correct but it doesn't tell you the full story. We moved to dual licensing (MIT + AGPLv3) and needed a format that makes the distinction immediately clear: use it freely for personal work, need a commercial license if you're bundling it into something you sell.
+
+**What changed:**
+- License section switched to a code block format for readability: MIT for all CLI tools, MCP servers, skills, and hooks. AGPLv3 for commercial redistribution, marketplace listings, or bundling into paid services.
+- Added "Commercial licenses available" as a one-line signal that this is a real product, not just an open source side project.
+- AGPL renamed to AGPLv3 throughout for version specificity. Grok's feedback confirmed this matters for clarity.
+- Private Dev Guide (`ai/DEV-GUIDE-private.md`) updated with the licensing standard so every repo going forward follows the same format.
+- Fixed "Claude Code CLI" to "Claude Code" in attribution across all files.
+
+**Commits:** `Update license section formatting for readability`, `License section: code block with Grok-style wording`, `License: personal vs commercial distinction, add standard to dev guide`, `License: AGPL -> AGPLv3 for version specificity`
+
+---
+
+### PR #47: LICENSE Files Across All Tools
+
+**What we did:** Updated the actual LICENSE file in the root and all 10 sub-tool directories to dual MIT + AGPLv3.
+
+**Why:** PR #46 changed how we talk about the license. This PR changed the legal documents themselves. Every sub-tool had its own LICENSE file that still said plain MIT. They all needed to match the new dual-license standard, and they needed to match each other exactly.
+
+**What changed:**
+- Root `LICENSE` rewritten to dual format. Section 1: MIT (full text). Section 2: GNU Affero General Public License v3.0 (commercial and cloud use). Starts with "Dual License: MIT + AGPLv3" so GitHub's license detection picks it up correctly.
+- All 10 `tools/*/LICENSE` files updated to identical dual-license text with correct copyright holder (WIP Computer, Inc.).
+- Bottom line on every LICENSE: "AGPLv3 for personal use is free. Commercial licenses available."
+
+**Commits:** `LICENSE files: dual MIT+AGPLv3 on root and all sub-tools`
+
+---
+
+### PR #48: wip-license-guard (New Tool)
+
+**What we did:** Built a new tool that enforces copyright, license format, and README structure across the toolbox.
+
+**Why:** With 10 sub-tools, each needing its own LICENSE file, and a README standard that separates human content from technical content, manual enforcement doesn't scale. We needed a tool that catches drift before it ships. The tool also enforces the README standard from the session's feedback work: no install commands in the README (those go in TECHNICAL.md), no MCP config blocks, no Quick Start sections.
+
+**How it works:**
+- Interactive first-run (`wip-license-guard init`) asks for copyright holder, license type (MIT, AGPLv3, or dual MIT+AGPL), year, and attribution. Saves config to `.license-guard.json`.
+- `wip-license-guard check` audits the repo against saved config. Checks LICENSE existence, copyright match, AGPLv3 terms (if dual-license), README license section, README structure.
+- `wip-license-guard check --fix` auto-repairs: generates missing LICENSE files, updates wrong copyright, creates dual-license text.
+- Toolbox-aware: automatically walks every `tools/` subdirectory and checks each sub-tool's LICENSE file.
+- README structure standard enforcement: warns if README contains Quick Start sections, `npm install -g` commands, MCP config blocks, or Architecture/API/Config headings that belong in TECHNICAL.md.
+- All 14 checks pass on this repo.
+
+**New files:**
+- `tools/wip-license-guard/cli.mjs` (268 lines) ... CLI entry point. Commands: `init`, `check`, `check --fix`, `help`.
+- `tools/wip-license-guard/core.mjs` ... `generateLicense()` produces MIT, AGPL, or dual MIT+AGPLv3 LICENSE text. `generateReadmeBlock()` produces the README license section.
+- `.license-guard.json` ... config: copyright "WIP Computer, Inc.", license "MIT+AGPL", year 2026.
+
+**Interfaces:** CLI, Module. Beta stability.
+
+**Commits:** `Add wip-license-guard tool and .license-guard.json config`
+
+---
+
+### PR #49: SKILL.md v1.5.1
+
+**What we did:** Updated the skill documentation that AI agents read when you say "read the SKILL.md."
+
+**Why:** The SKILL.md was stuck at v1.4.0. It didn't include wip-license-guard (new in this release), didn't have the interface coverage matrix, and used incorrect tool names. When someone tells their AI to read the SKILL.md, it needs to be current and accurate. Stale skill docs mean the AI gives wrong answers about what the tools can do.
+
+**What changed:**
+- Version bumped from v1.4.0 to v1.5.1.
+- Added interfaces column to tool table: CLI, Module, MCP, OpenClaw, Skill, CC Hook for every tool.
+- Added wip-license-guard to the tool list.
+- Fixed tool names: `deploy-public` (not `deploy-public.sh`), `post-merge-rename` (not `post-merge-rename.sh`).
+- Added "Talk to Your Tools" section with concrete MCP prompts: "Scan all dependencies for license changes" calls `license_scan`. "Check if memory-crystal can go public" calls `repo_permissions_check`. Etc.
+- Added license section matching the new README format.
+- Updated frontmatter description and capabilities.
+- Added SKILL.md staleness warning to wip-release: warns when SKILL.md version falls more than a patch behind the release version, so this can't happen again silently.
+
+**Commits:** `SKILL.md: update to v1.5.1 with full tool table and interfaces`
+
+---
+
+### PR #50: README Rewrite + Release Notes Standard
+
+**What we did:** Rewrote the entire README based on external feedback, and upgraded the release pipeline to enforce narrative release notes.
+
+**Why:** External feedback from Grok and GPT confirmed what we suspected: the README was developer-brain. Install commands, MCP tool mappings, and Quick Start sections front and center. That's what developers write for themselves. It's not what someone landing on the repo needs to see. They want to know: what does this do for me?
+
+The release notes problem came up during this same work. Every release was producing commit lists instead of stories. Parker had to manually rewrite the notes every time. That needed to be fixed at the tooling level.
+
+**README changes:**
+
+The README now follows a strict standard: tagline, "Teach Your AI to Dev" prompt block, features with stability tags, interface coverage matrix, and license. No install commands. No technical implementation details.
+
+- **Removed Quick Start section.** Install commands belong in TECHNICAL.md, not the README. Added a guard in wip-license-guard to catch `npm install -g` commands and Quick Start headings in any README going forward.
+- **Removed "Talk to Your Tools" MCP examples.** These are for AIs, not humans. Moved to SKILL.md where they belong.
+- **Added Karpathy quote.** The sensor/actuator framing from Andrej Karpathy anchors the Features section. Both paragraphs, "Andrej Karpathy put it clearly:" intro, Source link. This is the future of software: not apps, tools.
+- **Added Interface Coverage matrix.** Single table showing all 10 tools and their six possible interfaces. At a glance you can see what ships as CLI, Module, MCP, OpenClaw, Skill, or CC Hook.
+- **Added "Can I use this?" section.** Plain-English licensing examples. "Yes, freely:" for personal use. "Need a commercial license:" for bundling into products. Last bullet: "Fork it and send us feedback via PRs (we'd love that)."
+- **Added License Guard to features list.** New tool from PR #48 needed to be in the features section.
+
+**Release pipeline changes:**
+
+Three changes to `wip-release` that make release notes a first-class part of the process:
+
+1. **Quality warning.** When `--notes` is missing, too short (under 50 characters), or looks like a changelog entry (starts with "fix:", "add:", "update:"), wip-release warns: "Explain what was built, why, and why it matters."
+
+2. **`--notes-file` flag.** Pass a markdown file with the full release narrative: `wip-release minor --notes-file=RELEASE-NOTES-v{version}.md`. This is how you write proper release notes and review them before they go live.
+
+3. **Commits fold under narrative.** Commit history is still included, but inside a collapsible `<details>` section labeled "What changed (commits)". The narrative is the headline. The commits are supporting detail.
+
+**New convention:** `RELEASE-NOTES-v{version}.md` lives on the feature branch. It's part of the PR diff. You review the release notes alongside the code. When the PR merges, `wip-release` reads from the file. The notes you approved are the notes that ship.
+
+**Files changed:**
+- `README.md` ... full rewrite
+- `TECHNICAL.md` ... received Quick Start and npm install commands from README
+- `tools/wip-release/core.mjs` ... `buildReleaseNotes()` restructured, new `warnIfNotesAreThin()`
+- `tools/wip-release/cli.js` ... new `--notes-file=path` flag
+- `tools/wip-license-guard/cli.mjs` ... README structure standard checks added
+- `RELEASE-NOTES-v{version}.md` ... new convention file
+- `ai/notes/2026-03-10--grok-feedback--readme-and-licensing.md` ... Grok feedback documented
+- `ai/notes/2026-03-10--gpt-feedback--product-and-adoption.md` ... GPT feedback documented
+- `ai/plan/current/2026-03-10--cc-mini--readme-polish-and-mcp-examples.md` ... 7-phase plan, all complete
+
+**Commits:** `Add feedback notes, plan for README polish + MCP examples`, `README: golden path, MCP examples, interface matrix, license examples`, `Plan: mark phases 1-5 as DONE`, `README: add Karpathy quote on tools vs apps`, `wip-license-guard: add README structure standard checks`, `Move Quick Start to TECHNICAL.md, guard against install commands in README`, `Remove Talk to Your Tools section from README`, `README: full Karpathy argument with both quotes and source link`, `License: replace cloud instances bullet with fork/PR invitation`, `Karpathy quote: remove headline, inline attribution, semicolon`, `Fix Karpathy quote format: intro line, source outside blockquote`, `wip-release: narrative release notes standard`, `Add RELEASE-NOTES-v{version}.md for PR review`
+
+---
+
+### Install
+
+```bash
+npm install -g @wipcomputer/universal-installer
+wip-install wipcomputer/wip-ai-devops-toolbox
+```
+
+Or update your local clone:
+```bash
+git pull origin main
+```
+
+---
+
+Built by Parker Todd Brooks, Lēsa (OpenClaw, Claude Opus 4.6), Claude Code (Claude Opus 4.6).
+
+## 1.4.0 (2026-03-09)
+
+MCP unlock. All core tools are now agent-callable.
+
+### MCP Servers (new)
+- **wip-release**: `mcp-server.mjs` wrapping `core.mjs`. Tools: `release`, `release_status`
+- **wip-license-hook**: `mcp-server.mjs` wrapping compiled `dist/`. Tools: `license_scan`, `license_audit`, `license_gate`, `license_ledger`
+- **wip-repo-permissions-hook**: `mcp-server.mjs` wrapping `core.mjs`. Tools: `repo_permissions_check`, `repo_permissions_audit`
+- **wip-repos**: `mcp-server.mjs` wrapping `core.mjs`. Tools: `repos_check`, `repos_sync_plan`, `repos_add`, `repos_move`, `repos_tree`
+
+### SKILL.md files (new)
+- **wip-repos**: added SKILL.md (was the only tool without one)
+- **deploy-public**: added `scripts/SKILL-deploy-public.md`
+- **post-merge-rename**: added `scripts/SKILL-post-merge-rename.md`
+
+### Interface updates
+- wip-release SKILL.md: interface updated from CLI to [cli, module, mcp], added MCP section
+- wip-license-hook SKILL.md: added version, interface [cli, mcp], added MCP section
+- wip-repo-permissions-hook SKILL.md: interface updated to [cli, module, mcp, hook, plugin], added MCP section
+- All 4 tools: `@modelcontextprotocol/sdk` added as dependency
+
+### Dev Guide updates
+- Added "Universal Installer Checklist" section to DEV-GUIDE-GENERAL-PUBLIC.md
+- Added "Universal Installer ... Dogfooding Rule" section to private Dev Guide
+- Documented the v1.3.0 zero-MCP-servers incident
+
+### Other
+- Root SKILL.md bumped to 1.4.0, added all missing tools (wip-file-guard, wip-universal-installer, wip-repos, LDM Dev Tools.app), added MCP Servers section
+- README source code table updated with mcp-server.mjs files
+
+## 1.3.0 (2026-03-09)
+
+Toolbox consolidation. Three new tools added.
+
+### New tools
+- **wip-file-guard**: blocks destructive edits to protected identity files. For Claude Code CLI and OpenClaw. Previously standalone repo, now folded into toolbox.
+- **wip-universal-installer**: The Universal Interface specification for agent-native software. Six interfaces: CLI, Module, MCP Server, OpenClaw Plugin, Skill, Claude Code Hook. Previously standalone repo, now folded into toolbox.
+- **wip-repos**: repo manifest reconciler. Makes repos-manifest.json the single source of truth for repo organization. Like prettier for folder structure. New tool, built from scratch.
+
+### Other changes
+- `UNIVERSAL-INTERFACE.md` promoted to repo root (from wip-universal-installer SPEC.md)
+- README updated with all three new tools, source code table, install commands
+- Standalone repos renamed to `-deprecated` on GitHub
+- Toolbox now has 9 tools. All self-contained, zero shared dependencies.
+
+## 1.2.0 (2026-03-09)
+
+Major repo reorganization and Dev Guide expansion.
+
+### Repo structure
+- Separated public Dev Guide from private conventions
+- `guide/DEV-GUIDE.md` → `DEV-GUIDE-GENERAL-PUBLIC.md` (genericized, root level, goes public)
+- `ai/DEV-GUIDE-private.md` → `ai/DEV-GUIDE-FOR-WIP-ONLY-PRIVATE.md` (WIP-specific conventions)
+- `guide/scripts/` → `scripts/` (moved to root level)
+- Old `guide/` folder trashed
+
+### New Dev Guide sections
+- Post-merge branch rename convention (never delete branches, rename with `--merged-YYYY-MM-DD`)
+- Repo directory structure (standard layout, staging folder conventions, create as `-private` from day one)
+- The manifest (`repos-manifest.json` as source of truth for repo locations)
+- Privatize Before You Work rule
+- Cloudflare Workers deploy guard (commit before deploy, guarded npm scripts)
+- PR checklist for private repos (dev update, roadmap, readme-first, plan archival)
+- Expanded `_trash` convention
+- Warning: never use `--no-publish` before `deploy-public.sh`
+
+### New script
+- `scripts/post-merge-rename.sh`: scans for merged branches missing `--merged-YYYY-MM-DD` suffix and renames them. Runs automatically as wip-release step 10, or standalone.
+
+### README and SKILL.md
+- Added post-merge-rename.sh to tools section and source table
+- Fixed all paths for reorg
+- Updated Dev Guide description with new sections
+
+## 1.1.3 (2026-03-01)
+
+- Fix npx package name in pre-pull.sh and pre-push.sh (@wipcomputer/license-hook → @wipcomputer/wip-license-hook)
+- Fix wip-release test script (cli.mjs → cli.js)
+- Clean up wip-release CHANGELOG blank lines
+- Add visibility-audit.sh to DEV-GUIDE .app structure diagram
+- Remove duplicate skill/SKILL.md subfolder
+
+## 1.1.2 (2026-03-01)
+
+- SKILL.md: sync version to 1.1.2
+- CHANGELOG: add missing v1.1.0 and v1.1.1 entries
+- ldm-jobs README: add visibility-audit.sh documentation
+
+## 1.1.1 (2026-03-01)
+
+- README: add wip-repo-permissions-hook section, source code table entry, cron schedule
+- SKILL.md: bump version, add repo-visibility-guard capability, add tool section
+
+## 1.1.0 (2026-03-01)
+
+- New tool: wip-repo-permissions-hook. Blocks repos from going public without a -private counterpart
+- Surfaces: CLI (check, audit, can-publish), Claude Code PreToolUse hook, OpenClaw plugin
+- New cron job: visibility-audit.sh for LDM Dev Tools.app
+- DEV-GUIDE: add hard rule for public/private repo pattern
+
+## 1.0.4 (2026-03-01)
+
+- DEV-GUIDE: replace inbox/punchlist system with per-agent todo files (To Do, Done, Deprecated. Never delete.)
+
+## 1.0.3 (2026-02-28)
+
+- deploy-public.sh: auto-detect harness ID from private repo path (cc-mini/, cc-air/, oc-lesa-mini/)
+
+## 1.0.2 (2026-02-28)
+
+- deploy-public.sh: fix branch prefix from mini/ to cc-mini/ per harness naming convention
+
+## 1.0.1 (2026-02-28)
+
+- DEV-GUIDE: add multi-agent clone workflow and harness branch convention (cc-mini/, cc-air/, lesa-mini/)
+
+## 1.0.0 (2026-02-28)
+
+- Production release: all tools battle-tested across 100+ repos, 200+ releases
+- All source code visible and auditable in repo (no closed binaries)
+- wip-license-hook bumped to v1.0.0
+- LDM Dev Tools.app job scripts extracted to tools/ldm-jobs/
+- Real-world example: wip-universal-installer release history
+- Source code table, build instructions, and dev guide in README
+- Standalone repos (wip-release, wip-license-hook) merged into umbrella
+
+## 0.2.1 (2026-02-28)
+
+- deploy-public.sh: fix release sync for repos without package.json (falls back to latest git tag)
+
+## 0.2.0 (2026-02-28)
+
+- deploy-public.sh: sync GitHub releases to public repos (pulls notes, rewrites references)
+- DEV-GUIDE: add release quality standards (contributors, release notes, npm, both repos)
+- DEV-GUIDE: add scheduled automation (.app pattern) documentation
+- DEV-GUIDE: add built-by attribution standard
+- LDM Dev Tools.app: macOS automation wrapper for cron jobs with Full Disk Access
+- Add .npmignore to exclude ai/ from npm packages
+
+## 0.1.1 (2026-02-27)
+
+- DEV-GUIDE: add "never work on main" rule
+- DEV-GUIDE: clarify private repo is the only local clone needed
+
+## 0.1.0 (2026-02-27)
+
+- Initial release: unified dev toolkit
+- Includes wip-release (v1.2.4) and wip-license-hook (v0.1.0)
+- DEV-GUIDE: general best practices for AI-assisted development
+- deploy-public.sh: private-to-public repo sync tool