docs(reports): close the nest_migration campaign with its verification record

[LittleCoinCoin]

Why

Closes the nest_migration campaign. Documentation only — no code, no manifests, no version change. The migration itself landed in #15; this records what verifying it actually proved.

What changed

• __reports__/nest_migration/00-findings_migration_v0.md — the install check as first measured, when colgrep-mcp could not be installed from Nest.
• __reports__/nest_migration/01-findings_migration_v1.md — after the Nest fix: all seven entries install.
• __reports__/nest_migration/README.md — topic index, plus the record of the one gate that closed after both reports were written.
• __roadmap__/nest_migration/ — all three leaves ✅, set through dirtree-rdm only, validate clean at both levels.

What the verification actually proved

Gate	Result
colgrep-mcp installs from Nest as published	✅
All 7 catalogue entries install and enable	✅
No failed to load, no duplicate-hooks failure	✅ 0
MCP server connects	✅ uvx colgrep-mcp==0.5.1 - ✔ Connected
Installed artifact shape	✅ extensions["com.openai"], 7 interface keys, no .codex-plugin/ / marketplace.json / .agents/
Search-policy hook fires in a fresh session	✅

The duplicate-hooks failure this repository hit at 0.4.0 and 0.5.0 did not fire, on a release where the hooks manifest changed shape. That class of failure is only reproducible through a real marketplace install — --plugin-dir, plugin details and plugin validate all accept a tree that fails one.

Two pieces of evidence that were nearly wrong

The first colgrep-mcp install was discarded rather than reused. It succeeded only because of a local marketplace-cache edit carrying an unpublished fix. Re-running the gate without uninstalling first would have re-confirmed the workaround and passed for the wrong reason — the marketplace-level twin of running a suite against the wrong checkout. The plugin was uninstalled and reinstalled from the published catalogue before the gate was called met.

The hook gate was left open rather than inferred. claude -p failed twice with an expired OAuth session, so v0 and v1 both record it unverified, with the installed hook script exercised directly as a partial substitute. After re-authentication a fresh session received the SessionStart context and quoted the denied-tools sentence verbatim. That closure is recorded in the topic README; the reports are left as written, because a finding states what was known when it was made, and editing them to look prescient would destroy the only evidence the gate was ever open.

Findings handed to other repositories

Each was diagnosed here, verified, and fixed upstream rather than worked around locally:

• Nest's colgrep-mcp entry used the github + repo shorthand, which Claude Code clones over SSH for a plugin source — while resolving the same shorthand over HTTPS for a marketplace source. Ruled out as a credential fault: gh auth reports https as its git protocol with repo scope, osxkeychain is configured, and both were ignored. Any user without a GitHub SSH key could not install. Fixed in Nest 2ebd2bc; the replacement shape was verified locally before being recommended.
• The upstream end_to_end gate verified five installs plus colgrep-mcp's listing. Listing and installing are different claims, and all five verified entries shared the working shape, so no counter-example existed anywhere in the evidence. The gate now installs every entry.
• claude plugin validate . validates one manifest, prefers the marketplace, and stops — so while this repository shipped a catalogue, its own gate never checked the plugin manifest. Documented here as stack-traps#validate-picks-one and upstream under the same anchor.
• The generator advised --force on a file it refuses to overwrite. Fixed upstream; splitting the ledger there nearly reintroduced the class of bug it was fixing, since the guard iterated one list.

Verification

• uv run pytest — 307 passed, 1 skipped
• uv run ruff check / ruff format --check — clean
• uv run cz check --rev-range main..HEAD — clean
• dirtree-rdm validate — OK at both roadmap levels

Not in scope

The v0.5.2 release is deliberately separate, and left to cz to compute from these commits. Worth recording that refactor has no bump_map entry in this repository, so the campaign's headline change — the manifest reshape — contributed no version bump; the patch comes from incidental fix commits. Since Codex reinstalls only on a version change, a pure refactor + docs campaign would have shipped a manifest no Codex user ever received.

🤖 Generated with Claude Code