fix: /upgrade carries the uncommitted plugin setting into the hub's worktree

[mauricios]

What changed and why

Found while writing the pilot's steps. The install prompt leaves the plugin setting uncommitted in .claude/settings.json on purpose, so the adoption or upgrade pull request carries it. But when the developer chooses parallel-agents during /upgrade, the whole upgrade moves into a worktree created from the last commit, and that uncommitted change stays behind:

• /upgrade would add the setting again in the worktree, so the pull request was still right.
• The main checkout kept its copy, and the first git pull after the merge refused to overwrite it — in the hub, where nothing should be uncommitted.

plugins/aplyca-framework/skills/upgrade/SKILL.md now:

• Checks git status in the main checkout before creating the worktree. It carries the plugin setting into the worktree, then restores the main checkout's copy (git restore .claude/settings.json), and lists both moves in the plan. Anything else uncommitted is the developer's: it asks, and never discards it.
• Tells three cases apart in the plugin-setting check:
  • already committed: nothing to do;
  • uncommitted from the install: commit it with the upgrade, in the worktree for a hub;
  • missing, from a user- or local-scope install: offer to add it.

Plugin 0.2.5, so claude plugin update picks it up. The practices check covers the new step.

Upgrade impact

Framework-internal: update the plugin.

How to verify

1. Run ./evals/run-evals.sh. Both claude plugin validate checks pass.
2. Read /upgrade Step 2, from "If the developer chooses parallel-agents".

Verified / not verified

• Verified: static suites 131, 61, 43, and 9 pass; the plugin and marketplace manifests validate.
• Not verified: a real /upgrade that installs the hub. The pilot is that test, if it chooses parallel-agents.

🤖 Generated with Claude Code