chore(release): 0.0.27 (leaves the alpha rail, magic_notifications ^0.3.0)

[anilcancakir]

Cuts the release that main has been carrying untagged as 0.0.1-alpha.27, and takes the package off the alpha rail while doing it. Replaces #127, which carried the first two commits under the old version number.

Draft on purpose: this must not merge before magic_notifications 0.3.0 is on pub.dev. That release is merged and dated on its own master and waiting for a tag. Until it exists flutter pub get cannot resolve ^0.3.0, so the Published graph job is red and dart pub publish --dry-run cannot be clean. The Sibling working trees job is red for a second, separate reason, and it is the cross-repo gate working as designed: it clones magic at master, where plugin-starter.md is still stamped v0.0.1-alpha.27, so skill_reference_stamp_test.dart fails (1418 passed, 1 failed). fluttersdk/magic#155 is the stamp move; merging it turns that job green on a re-run. Locally, against the sibling checkout carrying that branch, all 1448 pass.

The rail

0.0.1-alpha.26 is followed by 0.0.27. Twenty-six releases arrived as prereleases of a 0.0.1 that never shipped, which is not what the suffix means: every one of them was the current release, pub.dev showed the package as having no stable version, and a plain flutter pub add magic_starter refused to take it without an explicit prerelease pin. The counter is carried rather than reset, so the history stays monotonic and a package with 27 releases of surface does not go out labelled 0.0.1.

No adopter action. A caret raises the MINOR whenever the major is zero, so an existing ^0.0.1-alpha.26 reads >=0.0.1-alpha.26 <0.1.0 and takes 0.0.27 on the next pub upgrade.

Seven version sites move together: pubspec.yaml, CHANGELOG.md, CLAUDE.md, README.md, doc/getting-started/installation.md, the magicStarterVersion constant behind the starter:* banners, and the issue template placeholder. The sibling half is fluttersdk/magic#155, which moves plugin-starter.md's stamp: test/skill_reference_stamp_test.dart compares the two whenever a sibling checkout exists.

A constraint that was writing a conflict into consumer pubspecs

starter:install wrote magic_notifications: ^0.0.1-alpha.1 into the host's pubspec when the notifications feature was on. That literal had not moved since the notification screens lived in this package. It ends at 0.1.0, while this package's own floor has required 0.1.0 or later since alpha.25, so the two described one dependency with no intersection, and pub answers that by walking magic_starter back to a release that fits rather than by failing. Enabling notifications at install time silently scaffolded the app onto an older starter.

It is now magicNotificationsConstraint, and a new test reads it against the floor in pubspec.yaml. Written red first: it failed to compile on the missing constant, then failed on the value, and passes on ^0.3.0.

The rest, carried from #127

• magic_notifications floor ^0.2.0 to ^0.3.0. A reachability move, not a compilation one: ^0.2.0 reads >=0.2.0 <0.3.0, so an app asking for 0.3.0 alongside this package leaves pub no intersection and gets a silently downgraded starter. magic_example lost two starter releases to exactly this (Make the boilerplate resolve the packages it claims, and rename in one command magic_example#13).
• Five notifications.* keys into the install stub. bulk_title and bulk_description arrive with 0.3.0's bulk card; delete, delete_failed and channel_sms have been missing since the 0.2.0 floor landed in alpha.26 and render as their own key today.
• doc/basics/notifications.md documents the bulk card, the batch request shape it needs, and all five keys.

Verification

Run with a temporary, gitignored pubspec_overrides.yaml pointing magic_notifications at the sibling checkout at its 0.3.0 master, because that release is not published yet. magic resolved hosted at 0.0.10.

• flutter test: 1448 passed (rebased onto main at Release the push identity only once the vault agrees #132, which brought the push-identity work with it)
• dart analyze: no issues
• dart format --output=none --set-exit-if-changed .: 0 of 332 changed
• dart pub publish --dry-run: has to be re-run clean once 0.3.0 is live, which is part of undrafting this.

Rebased on 2026-09-11

Three commits landed on main after this branch opened (#130, #131, #132: the starter:doctor prefix report, the push identity declared off Auth.stateNotifier, and the docs pass). All three wrote into the same unreleased section, so they are part of this release and now sit under [0.0.27] beside the entries below. The rebase was clean, no conflict.

Merge order

1. Tag magic_notifications 0.3.0 and let it publish.
2. Merge docs(skill): follow magic_starter off the alpha rail magic#155 so the reference stamp matches.
3. Re-run the dry run here, undraft, merge.
4. Release 0.0.27 from main per .claude/commands/release.md, tag 0.0.27 with no v prefix and no --prerelease flag this time.

Author: Anılcan Çakır anilcan.cakir@gmail.com

[anilcancakir]

Ordering note, from the session working #128.

This release does not contain #128, which adds the half of the push identity the package was missing: Notify.logoutPush() had one caller and initializePush had none, anywhere in lib/ or in magic_example, so an adopter who wires nothing gets a device subscribed under no external id while the Laravel side addresses user_<id>. Nothing on the client fails; the only trace is a zero-recipient report on the server.

Cutting 0.0.27 first bakes that gap into the version that leaves the alpha rail, which is the one adopters will reach for. #128 is green (1424 tests, analyzer and format clean) and has answered its kodizm round; it is waiting on re-review only.

There is also a mechanical conflict either way: #128 adds a CHANGELOG entry under ## [0.0.1-alpha.27] - 2026-09-09, which this PR renames to ## [0.0.27] - 2026-09-11. Merging #128 first carries the entry through the rename; merging this first leaves #128 writing under a heading that no longer exists.

No action needed from you if the plan was already to take #128 first. Flagging because the two PRs were opened within minutes of each other by different sessions.

[anilcancakir]

Follow-up to my ordering note: #128 merged as fec9e9b, so this release now contains the push-identity half.

It will want a rebase. #128 added its changelog entry under ## [0.0.1-alpha.27] - 2026-09-09, which this PR renames to ## [0.0.27] - 2026-09-11, so the two touch the same heading. Rebasing onto main carries the entry through the rename, which is the outcome you want; nothing needs rewriting by hand.

Two things worth knowing for the release itself, neither a blocker:

• pubspec.yaml here pins magic_notifications: ^0.2.0, which is >=0.2.0 <0.3.0. When 0.3.0 publishes, no magic_starter adopter resolves it. Declare the push identity a session begins #128 does not need 0.3.0 (want, pushIntent and onPushDriverAttached all exist at 0.2.0), so this is a floor to raise deliberately rather than a dependency of the merged work.
• magic-starter-laravel merged the matching backend half as b846c11, which is also unreleased. The two default prefixes agree, so a version skew between them is safe; only an adopter who CHANGES the prefix needs both sides shipped together.