Skip to content

docs: release v1.1.0 — the packaged install by default, checked in real sessions - #32

Merged
mauricios merged 1 commit into
mainfrom
docs/release-v1.1.0
Oct 5, 2026
Merged

mauricios merged 1 commit into
mainfrom
docs/release-v1.1.0

Conversation

@mauricios

Copy link
Copy Markdown
Contributor

What changed and why

v1.1.0, a minor release (decision 0017): a new default for new projects, and evals for the packaged install. Nothing asks anything of an adopted team.

One more fix: /aplyca-adf:adopt takes the framework at the release it pins. It used to copy the skeleton from wherever the framework source was (a clone of the default branch, or a checkout) while pinning the plugin to the newest release tag. A project's committed files could then be newer than its pinned plugin, which matters more now that packaged is the default. The packaged eval in #30 found this. Step 1 now:

  1. finds the newest release tag;
  2. takes the framework at that tag, from a shallow clone of the tag or a worktree of a local checkout;
  3. records that tag's commit for the stamp.

docs/SETUP.md's manual copy says the same, and a static check holds it.

Upgrade impact

None for adopted projects. /aplyca-adf:upgrade moves the pin to v1.1.0, and recommends the switch to packaged to a committed project whose team works in Claude Code only.

How to verify

  • ./evals/run-evals.sh: the version check matches 1.1.0 against the heading.
  • ./evals/dynamic/run-session-evals.sh --suite adopt --cases packaged --models sonnet.

Verified / not verified

  • Verified:
    • Static suites pass: 154, 81, 45, and 11.
    • git clone --depth 1 --branch v1.0.6 gives commit ab56cb6.
    • The packaged adopt eval, rerun on Sonnet: 8 of 8, $1.30. The session set the framework up at v1.0.6 in a scratch worktree, stamped ab56cb6, and recommended packaged first. The run is added to the 2026-10-04-packaged-paths report.
  • Not verified:
    • An adoption that pins v1.1.0, which doesn't exist until the tag is pushed. The new project is the first.

Merge danger

  • Release notes, a version number, and /adopt's Step 1. A revert is safe.
  • Tag v1.1.0 right after the merge, before the new project adopts, so it pins this release.

🤖 Generated with Claude Code

…al sessions

A minor release: the packaged install becomes the default for new
projects (decision 0018), with evals for its paths. Unreleased becomes
v1.1.0, covering #29, #30, #31, and one more fix:

/aplyca-adf:adopt took the skeleton from wherever the framework source
was while pinning the newest release tag, so a project's committed files
could be newer than its pinned plugin. It now finds the newest release
tag, takes the framework at that tag (a shallow clone of it, or a
worktree of a local checkout), and stamps that tag's commit; SETUP.md's
manual copy says the same. The packaged adopt eval reran on Sonnet:
8/8, stamped ab56cb6 from a scratch worktree at v1.0.6.

plugin.json 1.1.0; the README names the release.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mauricios
mauricios marked this pull request as ready for review October 5, 2026 03:50
@mauricios
mauricios merged commit de05c95 into main Oct 5, 2026
1 check passed
@mauricios
mauricios deleted the docs/release-v1.1.0 branch October 5, 2026 03:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant