Document inline vs file-based kinds selection criteria (#412)

* Mark plan 208 as complete; PR #391 merged 2026-05-24

* Add guide: choose between inline and file-based kinds

* Fold kind-form decision into file-kinds.md; drop standalone guide

Addresses /code-review findings on PR #412:

- Wrong Diatáxis type (was how-to, content is background/decision-aid).
  Folded the unique 'when to keep inline / when to lift' selection
  criteria into docs/guides/file-kinds.md as a new H2 above the
  existing 'Split a kind into its own file' section, where it sits
  next to the mechanics it points at.
- Removed the standalone guide and its catalog rows.
- Cut sections that duplicated file-kinds.md or kind-files.md:
  the YAML side-by-side examples (closed: false would have errored
  on a frontmatter-only schema), the 'what stays inline regardless'
  block, the comparison table, and the 'mixing both forms' example
  (which mislabeled this repo's inline kinds as file-based).
- Dropped the stale .mdsmith.yml line-count snapshot.
- Removed the 'maintenance decision, not a behavioral one' seesaw.
- New section uses zero em-dashes.

* Replace 'alt-tabbing' with 'switching' in file-kinds.md

Global-English pass: alt-tab is a Windows/Linux phrasal-verb idiom;
the plain verb 'switching' is keyboard-agnostic and reads on a
first pass for non-native readers.

* Address /code-review findings 1-5 on file-kinds.md

- F1: replace bare KindBody with 'body keys' (host page never defines
  the typed term; reference page expects this guide to define it).
- F2: section-end pointer now goes directly to the kind-files reference
  instead of the next H2 (which itself relayed there).
- F3: 'A PR touching X names itself' was an idiomatic personification;
  rewrite as 'carries the kind name in its path'.
- F4: trim the 'Split a kind' H2 opener that re-stated the same trigger
  the new decision-aid section above already delivered; H2 now opens
  with the action.
- F5: 'outweighs the history isolation' used an undefined noun phrase;
  expand to 'outweighs the gain of isolating each kind's edit history'.

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: jeduden

PLAN.md

@@ -133,7 +133,7 @@ footer: |
 | 205 | 🔲     |        | [Move extension.ts concerns to wiring.ts](plan/205_arch-fix-extension-ts-srp.md)                                                        |
 | 206 | 🔲     |        | [Document cue/ in architecture layering map](plan/206_arch-fix-cue-types-docs.md)                                                       |
 | 207 | ✅     | sonnet | [LSP fix preview via ChangeAnnotation](plan/207_lsp-fix-preview.md)                                                                     |
-| 208 | 🔳     | opus   | [Kind-per-file config under `.mdsmith/kinds/`](plan/208_kind-files.md)                                                                  |
+| 208 | ✅     | opus   | [Kind-per-file config under `.mdsmith/kinds/`](plan/208_kind-files.md)                                                                  |
 | 209 | 🔲     | opus   | [Convention-per-file config under `.mdsmith/conventions/`](plan/209_convention-files.md)                                                |
 | 210 | ✅     | opus   | [Single source of truth for product messaging via `mdsmith extract`](plan/210_messaging-source-of-truth.md)                             |
 | 211 | 🔲     | opus   | [`<?include?>` projects any typed value of any kind via `extract`](plan/211_include-extract-value.md)                                   |

docs/guides/file-kinds.md

@@ -230,12 +230,59 @@ effective kinds:
   - plan (from kind-assignment[2]: glob plan/*.md AND fields-present id)
 ```
 
+## Choose inline or file-based
+
+Both forms accept the same body keys and
+produce identical diagnostics. Pick per kind
+based on edit history, body size, and how
+reviewers read the diff.
+
+### When to keep a kind inline
+
+Inline is the default. Keep a kind inline when:
+
+- The body fits on a screen and the project's
+  `kinds:` block is under about 50 lines.
+  Scanning every kind at once is faster in one
+  file.
+- The kind is new and still under iteration.
+  Editing in place is faster than switching
+  between two files.
+- The kind sits next to a related override or
+  `kind-assignment:` entry, and the proximity
+  helps a reader follow the wiring.
+- The project has fewer than six kinds. The
+  review cost of one extra file per kind
+  outweighs the gain of isolating each kind's
+  edit history.
+
+### When to lift a kind into its own file
+
+Move the kind to `.mdsmith/kinds/<name>.yaml`
+when:
+
+- The `kinds:` block has grown past about 150
+  lines or six kinds, and per-kind edits dirty
+  unrelated config history.
+- A reviewer should see which kind changed from
+  the file list alone. A PR touching
+  `.mdsmith/kinds/<name>.yaml` carries the kind
+  name in its path. A PR touching `.mdsmith.yml`
+  forces the reviewer to open the diff to find
+  which kind moved.
+- The kind body is large. A long frontmatter
+  schema and many rule overrides bloat the
+  inline view of every other kind.
+- The kind is reused across repos. Copying a
+  standalone file is cleaner than excising a
+  named block from a shared `.mdsmith.yml`.
+
+See [Kind files reference](../reference/kind-files.md)
+for layout details and the basename rule.
+
 ## Split a kind into its own file
 
-When a project's `kinds:` block has grown large
-enough that one kind's edits dirty the same
-`.mdsmith.yml` as every other config change, lift
-the kind into a standalone file under
+Lift the kind into a standalone file under
 `.mdsmith/kinds/<name>.yaml`. The basename is the
 kind's name; the body is identical to the inline
 `kinds.<name>:` body.

plan/208_kind-files.md

@@ -1,7 +1,7 @@
 ---
 id: 208
 title: Kind-per-file config under `.mdsmith/kinds/`
-status: "🔳"
+status: "✅"
 model: opus
 depends-on: [146, 135]
 summary: >-