Re-pin the fluttersdk stack to the 2026-09-22 batch

[anilcancakir]

Re-pins the boilerplate to the 2026-09-22 batch and proves the stack runs together.

Pins

Dependency	From	To
magic	^0.0.15	^0.0.16
magic_deeplink	^0.1.2	^0.1.3
magic_notifications	^0.3.3	^0.3.4
magic_social_auth	^0.0.4	^0.0.5
magic_starter	^0.0.31	^0.0.35
magic_devtools	^0.0.5	^0.0.6
fluttersdk_telescope	^0.0.6	^0.0.7
fluttersdk_dusk, fluttersdk_artisan	^0.0.15, ^0.0.16	unchanged (newest)
backend fluttersdk/magic-starter-laravel	^0.0.9	^0.0.10

magic_payments 0.0.4 and fluttersdk_wind 1.6.3 arrive transitively. The Composer pin lagged because Composer's caret on 0.0.x pins the patch (^0.0.9 is >=0.0.9 <0.0.10), so it never follows a release by itself. It moved with composer update fluttersdk/magic-starter-laravel rather than -W, and the lock diff is that one package.

backend/config/magic-starter.php needs no republish this time: diffed against the 0.0.10 vendor copy it differs only in the app's own lines (the Features import, use_uuids => false, four enabled features). 0.0.10 adds POST auth/guest/claim and fixes the guest device id lookup, no new config keys and no migration this app runs.

Gates

Resolved with pubspec_overrides.yaml moved aside, so the graph is the one a fork gets; grep -c "/Users/" pubspec.lock is 0. flutter analyze --no-fatal-infos no issues. flutter test 30 green. CHECK_ALLOW_HOSTED=1 bin/check --fast all green. Backend: vendor/bin/pint --test passed, php artisan test 2 green, php artisan migrate --pretend nothing to migrate.

Live check

• Backend on php artisan serve, app on ./bin/fsa start --device=chrome. The dev log carried no error, exception or bad state at boot.
• MagicRouter.instance.currentLocation answered /auth/login for a guest, so every route middleware alias resolved at Magic.init. The login screen rendered correctly, including the icon button and checkbox whose bg-transparent wind 1.6.3 now resolves.
• Registered a user through the UI with dusk (Sign up, Name, Email, Password, Confirm Password, Create Account). Auth.check() answered true, the location /, and the dashboard showed the user's name and the personal team in the sidebar. The backend served /api/v1/auth/register and /api/v1/notifications, and the user row exists in the app's SQLite database.
• Known noise only: OneSignal must be initialized before login on web, since a local run has no OneSignal app id.

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

A clean dependency re-pin: the hosted graph resolves, every gate is green here, and I found nothing that blocks the merge.

The diff is four files and no source change. I re-ran the resolution and the suites in a checkout with no pubspec_overrides.yaml and no sibling checkouts present, which is exactly the graph a fork gets, so CHECK_ALLOW_HOSTED=1 is measuring the right packages here rather than papering over local ones. flutter pub get left pubspec.lock byte-identical (git status empty), and grep -c "/Users/" pubspec.lock is 0 with no source: path entry.

I checked the two upgrades that could reach app code and neither does:

• wind 1.6.3 makes *-transparent resolve for the first time. The risk is a className that carried text-transparent / bg-transparent as dead weight and now paints it — magic_starter 0.0.35 fixed exactly that in its own brand examples. grep -rn "text-transparent\|bg-clip-text\|bg-transparent\|gradient" lib/ test/ finds no usage in this app outside the token-resolution test's regex, so nothing here changes appearance.
• magic_starter 0.0.32–0.0.34 adds navigationBreakpoint, sidebarExpandedBreakpoint, contentClassName, contentScrollPrimary, sidebarCollapsible and compactBrandBuilder, every default equal to the previously hardcoded value, and this app sets none of them (grep -rn "MagicStarterLayoutTheme\|contentClassName" lib/ is empty). The 0.0.34 guest-auth fixes land behind Features::guestAuth(), which is commented out in backend/config/magic-starter.php:48.

The Composer claim checks out too: diffing backend/config/magic-starter.php against the installed 0.0.10 vendor copy differs only in the Features import, use_uuids => false, and the four enabled features — no new keys.

Minor

.github/skills/magic-framework/SKILL.md:9 — maintainability. The mirrored copy is stamped magic 0.0.9 | Skill v0.1.11 (2026-08-31) while this PR moves magic to 0.0.16, whose changelog says the skill's plugin reference pages were rewritten for this batch (the starter page now covers 0.0.32–0.0.34's compact rail, contentClassName and the collapsible sidebar). AGENTS.md asks for bin/sync-skills after pulling a sibling, and bin/sync-skills says in its own header that CI can only catch hand-edits, not upstream drift — so this stays stale silently and Copilot's PR review keeps reading seven-release-old guidance. It was already stale before this PR, so it is not a regression, and I could not verify the drift directly: the sibling working trees are not in this checkout and the pub.dev archives ship no skills/ directory.

