From 2f28417298aa8c18c91ca7c64de11e0c5cc94e2b Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 27 Jul 2026 13:40:44 -0400
Subject: [PATCH 01/16] New recommended config for eslint-plugin-ember (v14)

---
 text/1217-eslint-plugin-ember-next-major.md | 265 ++++++++++++++++++++
 1 file changed, 265 insertions(+)
 create mode 100644 text/1217-eslint-plugin-ember-next-major.md

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
new file mode 100644
index 0000000000..cdc8ac3b54
--- /dev/null
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -0,0 +1,265 @@
+---
+stage: accepted
+start-date: 2026-07-27T00:00:00.000Z # In format YYYY-MM-DDT00:00:00.000Z
+release-date: # In format YYYY-MM-DDT00:00:00.000Z
+release-versions:
+teams: # delete teams that aren't relevant
+  - cli
+  - framework
+  - learning
+  - steering
+prs:
+  accepted: https://github.com/emberjs/rfcs/pull/1217
+project-link:
+suite:
+---
+
+# The next major of eslint-plugin-ember
+
+## Summary
+
+This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14):
+- all of the template rules that were enabled by default in `ember-template-lint` become enabled by default in `eslint-plugin-ember` -- this is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to
+- rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended` and moved to a new `legacy` config
+
+Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
+
+[rfc-1214]: https://github.com/emberjs/rfcs/pull/1214
+[issue-2158]: https://github.com/ember-cli/eslint-plugin-ember/issues/2158
+[issue-2060]: https://github.com/ember-cli/eslint-plugin-ember/issues/2060
+
+## Motivation
+
+Two things are converging on this major:
+
+1. [RFC #1214][rfc-1214] deprecates `ember-template-lint` and unifies all Ember lint rules in `eslint-plugin-ember`. As of `eslint-plugin-ember@13`, every `ember-template-lint` rule has been re-implemented as an `ember/template-*` rule[^no-partial], but none of them are in `recommended` yet -- they were kept opt-in (via the `template-lint-migration` config) so that folks running both tools wouldn't get two errors for every violation. With `ember-template-lint` deprecated, the template rules need to be on by default, or newly generated apps lose lint coverage they've always had -- including the A11y rules, which the Ember project has a core commitment to keeping on by default.
+
+2. The current `recommended` set still spends time linting for patterns that cannot exist in apps on `ember-source` 4+. Some of these rules are also the most expensive rules in the set -- profiling in [eslint-plugin-ember#2060][issue-2060] showed `ember/no-implicit-injections` and `ember/no-deprecated-router-transition-methods` at ~6.2 seconds _each_ (5.9% of total lint time, each) on a large app, checking for things that were removed from ember-source years ago.
+
+[^no-partial]: every rule except `no-partial` -- `{{partial}}` was removed from ember-source in 4.0, so there is nothing left to lint against.
+
+## Detailed design
+
+### Add the template rules to `recommended`
+
+The entire rule set of the existing [`template-lint-migration` config][migration-config] is added to `recommended`. This is exact parity with `ember-template-lint`'s `recommended` preset (95 rules), plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
+
+The full list is in the [Appendix](#appendix-template-rules-added-to-recommended).
+
+[migration-config]: https://github.com/ember-cli/eslint-plugin-ember/blob/main/lib/config/template-lint-migration.js
+
+> [!NOTE]
+> `ember-template-lint`'s own recommended preset had to _disable_ several rules for gjs/gts files (`no-implicit-this`, `builtin-component-arguments`, `no-builtin-form-components`, etc.) because it has no knowledge of imports and strict mode makes some of them redundant or wrong. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. This is one of the motivations of [RFC #1214][rfc-1214].
+
+These rules apply anywhere eslint can parse a template:
+- `.gjs` / `.gts` files -- already wired up by the existing configs via `ember-eslint-parser`, nothing for users to do
+- `.hbs` files -- requires a small config block (see below)
+
+Additionally, `ember/no-builtin-form-components` is added to `recommended` (flagged for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
+
+[pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
+
+### Linting `.hbs` files
+
+Existing apps with loose-mode templates opt in with one config block, using the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
+
+```js
+// eslint.config.mjs
+import { hbsParser, plugin as ember } from 'eslint-plugin-ember/recommended';
+
+export default [
+  // ... existing config ...
+  {
+    files: ['app/**/*.hbs'],
+    plugins: { ember },
+    languageOptions: { parser: hbsParser },
+  },
+];
+```
+
+Because the recommended template rules live in a `rules` block with no `files` restriction, they apply to these `.hbs` files automatically once the parser is in place -- there is no separate "hbs ruleset" to keep in sync.
+
+> [!IMPORTANT]
+> If a config has a `@typescript-eslint/parser` block with a broad `files` glob, that glob must be narrowed to `['**/*.{js,ts,gjs,gts}']` so it doesn't try to parse `.hbs` files -- flat config merges every matching block, and type-aware rules will error on non-JS files.
+
+This config block is documented in the migration guide required by [RFC #1214][rfc-1214], and does not go in the app blueprint -- newly generated apps have no `.hbs` files.
+
+### Remove legacy rules from `recommended`, add a `legacy` config
+
+The following rules are removed from `recommended`. They lint against APIs that no longer exist in `ember-source` 4+, so on any app that can actually install `eslint-plugin-ember@14` they can never fire -- they only cost lint time.
+
+| Rule | Why it's no longer needed |
+| ---- | ------------------------- |
+| `ember/no-implicit-injections` | implicit injections don't exist in ember-source 4+ ([RFC #0680](https://github.com/emberjs/rfcs/blob/master/text/0680-implicit-injection-deprecation.md)); one of the two most expensive rules in the set |
+| `ember/no-deprecated-router-transition-methods` | the deprecated transition methods were removed in 4.0; the other most expensive rule |
+| `ember/avoid-using-needs-in-controllers` | `needs` was removed before 3.x |
+| `ember/routes-segments-snake-case` | the rule's motivation was the implicit route model, which is deprecated ([RFC #0774](https://github.com/emberjs/rfcs/blob/master/text/0774-implicit-record-route-loading.md)); raised in [#2060][issue-2060] |
+| `ember/no-deeply-nested-dependent-keys-with-each` | computed-property era ([#1950][issue-1950]) |
+| `ember/no-volatile-computed-properties` | `.volatile()` was removed in 4.0 |
+| `ember/closure-actions` | 3.x-era invocation style |
+| `ember/no-function-prototype-extensions` | prototype extensions were removed in 4.0 |
+| `ember/no-old-shims` | ember-cli-shims era |
+| `ember/no-string-prototype-extensions` | prototype extensions were removed in 4.0 |
+| `ember/no-get-with-default` | `getWithDefault` was removed in 4.0 |
+| `ember/no-try-invoke` | `tryInvoke` was removed in 4.0 |
+| `ember/no-test-module-for` | `moduleFor*` was removed from ember-qunit long ago |
+| `ember/require-fetch-import` | `ember-fetch` is removed from the blueprint ([RFC #1065](https://github.com/emberjs/rfcs/blob/master/text/1065-remove-ember-fetch.md)); see [#1224][issue-1224] |
+
+[issue-1950]: https://github.com/ember-cli/eslint-plugin-ember/issues/1950
+[issue-1224]: https://github.com/ember-cli/eslint-plugin-ember/issues/1224
+
+None of these rules are deleted from the plugin. As proposed in [#1950][issue-1950], they move to a new `legacy` config, so apps still working through older ember-source versions can do:
+
+```js
+import emberRecommended from 'eslint-plugin-ember/configs/recommended';
+import emberLegacy from 'eslint-plugin-ember/configs/legacy';
+
+export default [...emberRecommended, ...emberLegacy];
+```
+
+and get exactly the coverage they have today.
+
+> [!NOTE]
+> There is a second group of rules that guard against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become `legacy` candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
+
+### What happens to `template-lint-migration`
+
+The config sticks around in v14 unchanged -- it's load-bearing for the [RFC #1214][rfc-1214] migration guide, and spreading it after `recommended` is harmless once the rules overlap. It gets removed in the major after this one, when the `ember-template-lint` deprecation window closes.
+
+### Other breaking changes
+
+[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- they're listed only so readers know this RFC is intentionally scoped to the `recommended` rule set.
+
+## How we teach this
+
+Most of the teaching work is already required by [RFC #1214][rfc-1214]: the migration guide from `ember-template-lint` covers the `.hbs` parser block, the directive conversion (`template-lint-disable` → `eslint-disable-next-line`), and moving custom rule overrides from `.template-lintrc.js` into `eslint.config.mjs`.
+
+For the v14 upgrade itself:
+
+- Newly generated apps just get the new config from the blueprint. No teaching needed.
+- Existing apps upgrading to v14 will see new errors -- in gjs/gts files immediately, and in hbs files once they add the parser block. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
+- Apps that were already using the `template-lint-migration` config see no new template errors at all -- v14 is a no-op for them.
+
+## Drawbacks
+
+- Existing apps get a wall of new lint errors on upgrade. This is unavoidable if we want parity for new apps (per RFC #1214), and bulk suppressions make it a mechanical one-time cost rather than a blocker.
+- Apps still supporting ember-source 3.x need to know to add the `legacy` config. The release notes and the changelog entry for each removed rule cover this.
+
+## Alternatives
+
+### Keep the template rules opt-in
+
+This contradicts RFC #1214 -- newly generated apps would ship without the default lint coverage (including A11y coverage) that every Ember app has had for years.
+
+### Enable only the A11y subset by default
+
+Preserves the A11y commitment with fewer new errors, but breaks parity with what `ember-template-lint` users have today, and makes "did I migrate correctly?" harder to answer. Parity is the simpler story: same rules, one tool.
+
+### Delete the legacy rules instead of moving them to a `legacy` config
+
+Less maintenance, but folks on long-lived 3.x apps lose coverage with no recourse. The rules already exist and are tested; keeping them in an off-by-default config costs almost nothing.
+
+## Unresolved questions
+
+- Should `ember/template-no-bare-strings` (off by default in `ember-template-lint`, off by default here) get any special mention in the migration guide for i18n-heavy apps? (Leaning yes, but it's a docs question, not a config question.)
+
+## Appendix: template rules added to `recommended`
+
+All 96 rules from the `template-lint-migration` config, at `error`. This is `ember-template-lint`'s recommended preset (minus `no-partial`, which has no equivalent because `{{partial}}` no longer exists) plus `template-no-template-lint-directives`.
+
+- `ember/template-builtin-component-arguments`
+- `ember/template-deprecated-inline-view-helper`
+- `ember/template-deprecated-render-helper`
+- `ember/template-link-href-attributes`
+- `ember/template-link-rel-noopener`
+- `ember/template-no-abstract-roles`
+- `ember/template-no-accesskey-attribute`
+- `ember/template-no-action`
+- `ember/template-no-action-on-submit-button`
+- `ember/template-no-args-paths`
+- `ember/template-no-arguments-for-html-elements`
+- `ember/template-no-aria-hidden-body`
+- `ember/template-no-aria-unsupported-elements`
+- `ember/template-no-array-prototype-extensions`
+- `ember/template-no-at-ember-render-modifiers`
+- `ember/template-no-attrs-in-components`
+- `ember/template-no-autofocus-attribute`
+- `ember/template-no-block-params-for-html-elements`
+- `ember/template-no-builtin-form-components`
+- `ember/template-no-capital-arguments`
+- `ember/template-no-class-bindings`
+- `ember/template-no-curly-component-invocation`
+- `ember/template-no-debugger`
+- `ember/template-no-duplicate-attributes`
+- `ember/template-no-duplicate-id`
+- `ember/template-no-duplicate-landmark-elements`
+- `ember/template-no-empty-headings`
+- `ember/template-no-extra-mut-helper-argument`
+- `ember/template-no-forbidden-elements`
+- `ember/template-no-heading-inside-button`
+- `ember/template-no-html-comments`
+- `ember/template-no-implicit-this`
+- `ember/template-no-index-component-invocation`
+- `ember/template-no-inline-styles`
+- `ember/template-no-input-block`
+- `ember/template-no-input-tagname`
+- `ember/template-no-invalid-aria-attributes`
+- `ember/template-no-invalid-interactive`
+- `ember/template-no-invalid-link-text`
+- `ember/template-no-invalid-link-title`
+- `ember/template-no-invalid-meta`
+- `ember/template-no-invalid-role`
+- `ember/template-no-link-to-positional-params`
+- `ember/template-no-link-to-tagname`
+- `ember/template-no-log`
+- `ember/template-no-negated-condition`
+- `ember/template-no-nested-interactive`
+- `ember/template-no-nested-landmark`
+- `ember/template-no-nested-splattributes`
+- `ember/template-no-obscure-array-access`
+- `ember/template-no-obsolete-elements`
+- `ember/template-no-outlet-outside-routes`
+- `ember/template-no-passed-in-event-handlers`
+- `ember/template-no-pointer-down-event-binding`
+- `ember/template-no-positional-data-test-selectors`
+- `ember/template-no-positive-tabindex`
+- `ember/template-no-potential-path-strings`
+- `ember/template-no-quoteless-attributes`
+- `ember/template-no-redundant-fn`
+- `ember/template-no-redundant-role`
+- `ember/template-no-route-action`
+- `ember/template-no-scope-outside-table-headings`
+- `ember/template-no-shadowed-elements`
+- `ember/template-no-template-lint-directives`
+- `ember/template-no-triple-curlies`
+- `ember/template-no-unbalanced-curlies`
+- `ember/template-no-unbound`
+- `ember/template-no-unknown-arguments-for-builtin-components`
+- `ember/template-no-unnecessary-component-helper`
+- `ember/template-no-unnecessary-curly-parens`
+- `ember/template-no-unnecessary-curly-strings`
+- `ember/template-no-unsupported-role-attributes`
+- `ember/template-no-unused-block-params`
+- `ember/template-no-valueless-arguments`
+- `ember/template-no-whitespace-for-layout`
+- `ember/template-no-whitespace-within-word`
+- `ember/template-no-with`
+- `ember/template-no-yield-only`
+- `ember/template-no-yield-to-default`
+- `ember/template-require-aria-activedescendant-tabindex`
+- `ember/template-require-button-type`
+- `ember/template-require-context-role`
+- `ember/template-require-has-block-helper`
+- `ember/template-require-iframe-title`
+- `ember/template-require-input-label`
+- `ember/template-require-lang-attribute`
+- `ember/template-require-mandatory-role-attributes`
+- `ember/template-require-media-caption`
+- `ember/template-require-presentational-children`
+- `ember/template-require-valid-alt-text`
+- `ember/template-require-valid-named-block-naming-format`
+- `ember/template-simple-modifiers`
+- `ember/template-simple-unless`
+- `ember/template-splat-attributes-only`
+- `ember/template-style-concatenation`
+- `ember/template-table-groups`

From a902494ccbbfbdbb005005ea8d514121cc5be837 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 27 Jul 2026 13:46:38 -0400
Subject: [PATCH 02/16] Updates

---
 text/1217-eslint-plugin-ember-next-major.md | 58 ++++++++++++---------
 1 file changed, 33 insertions(+), 25 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index cdc8ac3b54..3aeda6a8ea 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -19,8 +19,8 @@ suite:
 ## Summary
 
 This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14):
-- all of the template rules that were enabled by default in `ember-template-lint` become enabled by default in `eslint-plugin-ember` -- this is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to
-- rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended` and moved to a new `legacy` config
+- the template rules that were enabled by default in `ember-template-lint` become enabled by default for gjs/gts files -- this is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via the hbs config (currently named `template-lint-migration`)
+- rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended`
 
 Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
 
@@ -40,32 +40,31 @@ Two things are converging on this major:
 
 ## Detailed design
 
-### Add the template rules to `recommended`
+### Add the template rules to `recommended`, for gjs/gts only
 
-The entire rule set of the existing [`template-lint-migration` config][migration-config] is added to `recommended`. This is exact parity with `ember-template-lint`'s `recommended` preset (95 rules), plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
+The entire rule set of the existing [`template-lint-migration` config][migration-config] is added to `recommended`, scoped to `**/*.{gjs,gts}`. This is exact parity with `ember-template-lint`'s `recommended` preset (95 rules), plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
 
 The full list is in the [Appendix](#appendix-template-rules-added-to-recommended).
 
+The `recommended` config today is gjs/gts (and js/ts) only, and that does not change -- it never touches `.hbs` files, so adding it to a project can never require also configuring an hbs parser. Newly generated apps have no `.hbs` files, so `recommended` alone gives them full lint parity with what `ember-template-lint` provided.
+
 [migration-config]: https://github.com/ember-cli/eslint-plugin-ember/blob/main/lib/config/template-lint-migration.js
 
 > [!NOTE]
 > `ember-template-lint`'s own recommended preset had to _disable_ several rules for gjs/gts files (`no-implicit-this`, `builtin-component-arguments`, `no-builtin-form-components`, etc.) because it has no knowledge of imports and strict mode makes some of them redundant or wrong. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. This is one of the motivations of [RFC #1214][rfc-1214].
 
-These rules apply anywhere eslint can parse a template:
-- `.gjs` / `.gts` files -- already wired up by the existing configs via `ember-eslint-parser`, nothing for users to do
-- `.hbs` files -- requires a small config block (see below)
-
 Additionally, `ember/no-builtin-form-components` is added to `recommended` (flagged for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
 
 [pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
 
-### Linting `.hbs` files
+### Linting `.hbs` files stays opt-in
 
-Existing apps with loose-mode templates opt in with one config block, using the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
+Existing apps with loose-mode templates opt in with the hbs config -- the [`template-lint-migration` config][migration-config] (same rule set as above) plus a parser block routing `.hbs` files to the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
 
 ```js
 // eslint.config.mjs
 import { hbsParser, plugin as ember } from 'eslint-plugin-ember/recommended';
+import emberTemplateLintMigration from 'eslint-plugin-ember/configs/template-lint-migration';
 
 export default [
   // ... existing config ...
@@ -74,17 +73,16 @@ export default [
     plugins: { ember },
     languageOptions: { parser: hbsParser },
   },
+  ...emberTemplateLintMigration,
 ];
 ```
 
-Because the recommended template rules live in a `rules` block with no `files` restriction, they apply to these `.hbs` files automatically once the parser is in place -- there is no separate "hbs ruleset" to keep in sync.
-
 > [!IMPORTANT]
 > If a config has a `@typescript-eslint/parser` block with a broad `files` glob, that glob must be narrowed to `['**/*.{js,ts,gjs,gts}']` so it doesn't try to parse `.hbs` files -- flat config merges every matching block, and type-aware rules will error on non-JS files.
 
 This config block is documented in the migration guide required by [RFC #1214][rfc-1214], and does not go in the app blueprint -- newly generated apps have no `.hbs` files.
 
-### Remove legacy rules from `recommended`, add a `legacy` config
+### Remove legacy rules from `recommended`
 
 The following rules are removed from `recommended`. They lint against APIs that no longer exist in `ember-source` 4+, so on any app that can actually install `eslint-plugin-ember@14` they can never fire -- they only cost lint time.
 
@@ -108,23 +106,28 @@ The following rules are removed from `recommended`. They lint against APIs that
 [issue-1950]: https://github.com/ember-cli/eslint-plugin-ember/issues/1950
 [issue-1224]: https://github.com/ember-cli/eslint-plugin-ember/issues/1224
 
-None of these rules are deleted from the plugin. As proposed in [#1950][issue-1950], they move to a new `legacy` config, so apps still working through older ember-source versions can do:
+None of these rules are deleted from the plugin -- they just come out of `recommended`. Apps still working through an older ember-source can re-enable them in their own config:
 
 ```js
-import emberRecommended from 'eslint-plugin-ember/configs/recommended';
-import emberLegacy from 'eslint-plugin-ember/configs/legacy';
-
-export default [...emberRecommended, ...emberLegacy];
+export default [
+  ...emberRecommended,
+  {
+    rules: {
+      'ember/no-get-with-default': 'error',
+      // ...whichever of the removed rules still apply
+    },
+  },
+];
 ```
 
-and get exactly the coverage they have today.
+or simply stay on `eslint-plugin-ember@13` until they're on ember-source 4+.
 
 > [!NOTE]
-> There is a second group of rules that guard against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become `legacy` candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
+> There is a second group of rules that guard against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
 
 ### What happens to `template-lint-migration`
 
-The config sticks around in v14 unchanged -- it's load-bearing for the [RFC #1214][rfc-1214] migration guide, and spreading it after `recommended` is harmless once the rules overlap. It gets removed in the major after this one, when the `ember-template-lint` deprecation window closes.
+The config sticks around -- it's load-bearing for the [RFC #1214][rfc-1214] migration guide, and once `ember-template-lint` is gone it's not really a _migration_ config anymore, it's the hbs config. v14 should rename it to `hbs` (keeping `template-lint-migration` as an alias for the deprecation window) so that its long-term purpose is reflected in its name.
 
 ### Other breaking changes
 
@@ -137,13 +140,14 @@ Most of the teaching work is already required by [RFC #1214][rfc-1214]: the migr
 For the v14 upgrade itself:
 
 - Newly generated apps just get the new config from the blueprint. No teaching needed.
-- Existing apps upgrading to v14 will see new errors -- in gjs/gts files immediately, and in hbs files once they add the parser block. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
+- Existing apps upgrading to v14 will see new errors in their gjs/gts files. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
+- Apps with `.hbs` files opt in to hbs linting via the hbs config -- that's a migration-from-`ember-template-lint` task (covered by RFC #1214's migration guide), not a v14-upgrade task.
 - Apps that were already using the `template-lint-migration` config see no new template errors at all -- v14 is a no-op for them.
 
 ## Drawbacks
 
 - Existing apps get a wall of new lint errors on upgrade. This is unavoidable if we want parity for new apps (per RFC #1214), and bulk suppressions make it a mechanical one-time cost rather than a blocker.
-- Apps still supporting ember-source 3.x need to know to add the `legacy` config. The release notes and the changelog entry for each removed rule cover this.
+- Apps still supporting ember-source 3.x silently lose coverage for the removed rules unless they re-enable them. The release notes and the changelog entry for each removed rule cover this -- and staying on v13 is always an option, since nothing about v13 stops working.
 
 ## Alternatives
 
@@ -155,9 +159,13 @@ This contradicts RFC #1214 -- newly generated apps would ship without the defaul
 
 Preserves the A11y commitment with fewer new errors, but breaks parity with what `ember-template-lint` users have today, and makes "did I migrate correctly?" harder to answer. Parity is the simpler story: same rules, one tool.
 
-### Delete the legacy rules instead of moving them to a `legacy` config
+### Ship a `legacy` config with the removed rules
+
+[#1950][issue-1950] proposed this. It's a config we'd have to name, document, and maintain for an audience that shrinks every year -- and that audience already has two simpler options: stay on v13, or re-enable the handful of rules they still want in their own config. Not worth the surface area.
+
+### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
-Less maintenance, but folks on long-lived 3.x apps lose coverage with no recourse. The rules already exist and are tested; keeping them in an off-by-default config costs almost nothing.
+Then `recommended` would error-or-crash for anyone with `.hbs` files who hasn't configured the hbs parser. Keeping `recommended` gjs/gts-only means it stays safe to adopt without any parser setup, and hbs linting remains a deliberate opt-in.
 
 ## Unresolved questions
 

From b905196b5034b70da53ee523950ce106197e9e44 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 27 Jul 2026 13:55:46 -0400
Subject: [PATCH 03/16] Updates

---
 text/1217-eslint-plugin-ember-next-major.md | 49 +++++++++++++--------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 3aeda6a8ea..ff9179af0b 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -19,7 +19,7 @@ suite:
 ## Summary
 
 This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14):
-- the template rules that were enabled by default in `ember-template-lint` become enabled by default for gjs/gts files -- this is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via the hbs config (currently named `template-lint-migration`)
+- the template rules that were enabled by default in `ember-template-lint` -- those of them that are applicable to strict mode -- become enabled by default for gjs/gts files. This is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via `template-lint-migration` (the hbs config), which keeps the full `ember-template-lint` parity set
 - rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended`
 
 Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
@@ -40,18 +40,21 @@ Two things are converging on this major:
 
 ## Detailed design
 
-### Add the template rules to `recommended`, for gjs/gts only
+### Add the gjs/gts-applicable template rules to `recommended`
 
-The entire rule set of the existing [`template-lint-migration` config][migration-config] is added to `recommended`, scoped to `**/*.{gjs,gts}`. This is exact parity with `ember-template-lint`'s `recommended` preset (95 rules), plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
+The rules from the existing [`template-lint-migration` config][migration-config] that are applicable to strict-mode templates are added to `recommended`, scoped to `**/*.{gjs,gts}`. The full list is in [Appendix A](#appendix-a-template-rules-added-to-recommended). The baseline is `ember-template-lint`'s `recommended` preset, plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
 
-The full list is in the [Appendix](#appendix-template-rules-added-to-recommended).
+"Applicable to strict-mode templates" excludes two groups, which stay in the hbs config only ([Appendix B](#appendix-b-loose-mode-only-rules-not-added-to-recommended)):
+
+- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation` -- strict mode _is_ the fix these rules push you toward. `ember-template-lint`'s own recommended preset disables both for gjs/gts.
+- rules that lint constructs which cannot be expressed in strict mode in the first place (`{{action}}`, curly `{{input}}`, `{{#with}}`, the old `{{view}}`/`{{render}}` helpers, ...). These can never fire in a gjs/gts file, so keeping them enabled would only cost lint time -- the same reasoning as the legacy JS rule removals below.
 
 The `recommended` config today is gjs/gts (and js/ts) only, and that does not change -- it never touches `.hbs` files, so adding it to a project can never require also configuring an hbs parser. Newly generated apps have no `.hbs` files, so `recommended` alone gives them full lint parity with what `ember-template-lint` provided.
 
 [migration-config]: https://github.com/ember-cli/eslint-plugin-ember/blob/main/lib/config/template-lint-migration.js
 
 > [!NOTE]
-> `ember-template-lint`'s own recommended preset had to _disable_ several rules for gjs/gts files (`no-implicit-this`, `builtin-component-arguments`, `no-builtin-form-components`, etc.) because it has no knowledge of imports and strict mode makes some of them redundant or wrong. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. This is one of the motivations of [RFC #1214][rfc-1214].
+> `ember-template-lint`'s recommended preset also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
 
 Additionally, `ember/no-builtin-form-components` is added to `recommended` (flagged for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
 
@@ -59,7 +62,7 @@ Additionally, `ember/no-builtin-form-components` is added to `recommended` (flag
 
 ### Linting `.hbs` files stays opt-in
 
-Existing apps with loose-mode templates opt in with the hbs config -- the [`template-lint-migration` config][migration-config] (same rule set as above) plus a parser block routing `.hbs` files to the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
+Existing apps with loose-mode templates opt in with the hbs config -- the [`template-lint-migration` config][migration-config], which keeps the _full_ `ember-template-lint` parity set (including the loose-mode-only rules that don't move to `recommended`) -- plus a parser block routing `.hbs` files to the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
 
 ```js
 // eslint.config.mjs
@@ -127,7 +130,9 @@ or simply stay on `eslint-plugin-ember@13` until they're on ember-source 4+.
 
 ### What happens to `template-lint-migration`
 
-The config sticks around -- it's load-bearing for the [RFC #1214][rfc-1214] migration guide, and once `ember-template-lint` is gone it's not really a _migration_ config anymore, it's the hbs config. v14 should rename it to `hbs` (keeping `template-lint-migration` as an alias for the deprecation window) so that its long-term purpose is reflected in its name.
+The config sticks around and takes on a permanent role: it is what folks who still have `.hbs` files should use. It keeps the full `ember-template-lint` parity set, so hbs coverage is identical before and after this major. It's also load-bearing for the [RFC #1214][rfc-1214] migration guide.
+
+Since it's not really a _migration_ config anymore, v14 should rename it to `hbs` (keeping `template-lint-migration` as an alias for the deprecation window) so that its long-term purpose is reflected in its name.
 
 ### Other breaking changes
 
@@ -169,20 +174,18 @@ Then `recommended` would error-or-crash for anyone with `.hbs` files who hasn't
 
 ## Unresolved questions
 
+- The Appendix A / Appendix B partition should be treated as the starting point, not gospel -- the implementation should audit each rule against what strict mode can actually express (some loose-mode constructs, like `{{unbound}}` or `{{mut}}`, are still keywords in strict mode and their rules stay in Appendix A). Rules found to be miscategorized during implementation move to the right list without re-RFCing.
 - Should `ember/template-no-bare-strings` (off by default in `ember-template-lint`, off by default here) get any special mention in the migration guide for i18n-heavy apps? (Leaning yes, but it's a docs question, not a config question.)
 
-## Appendix: template rules added to `recommended`
+## Appendix A: template rules added to `recommended`
 
-All 96 rules from the `template-lint-migration` config, at `error`. This is `ember-template-lint`'s recommended preset (minus `no-partial`, which has no equivalent because `{{partial}}` no longer exists) plus `template-no-template-lint-directives`.
+87 rules, at `error`, scoped to `**/*.{gjs,gts}`. This is the `template-lint-migration` rule set (`ember-template-lint`'s recommended preset -- minus `no-partial`, which has no equivalent because `{{partial}}` no longer exists -- plus `template-no-template-lint-directives`) with the loose-mode-only rules from Appendix B taken out.
 
 - `ember/template-builtin-component-arguments`
-- `ember/template-deprecated-inline-view-helper`
-- `ember/template-deprecated-render-helper`
 - `ember/template-link-href-attributes`
 - `ember/template-link-rel-noopener`
 - `ember/template-no-abstract-roles`
 - `ember/template-no-accesskey-attribute`
-- `ember/template-no-action`
 - `ember/template-no-action-on-submit-button`
 - `ember/template-no-args-paths`
 - `ember/template-no-arguments-for-html-elements`
@@ -196,7 +199,6 @@ All 96 rules from the `template-lint-migration` config, at `error`. This is `emb
 - `ember/template-no-builtin-form-components`
 - `ember/template-no-capital-arguments`
 - `ember/template-no-class-bindings`
-- `ember/template-no-curly-component-invocation`
 - `ember/template-no-debugger`
 - `ember/template-no-duplicate-attributes`
 - `ember/template-no-duplicate-id`
@@ -206,11 +208,8 @@ All 96 rules from the `template-lint-migration` config, at `error`. This is `emb
 - `ember/template-no-forbidden-elements`
 - `ember/template-no-heading-inside-button`
 - `ember/template-no-html-comments`
-- `ember/template-no-implicit-this`
 - `ember/template-no-index-component-invocation`
 - `ember/template-no-inline-styles`
-- `ember/template-no-input-block`
-- `ember/template-no-input-tagname`
 - `ember/template-no-invalid-aria-attributes`
 - `ember/template-no-invalid-interactive`
 - `ember/template-no-invalid-link-text`
@@ -235,7 +234,6 @@ All 96 rules from the `template-lint-migration` config, at `error`. This is `emb
 - `ember/template-no-quoteless-attributes`
 - `ember/template-no-redundant-fn`
 - `ember/template-no-redundant-role`
-- `ember/template-no-route-action`
 - `ember/template-no-scope-outside-table-headings`
 - `ember/template-no-shadowed-elements`
 - `ember/template-no-template-lint-directives`
@@ -251,7 +249,6 @@ All 96 rules from the `template-lint-migration` config, at `error`. This is `emb
 - `ember/template-no-valueless-arguments`
 - `ember/template-no-whitespace-for-layout`
 - `ember/template-no-whitespace-within-word`
-- `ember/template-no-with`
 - `ember/template-no-yield-only`
 - `ember/template-no-yield-to-default`
 - `ember/template-require-aria-activedescendant-tabindex`
@@ -271,3 +268,19 @@ All 96 rules from the `template-lint-migration` config, at `error`. This is `emb
 - `ember/template-splat-attributes-only`
 - `ember/template-style-concatenation`
 - `ember/template-table-groups`
+
+## Appendix B: loose-mode-only rules, not added to `recommended`
+
+These 9 rules stay in the hbs config (`template-lint-migration`), keeping full `ember-template-lint` parity for `.hbs` files.
+
+| Rule | Why it doesn't apply to gjs/gts |
+| ---- | ------------------------------- |
+| `ember/template-no-implicit-this` | strict mode has no implicit `this` -- an unresolved reference is a build error |
+| `ember/template-no-curly-component-invocation` | the component-or-property ambiguity this rule guards against doesn't exist in strict mode |
+| `ember/template-no-action` | `{{action}}` has no strict-mode import |
+| `ember/template-no-route-action` | `{{route-action}}` has no strict-mode import |
+| `ember/template-no-input-block` | curly `{{input}}` cannot resolve in strict mode |
+| `ember/template-no-input-tagname` | curly `{{input}}` cannot resolve in strict mode |
+| `ember/template-no-with` | `{{#with}}` was removed in ember-source 4.0 and cannot be expressed in strict mode |
+| `ember/template-deprecated-render-helper` | `{{render}}` is long gone and cannot be expressed in strict mode |
+| `ember/template-deprecated-inline-view-helper` | `{{view}}` is long gone and cannot be expressed in strict mode |

From 905b84b012ab15b597df7a07b5fe410a43b7afd3 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 27 Jul 2026 15:40:45 -0400
Subject: [PATCH 04/16] Humanize

---
 text/1217-eslint-plugin-ember-next-major.md | 24 ++++++++++-----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index ff9179af0b..40614cefc6 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -30,7 +30,7 @@ Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to
 
 ## Motivation
 
-Two things are converging on this major:
+This major has two motivations:
 
 1. [RFC #1214][rfc-1214] deprecates `ember-template-lint` and unifies all Ember lint rules in `eslint-plugin-ember`. As of `eslint-plugin-ember@13`, every `ember-template-lint` rule has been re-implemented as an `ember/template-*` rule[^no-partial], but none of them are in `recommended` yet -- they were kept opt-in (via the `template-lint-migration` config) so that folks running both tools wouldn't get two errors for every violation. With `ember-template-lint` deprecated, the template rules need to be on by default, or newly generated apps lose lint coverage they've always had -- including the A11y rules, which the Ember project has a core commitment to keeping on by default.
 
@@ -46,7 +46,7 @@ The rules from the existing [`template-lint-migration` config][migration-config]
 
 "Applicable to strict-mode templates" excludes two groups, which stay in the hbs config only ([Appendix B](#appendix-b-loose-mode-only-rules-not-added-to-recommended)):
 
-- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation` -- strict mode _is_ the fix these rules push you toward. `ember-template-lint`'s own recommended preset disables both for gjs/gts.
+- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation` -- the whole point of these rules is to prepare loose-mode templates for strict mode, and a gjs/gts file is already there. `ember-template-lint`'s own recommended preset disables both for gjs/gts.
 - rules that lint constructs which cannot be expressed in strict mode in the first place (`{{action}}`, curly `{{input}}`, `{{#with}}`, the old `{{view}}`/`{{render}}` helpers, ...). These can never fire in a gjs/gts file, so keeping them enabled would only cost lint time -- the same reasoning as the legacy JS rule removals below.
 
 The `recommended` config today is gjs/gts (and js/ts) only, and that does not change -- it never touches `.hbs` files, so adding it to a project can never require also configuring an hbs parser. Newly generated apps have no `.hbs` files, so `recommended` alone gives them full lint parity with what `ember-template-lint` provided.
@@ -56,7 +56,7 @@ The `recommended` config today is gjs/gts (and js/ts) only, and that does not ch
 > [!NOTE]
 > `ember-template-lint`'s recommended preset also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
 
-Additionally, `ember/no-builtin-form-components` is added to `recommended` (flagged for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
+One more addition: `ember/no-builtin-form-components` (called out for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
 
 [pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
 
@@ -126,17 +126,17 @@ export default [
 or simply stay on `eslint-plugin-ember@13` until they're on ember-source 4+.
 
 > [!NOTE]
-> There is a second group of rules that guard against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
+> There is a second group of rules that lint against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
 
 ### What happens to `template-lint-migration`
 
-The config sticks around and takes on a permanent role: it is what folks who still have `.hbs` files should use. It keeps the full `ember-template-lint` parity set, so hbs coverage is identical before and after this major. It's also load-bearing for the [RFC #1214][rfc-1214] migration guide.
+The config stays, permanently: it is what folks who still have `.hbs` files should use. It keeps the full `ember-template-lint` parity set, so hbs coverage is identical before and after this major, and the [RFC #1214][rfc-1214] migration guide is written around it.
 
 Since it's not really a _migration_ config anymore, v14 should rename it to `hbs` (keeping `template-lint-migration` as an alias for the deprecation window) so that its long-term purpose is reflected in its name.
 
 ### Other breaking changes
 
-[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- they're listed only so readers know this RFC is intentionally scoped to the `recommended` rule set.
+[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- this RFC is only about the `recommended` rule set.
 
 ## How we teach this
 
@@ -151,7 +151,7 @@ For the v14 upgrade itself:
 
 ## Drawbacks
 
-- Existing apps get a wall of new lint errors on upgrade. This is unavoidable if we want parity for new apps (per RFC #1214), and bulk suppressions make it a mechanical one-time cost rather than a blocker.
+- Existing apps get a bunch of new lint errors on upgrade. That's the point of the major (per RFC #1214), and bulk suppressions exist so that nobody has to fix them all in one PR.
 - Apps still supporting ember-source 3.x silently lose coverage for the removed rules unless they re-enable them. The release notes and the changelog entry for each removed rule cover this -- and staying on v13 is always an option, since nothing about v13 stops working.
 
 ## Alternatives
@@ -162,19 +162,19 @@ This contradicts RFC #1214 -- newly generated apps would ship without the defaul
 
 ### Enable only the A11y subset by default
 
-Preserves the A11y commitment with fewer new errors, but breaks parity with what `ember-template-lint` users have today, and makes "did I migrate correctly?" harder to answer. Parity is the simpler story: same rules, one tool.
+Preserves the A11y commitment with fewer new errors, but breaks parity with what `ember-template-lint` users have today, and makes "did I migrate correctly?" harder to answer. Parity is easier to explain: same rules, one tool.
 
 ### Ship a `legacy` config with the removed rules
 
-[#1950][issue-1950] proposed this. It's a config we'd have to name, document, and maintain for an audience that shrinks every year -- and that audience already has two simpler options: stay on v13, or re-enable the handful of rules they still want in their own config. Not worth the surface area.
+[#1950][issue-1950] proposed this. It's another config to name, document, and maintain, for a set of apps that shrinks every year -- and those apps already have two options: stay on v13, or re-enable the handful of rules they still want in their own config. Not worth maintaining.
 
 ### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
-Then `recommended` would error-or-crash for anyone with `.hbs` files who hasn't configured the hbs parser. Keeping `recommended` gjs/gts-only means it stays safe to adopt without any parser setup, and hbs linting remains a deliberate opt-in.
+Then `recommended` would blow up for anyone with `.hbs` files who hasn't configured the hbs parser. Keeping `recommended` gjs/gts-only means it works without any parser setup, and hbs linting stays opt-in.
 
 ## Unresolved questions
 
-- The Appendix A / Appendix B partition should be treated as the starting point, not gospel -- the implementation should audit each rule against what strict mode can actually express (some loose-mode constructs, like `{{unbound}}` or `{{mut}}`, are still keywords in strict mode and their rules stay in Appendix A). Rules found to be miscategorized during implementation move to the right list without re-RFCing.
+- The Appendix A / Appendix B split is a best guess -- during implementation, each rule should be checked against what strict mode can actually express (some loose-mode constructs, like `{{unbound}}` or `{{mut}}`, are still keywords in strict mode, so their rules stay in Appendix A). Rules that end up in the wrong list move without re-RFCing.
 - Should `ember/template-no-bare-strings` (off by default in `ember-template-lint`, off by default here) get any special mention in the migration guide for i18n-heavy apps? (Leaning yes, but it's a docs question, not a config question.)
 
 ## Appendix A: template rules added to `recommended`
@@ -276,7 +276,7 @@ These 9 rules stay in the hbs config (`template-lint-migration`), keeping full `
 | Rule | Why it doesn't apply to gjs/gts |
 | ---- | ------------------------------- |
 | `ember/template-no-implicit-this` | strict mode has no implicit `this` -- an unresolved reference is a build error |
-| `ember/template-no-curly-component-invocation` | the component-or-property ambiguity this rule guards against doesn't exist in strict mode |
+| `ember/template-no-curly-component-invocation` | the component-or-property ambiguity doesn't exist in strict mode |
 | `ember/template-no-action` | `{{action}}` has no strict-mode import |
 | `ember/template-no-route-action` | `{{route-action}}` has no strict-mode import |
 | `ember/template-no-input-block` | curly `{{input}}` cannot resolve in strict mode |

From 40a9d2315cccf3cf1ce83cbc9fe2baadf5d891df Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 27 Jul 2026 15:43:51 -0400
Subject: [PATCH 05/16] Add links to all the docs of all the rules

---
 text/1217-eslint-plugin-ember-next-major.md | 192 ++++++++++----------
 1 file changed, 96 insertions(+), 96 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 40614cefc6..9ab5ecd912 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -181,93 +181,93 @@ Then `recommended` would blow up for anyone with `.hbs` files who hasn't configu
 
 87 rules, at `error`, scoped to `**/*.{gjs,gts}`. This is the `template-lint-migration` rule set (`ember-template-lint`'s recommended preset -- minus `no-partial`, which has no equivalent because `{{partial}}` no longer exists -- plus `template-no-template-lint-directives`) with the loose-mode-only rules from Appendix B taken out.
 
-- `ember/template-builtin-component-arguments`
-- `ember/template-link-href-attributes`
-- `ember/template-link-rel-noopener`
-- `ember/template-no-abstract-roles`
-- `ember/template-no-accesskey-attribute`
-- `ember/template-no-action-on-submit-button`
-- `ember/template-no-args-paths`
-- `ember/template-no-arguments-for-html-elements`
-- `ember/template-no-aria-hidden-body`
-- `ember/template-no-aria-unsupported-elements`
-- `ember/template-no-array-prototype-extensions`
-- `ember/template-no-at-ember-render-modifiers`
-- `ember/template-no-attrs-in-components`
-- `ember/template-no-autofocus-attribute`
-- `ember/template-no-block-params-for-html-elements`
-- `ember/template-no-builtin-form-components`
-- `ember/template-no-capital-arguments`
-- `ember/template-no-class-bindings`
-- `ember/template-no-debugger`
-- `ember/template-no-duplicate-attributes`
-- `ember/template-no-duplicate-id`
-- `ember/template-no-duplicate-landmark-elements`
-- `ember/template-no-empty-headings`
-- `ember/template-no-extra-mut-helper-argument`
-- `ember/template-no-forbidden-elements`
-- `ember/template-no-heading-inside-button`
-- `ember/template-no-html-comments`
-- `ember/template-no-index-component-invocation`
-- `ember/template-no-inline-styles`
-- `ember/template-no-invalid-aria-attributes`
-- `ember/template-no-invalid-interactive`
-- `ember/template-no-invalid-link-text`
-- `ember/template-no-invalid-link-title`
-- `ember/template-no-invalid-meta`
-- `ember/template-no-invalid-role`
-- `ember/template-no-link-to-positional-params`
-- `ember/template-no-link-to-tagname`
-- `ember/template-no-log`
-- `ember/template-no-negated-condition`
-- `ember/template-no-nested-interactive`
-- `ember/template-no-nested-landmark`
-- `ember/template-no-nested-splattributes`
-- `ember/template-no-obscure-array-access`
-- `ember/template-no-obsolete-elements`
-- `ember/template-no-outlet-outside-routes`
-- `ember/template-no-passed-in-event-handlers`
-- `ember/template-no-pointer-down-event-binding`
-- `ember/template-no-positional-data-test-selectors`
-- `ember/template-no-positive-tabindex`
-- `ember/template-no-potential-path-strings`
-- `ember/template-no-quoteless-attributes`
-- `ember/template-no-redundant-fn`
-- `ember/template-no-redundant-role`
-- `ember/template-no-scope-outside-table-headings`
-- `ember/template-no-shadowed-elements`
-- `ember/template-no-template-lint-directives`
-- `ember/template-no-triple-curlies`
-- `ember/template-no-unbalanced-curlies`
-- `ember/template-no-unbound`
-- `ember/template-no-unknown-arguments-for-builtin-components`
-- `ember/template-no-unnecessary-component-helper`
-- `ember/template-no-unnecessary-curly-parens`
-- `ember/template-no-unnecessary-curly-strings`
-- `ember/template-no-unsupported-role-attributes`
-- `ember/template-no-unused-block-params`
-- `ember/template-no-valueless-arguments`
-- `ember/template-no-whitespace-for-layout`
-- `ember/template-no-whitespace-within-word`
-- `ember/template-no-yield-only`
-- `ember/template-no-yield-to-default`
-- `ember/template-require-aria-activedescendant-tabindex`
-- `ember/template-require-button-type`
-- `ember/template-require-context-role`
-- `ember/template-require-has-block-helper`
-- `ember/template-require-iframe-title`
-- `ember/template-require-input-label`
-- `ember/template-require-lang-attribute`
-- `ember/template-require-mandatory-role-attributes`
-- `ember/template-require-media-caption`
-- `ember/template-require-presentational-children`
-- `ember/template-require-valid-alt-text`
-- `ember/template-require-valid-named-block-naming-format`
-- `ember/template-simple-modifiers`
-- `ember/template-simple-unless`
-- `ember/template-splat-attributes-only`
-- `ember/template-style-concatenation`
-- `ember/template-table-groups`
+- [`ember/template-builtin-component-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-builtin-component-arguments.md)
+- [`ember/template-link-href-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-link-href-attributes.md)
+- [`ember/template-link-rel-noopener`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-link-rel-noopener.md)
+- [`ember/template-no-abstract-roles`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-abstract-roles.md)
+- [`ember/template-no-accesskey-attribute`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-accesskey-attribute.md)
+- [`ember/template-no-action-on-submit-button`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-action-on-submit-button.md)
+- [`ember/template-no-args-paths`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-args-paths.md)
+- [`ember/template-no-arguments-for-html-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-arguments-for-html-elements.md)
+- [`ember/template-no-aria-hidden-body`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-aria-hidden-body.md)
+- [`ember/template-no-aria-unsupported-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-aria-unsupported-elements.md)
+- [`ember/template-no-array-prototype-extensions`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-array-prototype-extensions.md)
+- [`ember/template-no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-at-ember-render-modifiers.md)
+- [`ember/template-no-attrs-in-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-attrs-in-components.md)
+- [`ember/template-no-autofocus-attribute`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-autofocus-attribute.md)
+- [`ember/template-no-block-params-for-html-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-block-params-for-html-elements.md)
+- [`ember/template-no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-builtin-form-components.md)
+- [`ember/template-no-capital-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-capital-arguments.md)
+- [`ember/template-no-class-bindings`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-class-bindings.md)
+- [`ember/template-no-debugger`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-debugger.md)
+- [`ember/template-no-duplicate-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-duplicate-attributes.md)
+- [`ember/template-no-duplicate-id`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-duplicate-id.md)
+- [`ember/template-no-duplicate-landmark-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-duplicate-landmark-elements.md)
+- [`ember/template-no-empty-headings`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-empty-headings.md)
+- [`ember/template-no-extra-mut-helper-argument`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-extra-mut-helper-argument.md)
+- [`ember/template-no-forbidden-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-forbidden-elements.md)
+- [`ember/template-no-heading-inside-button`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-heading-inside-button.md)
+- [`ember/template-no-html-comments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-html-comments.md)
+- [`ember/template-no-index-component-invocation`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-index-component-invocation.md)
+- [`ember/template-no-inline-styles`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-inline-styles.md)
+- [`ember/template-no-invalid-aria-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-aria-attributes.md)
+- [`ember/template-no-invalid-interactive`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-interactive.md)
+- [`ember/template-no-invalid-link-text`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-link-text.md)
+- [`ember/template-no-invalid-link-title`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-link-title.md)
+- [`ember/template-no-invalid-meta`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-meta.md)
+- [`ember/template-no-invalid-role`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-invalid-role.md)
+- [`ember/template-no-link-to-positional-params`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-link-to-positional-params.md)
+- [`ember/template-no-link-to-tagname`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-link-to-tagname.md)
+- [`ember/template-no-log`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-log.md)
+- [`ember/template-no-negated-condition`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-negated-condition.md)
+- [`ember/template-no-nested-interactive`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-nested-interactive.md)
+- [`ember/template-no-nested-landmark`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-nested-landmark.md)
+- [`ember/template-no-nested-splattributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-nested-splattributes.md)
+- [`ember/template-no-obscure-array-access`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-obscure-array-access.md)
+- [`ember/template-no-obsolete-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-obsolete-elements.md)
+- [`ember/template-no-outlet-outside-routes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-outlet-outside-routes.md)
+- [`ember/template-no-passed-in-event-handlers`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-passed-in-event-handlers.md)
+- [`ember/template-no-pointer-down-event-binding`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-pointer-down-event-binding.md)
+- [`ember/template-no-positional-data-test-selectors`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-positional-data-test-selectors.md)
+- [`ember/template-no-positive-tabindex`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-positive-tabindex.md)
+- [`ember/template-no-potential-path-strings`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-potential-path-strings.md)
+- [`ember/template-no-quoteless-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-quoteless-attributes.md)
+- [`ember/template-no-redundant-fn`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-redundant-fn.md)
+- [`ember/template-no-redundant-role`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-redundant-role.md)
+- [`ember/template-no-scope-outside-table-headings`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-scope-outside-table-headings.md)
+- [`ember/template-no-shadowed-elements`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-shadowed-elements.md)
+- [`ember/template-no-template-lint-directives`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-template-lint-directives.md)
+- [`ember/template-no-triple-curlies`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-triple-curlies.md)
+- [`ember/template-no-unbalanced-curlies`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unbalanced-curlies.md)
+- [`ember/template-no-unbound`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unbound.md)
+- [`ember/template-no-unknown-arguments-for-builtin-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unknown-arguments-for-builtin-components.md)
+- [`ember/template-no-unnecessary-component-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unnecessary-component-helper.md)
+- [`ember/template-no-unnecessary-curly-parens`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unnecessary-curly-parens.md)
+- [`ember/template-no-unnecessary-curly-strings`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unnecessary-curly-strings.md)
+- [`ember/template-no-unsupported-role-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unsupported-role-attributes.md)
+- [`ember/template-no-unused-block-params`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-unused-block-params.md)
+- [`ember/template-no-valueless-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-valueless-arguments.md)
+- [`ember/template-no-whitespace-for-layout`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-whitespace-for-layout.md)
+- [`ember/template-no-whitespace-within-word`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-whitespace-within-word.md)
+- [`ember/template-no-yield-only`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-yield-only.md)
+- [`ember/template-no-yield-to-default`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-yield-to-default.md)
+- [`ember/template-require-aria-activedescendant-tabindex`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-aria-activedescendant-tabindex.md)
+- [`ember/template-require-button-type`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-button-type.md)
+- [`ember/template-require-context-role`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-context-role.md)
+- [`ember/template-require-has-block-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-has-block-helper.md)
+- [`ember/template-require-iframe-title`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-iframe-title.md)
+- [`ember/template-require-input-label`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-input-label.md)
+- [`ember/template-require-lang-attribute`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-lang-attribute.md)
+- [`ember/template-require-mandatory-role-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-mandatory-role-attributes.md)
+- [`ember/template-require-media-caption`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-media-caption.md)
+- [`ember/template-require-presentational-children`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-presentational-children.md)
+- [`ember/template-require-valid-alt-text`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-valid-alt-text.md)
+- [`ember/template-require-valid-named-block-naming-format`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-require-valid-named-block-naming-format.md)
+- [`ember/template-simple-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-simple-modifiers.md)
+- [`ember/template-simple-unless`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-simple-unless.md)
+- [`ember/template-splat-attributes-only`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-splat-attributes-only.md)
+- [`ember/template-style-concatenation`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-style-concatenation.md)
+- [`ember/template-table-groups`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-table-groups.md)
 
 ## Appendix B: loose-mode-only rules, not added to `recommended`
 
@@ -275,12 +275,12 @@ These 9 rules stay in the hbs config (`template-lint-migration`), keeping full `
 
 | Rule | Why it doesn't apply to gjs/gts |
 | ---- | ------------------------------- |
-| `ember/template-no-implicit-this` | strict mode has no implicit `this` -- an unresolved reference is a build error |
-| `ember/template-no-curly-component-invocation` | the component-or-property ambiguity doesn't exist in strict mode |
-| `ember/template-no-action` | `{{action}}` has no strict-mode import |
-| `ember/template-no-route-action` | `{{route-action}}` has no strict-mode import |
-| `ember/template-no-input-block` | curly `{{input}}` cannot resolve in strict mode |
-| `ember/template-no-input-tagname` | curly `{{input}}` cannot resolve in strict mode |
-| `ember/template-no-with` | `{{#with}}` was removed in ember-source 4.0 and cannot be expressed in strict mode |
-| `ember/template-deprecated-render-helper` | `{{render}}` is long gone and cannot be expressed in strict mode |
-| `ember/template-deprecated-inline-view-helper` | `{{view}}` is long gone and cannot be expressed in strict mode |
+| [`ember/template-no-implicit-this`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-implicit-this.md) | strict mode has no implicit `this` -- an unresolved reference is a build error |
+| [`ember/template-no-curly-component-invocation`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-curly-component-invocation.md) | the component-or-property ambiguity doesn't exist in strict mode |
+| [`ember/template-no-action`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-action.md) | `{{action}}` has no strict-mode import |
+| [`ember/template-no-route-action`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-route-action.md) | `{{route-action}}` has no strict-mode import |
+| [`ember/template-no-input-block`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-input-block.md) | curly `{{input}}` cannot resolve in strict mode |
+| [`ember/template-no-input-tagname`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-input-tagname.md) | curly `{{input}}` cannot resolve in strict mode |
+| [`ember/template-no-with`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-with.md) | `{{#with}}` was removed in ember-source 4.0 and cannot be expressed in strict mode |
+| [`ember/template-deprecated-render-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-render-helper.md) | `{{render}}` is long gone and cannot be expressed in strict mode |
+| [`ember/template-deprecated-inline-view-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-inline-view-helper.md) | `{{view}}` is long gone and cannot be expressed in strict mode |

From 75a47250c2404c68626c87a0d92b310563a3704c Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 15:06:53 -0400
Subject: [PATCH 06/16] Add no-modifier-without-element-usage to the v14
 recommended set

Groups it with no-builtin-form-components under a new "Add two JS rules
to recommended" section, with the motivation, drawback, and alternative
that reviewers will ask about.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 23 ++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 9ab5ecd912..8b2c7661cc 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -21,6 +21,7 @@ suite:
 This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14):
 - the template rules that were enabled by default in `ember-template-lint` -- those of them that are applicable to strict mode -- become enabled by default for gjs/gts files. This is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via `template-lint-migration` (the hbs config), which keeps the full `ember-template-lint` parity set
 - rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended`
+- two JS rules that catch patterns which are still possible today are added to `recommended`: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`
 
 Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
 
@@ -30,12 +31,14 @@ Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to
 
 ## Motivation
 
-This major has two motivations:
+This major has three motivations:
 
 1. [RFC #1214][rfc-1214] deprecates `ember-template-lint` and unifies all Ember lint rules in `eslint-plugin-ember`. As of `eslint-plugin-ember@13`, every `ember-template-lint` rule has been re-implemented as an `ember/template-*` rule[^no-partial], but none of them are in `recommended` yet -- they were kept opt-in (via the `template-lint-migration` config) so that folks running both tools wouldn't get two errors for every violation. With `ember-template-lint` deprecated, the template rules need to be on by default, or newly generated apps lose lint coverage they've always had -- including the A11y rules, which the Ember project has a core commitment to keeping on by default.
 
 2. The current `recommended` set still spends time linting for patterns that cannot exist in apps on `ember-source` 4+. Some of these rules are also the most expensive rules in the set -- profiling in [eslint-plugin-ember#2060][issue-2060] showed `ember/no-implicit-injections` and `ember/no-deprecated-router-transition-methods` at ~6.2 seconds _each_ (5.9% of total lint time, each) on a large app, checking for things that were removed from ember-source years ago.
 
+3. A major is the only place `recommended` can gain a rule that reports on existing code. Two such rules are ready and are held back only by the semver cost: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that are still reachable in an app on the latest `ember-source`, which is the opposite of the rules being removed in motivation 2.
+
 [^no-partial]: every rule except `no-partial` -- `{{partial}}` was removed from ember-source in 4.0, so there is nothing left to lint against.
 
 ## Detailed design
@@ -56,7 +59,16 @@ The `recommended` config today is gjs/gts (and js/ts) only, and that does not ch
 > [!NOTE]
 > `ember-template-lint`'s recommended preset also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
 
-One more addition: `ember/no-builtin-form-components` (called out for the next major in [eslint-plugin-ember#2060][issue-2060], implemented in [#2282][pr-2282]) -- native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers.
+### Add two JS rules to `recommended`
+
+Both rules already ship in the plugin as opt-in. Neither is a template rule, so both are scoped the way the rest of `recommended` is, not to `**/*.{gjs,gts}`.
+
+| Rule | Why it belongs in `recommended` |
+| ---- | ------------------------------- |
+| [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers. Called out for the next major in [#2060][issue-2060], implemented in [#2282][pr-2282] |
+| [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | a modifier that never references its element is an effect scheduled by render. That is the data flow this RFC's `recommended` set already rejects in templates via `ember/template-no-at-ember-render-modifiers`, and it is just as available through `ember-modifier` directly |
+
+`ember/no-modifier-without-element-usage` covers both modifier styles: the `element` parameter of a `modifier()` callback, and `modify(element)` or `this.element` in a class modifier. Any reference counts, so passing the element to a chart library or a `ResizeObserver` is fine. What it catches is the modifier that exists only to run code at render time, which brings the problems that [`ember/no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-at-ember-render-modifiers.md) documents: extra renders, render loops, and behavior separated from the data it depends on. Those problems do not come from `@ember/render-modifiers` as a package, so a rule that only bans that import leaves the pattern reachable with three lines of `ember-modifier`.
 
 [pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
 
@@ -145,13 +157,14 @@ Most of the teaching work is already required by [RFC #1214][rfc-1214]: the migr
 For the v14 upgrade itself:
 
 - Newly generated apps just get the new config from the blueprint. No teaching needed.
-- Existing apps upgrading to v14 will see new errors in their gjs/gts files. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
+- Existing apps upgrading to v14 will see new errors in their gjs/gts files, and in js/ts files from the two added JS rules. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
 - Apps with `.hbs` files opt in to hbs linting via the hbs config -- that's a migration-from-`ember-template-lint` task (covered by RFC #1214's migration guide), not a v14-upgrade task.
 - Apps that were already using the `template-lint-migration` config see no new template errors at all -- v14 is a no-op for them.
 
 ## Drawbacks
 
 - Existing apps get a bunch of new lint errors on upgrade. That's the point of the major (per RFC #1214), and bulk suppressions exist so that nobody has to fix them all in one PR.
+- `ember/no-modifier-without-element-usage` has no autofix, and clearing a violation is a refactor rather than a rename: the behavior moves to derived state, a resource, or an event handler on the element that already triggers it. Apps that used modifiers as render hooks will want bulk suppressions for this rule while they work through it.
 - Apps still supporting ember-source 3.x silently lose coverage for the removed rules unless they re-enable them. The release notes and the changelog entry for each removed rule cover this -- and staying on v13 is always an option, since nothing about v13 stops working.
 
 ## Alternatives
@@ -168,6 +181,10 @@ Preserves the A11y commitment with fewer new errors, but breaks parity with what
 
 [#1950][issue-1950] proposed this. It's another config to name, document, and maintain, for a set of apps that shrinks every year -- and those apps already have two options: stay on v13, or re-enable the handful of rules they still want in their own config. Not worth maintaining.
 
+### Keep `ember/no-modifier-without-element-usage` opt-in and rely on `ember/no-at-ember-render-modifiers`
+
+`ember/no-at-ember-render-modifiers` is already in `recommended`, so the argument is that the pattern is covered. It is not: that rule bans an import, and the same effect-on-render pattern is available by writing the modifier by hand. An app that removes `@ember/render-modifiers` by reimplementing `{{did-insert}}` locally passes today's `recommended` set.
+
 ### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
 Then `recommended` would blow up for anyone with `.hbs` files who hasn't configured the hbs parser. Keeping `recommended` gjs/gts-only means it works without any parser setup, and hbs linting stays opt-in.

From 76e365f70cb8feee1a6418dc2eb8b44e52b42c44 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 17:36:45 -0400
Subject: [PATCH 07/16] Remove recommended-gjs and recommended-gts in v14

recommended carries their rules now. Records the typescript-eslint
disables moving into the gts block, which does change what is linted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 23 ++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 8b2c7661cc..a627131e3f 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -22,6 +22,7 @@ This RFC defines the `recommended` config for the next major of `eslint-plugin-e
 - the template rules that were enabled by default in `ember-template-lint` -- those of them that are applicable to strict mode -- become enabled by default for gjs/gts files. This is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via `template-lint-migration` (the hbs config), which keeps the full `ember-template-lint` parity set
 - rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended`
 - two JS rules that catch patterns which are still possible today are added to `recommended`: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`
+- the `recommended-gjs` and `recommended-gts` configs are removed, because `recommended` now carries their rules, scoped per file type
 
 Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
 
@@ -72,6 +73,26 @@ Both rules already ship in the plugin as opt-in. Neither is a template rule, so
 
 [pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
 
+### Remove the `recommended-gjs` and `recommended-gts` configs
+
+`recommended` now carries the gjs and gts rules itself, in blocks scoped by `files`. Both extra configs became redundant, so v14 removes them.
+
+`recommended-gts` also did one thing that `recommended` did not. It turned off the core rules that TypeScript already reports, and turned on the four that TypeScript makes better (`no-var`, `prefer-const`, `prefer-rest-params`, `prefer-spread`). That set comes from the `eslint-recommended` config of typescript-eslint. `recommended` now applies it to `**/*.gts`.
+
+The result is one config instead of three:
+
+```js
+// eslint.config.mjs
+import emberRecommended from 'eslint-plugin-ember/configs/recommended';
+
+export default [
+  ...emberRecommended,
+  // a parser block per file type is still required
+];
+```
+
+An app that extends `plugin:ember/recommended-gjs` or `plugin:ember/recommended-gts` deletes those two lines. Every rule they set is in `recommended` already.
+
 ### Linting `.hbs` files stays opt-in
 
 Existing apps with loose-mode templates opt in with the hbs config -- the [`template-lint-migration` config][migration-config], which keeps the _full_ `ember-template-lint` parity set (including the loose-mode-only rules that don't move to `recommended`) -- plus a parser block routing `.hbs` files to the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
@@ -148,7 +169,7 @@ Since it's not really a _migration_ config anymore, v14 should rename it to `hbs
 
 ### Other breaking changes
 
-[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- this RFC is only about the `recommended` rule set.
+[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- this RFC is only about the `recommended` rule set. The two config removals above are the exception: they are specified here because folding the typescript-eslint disables into `recommended` changes what is linted in a gts file.
 
 ## How we teach this
 

From 13a849a12b53048405829eaa994f134ffbba5c21 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:06:47 -0400
Subject: [PATCH 08/16] Rewrite the prose in Simplified Technical English

One idea per sentence, active voice, simple tenses, no dashes as
punctuation, no semicolons. Facts, links, code, and the appendix lists
are unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 150 +++++++++++---------
 1 file changed, 79 insertions(+), 71 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index a627131e3f..1d8db8d673 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -18,13 +18,15 @@ suite:
 
 ## Summary
 
-This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14):
-- the template rules that were enabled by default in `ember-template-lint` -- those of them that are applicable to strict mode -- become enabled by default for gjs/gts files. This is the config change that [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to. The `recommended` config is (and stays) gjs/gts only -- linting `.hbs` files remains opt-in via `template-lint-migration` (the hbs config), which keeps the full `ember-template-lint` parity set
-- rules that only exist to catch patterns from `ember-source` 3.x and earlier are removed from `recommended`
-- two JS rules that catch patterns which are still possible today are added to `recommended`: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`
-- the `recommended-gjs` and `recommended-gts` configs are removed, because `recommended` now carries their rules, scoped per file type
+This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14).
 
-Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to the recommended sets of rules require an RFC -- this is that RFC. Planning for the release itself is tracked in [eslint-plugin-ember#2060][issue-2060].
+- The template rules that `ember-template-lint` enabled by default become enabled by default for gjs/gts files. This covers the rules that apply to strict mode. [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to this config change.
+- `recommended` stays gjs/gts only. Linting of `.hbs` files stays opt-in through `template-lint-migration`, the hbs config, which keeps the full `ember-template-lint` parity set.
+- Rules that catch patterns from `ember-source` 3.x and earlier come out of `recommended`.
+- Two JS rules go into `recommended`: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that are still possible today.
+- The `recommended-gjs` and `recommended-gts` configs are removed. `recommended` now carries their rules, scoped per file type.
+
+[eslint-plugin-ember#2158][issue-2158] requires an RFC for each change to a recommended rule set. This is that RFC. [eslint-plugin-ember#2060][issue-2060] tracks the plan for the release itself.
 
 [rfc-1214]: https://github.com/emberjs/rfcs/pull/1214
 [issue-2158]: https://github.com/ember-cli/eslint-plugin-ember/issues/2158
@@ -32,54 +34,58 @@ Per the process agreed to in [eslint-plugin-ember#2158][issue-2158], changes to
 
 ## Motivation
 
-This major has three motivations:
+This major has three motivations.
+
+1. [RFC #1214][rfc-1214] deprecates `ember-template-lint` and unifies all Ember lint rules in `eslint-plugin-ember`. `eslint-plugin-ember@13` provides every `ember-template-lint` rule as an `ember/template-*` rule[^no-partial]. None of those rules are in `recommended` yet. They stay opt-in through the `template-lint-migration` config, so that a project with both tools does not get two errors for each violation.
 
-1. [RFC #1214][rfc-1214] deprecates `ember-template-lint` and unifies all Ember lint rules in `eslint-plugin-ember`. As of `eslint-plugin-ember@13`, every `ember-template-lint` rule has been re-implemented as an `ember/template-*` rule[^no-partial], but none of them are in `recommended` yet -- they were kept opt-in (via the `template-lint-migration` config) so that folks running both tools wouldn't get two errors for every violation. With `ember-template-lint` deprecated, the template rules need to be on by default, or newly generated apps lose lint coverage they've always had -- including the A11y rules, which the Ember project has a core commitment to keeping on by default.
+   `ember-template-lint` is now deprecated, so the template rules must be on by default. If they are not, a new app loses lint coverage that every Ember app has had for years. That coverage includes the A11y rules, and the Ember project has a core commitment to those rules on by default.
 
-2. The current `recommended` set still spends time linting for patterns that cannot exist in apps on `ember-source` 4+. Some of these rules are also the most expensive rules in the set -- profiling in [eslint-plugin-ember#2060][issue-2060] showed `ember/no-implicit-injections` and `ember/no-deprecated-router-transition-methods` at ~6.2 seconds _each_ (5.9% of total lint time, each) on a large app, checking for things that were removed from ember-source years ago.
+2. The current `recommended` set spends lint time on patterns that cannot exist in an app on `ember-source` 4+. Some of those rules are also the most expensive rules in the set. Profiling in [eslint-plugin-ember#2060][issue-2060] measured `ember/no-implicit-injections` and `ember/no-deprecated-router-transition-methods` at about 6.2 seconds _each_ on a large app. Each rule is 5.9% of the total lint time. Both rules check for API that ember-source removed years ago.
 
-3. A major is the only place `recommended` can gain a rule that reports on existing code. Two such rules are ready and are held back only by the semver cost: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that are still reachable in an app on the latest `ember-source`, which is the opposite of the rules being removed in motivation 2.
+3. A major release is the only place where `recommended` can gain a rule that reports on existing code. Two such rules are ready, and only the semver cost holds them back: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that an app on the latest `ember-source` can still reach. That is the opposite of the rules that motivation 2 removes.
 
-[^no-partial]: every rule except `no-partial` -- `{{partial}}` was removed from ember-source in 4.0, so there is nothing left to lint against.
+[^no-partial]: every rule except `no-partial`. ember-source removed `{{partial}}` in 4.0, so no code is left to lint.
 
 ## Detailed design
 
 ### Add the gjs/gts-applicable template rules to `recommended`
 
-The rules from the existing [`template-lint-migration` config][migration-config] that are applicable to strict-mode templates are added to `recommended`, scoped to `**/*.{gjs,gts}`. The full list is in [Appendix A](#appendix-a-template-rules-added-to-recommended). The baseline is `ember-template-lint`'s `recommended` preset, plus `ember/template-no-template-lint-directives`, which converts leftover `{{! template-lint-disable ... }}` comments to eslint directives via `eslint --fix`.
+The rules in the [`template-lint-migration` config][migration-config] that apply to strict-mode templates go into `recommended`, scoped to `**/*.{gjs,gts}`. [Appendix A](#appendix-a-template-rules-added-to-recommended) has the full list. The baseline is the `recommended` preset of `ember-template-lint`, plus `ember/template-no-template-lint-directives`. That rule converts each leftover `{{! template-lint-disable ... }}` comment to an eslint directive through `eslint --fix`.
 
-"Applicable to strict-mode templates" excludes two groups, which stay in the hbs config only ([Appendix B](#appendix-b-loose-mode-only-rules-not-added-to-recommended)):
+Two groups of rules do not apply to strict-mode templates. Both stay in the hbs config only ([Appendix B](#appendix-b-loose-mode-only-rules-not-added-to-recommended)):
 
-- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation` -- the whole point of these rules is to prepare loose-mode templates for strict mode, and a gjs/gts file is already there. `ember-template-lint`'s own recommended preset disables both for gjs/gts.
-- rules that lint constructs which cannot be expressed in strict mode in the first place (`{{action}}`, curly `{{input}}`, `{{#with}}`, the old `{{view}}`/`{{render}}` helpers, ...). These can never fire in a gjs/gts file, so keeping them enabled would only cost lint time -- the same reasoning as the legacy JS rule removals below.
+- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation`. These two rules prepare a loose-mode template for strict mode, and a gjs/gts file is already there. The recommended preset of `ember-template-lint` also disables both for gjs/gts.
+- Rules for constructs that strict mode cannot express, such as `{{action}}`, curly `{{input}}`, `{{#with}}`, and the old `{{view}}` and `{{render}}` helpers. These rules can never report in a gjs/gts file, so they only cost lint time. This is the same reason as the legacy JS rule removals below.
 
-The `recommended` config today is gjs/gts (and js/ts) only, and that does not change -- it never touches `.hbs` files, so adding it to a project can never require also configuring an hbs parser. Newly generated apps have no `.hbs` files, so `recommended` alone gives them full lint parity with what `ember-template-lint` provided.
+`recommended` today covers gjs/gts and js/ts only, and that does not change. It never reads `.hbs` files, so a project can add it without an hbs parser. A new app has no `.hbs` files, so `recommended` alone gives that app full lint parity with `ember-template-lint`.
 
 [migration-config]: https://github.com/ember-cli/eslint-plugin-ember/blob/main/lib/config/template-lint-migration.js
 
 > [!NOTE]
-> `ember-template-lint`'s recommended preset also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint implementations don't have this problem -- they can see the whole module, so (for example) `ember/template-builtin-component-arguments` can check whether `<Input>` is actually the one from `@ember/component`, and not a local component that happens to share the name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
+> The recommended preset of `ember-template-lint` also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint rules do not have this problem, because they see the whole module. For example, `ember/template-builtin-component-arguments` can tell whether `<Input>` is the one from `@ember/component`, or a local component with the same name. Those three rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
 
 ### Add two JS rules to `recommended`
 
-Both rules already ship in the plugin as opt-in. Neither is a template rule, so both are scoped the way the rest of `recommended` is, not to `**/*.{gjs,gts}`.
+Both rules are already in the plugin as opt-in. Neither rule is a template rule, so `recommended` scopes both the way it scopes its other JS rules, not to `**/*.{gjs,gts}`.
 
 | Rule | Why it belongs in `recommended` |
 | ---- | ------------------------------- |
-| [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | native `<input>` / `<textarea>` are preferred over the classic-component `<Input>` / `<Textarea>` wrappers. Called out for the next major in [#2060][issue-2060], implemented in [#2282][pr-2282] |
-| [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | a modifier that never references its element is an effect scheduled by render. That is the data flow this RFC's `recommended` set already rejects in templates via `ember/template-no-at-ember-render-modifiers`, and it is just as available through `ember-modifier` directly |
+| [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | A native `<input>` or `<textarea>` is better than the classic-component `<Input>` or `<Textarea>` wrapper. Named for the next major in [#2060][issue-2060], and implemented in [#2282][pr-2282] |
+| [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | A modifier that never reads its element is an effect that render schedules. The `recommended` set in this RFC already rejects that data flow in templates, through `ember/template-no-at-ember-render-modifiers`. `ember-modifier` makes the same pattern just as available |
 
-`ember/no-modifier-without-element-usage` covers both modifier styles: the `element` parameter of a `modifier()` callback, and `modify(element)` or `this.element` in a class modifier. Any reference counts, so passing the element to a chart library or a `ResizeObserver` is fine. What it catches is the modifier that exists only to run code at render time, which brings the problems that [`ember/no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-at-ember-render-modifiers.md) documents: extra renders, render loops, and behavior separated from the data it depends on. Those problems do not come from `@ember/render-modifiers` as a package, so a rule that only bans that import leaves the pattern reachable with three lines of `ember-modifier`.
+`ember/no-modifier-without-element-usage` covers both modifier styles. It reads the `element` parameter of a `modifier()` callback, and `modify(element)` or `this.element` in a class modifier. Any reference counts, so a modifier can pass its element to a chart library or to a `ResizeObserver`.
+
+The rule catches the modifier that exists only to run code at render time. [`ember/no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-at-ember-render-modifiers.md) documents the problems of that pattern: extra renders, render loops, and behavior that sits apart from the data it depends on. Those problems do not come from the `@ember/render-modifiers` package. A rule that bans one import leaves the pattern three lines of `ember-modifier` away.
 
 [pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
 
 ### Remove the `recommended-gjs` and `recommended-gts` configs
 
-`recommended` now carries the gjs and gts rules itself, in blocks scoped by `files`. Both extra configs became redundant, so v14 removes them.
+`recommended` now carries the gjs and gts rules itself, in blocks that `files` scopes. Both extra configs are redundant, so v14 removes them.
 
-`recommended-gts` also did one thing that `recommended` did not. It turned off the core rules that TypeScript already reports, and turned on the four that TypeScript makes better (`no-var`, `prefer-const`, `prefer-rest-params`, `prefer-spread`). That set comes from the `eslint-recommended` config of typescript-eslint. `recommended` now applies it to `**/*.gts`.
+`recommended-gts` did one more thing. It turned off the core rules that TypeScript already reports. It also turned on the four rules that TypeScript makes better: `no-var`, `prefer-const`, `prefer-rest-params`, and `prefer-spread`. That set comes from the `eslint-recommended` config of typescript-eslint. `recommended` now applies it to `**/*.gts`.
 
-The result is one config instead of three:
+The result is one config in place of three:
 
 ```js
 // eslint.config.mjs
@@ -91,11 +97,11 @@ export default [
 ];
 ```
 
-An app that extends `plugin:ember/recommended-gjs` or `plugin:ember/recommended-gts` deletes those two lines. Every rule they set is in `recommended` already.
+An app that extends `plugin:ember/recommended-gjs` or `plugin:ember/recommended-gts` deletes those two lines. `recommended` sets every rule that they set.
 
 ### Linting `.hbs` files stays opt-in
 
-Existing apps with loose-mode templates opt in with the hbs config -- the [`template-lint-migration` config][migration-config], which keeps the _full_ `ember-template-lint` parity set (including the loose-mode-only rules that don't move to `recommended`) -- plus a parser block routing `.hbs` files to the hbs parser that `eslint-plugin-ember` already ships (via `ember-eslint-parser/hbs`):
+An app with loose-mode templates opts in with the hbs config. That config is [`template-lint-migration`][migration-config]. It keeps the _full_ `ember-template-lint` parity set, and that set includes the loose-mode-only rules that stay out of `recommended`. The app also needs a parser block that routes `.hbs` files to the hbs parser. `eslint-plugin-ember` already ships that parser as `ember-eslint-parser/hbs`.
 
 ```js
 // eslint.config.mjs
@@ -114,35 +120,35 @@ export default [
 ```
 
 > [!IMPORTANT]
-> If a config has a `@typescript-eslint/parser` block with a broad `files` glob, that glob must be narrowed to `['**/*.{js,ts,gjs,gts}']` so it doesn't try to parse `.hbs` files -- flat config merges every matching block, and type-aware rules will error on non-JS files.
+> If a config has a `@typescript-eslint/parser` block with a broad `files` glob, narrow that glob to `['**/*.{js,ts,gjs,gts}']`. Flat config merges every block that matches a file, and a type-aware rule reports an error on a file that is not JS.
 
-This config block is documented in the migration guide required by [RFC #1214][rfc-1214], and does not go in the app blueprint -- newly generated apps have no `.hbs` files.
+The migration guide that [RFC #1214][rfc-1214] requires documents this config block. The block does not go in the app blueprint, because a new app has no `.hbs` files.
 
 ### Remove legacy rules from `recommended`
 
-The following rules are removed from `recommended`. They lint against APIs that no longer exist in `ember-source` 4+, so on any app that can actually install `eslint-plugin-ember@14` they can never fire -- they only cost lint time.
+The rules in the table below come out of `recommended`. Each rule lints for API that `ember-source` 4+ does not have. No app that can install `eslint-plugin-ember@14` can trigger them, so they only cost lint time.
 
-| Rule | Why it's no longer needed |
-| ---- | ------------------------- |
-| `ember/no-implicit-injections` | implicit injections don't exist in ember-source 4+ ([RFC #0680](https://github.com/emberjs/rfcs/blob/master/text/0680-implicit-injection-deprecation.md)); one of the two most expensive rules in the set |
-| `ember/no-deprecated-router-transition-methods` | the deprecated transition methods were removed in 4.0; the other most expensive rule |
-| `ember/avoid-using-needs-in-controllers` | `needs` was removed before 3.x |
-| `ember/routes-segments-snake-case` | the rule's motivation was the implicit route model, which is deprecated ([RFC #0774](https://github.com/emberjs/rfcs/blob/master/text/0774-implicit-record-route-loading.md)); raised in [#2060][issue-2060] |
+| Rule | Why it is no longer necessary |
+| ---- | ----------------------------- |
+| `ember/no-implicit-injections` | implicit injections do not exist in ember-source 4+ ([RFC #0680](https://github.com/emberjs/rfcs/blob/master/text/0680-implicit-injection-deprecation.md)). One of the two most expensive rules in the set |
+| `ember/no-deprecated-router-transition-methods` | 4.0 removed the deprecated transition methods. The other most expensive rule |
+| `ember/avoid-using-needs-in-controllers` | ember-source removed `needs` before 3.x |
+| `ember/routes-segments-snake-case` | the motivation for this rule was the implicit route model, which is deprecated ([RFC #0774](https://github.com/emberjs/rfcs/blob/master/text/0774-implicit-record-route-loading.md)). Raised in [#2060][issue-2060] |
 | `ember/no-deeply-nested-dependent-keys-with-each` | computed-property era ([#1950][issue-1950]) |
-| `ember/no-volatile-computed-properties` | `.volatile()` was removed in 4.0 |
+| `ember/no-volatile-computed-properties` | 4.0 removed `.volatile()` |
 | `ember/closure-actions` | 3.x-era invocation style |
-| `ember/no-function-prototype-extensions` | prototype extensions were removed in 4.0 |
+| `ember/no-function-prototype-extensions` | 4.0 removed prototype extensions |
 | `ember/no-old-shims` | ember-cli-shims era |
-| `ember/no-string-prototype-extensions` | prototype extensions were removed in 4.0 |
-| `ember/no-get-with-default` | `getWithDefault` was removed in 4.0 |
-| `ember/no-try-invoke` | `tryInvoke` was removed in 4.0 |
-| `ember/no-test-module-for` | `moduleFor*` was removed from ember-qunit long ago |
-| `ember/require-fetch-import` | `ember-fetch` is removed from the blueprint ([RFC #1065](https://github.com/emberjs/rfcs/blob/master/text/1065-remove-ember-fetch.md)); see [#1224][issue-1224] |
+| `ember/no-string-prototype-extensions` | 4.0 removed prototype extensions |
+| `ember/no-get-with-default` | 4.0 removed `getWithDefault` |
+| `ember/no-try-invoke` | 4.0 removed `tryInvoke` |
+| `ember/no-test-module-for` | ember-qunit removed `moduleFor*` long ago |
+| `ember/require-fetch-import` | the blueprint no longer has `ember-fetch` ([RFC #1065](https://github.com/emberjs/rfcs/blob/master/text/1065-remove-ember-fetch.md)). See [#1224][issue-1224] |
 
 [issue-1950]: https://github.com/ember-cli/eslint-plugin-ember/issues/1950
 [issue-1224]: https://github.com/ember-cli/eslint-plugin-ember/issues/1224
 
-None of these rules are deleted from the plugin -- they just come out of `recommended`. Apps still working through an older ember-source can re-enable them in their own config:
+The plugin keeps all of these rules. They only come out of `recommended`. An app that still supports an older ember-source can turn them on again in its own config:
 
 ```js
 export default [
@@ -156,68 +162,70 @@ export default [
 ];
 ```
 
-or simply stay on `eslint-plugin-ember@13` until they're on ember-source 4+.
+That app can also stay on `eslint-plugin-ember@13` until it is on ember-source 4+.
 
 > [!NOTE]
-> There is a second group of rules that lint against `@ember/component`-era patterns (`ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, `ember/no-classic-components`). Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates once `@ember/component` is deprecated (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
+> A second group of rules lints for `@ember/component`-era patterns: `ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, and `ember/no-classic-components`. Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates after the deprecation of `@ember/component` (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
 
 ### What happens to `template-lint-migration`
 
-The config stays, permanently: it is what folks who still have `.hbs` files should use. It keeps the full `ember-template-lint` parity set, so hbs coverage is identical before and after this major, and the [RFC #1214][rfc-1214] migration guide is written around it.
+The config stays, permanently. An app that still has `.hbs` files uses it. It keeps the full `ember-template-lint` parity set, so hbs coverage is the same before and after this major. The migration guide from [RFC #1214][rfc-1214] is written around it.
 
-Since it's not really a _migration_ config anymore, v14 should rename it to `hbs` (keeping `template-lint-migration` as an alias for the deprecation window) so that its long-term purpose is reflected in its name.
+This config is no longer a _migration_ config, so v14 renames it to `hbs`. The name `template-lint-migration` stays as an alias for the deprecation window. The new name states the long-term purpose of the config.
 
 ### Other breaking changes
 
-[#2060][issue-2060] also tracks routine breaking changes for the release (dropping EOL node versions, matching eslint's supported version ranges, config export cleanup). Those don't change what is linted, so they don't need an RFC and aren't specified here -- this RFC is only about the `recommended` rule set. The two config removals above are the exception: they are specified here because folding the typescript-eslint disables into `recommended` changes what is linted in a gts file.
+[#2060][issue-2060] also tracks routine breaking changes for the release. The plugin drops EOL node versions, matches the supported version range of eslint, and cleans up its config exports. Those changes do not change what the plugin lints, so they need no RFC and are not specified here. This RFC covers the `recommended` rule set.
+
+The two config removals above are the exception. This RFC specifies them, because the typescript-eslint disables move into `recommended` and change what the plugin lints in a gts file.
 
 ## How we teach this
 
-Most of the teaching work is already required by [RFC #1214][rfc-1214]: the migration guide from `ember-template-lint` covers the `.hbs` parser block, the directive conversion (`template-lint-disable` → `eslint-disable-next-line`), and moving custom rule overrides from `.template-lintrc.js` into `eslint.config.mjs`.
+[RFC #1214][rfc-1214] already requires most of the teaching work. Its migration guide from `ember-template-lint` covers the `.hbs` parser block and the directive conversion (`template-lint-disable` → `eslint-disable-next-line`). The guide also covers the move of custom rule overrides from `.template-lintrc.js` into `eslint.config.mjs`.
 
 For the v14 upgrade itself:
 
-- Newly generated apps just get the new config from the blueprint. No teaching needed.
-- Existing apps upgrading to v14 will see new errors in their gjs/gts files, and in js/ts files from the two added JS rules. The release notes should point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future) for adopting the new rules incrementally instead of fixing everything in one PR. (This replaces the `lint-todo` workflow from `ember-template-lint`, per RFC #1214.)
-- Apps with `.hbs` files opt in to hbs linting via the hbs config -- that's a migration-from-`ember-template-lint` task (covered by RFC #1214's migration guide), not a v14-upgrade task.
-- Apps that were already using the `template-lint-migration` config see no new template errors at all -- v14 is a no-op for them.
+- A new app gets the new config from the blueprint. It needs no teaching.
+- An existing app sees new errors in its gjs/gts files after the upgrade. The two added JS rules also report new errors in js/ts files. The release notes point at [eslint bulk suppressions](https://eslint.org/blog/2025/04/introducing-bulk-suppressions/) and [Lint to the Future](https://github.com/mansona/lint-to-the-future). Both let a team adopt the new rules one part at a time, in place of one large PR. This replaces the `lint-todo` workflow of `ember-template-lint`, per RFC #1214.
+- An app with `.hbs` files opts in to hbs linting with the hbs config. That is a task for the migration from `ember-template-lint`, which the RFC #1214 guide covers. It is not a v14 upgrade task.
+- An app that already uses the `template-lint-migration` config sees no new template errors. For that app, v14 is a no-op.
 
 ## Drawbacks
 
-- Existing apps get a bunch of new lint errors on upgrade. That's the point of the major (per RFC #1214), and bulk suppressions exist so that nobody has to fix them all in one PR.
-- `ember/no-modifier-without-element-usage` has no autofix, and clearing a violation is a refactor rather than a rename: the behavior moves to derived state, a resource, or an event handler on the element that already triggers it. Apps that used modifiers as render hooks will want bulk suppressions for this rule while they work through it.
-- Apps still supporting ember-source 3.x silently lose coverage for the removed rules unless they re-enable them. The release notes and the changelog entry for each removed rule cover this -- and staying on v13 is always an option, since nothing about v13 stops working.
+- An existing app gets many new lint errors after the upgrade. That is the purpose of the major, per RFC #1214. Bulk suppressions exist, so no team has to correct every error in one PR.
+- `ember/no-modifier-without-element-usage` has no autofix. To clear a report, a team refactors the modifier. The behavior moves to derived state, to a resource, or to an event handler on the element that already triggers it. An app that used modifiers as render hooks can suppress this rule in bulk while it works through them.
+- An app that still supports ember-source 3.x loses the coverage of the removed rules, unless it turns them on again. The release notes and the changelog entry for each removed rule state this. An app can also stay on v13, because nothing in v13 stops working.
 
 ## Alternatives
 
 ### Keep the template rules opt-in
 
-This contradicts RFC #1214 -- newly generated apps would ship without the default lint coverage (including A11y coverage) that every Ember app has had for years.
+This contradicts RFC #1214. A new app then ships without the default lint coverage that every Ember app has had for years, and that coverage includes A11y.
 
 ### Enable only the A11y subset by default
 
-Preserves the A11y commitment with fewer new errors, but breaks parity with what `ember-template-lint` users have today, and makes "did I migrate correctly?" harder to answer. Parity is easier to explain: same rules, one tool.
+This keeps the A11y commitment and creates fewer new errors. It also breaks parity with what an `ember-template-lint` user has today, and it makes the question "did I migrate correctly?" harder to answer. Parity is easier to explain: the same rules, one tool.
 
 ### Ship a `legacy` config with the removed rules
 
-[#1950][issue-1950] proposed this. It's another config to name, document, and maintain, for a set of apps that shrinks every year -- and those apps already have two options: stay on v13, or re-enable the handful of rules they still want in their own config. Not worth maintaining.
+[#1950][issue-1950] proposed this. It is one more config to name, to document, and to maintain, for a set of apps that gets smaller every year. Those apps already have two options. They can stay on v13, or they can turn on the few rules they still want in their own config. The cost of maintenance is too high for that result.
 
 ### Keep `ember/no-modifier-without-element-usage` opt-in and rely on `ember/no-at-ember-render-modifiers`
 
-`ember/no-at-ember-render-modifiers` is already in `recommended`, so the argument is that the pattern is covered. It is not: that rule bans an import, and the same effect-on-render pattern is available by writing the modifier by hand. An app that removes `@ember/render-modifiers` by reimplementing `{{did-insert}}` locally passes today's `recommended` set.
+`ember/no-at-ember-render-modifiers` is already in `recommended`, so the argument is that it covers the pattern. It does not. That rule bans an import, and a hand-written modifier reaches the same effect-on-render pattern. An app that removes `@ember/render-modifiers` and reimplements `{{did-insert}}` locally passes the `recommended` set of today.
 
 ### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
-Then `recommended` would blow up for anyone with `.hbs` files who hasn't configured the hbs parser. Keeping `recommended` gjs/gts-only means it works without any parser setup, and hbs linting stays opt-in.
+`recommended` then tries to lint `.hbs` files. An app without an hbs parser gets a parse error for each one. A gjs/gts-only `recommended` works with no parser setup, and hbs linting stays opt-in.
 
 ## Unresolved questions
 
-- The Appendix A / Appendix B split is a best guess -- during implementation, each rule should be checked against what strict mode can actually express (some loose-mode constructs, like `{{unbound}}` or `{{mut}}`, are still keywords in strict mode, so their rules stay in Appendix A). Rules that end up in the wrong list move without re-RFCing.
-- Should `ember/template-no-bare-strings` (off by default in `ember-template-lint`, off by default here) get any special mention in the migration guide for i18n-heavy apps? (Leaning yes, but it's a docs question, not a config question.)
+- The split between Appendix A and Appendix B is a best guess. During implementation, each rule must be checked against what strict mode can express. Some loose-mode constructs, such as `{{unbound}}` and `{{mut}}`, are still keywords in strict mode, so their rules stay in Appendix A. A rule in the wrong list moves without a new RFC.
+- Does `ember/template-no-bare-strings` need a special mention in the migration guide, for an app with heavy i18n? The rule is off by default in `ember-template-lint`, and off by default here. This is a docs question, not a config question.
 
 ## Appendix A: template rules added to `recommended`
 
-87 rules, at `error`, scoped to `**/*.{gjs,gts}`. This is the `template-lint-migration` rule set (`ember-template-lint`'s recommended preset -- minus `no-partial`, which has no equivalent because `{{partial}}` no longer exists -- plus `template-no-template-lint-directives`) with the loose-mode-only rules from Appendix B taken out.
+87 rules, at `error`, scoped to `**/*.{gjs,gts}`. This is the `template-lint-migration` rule set without the loose-mode-only rules of Appendix B. That set is the recommended preset of `ember-template-lint`, minus `no-partial`, plus `template-no-template-lint-directives`. `no-partial` has no equivalent, because `{{partial}}` no longer exists.
 
 - [`ember/template-builtin-component-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-builtin-component-arguments.md)
 - [`ember/template-link-href-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-link-href-attributes.md)
@@ -309,16 +317,16 @@ Then `recommended` would blow up for anyone with `.hbs` files who hasn't configu
 
 ## Appendix B: loose-mode-only rules, not added to `recommended`
 
-These 9 rules stay in the hbs config (`template-lint-migration`), keeping full `ember-template-lint` parity for `.hbs` files.
+These 9 rules stay in the hbs config, `template-lint-migration`. They keep full `ember-template-lint` parity for `.hbs` files.
 
-| Rule | Why it doesn't apply to gjs/gts |
+| Rule | Why it does not apply to gjs/gts |
 | ---- | ------------------------------- |
-| [`ember/template-no-implicit-this`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-implicit-this.md) | strict mode has no implicit `this` -- an unresolved reference is a build error |
-| [`ember/template-no-curly-component-invocation`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-curly-component-invocation.md) | the component-or-property ambiguity doesn't exist in strict mode |
+| [`ember/template-no-implicit-this`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-implicit-this.md) | strict mode has no implicit `this`. An unresolved reference is a build error |
+| [`ember/template-no-curly-component-invocation`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-curly-component-invocation.md) | strict mode has no component-or-property ambiguity |
 | [`ember/template-no-action`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-action.md) | `{{action}}` has no strict-mode import |
 | [`ember/template-no-route-action`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-route-action.md) | `{{route-action}}` has no strict-mode import |
 | [`ember/template-no-input-block`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-input-block.md) | curly `{{input}}` cannot resolve in strict mode |
 | [`ember/template-no-input-tagname`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-input-tagname.md) | curly `{{input}}` cannot resolve in strict mode |
-| [`ember/template-no-with`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-with.md) | `{{#with}}` was removed in ember-source 4.0 and cannot be expressed in strict mode |
-| [`ember/template-deprecated-render-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-render-helper.md) | `{{render}}` is long gone and cannot be expressed in strict mode |
-| [`ember/template-deprecated-inline-view-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-inline-view-helper.md) | `{{view}}` is long gone and cannot be expressed in strict mode |
+| [`ember/template-no-with`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-with.md) | ember-source removed `{{#with}}` in 4.0, and strict mode cannot express it |
+| [`ember/template-deprecated-render-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-render-helper.md) | `{{render}}` is long gone, and strict mode cannot express it |
+| [`ember/template-deprecated-inline-view-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-inline-view-helper.md) | `{{view}}` is long gone, and strict mode cannot express it |

From 61e053027e1d75a53efcf398bf1186d6e6e088c1 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:26:44 -0400
Subject: [PATCH 09/16] Apply suggestion from @NullVoxPopuli

---
 text/1217-eslint-plugin-ember-next-major.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 1d8db8d673..5ae8b06e91 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -23,7 +23,7 @@ This RFC defines the `recommended` config for the next major of `eslint-plugin-e
 - The template rules that `ember-template-lint` enabled by default become enabled by default for gjs/gts files. This covers the rules that apply to strict mode. [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to this config change.
 - `recommended` stays gjs/gts only. Linting of `.hbs` files stays opt-in through `template-lint-migration`, the hbs config, which keeps the full `ember-template-lint` parity set.
 - Rules that catch patterns from `ember-source` 3.x and earlier come out of `recommended`.
-- Two JS rules go into `recommended`: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that are still possible today.
+- A number of other recommended rule changes (see appendices)
 - The `recommended-gjs` and `recommended-gts` configs are removed. `recommended` now carries their rules, scoped per file type.
 
 [eslint-plugin-ember#2158][issue-2158] requires an RFC for each change to a recommended rule set. This is that RFC. [eslint-plugin-ember#2060][issue-2060] tracks the plan for the release itself.

From a85f59949d837cd15bf8227ee2b54ae325442844 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:36:54 -0400
Subject: [PATCH 10/16] Move every rule name into the appendices

The body now describes policy and points at the lists. New Appendix C for
the two added JS rules, new Appendix D for the removed rules.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 107 ++++++++++----------
 1 file changed, 55 insertions(+), 52 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 5ae8b06e91..782ed4e0e0 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -40,50 +40,39 @@ This major has three motivations.
 
    `ember-template-lint` is now deprecated, so the template rules must be on by default. If they are not, a new app loses lint coverage that every Ember app has had for years. That coverage includes the A11y rules, and the Ember project has a core commitment to those rules on by default.
 
-2. The current `recommended` set spends lint time on patterns that cannot exist in an app on `ember-source` 4+. Some of those rules are also the most expensive rules in the set. Profiling in [eslint-plugin-ember#2060][issue-2060] measured `ember/no-implicit-injections` and `ember/no-deprecated-router-transition-methods` at about 6.2 seconds _each_ on a large app. Each rule is 5.9% of the total lint time. Both rules check for API that ember-source removed years ago.
+2. The current `recommended` set spends lint time on patterns that cannot exist in an app on `ember-source` 4+. Some of those rules are also the most expensive rules in the set. Profiling in [eslint-plugin-ember#2060][issue-2060] measured the two most expensive at about 6.2 seconds _each_ on a large app. Each of the two is 5.9% of the total lint time. Both check for API that ember-source removed years ago.
 
-3. A major release is the only place where `recommended` can gain a rule that reports on existing code. Two such rules are ready, and only the semver cost holds them back: `ember/no-builtin-form-components` and `ember/no-modifier-without-element-usage`. Both catch patterns that an app on the latest `ember-source` can still reach. That is the opposite of the rules that motivation 2 removes.
+3. A major release is the only place where `recommended` can gain a rule that reports on existing code. Two such rules are ready, and only the semver cost holds them back. Both catch patterns that an app on the latest `ember-source` can still reach. That is the opposite of the rules that motivation 2 removes.
 
-[^no-partial]: every rule except `no-partial`. ember-source removed `{{partial}}` in 4.0, so no code is left to lint.
+[^no-partial]: every rule except the one for `{{partial}}`. ember-source removed `{{partial}}` in 4.0, so no code is left to lint.
 
 ## Detailed design
 
-### Add the gjs/gts-applicable template rules to `recommended`
+### Add the strict-mode template rules to `recommended`
 
-The rules in the [`template-lint-migration` config][migration-config] that apply to strict-mode templates go into `recommended`, scoped to `**/*.{gjs,gts}`. [Appendix A](#appendix-a-template-rules-added-to-recommended) has the full list. The baseline is the `recommended` preset of `ember-template-lint`, plus `ember/template-no-template-lint-directives`. That rule converts each leftover `{{! template-lint-disable ... }}` comment to an eslint directive through `eslint --fix`.
+The rules in the [`template-lint-migration` config][migration-config] that apply to strict-mode templates go into `recommended`, scoped to `**/*.{gjs,gts}`. [Appendix A](#appendix-a-template-rules-added-to-recommended) has the full list. The baseline is the `recommended` preset of `ember-template-lint`, plus one rule that converts each leftover `{{! template-lint-disable ... }}` comment to an eslint directive through `eslint --fix`.
 
 Two groups of rules do not apply to strict-mode templates. Both stay in the hbs config only ([Appendix B](#appendix-b-loose-mode-only-rules-not-added-to-recommended)):
 
-- `ember/template-no-implicit-this` and `ember/template-no-curly-component-invocation`. These two rules prepare a loose-mode template for strict mode, and a gjs/gts file is already there. The recommended preset of `ember-template-lint` also disables both for gjs/gts.
-- Rules for constructs that strict mode cannot express, such as `{{action}}`, curly `{{input}}`, `{{#with}}`, and the old `{{view}}` and `{{render}}` helpers. These rules can never report in a gjs/gts file, so they only cost lint time. This is the same reason as the legacy JS rule removals below.
+- Rules that prepare a loose-mode template for strict mode. A gjs/gts file is already there, and the recommended preset of `ember-template-lint` also disables these rules for gjs/gts.
+- Rules for constructs that strict mode cannot express, such as `{{action}}`, curly `{{input}}`, and `{{#with}}`. These rules can never report in a gjs/gts file, so they only cost lint time.
 
 `recommended` today covers gjs/gts and js/ts only, and that does not change. It never reads `.hbs` files, so a project can add it without an hbs parser. A new app has no `.hbs` files, so `recommended` alone gives that app full lint parity with `ember-template-lint`.
 
 [migration-config]: https://github.com/ember-cli/eslint-plugin-ember/blob/main/lib/config/template-lint-migration.js
 
 > [!NOTE]
-> The recommended preset of `ember-template-lint` also had to disable `builtin-component-arguments`, `no-builtin-form-components`, and `no-unknown-arguments-for-builtin-components` for gjs/gts, because it has no knowledge of imports. The eslint rules do not have this problem, because they see the whole module. For example, `ember/template-builtin-component-arguments` can tell whether `<Input>` is the one from `@ember/component`, or a local component with the same name. Those three rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
+> The recommended preset of `ember-template-lint` had to disable its builtin-component rules for gjs/gts, because it has no knowledge of imports. The eslint versions see the whole module. They can tell whether `<Input>` is the one from `@ember/component`, or a local component with the same name. Those rules _do_ move to `recommended`. This is one of the motivations of [RFC #1214][rfc-1214].
 
 ### Add two JS rules to `recommended`
 
-Both rules are already in the plugin as opt-in. Neither rule is a template rule, so `recommended` scopes both the way it scopes its other JS rules, not to `**/*.{gjs,gts}`.
-
-| Rule | Why it belongs in `recommended` |
-| ---- | ------------------------------- |
-| [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | A native `<input>` or `<textarea>` is better than the classic-component `<Input>` or `<Textarea>` wrapper. Named for the next major in [#2060][issue-2060], and implemented in [#2282][pr-2282] |
-| [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | A modifier that never reads its element is an effect that render schedules. The `recommended` set in this RFC already rejects that data flow in templates, through `ember/template-no-at-ember-render-modifiers`. `ember-modifier` makes the same pattern just as available |
-
-`ember/no-modifier-without-element-usage` covers both modifier styles. It reads the `element` parameter of a `modifier()` callback, and `modify(element)` or `this.element` in a class modifier. Any reference counts, so a modifier can pass its element to a chart library or to a `ResizeObserver`.
-
-The rule catches the modifier that exists only to run code at render time. [`ember/no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-at-ember-render-modifiers.md) documents the problems of that pattern: extra renders, render loops, and behavior that sits apart from the data it depends on. Those problems do not come from the `@ember/render-modifiers` package. A rule that bans one import leaves the pattern three lines of `ember-modifier` away.
-
-[pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
+Two JS rules go into `recommended`. Both are already in the plugin as opt-in. Neither one is a template rule, so `recommended` scopes both the way it scopes its other JS rules, not to `**/*.{gjs,gts}`. [Appendix C](#appendix-c-js-rules-added-to-recommended) has both, with the reason for each.
 
 ### Remove the `recommended-gjs` and `recommended-gts` configs
 
 `recommended` now carries the gjs and gts rules itself, in blocks that `files` scopes. Both extra configs are redundant, so v14 removes them.
 
-`recommended-gts` did one more thing. It turned off the core rules that TypeScript already reports. It also turned on the four rules that TypeScript makes better: `no-var`, `prefer-const`, `prefer-rest-params`, and `prefer-spread`. That set comes from the `eslint-recommended` config of typescript-eslint. `recommended` now applies it to `**/*.gts`.
+`recommended-gts` did one more thing. It turned off the core rules that TypeScript already reports, and it turned on the four that TypeScript makes better. That set comes from the `eslint-recommended` config of typescript-eslint. `recommended` now applies it to `**/*.gts`.
 
 The result is one config in place of three:
 
@@ -126,37 +115,16 @@ The migration guide that [RFC #1214][rfc-1214] requires documents this config bl
 
 ### Remove legacy rules from `recommended`
 
-The rules in the table below come out of `recommended`. Each rule lints for API that `ember-source` 4+ does not have. No app that can install `eslint-plugin-ember@14` can trigger them, so they only cost lint time.
-
-| Rule | Why it is no longer necessary |
-| ---- | ----------------------------- |
-| `ember/no-implicit-injections` | implicit injections do not exist in ember-source 4+ ([RFC #0680](https://github.com/emberjs/rfcs/blob/master/text/0680-implicit-injection-deprecation.md)). One of the two most expensive rules in the set |
-| `ember/no-deprecated-router-transition-methods` | 4.0 removed the deprecated transition methods. The other most expensive rule |
-| `ember/avoid-using-needs-in-controllers` | ember-source removed `needs` before 3.x |
-| `ember/routes-segments-snake-case` | the motivation for this rule was the implicit route model, which is deprecated ([RFC #0774](https://github.com/emberjs/rfcs/blob/master/text/0774-implicit-record-route-loading.md)). Raised in [#2060][issue-2060] |
-| `ember/no-deeply-nested-dependent-keys-with-each` | computed-property era ([#1950][issue-1950]) |
-| `ember/no-volatile-computed-properties` | 4.0 removed `.volatile()` |
-| `ember/closure-actions` | 3.x-era invocation style |
-| `ember/no-function-prototype-extensions` | 4.0 removed prototype extensions |
-| `ember/no-old-shims` | ember-cli-shims era |
-| `ember/no-string-prototype-extensions` | 4.0 removed prototype extensions |
-| `ember/no-get-with-default` | 4.0 removed `getWithDefault` |
-| `ember/no-try-invoke` | 4.0 removed `tryInvoke` |
-| `ember/no-test-module-for` | ember-qunit removed `moduleFor*` long ago |
-| `ember/require-fetch-import` | the blueprint no longer has `ember-fetch` ([RFC #1065](https://github.com/emberjs/rfcs/blob/master/text/1065-remove-ember-fetch.md)). See [#1224][issue-1224] |
-
-[issue-1950]: https://github.com/ember-cli/eslint-plugin-ember/issues/1950
-[issue-1224]: https://github.com/ember-cli/eslint-plugin-ember/issues/1224
+[Appendix D](#appendix-d-rules-removed-from-recommended) lists the rules that come out of `recommended`. Each one lints for API that `ember-source` 4+ does not have. No app that can install `eslint-plugin-ember@14` can trigger them, so they only cost lint time.
 
-The plugin keeps all of these rules. They only come out of `recommended`. An app that still supports an older ember-source can turn them on again in its own config:
+The plugin keeps every one of these rules. They only come out of `recommended`. An app that still supports an older ember-source can turn them on again in its own config:
 
 ```js
 export default [
   ...emberRecommended,
   {
     rules: {
-      'ember/no-get-with-default': 'error',
-      // ...whichever of the removed rules still apply
+      // whichever of the removed rules still apply
     },
   },
 ];
@@ -164,9 +132,6 @@ export default [
 
 That app can also stay on `eslint-plugin-ember@13` until it is on ember-source 4+.
 
-> [!NOTE]
-> A second group of rules lints for `@ember/component`-era patterns: `ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, and `ember/no-classic-components`. Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates after the deprecation of `@ember/component` (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).
-
 ### What happens to `template-lint-migration`
 
 The config stays, permanently. An app that still has `.hbs` files uses it. It keeps the full `ember-template-lint` parity set, so hbs coverage is the same before and after this major. The migration guide from [RFC #1214][rfc-1214] is written around it.
@@ -193,7 +158,7 @@ For the v14 upgrade itself:
 ## Drawbacks
 
 - An existing app gets many new lint errors after the upgrade. That is the purpose of the major, per RFC #1214. Bulk suppressions exist, so no team has to correct every error in one PR.
-- `ember/no-modifier-without-element-usage` has no autofix. To clear a report, a team refactors the modifier. The behavior moves to derived state, to a resource, or to an event handler on the element that already triggers it. An app that used modifiers as render hooks can suppress this rule in bulk while it works through them.
+- Neither added JS rule has an autofix, so a report means a refactor and not a rename. An app can suppress both rules in bulk while it works through them.
 - An app that still supports ember-source 3.x loses the coverage of the removed rules, unless it turns them on again. The release notes and the changelog entry for each removed rule state this. An app can also stay on v13, because nothing in v13 stops working.
 
 ## Alternatives
@@ -210,9 +175,9 @@ This keeps the A11y commitment and creates fewer new errors. It also breaks pari
 
 [#1950][issue-1950] proposed this. It is one more config to name, to document, and to maintain, for a set of apps that gets smaller every year. Those apps already have two options. They can stay on v13, or they can turn on the few rules they still want in their own config. The cost of maintenance is too high for that result.
 
-### Keep `ember/no-modifier-without-element-usage` opt-in and rely on `ember/no-at-ember-render-modifiers`
+### Keep the two new JS rules opt-in
 
-`ember/no-at-ember-render-modifiers` is already in `recommended`, so the argument is that it covers the pattern. It does not. That rule bans an import, and a hand-written modifier reaches the same effect-on-render pattern. An app that removes `@ember/render-modifiers` and reimplements `{{did-insert}}` locally passes the `recommended` set of today.
+A rule that is already in `recommended` bans one import for the same pattern as one of the two new rules. That ban is not enough, because hand-written code reaches the same pattern without that import. [Appendix C](#appendix-c-js-rules-added-to-recommended) has the detail.
 
 ### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
@@ -221,7 +186,7 @@ This keeps the A11y commitment and creates fewer new errors. It also breaks pari
 ## Unresolved questions
 
 - The split between Appendix A and Appendix B is a best guess. During implementation, each rule must be checked against what strict mode can express. Some loose-mode constructs, such as `{{unbound}}` and `{{mut}}`, are still keywords in strict mode, so their rules stay in Appendix A. A rule in the wrong list moves without a new RFC.
-- Does `ember/template-no-bare-strings` need a special mention in the migration guide, for an app with heavy i18n? The rule is off by default in `ember-template-lint`, and off by default here. This is a docs question, not a config question.
+- The rule for bare strings in templates is off by default in `ember-template-lint`, and it stays off here. Does the migration guide need a special note about it, for an app with heavy i18n? This is a docs question, not a config question.
 
 ## Appendix A: template rules added to `recommended`
 
@@ -330,3 +295,41 @@ These 9 rules stay in the hbs config, `template-lint-migration`. They keep full
 | [`ember/template-no-with`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-no-with.md) | ember-source removed `{{#with}}` in 4.0, and strict mode cannot express it |
 | [`ember/template-deprecated-render-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-render-helper.md) | `{{render}}` is long gone, and strict mode cannot express it |
 | [`ember/template-deprecated-inline-view-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-inline-view-helper.md) | `{{view}}` is long gone, and strict mode cannot express it |
+
+## Appendix C: JS rules added to `recommended`
+
+Both rules are in the plugin today as opt-in.
+
+| Rule | Why it belongs in `recommended` |
+| ---- | ------------------------------- |
+| [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | A native `<input>` or `<textarea>` is better than the classic-component `<Input>` or `<Textarea>` wrapper. Named for the next major in [#2060][issue-2060], and implemented in [#2282][pr-2282] |
+| [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | A modifier that never reads its element is an effect that render schedules. `ember/template-no-at-ember-render-modifiers` already rejects that data flow in a template, and it is in `recommended` today. That rule bans one import, and `ember-modifier` reaches the same pattern in three lines |
+
+[pr-2282]: https://github.com/ember-cli/eslint-plugin-ember/pull/2282
+
+## Appendix D: rules removed from `recommended`
+
+The plugin keeps each of these rules. They only come out of `recommended`.
+
+| Rule | Why it is no longer necessary |
+| ---- | ----------------------------- |
+| `ember/no-implicit-injections` | implicit injections do not exist in ember-source 4+ ([RFC #0680](https://github.com/emberjs/rfcs/blob/master/text/0680-implicit-injection-deprecation.md)). One of the two most expensive rules in the set |
+| `ember/no-deprecated-router-transition-methods` | 4.0 removed the deprecated transition methods. The other most expensive rule |
+| `ember/avoid-using-needs-in-controllers` | ember-source removed `needs` before 3.x |
+| `ember/routes-segments-snake-case` | the motivation for this rule was the implicit route model, which is deprecated ([RFC #0774](https://github.com/emberjs/rfcs/blob/master/text/0774-implicit-record-route-loading.md)). Raised in [#2060][issue-2060] |
+| `ember/no-deeply-nested-dependent-keys-with-each` | computed-property era ([#1950][issue-1950]) |
+| `ember/no-volatile-computed-properties` | 4.0 removed `.volatile()` |
+| `ember/closure-actions` | 3.x-era invocation style |
+| `ember/no-function-prototype-extensions` | 4.0 removed prototype extensions |
+| `ember/no-old-shims` | ember-cli-shims era |
+| `ember/no-string-prototype-extensions` | 4.0 removed prototype extensions |
+| `ember/no-get-with-default` | 4.0 removed `getWithDefault` |
+| `ember/no-try-invoke` | 4.0 removed `tryInvoke` |
+| `ember/no-test-module-for` | ember-qunit removed `moduleFor*` long ago |
+| `ember/require-fetch-import` | the blueprint no longer has `ember-fetch` ([RFC #1065](https://github.com/emberjs/rfcs/blob/master/text/1065-remove-ember-fetch.md)). See [#1224][issue-1224] |
+
+[issue-1950]: https://github.com/ember-cli/eslint-plugin-ember/issues/1950
+[issue-1224]: https://github.com/ember-cli/eslint-plugin-ember/issues/1224
+
+> [!NOTE]
+> A second group of rules lints for `@ember/component`-era patterns: `ember/no-actions-hash`, `ember/no-component-lifecycle-hooks`, `ember/no-attrs-in-components`, `ember/no-observers`, `ember/require-tagless-components`, and `ember/no-classic-components`. Those patterns are still _possible_ today, so these rules stay in `recommended` for this major. They become removal candidates after the deprecation of `@ember/component` (see [RFC #1216](https://github.com/emberjs/rfcs/pull/1216)).

From 10ce5e4f0bc09bfa66a85e18761d135b47218418 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:42:56 -0400
Subject: [PATCH 11/16] template-lint-migration stays as long as .hbs exists

Not permanently.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 782ed4e0e0..5b8abe1a33 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -134,9 +134,9 @@ That app can also stay on `eslint-plugin-ember@13` until it is on ember-source 4
 
 ### What happens to `template-lint-migration`
 
-The config stays, permanently. An app that still has `.hbs` files uses it. It keeps the full `ember-template-lint` parity set, so hbs coverage is the same before and after this major. The migration guide from [RFC #1214][rfc-1214] is written around it.
+The config stays for as long as `.hbs` exists. An app with `.hbs` files uses it, and hbs coverage does not change in this major. The migration guide from [RFC #1214][rfc-1214] is written around it.
 
-This config is no longer a _migration_ config, so v14 renames it to `hbs`. The name `template-lint-migration` stays as an alias for the deprecation window. The new name states the long-term purpose of the config.
+This config is no longer a migration config, so v14 renames it to `hbs`. `template-lint-migration` stays as an alias for the deprecation window.
 
 ### Other breaking changes
 

From cf55bf0189f436c001242801f5acf882e3169169 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:44:50 -0400
Subject: [PATCH 12/16] Rename the hbs config with no alias

v14 ships `hbs` only. Updates the v14-facing references and the example
import.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 5b8abe1a33..b9b21dd1ed 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -21,7 +21,7 @@ suite:
 This RFC defines the `recommended` config for the next major of `eslint-plugin-ember` (v14).
 
 - The template rules that `ember-template-lint` enabled by default become enabled by default for gjs/gts files. This covers the rules that apply to strict mode. [RFC #1214 "Deprecate ember-template-lint"][rfc-1214] committed us to this config change.
-- `recommended` stays gjs/gts only. Linting of `.hbs` files stays opt-in through `template-lint-migration`, the hbs config, which keeps the full `ember-template-lint` parity set.
+- `recommended` stays gjs/gts only. Linting of `.hbs` files stays opt-in through the `hbs` config, which keeps the full `ember-template-lint` parity set.
 - Rules that catch patterns from `ember-source` 3.x and earlier come out of `recommended`.
 - A number of other recommended rule changes (see appendices)
 - The `recommended-gjs` and `recommended-gts` configs are removed. `recommended` now carries their rules, scoped per file type.
@@ -90,12 +90,12 @@ An app that extends `plugin:ember/recommended-gjs` or `plugin:ember/recommended-
 
 ### Linting `.hbs` files stays opt-in
 
-An app with loose-mode templates opts in with the hbs config. That config is [`template-lint-migration`][migration-config]. It keeps the _full_ `ember-template-lint` parity set, and that set includes the loose-mode-only rules that stay out of `recommended`. The app also needs a parser block that routes `.hbs` files to the hbs parser. `eslint-plugin-ember` already ships that parser as `ember-eslint-parser/hbs`.
+An app with loose-mode templates opts in with the `hbs` config, which v14 renames from [`template-lint-migration`][migration-config]. It keeps the _full_ `ember-template-lint` parity set, and that set includes the loose-mode-only rules that stay out of `recommended`. The app also needs a parser block that routes `.hbs` files to the hbs parser. `eslint-plugin-ember` already ships that parser as `ember-eslint-parser/hbs`.
 
 ```js
 // eslint.config.mjs
 import { hbsParser, plugin as ember } from 'eslint-plugin-ember/recommended';
-import emberTemplateLintMigration from 'eslint-plugin-ember/configs/template-lint-migration';
+import emberHbs from 'eslint-plugin-ember/configs/hbs';
 
 export default [
   // ... existing config ...
@@ -104,7 +104,7 @@ export default [
     plugins: { ember },
     languageOptions: { parser: hbsParser },
   },
-  ...emberTemplateLintMigration,
+  ...emberHbs,
 ];
 ```
 
@@ -136,7 +136,7 @@ That app can also stay on `eslint-plugin-ember@13` until it is on ember-source 4
 
 The config stays for as long as `.hbs` exists. An app with `.hbs` files uses it, and hbs coverage does not change in this major. The migration guide from [RFC #1214][rfc-1214] is written around it.
 
-This config is no longer a migration config, so v14 renames it to `hbs`. `template-lint-migration` stays as an alias for the deprecation window.
+This config is no longer a migration config, so v14 renames it to `hbs`. The old name stops working in v14, and the release notes carry the rename.
 
 ### Other breaking changes
 
@@ -282,7 +282,7 @@ A rule that is already in `recommended` bans one import for the same pattern as
 
 ## Appendix B: loose-mode-only rules, not added to `recommended`
 
-These 9 rules stay in the hbs config, `template-lint-migration`. They keep full `ember-template-lint` parity for `.hbs` files.
+These 9 rules stay in the `hbs` config. They keep full `ember-template-lint` parity for `.hbs` files.
 
 | Rule | Why it does not apply to gjs/gts |
 | ---- | ------------------------------- |

From 09d78b48e15004713d05328be5d07a19a465ef30 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:45:59 -0400
Subject: [PATCH 13/16] o current unresolved questions

---
 text/1217-eslint-plugin-ember-next-major.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index b9b21dd1ed..db5b9488a3 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -185,8 +185,7 @@ A rule that is already in `recommended` bans one import for the same pattern as
 
 ## Unresolved questions
 
-- The split between Appendix A and Appendix B is a best guess. During implementation, each rule must be checked against what strict mode can express. Some loose-mode constructs, such as `{{unbound}}` and `{{mut}}`, are still keywords in strict mode, so their rules stay in Appendix A. A rule in the wrong list moves without a new RFC.
-- The rule for bare strings in templates is off by default in `ember-template-lint`, and it stays off here. Does the migration guide need a special note about it, for an app with heavy i18n? This is a docs question, not a config question.
+n/a
 
 ## Appendix A: template rules added to `recommended`
 

From e2e23df040e6fc3b591a665d3841785b575cec6c Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Mon, 17 Aug 2026 18:48:46 -0400
Subject: [PATCH 14/16] List every rule in the appendices, not only the
 template ones

Appendix C now holds all 59 JS rules of the set and marks the two new
ones. Appendix A records the one gjs/gts rule that has no
ember-template-lint equivalent, for 88 in total.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
 text/1217-eslint-plugin-ember-next-major.md | 78 +++++++++++++++++++--
 1 file changed, 71 insertions(+), 7 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index db5b9488a3..53099c347e 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -66,7 +66,7 @@ Two groups of rules do not apply to strict-mode templates. Both stay in the hbs
 
 ### Add two JS rules to `recommended`
 
-Two JS rules go into `recommended`. Both are already in the plugin as opt-in. Neither one is a template rule, so `recommended` scopes both the way it scopes its other JS rules, not to `**/*.{gjs,gts}`. [Appendix C](#appendix-c-js-rules-added-to-recommended) has both, with the reason for each.
+Two JS rules go into `recommended`. Both are already in the plugin as opt-in. Neither one is a template rule, so `recommended` scopes both the way it scopes its other JS rules, not to `**/*.{gjs,gts}`. [Appendix C](#appendix-c-js-rules-in-recommended) lists every JS rule in the set, and gives the reason for each new one.
 
 ### Remove the `recommended-gjs` and `recommended-gts` configs
 
@@ -177,7 +177,7 @@ This keeps the A11y commitment and creates fewer new errors. It also breaks pari
 
 ### Keep the two new JS rules opt-in
 
-A rule that is already in `recommended` bans one import for the same pattern as one of the two new rules. That ban is not enough, because hand-written code reaches the same pattern without that import. [Appendix C](#appendix-c-js-rules-added-to-recommended) has the detail.
+A rule that is already in `recommended` bans one import for the same pattern as one of the two new rules. That ban is not enough, because hand-written code reaches the same pattern without that import. [Appendix C](#appendix-c-js-rules-in-recommended) has the detail.
 
 ### Merge the template rules into `recommended` unscoped (including `.hbs`)
 
@@ -191,6 +191,8 @@ n/a
 
 87 rules, at `error`, scoped to `**/*.{gjs,gts}`. This is the `template-lint-migration` rule set without the loose-mode-only rules of Appendix B. That set is the recommended preset of `ember-template-lint`, minus `no-partial`, plus `template-no-template-lint-directives`. `no-partial` has no equivalent, because `{{partial}}` no longer exists.
 
+`recommended` also enables [`ember/template-no-let-reference`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/template-no-let-reference.md) for gjs/gts today, and that does not change. `ember-template-lint` has no equivalent rule. The gjs/gts set is 88 rules in total.
+
 - [`ember/template-builtin-component-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-builtin-component-arguments.md)
 - [`ember/template-link-href-attributes`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-link-href-attributes.md)
 - [`ember/template-link-rel-noopener`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-link-rel-noopener.md)
@@ -295,11 +297,73 @@ These 9 rules stay in the `hbs` config. They keep full `ember-template-lint` par
 | [`ember/template-deprecated-render-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-render-helper.md) | `{{render}}` is long gone, and strict mode cannot express it |
 | [`ember/template-deprecated-inline-view-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/6f89075805fdf4487d3f3631fbed58f5e1b8bdab/docs/rules/template-deprecated-inline-view-helper.md) | `{{view}}` is long gone, and strict mode cannot express it |
 
-## Appendix C: JS rules added to `recommended`
-
-Both rules are in the plugin today as opt-in.
-
-| Rule | Why it belongs in `recommended` |
+## Appendix C: JS rules in `recommended`
+
+59 rules, at `error`, for js/ts and gjs/gts. Two of them are new in v14.
+
+- [`ember/avoid-leaking-state-in-ember-objects`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/avoid-leaking-state-in-ember-objects.md)
+- [`ember/classic-decorator-hooks`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/classic-decorator-hooks.md)
+- [`ember/classic-decorator-no-classic-methods`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/classic-decorator-no-classic-methods.md)
+- [`ember/jquery-ember-run`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/jquery-ember-run.md)
+- [`ember/new-module-imports`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/new-module-imports.md)
+- [`ember/no-actions-hash`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-actions-hash.md)
+- [`ember/no-arrow-function-computed-properties`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-arrow-function-computed-properties.md)
+- [`ember/no-assignment-of-untracked-properties-used-in-tracking-contexts`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-assignment-of-untracked-properties-used-in-tracking-contexts.md)
+- [`ember/no-at-ember-render-modifiers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-at-ember-render-modifiers.md)
+- [`ember/no-attrs-in-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-attrs-in-components.md)
+- [`ember/no-attrs-snapshot`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-attrs-snapshot.md)
+- [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) (new in v14)
+- [`ember/no-capital-letters-in-routes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-capital-letters-in-routes.md)
+- [`ember/no-classic-classes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-classic-classes.md)
+- [`ember/no-classic-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-classic-components.md)
+- [`ember/no-component-lifecycle-hooks`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-component-lifecycle-hooks.md)
+- [`ember/no-computed-properties-in-native-classes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-computed-properties-in-native-classes.md)
+- [`ember/no-controller-access-in-routes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-controller-access-in-routes.md)
+- [`ember/no-duplicate-dependent-keys`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-duplicate-dependent-keys.md)
+- [`ember/no-ember-super-in-es-classes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-ember-super-in-es-classes.md)
+- [`ember/no-ember-testing-in-module-scope`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-ember-testing-in-module-scope.md)
+- [`ember/no-empty-glimmer-component-classes`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-empty-glimmer-component-classes.md)
+- [`ember/no-get`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-get.md)
+- [`ember/no-global-jquery`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-global-jquery.md)
+- [`ember/no-incorrect-calls-with-inline-anonymous-functions`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-incorrect-calls-with-inline-anonymous-functions.md)
+- [`ember/no-incorrect-computed-macros`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-incorrect-computed-macros.md)
+- [`ember/no-invalid-debug-function-arguments`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-invalid-debug-function-arguments.md)
+- [`ember/no-invalid-dependent-keys`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-invalid-dependent-keys.md)
+- [`ember/no-invalid-test-waiters`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-invalid-test-waiters.md)
+- [`ember/no-jquery`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-jquery.md)
+- [`ember/no-legacy-test-waiters`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-legacy-test-waiters.md)
+- [`ember/no-mixins`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-mixins.md)
+- [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) (new in v14)
+- [`ember/no-new-mixins`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-new-mixins.md)
+- [`ember/no-noop-setup-on-error-in-before`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-noop-setup-on-error-in-before.md)
+- [`ember/no-observers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-observers.md)
+- [`ember/no-on-calls-in-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-on-calls-in-components.md)
+- [`ember/no-pause-test`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-pause-test.md)
+- [`ember/no-private-routing-service`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-private-routing-service.md)
+- [`ember/no-restricted-resolver-tests`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-restricted-resolver-tests.md)
+- [`ember/no-runloop`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-runloop.md)
+- [`ember/no-settled-after-test-helper`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-settled-after-test-helper.md)
+- [`ember/no-shadow-route-definition`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-shadow-route-definition.md)
+- [`ember/no-side-effects`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-side-effects.md)
+- [`ember/no-test-and-then`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-test-and-then.md)
+- [`ember/no-test-import-export`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-test-import-export.md)
+- [`ember/no-test-support-import`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-test-support-import.md)
+- [`ember/no-test-this-render`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-test-this-render.md)
+- [`ember/no-tracked-properties-from-args`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-tracked-properties-from-args.md)
+- [`ember/no-unnecessary-route-path-option`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-unnecessary-route-path-option.md)
+- [`ember/prefer-ember-test-helpers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/prefer-ember-test-helpers.md)
+- [`ember/require-computed-macros`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-computed-macros.md)
+- [`ember/require-computed-property-dependencies`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-computed-property-dependencies.md)
+- [`ember/require-return-from-computed`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-return-from-computed.md)
+- [`ember/require-super-in-lifecycle-hooks`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-super-in-lifecycle-hooks.md)
+- [`ember/require-tagless-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-tagless-components.md)
+- [`ember/require-valid-css-selector-in-test-helpers`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-valid-css-selector-in-test-helpers.md)
+- [`ember/use-brace-expansion`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/use-brace-expansion.md)
+- [`ember/use-ember-data-rfc-395-imports`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/use-ember-data-rfc-395-imports.md)
+
+Both new rules are in the plugin today as opt-in.
+
+| New rule | Why it belongs in `recommended` |
 | ---- | ------------------------------- |
 | [`ember/no-builtin-form-components`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-builtin-form-components.md) | A native `<input>` or `<textarea>` is better than the classic-component `<Input>` or `<Textarea>` wrapper. Named for the next major in [#2060][issue-2060], and implemented in [#2282][pr-2282] |
 | [`ember/no-modifier-without-element-usage`](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-modifier-without-element-usage.md) | A modifier that never reads its element is an effect that render schedules. `ember/template-no-at-ember-render-modifiers` already rejects that data flow in a template, and it is in `recommended` today. That rule bans one import, and `ember-modifier` reaches the same pattern in three lines |

From 9ae3387bc5ce8e6e74c286aad9d56d5cab2070fe Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Tue, 18 Aug 2026 09:02:34 -0400
Subject: [PATCH 15/16] Add how we teach this entry, per @kategengler

---
 text/1217-eslint-plugin-ember-next-major.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 53099c347e..2833c397b7 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -155,6 +155,8 @@ For the v14 upgrade itself:
 - An app with `.hbs` files opts in to hbs linting with the hbs config. That is a task for the migration from `ember-template-lint`, which the RFC #1214 guide covers. It is not a v14 upgrade task.
 - An app that already uses the `template-lint-migration` config sees no new template errors. For that app, v14 is a no-op.
 
+- Ensure the Guides and Tutorial follow the new recommended config
+
 ## Drawbacks
 
 - An existing app gets many new lint errors after the upgrade. That is the purpose of the major, per RFC #1214. Bulk suppressions exist, so no team has to correct every error in one PR.

From 6c985701113c722af740f22b0c7e87cc183767b7 Mon Sep 17 00:00:00 2001
From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com>
Date: Tue, 18 Aug 2026 09:06:18 -0400
Subject: [PATCH 16/16] Clarify drawbacks

---
 text/1217-eslint-plugin-ember-next-major.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/text/1217-eslint-plugin-ember-next-major.md b/text/1217-eslint-plugin-ember-next-major.md
index 2833c397b7..a524505d76 100644
--- a/text/1217-eslint-plugin-ember-next-major.md
+++ b/text/1217-eslint-plugin-ember-next-major.md
@@ -159,9 +159,9 @@ For the v14 upgrade itself:
 
 ## Drawbacks
 
-- An existing app gets many new lint errors after the upgrade. That is the purpose of the major, per RFC #1214. Bulk suppressions exist, so no team has to correct every error in one PR.
-- Neither added JS rule has an autofix, so a report means a refactor and not a rename. An app can suppress both rules in bulk while it works through them.
-- An app that still supports ember-source 3.x loses the coverage of the removed rules, unless it turns them on again. The release notes and the changelog entry for each removed rule state this. An app can also stay on v13, because nothing in v13 stops working.
+- Not all rules have autofixes, but those that don't should already be linking to sufficient documentation to help developers have actionable information
+
+- No `hbs` support by default (some have not yet migrated to gjs/gts)
 
 ## Alternatives