Describe the NodeJS pinning as the one change it is

[tricknotes]

CHANGELOG wording only. Folds two entries from #674 into one.

Why

EmberCli::App#node_engine had an entry of its own, next to the entry for the engines.node pinning it exists to serve. It is not a separate decision for a reader to make — nothing asks them to call it — so listing it separately implied two changes where there is one.

The surrounding sections already draw the line at "one entry per decision the reader makes", not per PR or per method:

• 0.13.1 describes one change in one entry while naming both EmberCli::App#test and EmberCli.test!.
• 0.13.2 does the same for EmberCli::BuildError, rake ember:compile and rake ember:install.
• 0.13.0 splits into three entries because each asks the reader for a separate decision — enable the development server, raise the ember-cli-rails-assets requirement, configure origin.

What changed

 * Pin the NodeJS version in the `package.json` that `rails generate
   ember:heroku` writes, from the `engines.node` the Ember applications
-  declare. Applications that declare different versions are left unpinned
-* Add `EmberCli::App#node_engine`, reading `engines.node` from the Ember
-  application's `package.json`
+  declare, read through the new `EmberCli::App#node_engine`. Applications
+  that declare different versions are left unpinned

node_engine stays named, so the new public method is still discoverable from the CHANGELOG.

Out of scope

The other entries in the main section stay separate. Removing rails_12factor from the Gemfile, renaming App#yarn_enabled?, and the NodeJS pinning all sit under rails generate ember:heroku, but each asks the reader for a different action — and folding them would bury the "To upgrade" note on the first one.

Verification

Documentation only; no code changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_014rAfkAVGVifbaEoTVeT66u

---

Generated by Claude Code