Collect findings from other people's writing, with sources

The skill so far only held what we broke ourselves. Most of what is worth
knowing about a new SDK is found rather than suffered — release notes,
other people's articles — and that deserves a place too, on terms that
stay fair to whoever wrote it.

So: entries in our own words, source named and linked, and the one thing
no external article can supply — what it would replace in our code and
whether it is genuinely a step forward. Attribution answers plagiarism,
not copyright, so nothing is pasted; an API signature is a fact, the
paragraph explaining it is not ours to take.

First four entries come from Natalia Panferova's writing at nilcoalescing
.com: the close button role and concentric corners, both of which replace
things we hand-built; ScrollPosition, which replaces one wrapper view;
and the iOS 27 toolbar APIs, which we cannot use at our deployment target
but which would delete a workaround the day we can.

A LICENSE was overdue and now says plainly what is ours, what is Apple's
and stays out of the repository, and what belongs to the authors we cite.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

pdat-swift-practice/skills/apple-findings/references/waiting-on-target.md

@@ -0,0 +1,31 @@
+# Known, not yet usable
+
+Things worth having, blocked on a deployment target. Kept so nobody
+rediscovers them from scratch, and so the workarounds they replace can be
+deleted the day the target moves.
+
+## Adaptive toolbars (iOS 27)
+
+**What it is.** Explicit control over how a toolbar collapses when it runs
+out of room: `visibilityPriority` on a `ToolbarItem` (`.low`, `.automatic`,
+`.high`, or custom levels declared relative to those), an explicit
+`ToolbarOverflowMenu` for what should go into the overflow, and
+`ToolbarItem(placement: .topBarPinnedTrailing)` for what must never move.
+Related modifiers control minimisation on scroll.
+
+**What it replaces.** A workaround we already carry: `.secondaryAction`
+put our view-options menu into the system's own overflow, where it needed
+two taps to open, so it was rebuilt as an ordinary primary-action button
+with a hand-placed `ToolbarSpacer`. `visibilityPriority` plus
+`ToolbarOverflowMenu` is the supported way to say what we meant.
+
+**Step forward?** Yes, and it removes a comment explaining a hack.
+
+**Blocked on.** Deployment target iOS 26. Either raise it or gate with
+`#available`, which for a toolbar layout is more trouble than waiting.
+
+**Source.** Natalia Panferova, "Adaptive SwiftUI toolbars in iOS 27",
+nilcoalescing.com, 9 Aug 2026. Read 16 Aug 2026. Apple's
+`swiftui-whats-new-27` skill covers the same APIs in more depth — prefer
+it once the target moves; this entry exists for the "what of ours does it
+replace" note.