Swap ParameterFilter example for ignorable → ignored_columns

Review found `ActionDispatch::Http::ParameterFilter` →
`ActiveSupport::ParameterFilter` at Rails 6.0 → 6.1 was not a genuine
two-sided break: `ActiveSupport::ParameterFilter` shipped in Rails 6.0
(verified against the `activesupport/CHANGELOG.md` at the v6.0.0 tag),
so the replacement already exists on the current side and the correct
fix is an unconditional migration — the exact anti-pattern this PR is
arguing against.

Replace with the `ignorable` gem's `ignore_columns` → native
`ignored_columns=` at Rails 4.2 → 5.0. This is genuinely two-sided:
dropping the `ignorable` gem on the 5.0 side makes `ignore_columns`
raise `NoMethodError`, and `ignored_columns=` raises `NoMethodError` on
4.2 where the setter doesn't exist yet. `NextRails.next?` is required.

Updated `SKILL.md` Pattern, `examples/basic-setup.md` (scenario shifted
to 4.2 → 5.0), `references/code-patterns.md`, `README.md` Key Principle,
`workflows/cleanup-workflow.md` Step 2, and the `CHANGELOG.md` v1.1
entry.

Also added a "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 should be
migrated unconditionally — not wrapped in `NextRails.next?`.

Author: JuanVqz

README.md

@@ -66,20 +66,24 @@ In Claude Code, navigate to your Rails application directory and use natural lan
 "Clean up dual-boot code after upgrade"
 ```
 
-## Key Principle: Use `NextRails.next?` (not `respond_to?`!)
+## Key Principle: Use `NextRails.next?` (not feature detection)
 
 When writing code that must work with two versions, always use `NextRails.next?`:
 
 ```ruby
-# CORRECT
-if NextRails.next?
-  config.fixture_paths = ["#{::Rails.root}/spec/fixtures"]
-else
-  config.fixture_path = "#{::Rails.root}/spec/fixtures"
+# app/models/project.rb
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
 ```
 
-Never use `respond_to?` for version branching. It's hard to understand, hard to maintain, and obscures intent.
+Never use `respond_to?`, `defined?`, or other feature-detection patterns. They are fragile, hard to clean up, and obscure intent.
+
+Only branch when the old API genuinely breaks on the next version. A plain deprecation warning is not a reason for a conditional — if the new API works on both versions, just use it directly.
 
 ## Related Skills
 

dual-boot/CHANGELOG.md

@@ -1,7 +1,7 @@
 # Changelog
 
 ## v1.1 — 22 April 2026
-- Replaced `fixture_path`/`fixture_paths` and `serialize coder:` examples (both are backwards-compat deprecations) with genuine breaking changes (`ActionDispatch::Http::ParameterFilter` removal in Rails 6.1). Added explicit guidance: deprecations should be fixed by direct replacement, not wrapped in `NextRails.next?`. (#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. 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)
 
 ## v1.0 — 04 March 2025
 - Initial release as standalone skill (extracted from `rails-upgrade` skill)

dual-boot/SKILL.md

@@ -46,38 +46,43 @@ When writing code that must work with both the current and target versions, **al
 
 ### Pattern
 
-The right time for a conditional is when the old code actually **breaks** on the next version (removed constant, removed method, incompatible signature) — not when it merely emits a deprecation warning. Deprecations should be fixed by replacing the code outright, since the new form works on both versions.
+Reach for `NextRails.next?` only when the old and new APIs are genuinely **two-sided** — the old one raises on the next version and the new one doesn't exist on the current version. A plain deprecation warning is *not* a reason to branch: if the new API works on both sides, migrate the call site directly.
 
-Example: `ActionDispatch::Http::ParameterFilter` was removed in Rails 6.1 (replaced by `ActiveSupport::ParameterFilter`). Referencing the old constant under 6.1 raises `NameError`, so a conditional is required during 6.0 → 6.1 dual-boot.
-
-❌ **WRONG — Do NOT use feature detection (`defined?`, `respond_to?`, etc.):**
+❌ **WRONG — Do NOT use feature detection (`respond_to?`, `defined?`, etc.):**
 ```ruby
-if defined?(ActiveSupport::ParameterFilter)
-  filter = ActiveSupport::ParameterFilter.new([:password])
+if Project.respond_to?(:ignored_columns=)
+  self.ignored_columns += [:category]
 else
-  filter = ActionDispatch::Http::ParameterFilter.new([:password])
+  ignore_columns :category
 end
 ```
 
 ✅ **CORRECT — Use `NextRails.next?`:**
 ```ruby
