feat: evals for the packaged install's two ways in; /upgrade stamps the release's commit

[mauricios]

What changed and why

Two paths into the packaged install had never run in a real session. This PR adds session evals for both, and fixes the defect they found.

The evals:

• adopt suite, new packaged case. /aplyca-adf:adopt on a new project, where the follow-up chooses the packaged install.

• New upgrade suite, switch-to-packaged case. project.sh builds a committed adoption at v1.0.0 from that tag: the skeleton without the Antigravity and Cursor layers, the plugin pinned to v1.0.0, PDR-0001, and the stamp. /aplyca-adf:upgrade then moves it to the newest release, and the follow-up accepts the switch.

• evals/dynamic/check-packaged.sh checks the packaged layout for both cases, marking each check ✓ or ✘:

  • the stamp names the newest release, its commit, and install: packaged;
  • no framework machinery is committed;
  • the settings have no hooks block, pin the newest release, and turn on aplyca-adf;
  • the names note is in CLAUDE.md, and DEV-SETUP.md uses the full command names;
  • everything is committed.

  Each suite's inspect.sh adds its own checks: for the switch, the PDR, PDR-0001 marked amended, and main untouched.

• Runner: passes this checkout's path to a suite's project.sh; the upgrade suite runs like adopt.

What the runs found, and the fixes:

• /upgrade stamped an annotated tag's ID instead of the release's commit. The stamp read v1.0.6 · 130753a, from git rev-parse v1.0.6, and the branch and commit message used the same ID. The real commit is ab56cb6. /upgrade and /adopt now name git rev-parse --short '<tag>^{commit}'. check-packaged.sh now checks the stamp's commit, and it marks the first run ✘. The rerun stamped ab56cb6.
• The packaged smoke test in docs/SETUP.md lacked CLAUDE_PLUGIN_ROOT, which the plugin's hooks need since v1.0.2. Both sessions noticed and set it themselves; the doc now does.
• Open, not fixed here: /adopt copies the skeleton from the framework source as it is, which can be past the release it pins. In this run the two were identical. Adopting from the release tag would close it, and that's a separate change.

Upgrade impact

The evals are framework-internal. The fixes change /upgrade's and /adopt's instructions and one line of docs/SETUP.md. They reach projects with the next release; the plugin's version moves then.

How to verify

./evals/dynamic/run-session-evals.sh --suite adopt --cases packaged --models sonnet
./evals/dynamic/run-session-evals.sh --suite upgrade --models sonnet

Verified / not verified

• Verified, on Sonnet:
  • packaged: 8 of 8, $0.83.
  • switch-to-packaged: 10 of 10, $0.81, though its stamp named the tag's ID, which the checker didn't yet check.
  • switch-to-packaged after the fix: 10 of 10, stamped ab56cb6, $1.20.
  • Each transcript graded against its .expected.md (report: evals/dynamic/reports/2026-10-04-packaged-paths.md).
  • The checker marks ✘ on the committed v1.0.0 project and on run 1's stamp.
  • Static suites pass: 154, 81, 45, and 11.
• Not verified:
  • Opus.
  • A real install, where the framework comes from the marketplace or a clone. These sessions found it through the runner's copy of the checkout.

Merge danger

• The two skill paragraphs and a doc line are the only things outside evals. A revert is safe.

🤖 Generated with Claude Code