Address code review: drop Sidekiq example, small polish

Review findings audited:

1. **Sidekiq example dropped.** `Sidekiq.default_worker_options` is
   a deprecated alias on Sidekiq 6.5+ and only removed outright in
   7.0, so the "6.x → 7.x" framing was ambiguous — teaches a
   genuine two-sided case only for ≤ 6.4 → 7.0; on 6.5 → 7.0 it's
   deprecation-only, the exact anti-pattern invariant #7 excludes.
   Same reasoning that dropped the `session_store` example earlier
   in this PR. Removed rather than tightened because the boundary
   caveat would lengthen the skill for a gem-specific illustration.

2. **`update_attributes` version — verified correct, no change.**
   Rails 6.1 `activerecord/CHANGELOG.md` reads "Remove deprecated
   `ActiveRecord::Base#update_attributes` and `#update_attributes!`"
   (verified via `gh api ...?ref=v6.1.0`). The PR's "prior to the
   6.1 removal" phrasing is accurate; no fix needed.

3. **Gem-placement nudge in basic-setup.md Step 3.** Added one
   line noting that if the 4.2 app already has `gem 'ignorable'`
   at Gemfile root, it should move into the `else` branch so it's
   installed only for Rails 4.2.

4. **CHANGELOG v1.1 entry bulletized.** The five distinct changes
   (example swap, new "When NOT to Branch" section, broadened
   feature-detection rule, polarity standardization, invariant #7,
   session_store + Sidekiq removals) now read as separate bullets
   instead of one run-on paragraph.

5. **code-patterns.md intro nudge.** Added one sentence noting the
   `ignored_columns` example's pattern ("gem-provided API replaced
   by a native Rails API with different syntax") applies to any
   adjacent-version boundary, not just 4.2 → 5.0 — keeps the older
   version numbers from dating the teaching.

Author: JuanVqz

dual-boot/CHANGELOG.md

@@ -1,7 +1,12 @@
 # Changelog
 
 ## v1.1 — 22 April 2026
-- Replaced the `fixture_path`/`fixture_paths` and `serialize coder:` examples (both backwards-compat deprecations that don't require a conditional) with a genuine breaking change: `ignorable` gem's `ignore_columns` → native `ignored_columns=` at Rails 4.2 → 5.0, where each side's API raises `NoMethodError` on the other. Added explicit guidance that deprecations should be fixed by direct replacement, not wrapped in `NextRails.next?` (SKILL.md "Pattern", `references/code-patterns.md` "When NOT to Branch: Deprecations"). Broadened the "no feature detection" rule to call out `defined?` alongside `respond_to?`. Standardized on `NextRails.next?` polarity across the skill (removed the "`.current?` is also fine" clause from `CLAUDE.md`). Added invariant #7 codifying "only branch for genuine breaking changes". (#2)
+- Replaced the `fixture_path`/`fixture_paths` and `serialize coder:` examples (both backwards-compat deprecations that don't require a conditional) with a genuine breaking change: `ignorable` gem's `ignore_columns` → native `ignored_columns=` at Rails 4.2 → 5.0, where each side's API raises `NoMethodError` on the other. (#2)
+- Added a new "When NOT to Branch: Deprecations" section in `references/code-patterns.md` using `fixture_path` → `fixture_paths` as the counter-example, so readers learn that deprecations are unconditional migrations — not `NextRails.next?` conditionals.
+- Broadened the "no feature detection" rule to call out `defined?` and `const_defined?` alongside `respond_to?`.
+- Standardized on `NextRails.next?` polarity across the skill (removed the "`.current?` is also fine" clause from `CLAUDE.md`).
+- Added invariant #7 in `CLAUDE.md`: only branch for genuine breaking changes.
+- Removed the `session_store` and `Sidekiq` examples that didn't survive invariant #7 — both were either cosmetic config differences (session_store) or ambiguous across intra-major gem versions (`default_worker_options` is a deprecated alias on Sidekiq 6.5+, so the example only held for Sidekiq ≤ 6.4 → 7.0).
 
 ## v1.0 — 04 March 2025
 - Initial release as standalone skill (extracted from `rails-upgrade` skill)

dual-boot/examples/basic-setup.md

@@ -26,6 +26,8 @@ next_rails --init
 
 ### 3. Configure Gemfile
 
+If your 4.2 app already depends on a gem that needs dropping on the 5.0 side (the `ignorable` gem in this example), move it from the Gemfile root into the `else` branch so it's installed only for Rails 4.2.
+
 ```ruby
 # Gemfile
 

dual-boot/references/code-patterns.md

@@ -6,6 +6,8 @@ Use `NextRails.next?` anywhere your application code must behave differently bet
 
 **Only branch when the old code actually breaks on the next version.** A deprecation warning is not a reason for a conditional — if the new API works on both, replace the call site directly and let the deprecation disappear on its own. Reserve `NextRails.next?` for removed constants, removed methods, or incompatible signature/return-type changes that would raise an error otherwise.
 
+The version numbers in the example below are from a Rails 4.2 → 5.0 upgrade, but the pattern applies any time a gem-provided API is replaced by a native Rails API with different syntax (or vice versa) — the same shape works for any adjacent-version boundary where dropping the gem on one side makes the call unavailable.
+
 ---
 
 ## Rails API Changes Requiring a Conditional
@@ -76,21 +78,6 @@ end
 
 ---
 
-## Core Dependency Changes
-
-### Sidekiq API change (6.x → 7.x)
-
-```ruby
-# config/initializers/sidekiq.rb
-if NextRails.next?
-  Sidekiq.default_job_options = { 'retry' => 3 }
-else
-  Sidekiq.default_worker_options = { 'retry' => 3 }
-end
-```
-
----
-
 ## Gem Version Differences in the Gemfile
 
 ### Inline ternary for gem versions in test groups