-if NextRails.next?
-  filter = ActiveSupport::ParameterFilter.new([:password])
-else
-  filter = ActionDispatch::Http::ParameterFilter.new([:password])
+# app/models/project.rb
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
 ```
 
+This is a genuine two-sided case (Rails 4.2 → 5.0): on 4.2 the app uses the [`ignorable`](https://github.com/nthj/ignorable) gem's `ignore_columns` class method. Rails 5.0 introduced native `ignored_columns=` with different syntax, and once the gem is dropped on the 5.0 side, `ignore_columns` raises `NoMethodError`. `ignored_columns=` raises `NoMethodError` on 4.2 where it doesn't yet exist.
+
+Put the next-version branch on top so cleanup is mechanical: after the upgrade, keep the `if` body and drop the `else`. See `references/code-patterns.md` for more examples.
+
 ### When to Apply
 
 Use `NextRails.next?` branching for:
-- **Removed constants or methods** (e.g., `ActionDispatch::Http::ParameterFilter` removed in Rails 6.1, `update_attributes` removed in Rails 6.1)
-- **Incompatible signature or return-type changes** (e.g., a method that now returns a different object type)
-- **Gem version differences where the old API is gone in the new version** (not just renamed-with-alias)
-- **Initializer changes that break on one side** (e.g., middleware removed from defaults, config key that raises on the other version)
+- **Removed methods or constants** where the replacement only exists on the new side (e.g., a gem-provided method replaced by a native Rails method with different syntax)
+- **Incompatible signature or return-type changes** where the old and new forms genuinely fail on opposite sides
+- **Gem version differences** where the gem's API is different across versions pinned to each Rails version
+- **Initializer changes** where a config or middleware raises on one side
 - **Ruby version differences** (e.g., syntax changes, stdlib removals)
 
-**Not a reason to branch:** deprecation warnings. If the new API works on both versions, migrate the call site directly — do not wrap it in `NextRails.next?`. See `references/code-patterns.md` "When NOT to Branch: Deprecations".
+**Not a reason to branch:** plain deprecation warnings. If the new API works on both versions (e.g. `config.fixture_path=` → `config.fixture_paths=`, `update_attributes` → `update` before its removal), migrate the call site directly — do not wrap it in `NextRails.next?`. See `references/code-patterns.md` "When NOT to Branch: Deprecations".
 
 ---
 

dual-boot/examples/basic-setup.md

@@ -4,7 +4,7 @@ This example walks through a Rails version upgrade. The same approach applies wh
 
 ## Scenario
 
-You have a Rails 6.0 application and want to upgrade to Rails 6.1. You want to set up dual-boot to test both versions during the transition.
+You have a Rails 4.2 application and want to upgrade to Rails 5.0. You want to set up dual-boot to test both versions during the transition.
 
 ---
 
@@ -36,9 +36,10 @@ def next?
 end
 
 if next?
-  gem 'rails', '~> 6.1.0'
+  gem 'rails', '~> 5.0.0'
 else
-  gem 'rails', '~> 6.0.0'
+  gem 'rails', '~> 4.2.0'
+  gem 'ignorable' # used for `ignore_columns` on 4.2; dropped on 5.0
 end
 
 gem 'next_rails'
@@ -58,32 +59,30 @@ BUNDLE_GEMFILE=Gemfile.next bundle install
 ### 5. Run Tests Against Both
 
 ```bash
-# Current version (6.0)
+# Current version (4.2)
 bundle exec rspec
 # => All green
 
-# Next version (6.1)
+# Next version (5.0)
 BUNDLE_GEMFILE=Gemfile.next bundle exec rspec
 # => Some failures — fix using NextRails.next? branching
 ```
 
 ### 6. Fix a Breaking Change
 
-Rails 6.1 removed `ActionDispatch::Http::ParameterFilter` — referencing it under 6.1 raises `NameError: uninitialized constant`. The replacement `ActiveSupport::ParameterFilter` does not exist on 6.0, so a conditional is required:
+Rails 5.0 introduced a native `ignored_columns=` setter, replacing the `ignorable` gem's `ignore_columns` class method. With the gem dropped on the 5.0 side, `ignore_columns` raises `NoMethodError` there; `ignored_columns=` raises `NoMethodError` on 4.2 where it doesn't yet exist. A conditional is required:
 
 ```ruby
-# app/services/log_sanitizer.rb
-if NextRails.next?
-  filter = ActiveSupport::ParameterFilter.new([:password, :token])
-else
-  filter = ActionDispatch::Http::ParameterFilter.new([:password, :token])
+# app/models/project.rb
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
-
-filter.filter(params)
 ```
 
-Note: a pure deprecation warning (old API still works under next) is **not** a reason to branch — replace the call site directly. Reserve `NextRails.next?` for code that would otherwise fail to load or run.
-
 ### 7. Verify Both Pass
 
 ```bash
