Fix sidebar toggle visibility on desktop

Hide .sp-sidebar-toggle at min-width: 768px so the off-canvas hamburger button no longer overlaps the docked sidebar on desktop viewports.

Also adds a deprecation policy to CONTRIBUTING.md, closes Phase 5 P1 TODO items, and bumps @types/node to ^26.1.0 with lockfile-refreshed rolldown 1.1.4 and related transitive dependencies.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: bradpotts

CHANGELOG.md

@@ -6,6 +6,21 @@ reflects package releases published to npm.
 
 ## [Unreleased]
 
+## [2.7.1] - 2026-07-02
+
+**Release Title:** Phase 5 P0 - Sidebar Toggle Desktop Visibility Fix
+
+Contract change type: additive
+
+### Fixed
+
+- **Sidebar toggle button no longer stays visible on desktop**: the
+  `@media (min-width: 768px)` block in `components.css` reset `.sp-sidebar`
+  and `.sp-sidebar-backdrop` for the docked layout but never hid
+  `.sp-sidebar-toggle`, so the off-canvas hamburger button rendered on top
+  of the docked sidebar at all viewport widths. Added
+  `.sp-sidebar-toggle { display: none; }` to the same media query.
+
 ## [2.7.0] - 2026-06-30
 
 **Release Title:** Phase 5 P0 - Select and Textarea State Parity

CONTRIBUTING.md

@@ -220,6 +220,37 @@ opening a PR.
 - CSS entry point filenames and `package.json` export keys
 - The zero-hex policy itself
 
+## Deprecation Policy
+
+Before removing or renaming any public styling surface — a recipe function,
+a recipe option, a variant, a state, a CSS class, a CSS entry point, or a
+Tailwind export — it must go through a deprecation cycle. Silent removal is
+a `breaking` change with no migration window and is not acceptable for any
+surface listed under "Public API surfaces" above.
+
+**Step-by-step checklist for deprecating a public surface:**
+
+1. Keep the surface fully functional. A deprecated recipe, option, variant,
+   state, or class must keep working exactly as before — deprecation is a
+   notice, not a behavior change.
+2. Add a `CHANGELOG.md [Unreleased]` entry under a `### Deprecated` heading
+   naming the exact surface (function name, option name, variant/state
+   value, or class name), what replaces it, and the earliest major version
+   in which it may be removed.
+3. Note the deprecation in the relevant docstring or inline comment at the
+   call site in `src/`, and in the README wherever that surface is
+   documented, so consumers reading source or docs see it without needing
+   the changelog.
+4. Do not remove the surface in the same release that deprecates it. A
+   removal requires its own later `breaking`-classified change following
+   the existing breaking-change checklist, including Bradley Potts's
+   explicit approval.
+5. `ui-contract.manifest.json` continues to declare only the current,
+   supported contract — do not add deprecation metadata to the manifest.
+   The manifest's job is validating what's live today, not tracking
+   removal history; that history lives in `CHANGELOG.md`, which is already
+   the source of truth for classification and timeline.
+
 ## Pull Request Checklist
 
 1. Keep the change focused.

TODO.md

@@ -631,26 +631,47 @@ All six landed together with CSS, recipes, manifest, README, changelog, and
     and drop the `getInputClasses()` workaround — see
     `project-design/spectre-components/TODO.md` Phase 6 P0.
 
+- [x] `.sp-sidebar-toggle` stays visible on desktop, overlapping the docked
+      sidebar
+  - The `@media (min-width: 768px)` block in `src/styles/components.css`
+    reset `.sp-sidebar` and `.sp-sidebar-backdrop` for the docked layout but
+    never hid `.sp-sidebar-toggle`, so the off-canvas hamburger button
+    rendered on top of the docked sidebar at all viewport widths.
+  - Fix: added `.sp-sidebar-toggle { display: none; }` to the same media
+    query.
+
 - [x] Add regression coverage for downstream integration issues
   - Prefer focused contract tests over broad fixture expansion.
 
 - [x] Keep examples as verification fixtures
   - Add visual fixtures only when they support regression review for new public
     recipes or states.
 
-### P1: UI Deprecation Readiness
-
-- [ ] Define a UI deprecation policy before removing public styling surface
-  - Cover recipe functions, recipe options, variants, states, CSS classes, CSS
-    entry points, and Tailwind exports.
-
-- [ ] Decide whether `ui-contract.manifest.json` needs deprecation metadata
-  - Add metadata only if it can be validated and kept narrow.
-
-- [ ] Document deprecation notices in `CHANGELOG.md` and `CONTRIBUTING.md`
+### P1: UI Deprecation Readiness (done)
+
+- [x] Define a UI deprecation policy before removing public styling surface
+  - Added a "Deprecation Policy" section to `CONTRIBUTING.md`, covering
+    recipe functions, recipe options, variants, states, CSS classes, CSS
+    entry points, and Tailwind exports: keep the surface working, add a
+    `CHANGELOG.md` `### Deprecated` entry naming the replacement and
+    earliest removal version, note it at the source/README call site, and
+    require a separate later `breaking`-classified change (with Bradley
+    Potts's approval) to actually remove it.
+
+- [x] Decide whether `ui-contract.manifest.json` needs deprecation metadata
+  - Decision: no. The manifest's job is validating the current live
+    contract, not tracking removal history — `CHANGELOG.md` is already the
+    source of truth for classification and timeline, and adding parallel
+    deprecation state to the manifest would need its own validator for a
+    policy with zero deprecations to track yet. Revisit only if a real
+    deprecation needs machine-readable tracking beyond the changelog.
+
+- [x] Document deprecation notices in `CHANGELOG.md` and `CONTRIBUTING.md`
       before the first removal or rename
-  - Consumers should see what is deprecated, what replaces it, and when removal
-    can happen.
+  - Covered by the same `CONTRIBUTING.md` section: every deprecation gets a
+    `CHANGELOG.md [Unreleased]` entry plus an in-repo docstring/README note,
+    so consumers reading source, docs, or changelog all see the same notice
+    before anything is removed.
 
 ---
 
@@ -681,10 +702,12 @@ All six landed together with CSS, recipes, manifest, README, changelog, and
     previously recipe-less `sp-checkbox`/`sp-radio`/`sp-select`/
     `sp-textarea`/`sp-fieldset`/`sp-label` components in
     `spectre-components`.
-12. Phase 5 P0 — continuous; add regression coverage as adapter usage reveals
-    gaps.
-13. Phase 5 P1 — define deprecation mechanics before retiring any public
-    class, recipe option, or variant.
+12. Phase 5 P0 — all known gaps closed; the "track adapter feedback" line
+    stays open on a standing basis, add regression coverage as new usage
+    reveals gaps.
+13. **Phase 5 P1 — done.** Deprecation policy documented in
+    `CONTRIBUTING.md`; manifest deprecation metadata deliberately skipped
+    (see rationale above).
 
 ---