Docs: record v1.1 as released; adopt PR-only workflow

CLAUDE.md

@@ -844,13 +844,19 @@ investigation.
 -- caught and fixed 2026-08-04 while preparing the next release; if this
 sentence is now itself stale, distrust it the same way and check
 `git tag`/`gh release list` directly rather than propagating it forward
-again). `version.mk` is bumped to 1.1 for M15-M19 (all additive,
-backward-compatible -- REVISION bump, not VERSION); `sana2loop.readme`'s
-`Version:` field and every `$VER:` date cookie (device + all four tools)
-were updated to match ahead of the next tag push. No further milestones
-remain unscheduled except actually pushing that `v1.1` tag. The
-nullsana/vlink-inspired feature-idea queue is down to #31 (mirror device
-name) and #32 (stack-wiring walkthrough docs).
+again). **v1.1 released 2026-08-04** (M14-M19, all additive,
+backward-compatible -- REVISION bump, not VERSION; `sana2loop.readme`'s
+`Version:` field and every `$VER:` date cookie were updated to match
+before the tag push). The same day, `userdocs/Changelog.md` was caught
+still carrying the pre-v1.0 "no version has been tagged/published yet"
+claim in its What's-next section -- the exact staleness class this
+paragraph warns about, and it had already shipped to the published v1.1
+docs site (docs deploy on tag push; `docs.yml`'s `workflow_dispatch`
+exists for re-publishing a version after a docs-only fix like this).
+Fixed alongside its release header and M12 section. No further
+milestones are scheduled; the nullsana/vlink-inspired feature-idea
+queue is down to #31 (mirror device name) and #32 (stack-wiring
+walkthrough docs).
 
 ## Architecture
 
@@ -898,6 +904,21 @@ Both the pending-reads list and the pending-echoed-data list are wrapped in
 `Disable()`/`Enable()` critical sections since multiple tasks can call
 `BeginIO`/`AbortIO` on the same unit concurrently.
 
+## Workflow: all changes go via pull requests (since 2026-08-04)
+
+Never commit or push directly to `main` -- branch protection (enforced
+for admins too) requires a PR with passing status checks (`ci / build`,
+`ci / lint`, `ci / test-host`, `ci / test-target`,
+`Docs site + AmigaGuide build`; 0 approving reviews, since a solo owner
+can't approve their own PR) and blocks force pushes/deletion. Tag pushes
+are unaffected, so the `v<version>` release flow works unchanged.
+Motivated partly by the v1.1 release's `--generate-notes` coming out
+nearly empty: GitHub's generated notes only see PRs, and M14-M19 all
+landed as direct commits (the v1.1 notes were rewritten by hand
+afterwards). If a required check's job name ever changes (they come from
+`sidick/amiga-workflows`' reusable workflow), update the protection's
+required contexts to match or every merge will block.
+
 ## Build / test
 
 The Amiga build uses the **Bebbo m68k-amigaos GCC** cross-toolchain, same

userdocs/Changelog.md

@@ -8,8 +8,10 @@ landed in each, in user-facing terms — see the repository's
 for the full engineering detail behind each one.
 
 **v1.0** shipped 2026-07-31 (M0–M13, up through SANA-II Rev 2/3/4/7
-conformance). Everything from **M14** onward lands in the next tagged
-release.
+conformance). **v1.1** shipped 2026-08-04 (M14–M19: the configurable
+replay capacity, the nullsana-inspired config keys, multi-open fan-out,
+and the general-purpose companion tools — all additive and
+backward-compatible).
 
 ## Foundational milestones (M0–M4)
 
@@ -88,9 +90,9 @@ without writing your own program against the device — see
 
 ## M12 — Aminet packaging and release flow
 
-The infrastructure (not yet a shipped release) for packaging and
-publishing tagged versions to Aminet, with a human-approval gate before
-any actual upload.
+The infrastructure for packaging and publishing tagged versions to
+Aminet, with a human-approval gate before any actual upload — first
+exercised for real by the v1.0 release.
 
 ## M13 — SANA-II Rev 2/3/4/7 conformance
 
@@ -208,5 +210,16 @@ See [SanaDump and SanaSend](SanaDump-and-SanaSend.md),
 
 ## What's next
 
-- A proper first tagged release (the M12 packaging pipeline is built and
-  tested, but no version has been tagged/published yet).
+Two feature ideas from reviewing [vlink](https://aminet.net/package/comm/tcp/vlink)
+(Chris Brenner's 2000-era virtual SANA-II device, a second piece of
+prior art alongside nullsana) are queued but not yet scheduled:
+
+- A second device name (e.g. `loopmirror.device`) whose unit N
+  crossover-pairs with `loopback.device`'s unit N — vlink's own
+  `vlink.device`/`vlinkmirror.device` pattern, for consumers such as
+  ShapeShifter/Fusion that can only open unit 0 of a named device
+  ([#31](https://github.com/sidick/sana2loop/issues/31)).
+- Step-by-step walkthroughs for wiring the device into real network
+  stacks (Miami, AmiTCP, Roadshow), modeled on vlink.guide's own
+  numbered setup instructions
+  ([#32](https://github.com/sidick/sana2loop/issues/32)).