Tests

A pin bump carries no behaviour to test; the existing suites are the evidence, and all 30 Dart tests and both PHP tests pass against the hosted graph.

Checks I ran

• flutter pub get — resolved, pubspec.lock unchanged (exit 0)
• flutter analyze --no-fatal-infos — "No issues found!" (exit 0)
• flutter test — 30 passed (exit 0)
• CHECK_ALLOW_HOSTED=1 bin/check --fast — all green: flutter-analyze, design-tokens, registry, lockfile, overrides-parser, backend-pint (exit 0)
• composer install --no-scripts — installed from the lock, 0.0.10 present (exit 0)
• composer validate --no-check-publish — valid (exit 0)
• vendor/bin/pint --test — passed (exit 0)
• php artisan test — 2 passed (exit 0)
• diff config/magic-starter.php vendor/.../config/magic-starter.php — app-owned lines only
• Not run: the dusk/browser layer and php artisan migrate --pretend; I took the live-check section of the description as the author's own evidence rather than re-verifying it.

[anilcancakir]

Fixed the one Minor.

• .github/skills/magic-framework/SKILL.md:12, stale mirror: confirmed, it was stamped magic 0.0.9 | Skill v0.1.11 (2026-08-31). Re-synced with bin/sync-skills in 1441f21. The local sibling checkouts sit on unreleased branches, so I ran it in a scratch workspace whose magic and wind were detached at the tags 0.0.16 and 1.6.3: the copies now carry magic 0.0.16 | Skill v0.1.37 (2026-09-22) and fluttersdk_wind 1.6.x | Skill v2.18.0 (2026-09-22). wind-ui had drifted as well and moved in the same commit. bin/sync-skills --check in that workspace: magic-framework is current (magic 0.1.37), wind-ui is current (wind 2.18.0).

@kodizm please re-review.

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

The one Minor is fixed and verified mechanically; nothing new, and I still see no reason to hold the merge.

Since my last review the only new commit is 1441f21, which touches the two .github/skills/*/SKILL.md mirrors and nothing else. The dependency diff (pubspec.yaml, pubspec.lock, backend/composer.json, backend/composer.lock) is byte-for-byte what I already reviewed and ran the suites against, so I did not re-run those gates.

I did not take the re-sync on its word. bin/sync-skills --check here reproduces CI's side of the check — it strips the provenance banner and hashes the remainder against the sha256 the banner records — and both copies match:

sync-skills: magic-framework matches its recorded hash (upstream not checked, source absent)
sync-skills: wind-ui matches its recorded hash (upstream not checked, source absent)
exit=0

That is the strongest statement available in a checkout with no sibling working trees: it proves each file is the exact render() output of a source with that hash, so the new stamps were not hand-typed onto stale bodies. It cannot prove the sources were the 0.0.16 / 1.6.3 tags, which is the limit bin/sync-skills documents in its own header, not a gap in the fix.

Three cross-checks that the content is the right generation for this pin, rather than merely self-consistent:

• The stamps match what pubspec.lock actually resolves: magic 0.0.16 and fluttersdk_wind 1.6.3 against magic 0.0.16 | Skill v0.1.37 and fluttersdk_wind 1.6.x | Skill v2.18.0.
• The magic skill's new file_picker row says v12 is static and returns PlatformFile? with no FilePickerResult. pubspec.lock resolves file_picker 12.3.0, so the guidance describes the API this app's graph now has — and it arrived through magic's own constraint with no edit here, exactly as the pubspec.yaml:54-62 comment predicted it would.
• The wind skill's rewritten intrinsic-sizing paragraph (h-full and basis-* no longer trigger the LayoutBuilder throw, only grid does) is a 1.6 behaviour change, so the copy is genuinely the 1.6 generation rather than a re-stamped 1.5 body.

Both files are mirrors of separate repositories, so their prose is upstream's to get right, not this PR's. I read them for content that would mislead a reviewer bot and found only technical guidance — no instruction aimed at a reader.

Tests

Unchanged from my last pass: a pin bump carries no behaviour to test, and the two changed files are generated documentation with no runtime reach. The 30 Dart and 2 PHP tests I ran against the hosted graph remain the evidence for the dependency half.

Checks I ran

• bin/sync-skills --check — both mirrors match their recorded hash (exit 0)
• bin/sync-instructions --check — "mirrors are up to date" (exit 0); both are the gates CI runs at .github/workflows/ci.yml:40,46
• git show --stat 1441f21 — two files, +41 −17, no other path touched
• Version cross-check of pubspec.lock against the skill stamps — magic 0.0.16, fluttersdk_wind 1.6.3, file_picker 12.3.0
• Not re-run: flutter analyze / flutter test / CHECK_ALLOW_HOSTED=1 bin/check --fast / the backend suite, all green in my previous pass and reached by no file in the new commit. The dusk/browser layer remains the author's evidence, not mine.