`.claude-plugin/plugin.json` was manually bumped 3.0.3 → 3.0.4 → 3.0.5
→ 3.0.6 → 3.0.7 across recent feature commits (1f20c38, f8720da,
22d493b, 47350c3) without corresponding bumps to `.cursor-plugin`,
`.codex-plugin`, the release-please manifest, or the linked cli
package.json. AGENTS.md "Versioning Requirements" explicitly forbids
manual bumps here — release-please owns all three plugin.json files via
extra-files in .github/release-please-config.json, and the linked-versions
plugin keeps cli and compound-engineering in lockstep.

Drift broke `release:validate` on every PR's CI (PR #677 surfaced it).

Recovery uses the "forward" path (sync everything to 3.0.7) instead of
reverting .claude-plugin to 3.0.3, because developers running
compound-engineering from a local main checkout already have 3.0.7
installed. Reverting would orphan their cache dirs and trigger
version-regression warnings in tooling that treats the field as
monotonic. Forward-sync preserves semver monotonicity with zero
regression for any current install.

Changes:
- .cursor-plugin/plugin.json: 3.0.3 → 3.0.7 (compound-engineering extra-file)
- .codex-plugin/plugin.json: 3.0.3 → 3.0.7 (compound-engineering extra-file)
- .github/.release-please-manifest.json: compound-engineering 3.0.3 → 3.0.7
- .github/.release-please-manifest.json: . (cli, linked-versions) 3.0.3 → 3.0.7
- package.json: 3.0.3 → 3.0.7 (cli extra-file, linked to compound-engineering)

`bun run release:validate` now reports in-sync metadata. The next
release-please run will compute 3.0.8+ from a coherent starting point.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Commit 1f20c38 (feat(lfg): add ce-commit-push-pr step and remove ralph-loop)
renumbered the steps in lfg/SKILL.md when it removed the optional
ralph-loop step 1 and added ce-commit-push-pr as step 7. Two assertions
in tests/review-skill-contract.test.ts weren't updated:

1. The "Do not proceed to step 6" assertion now reads "step 5" in the
   skill, because residual handoff is the chronologically-next step
   after persisting autofixes.
2. The broad `not.toContain("ce-commit-push-pr")` assertion was
   tripping on step 7's legitimate use of the skill for the post-work
   commit/PR-open step. The intent was to verify the residual handoff
   doesn't route through confirmation-driven PR updates, which is
   already covered by the positive `gh pr edit` assertion. Replaced
   the broad check with a positive assertion on the exact "do not load
   any confirmation-driven PR update skill" phrase from step 5.

Running bun test after this and the release-metadata sync above now
reports 906/906 passing on this branch.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Captures the learnings from the direct-to-main drift incident so future
investigations don't have to rediscover the file relationships, the
decision tree, or why manifest manual edits are sometimes legitimate.

New solution doc `docs/solutions/workflow/release-please-version-drift-recovery.md`:
- File relationship map showing extra-files, manifest, and linked-versions
- How release-please reads manifest and writes extra-files
- Recovery decision tree (forward-sync vs backward-revert vs release-as pin)
- When manifest manual edits are legitimate (out-of-band recovery)
- The 2026-04-24 incident as worked example

Root AGENTS.md Working Agreement gains a `Merge policy` bullet making
explicit that all changes go through PRs, branch protection enforces
the `test` check, and direct merges have caused real damage. This is
the rule the incident implied but the doc never stated.

Plugin AGENTS.md Versioning Requirements gets a pointer to the recovery
doc so anyone hitting `release:validate` drift finds the playbook on
first stop instead of having to investigate the file relationships
from scratch.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>