@@ -94,29 +93,30 @@ BUNDLE_GEMFILE=Gemfile.next bundle exec rspec  # Next: green
 ### 8. Commit
 
 ```bash
-git add Gemfile Gemfile.next Gemfile.next.lock app/services/log_sanitizer.rb
-git commit -m "Set up dual-boot for Rails 6.0 → 6.1 upgrade"
+git add Gemfile Gemfile.next Gemfile.next.lock app/models/project.rb
+git commit -m "Set up dual-boot for Rails 4.2 → 5.0 upgrade"
 ```
 
 ---
 
 ## After Upgrade Is Complete
 
-Once you're fully on Rails 6.1, clean up:
+Once you're fully on Rails 5.0, clean up:
 
 ```ruby
-# app/services/log_sanitizer.rb — BEFORE cleanup
-if NextRails.next?
-  filter = ActiveSupport::ParameterFilter.new([:password, :token])
-else
-  filter = ActionDispatch::Http::ParameterFilter.new([:password, :token])
+# app/models/project.rb — BEFORE cleanup
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
 
-filter.filter(params)
-
-# app/services/log_sanitizer.rb — AFTER cleanup
-filter = ActiveSupport::ParameterFilter.new([:password, :token])
-filter.filter(params)
+# app/models/project.rb — AFTER cleanup
+class Project < ActiveRecord::Base
+  self.ignored_columns += [:category]
+end
 ```
 
 See `workflows/cleanup-workflow.md` for the full cleanup process.

dual-boot/references/code-patterns.md

@@ -8,20 +8,20 @@ Use `NextRails.next?` anywhere your application code must behave differently bet
 
 ---
 
-## Rails API Removals
+## Rails API Changes Requiring a Conditional
 
-### `ActionDispatch::Http::ParameterFilter` removed in Rails 6.1
+### `ignorable` gem → native `ignored_columns=` (Rails 4.2 → 5.0)
 
-Under Rails 6.1 the old constant raises `NameError`; under Rails 6.0 the new one does not yet exist. A conditional is required during dual-boot.
+An app using the [`ignorable`](https://github.com/nthj/ignorable) gem to ignore columns on Rails 4.2 hits a genuine two-sided case when upgrading to 5.0, which introduced a native `ignored_columns=` with different syntax. If the gem is dropped on the 5.0 side (since Rails now has the feature), `ignore_columns :category` raises `NoMethodError` there; `self.ignored_columns += [:category]` raises `NoMethodError` on 4.2 where the setter doesn't exist yet.
 
 ```ruby
-# app/services/log_sanitizer.rb
-if NextRails.next?
-  filter = ActiveSupport::ParameterFilter.new([:password, :token])
-  filter.filter(params)
-else
-  filter = ActionDispatch::Http::ParameterFilter.new([:password, :token])
-  filter.filter(params)
+# app/models/project.rb
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
 ```
 
@@ -49,7 +49,7 @@ end
 config.fixture_paths = ["#{::Rails.root}/spec/fixtures"]
 ```
 
-Same rule applies to `serialize :preferences, coder: JSON` vs. the older positional form, `update` vs. `update_attributes` (prior to 6.1 removal), and most Rails API evolution: if both versions accept the new form, migrate call sites directly and skip the conditional.
+Same rule applies to `serialize :preferences, coder: JSON` vs. the older positional form, `update` vs. `update_attributes` (prior to the 6.1 removal), and most Rails API evolution: if both versions accept the new form, migrate call sites directly and skip the conditional.
 
 ---
 

dual-boot/workflows/cleanup-workflow.md

@@ -28,16 +28,20 @@ For each file found in Step 1, keep only the `NextRails.next?` (true) branch and
 
 ### Before:
 ```ruby
-if NextRails.next?
-  config.fixture_paths = ["#{::Rails.root}/spec/fixtures"]
-else
-  config.fixture_path = "#{::Rails.root}/spec/fixtures"
+class Project < ActiveRecord::Base
+  if NextRails.next?
+    self.ignored_columns += [:category]
+  else
+    ignore_columns :category
+  end
 end
 ```
 
 ### After:
 ```ruby
-config.fixture_paths = ["#{::Rails.root}/spec/fixtures"]
+class Project < ActiveRecord::Base
+  self.ignored_columns += [:category]
+end
 ```
 
 ---