`ConvertFrom-Json -AsHashtable` is PowerShell 7+ only, and the Windows 11
reference machine used to validate this PR ships with Windows PowerShell
5.1 only (no `pwsh` on PATH). Without this follow-up, running the
installer on stock Windows fails at the parse step and leaves the
installation half-applied.
- Fall back to a manual `PSCustomObject` -> `Hashtable` conversion when
`-AsHashtable` raises, so the script parses the existing
settings.local.json on both PS 5.1 and PS 7+.
- Normalize both hook buckets (`PreToolUse`, `PostToolUse`) and their
inner `hooks` arrays as `System.Collections.ArrayList` before
serialization. PS 5.1 `ConvertTo-Json` otherwise collapses
single-element arrays into bare objects, which breaks the canonical
PR #1524 shape.
- Create the `skills/continuous-learning/hooks` destination directory
when it does not exist yet, and emit a clearer error if
settings.local.json is missing entirely.
- Update `INSTALL-HOOK-WRAPPER-FIX-20260422.md` to document the PS 5.1
compatibility guarantee and to cross-link PR #1542 (companion simple
patcher).
Verified on Windows 11 / Windows PowerShell 5.1.26100.8115 by running
`powershell -NoProfile -ExecutionPolicy Bypass -File
docs/fixes/install_hook_wrapper.ps1` against a sandbox `$env:USERPROFILE`
and against the real settings.local.json. Both produce the canonical
PR #1524 shape with LF-only output.
Under Claude Code v2.1.116 the first argv token of a hook command is
duplicated. When the token is a quoted Windows .exe path, bash.exe is
re-invoked with itself as script (exit 126). PR #1524 fixed the shape
of settings.local.json; this script keeps the installer consistent so
re-running it does not regenerate the broken form.
Changes:
- First token is now PATH-resolved `bash` instead of the quoted bash.exe
- Wrapper path is normalized to forward slashes for MSYS safety
- PreToolUse and PostToolUse get distinct pre/post positional arguments
- JSON output is written with LF endings (no mixed CRLF/LF)
Companion doc: docs/fixes/INSTALL-HOOK-WRAPPER-FIX-20260422.md
Re-renders hero.png without the baked-in stars (163k) and forks (25k) numbers
that were drifting from the README's own dynamic badges. Bottom stats now show
repo-derived catalog counts that don't rot: 310 total items (183 skills + 48
agents + 79 commands), 7 harnesses, ECC 2.0α, MIT.
Also shrinks the file from 534 KB to ~131 KB via tighter pngquant settings.
Addresses review comments from cubic and greptile (stat drift) and CodeRabbit
(file size).
`findPluginInstall()` in `scripts/harness-audit.js` scans two candidate
roots:
{rootDir}/.claude/plugins/
{HOME}/.claude/plugins/
Current Claude Code marketplace installs live one directory deeper:
{HOME}/.claude/plugins/marketplaces/{ecc,everything-claude-code}/...
As a result, running `node scripts/harness-audit.js repo` on any
consumer project reports `consumer-plugin-install: false` even when ECC
is fully installed via marketplace, costing 4 points from Tool Coverage.
Add the `marketplaces/` intermediate directory to `candidateRoots` so
both legacy and current install layouts are recognized. The change is
purely additive: existing candidate paths still resolve, and the new
ones only match when the marketplace layout is present.
Reproduction:
1. Install ECC via Claude Code plugin marketplace
2. cd into any consumer project
3. node ~/.claude/plugins/marketplaces/everything-claude-code/scripts/harness-audit.js repo
4. Observe consumer-plugin-install=false despite a working install
