clojure-mode is the reference to port from, not an ancestor to inherit

DISCUSS.md

@@ -290,19 +290,21 @@ the first argument. Bindings are pairs, so the alignment that reads correctly is
 bracket users in the same pass — `defn` parameter lists and `restart-case` clause parameters have the same shape and
 almost certainly the same bug.
 
-**Should `flan-mode` derive from `clojure-mode` instead?** Considered and declined, without much in it.
+**`clojure-mode` should be the reference, not the ancestor and not a dependency.** The distinction matters and was
+muddled once in conversation: the proposal is *not* `define-derived-mode` on `clojure-mode`, and not adding an external
+package. It is to rewrite `flan-mode`'s indentation and font-lock as our own code, **ported from `clojure-mode`'s source
+rather than from `lisp-mode`'s**.
 
-For: binding vectors, `#_` and a lot of tuned indentation for free, and the syntax genuinely is Clojure-shaped.
+The current mode has the wrong ancestor. It is built on Emacs's `lisp-indent-function`, and Emacs Lisp has none of the
+shapes Flan actually uses: no vectors as binding forms, no keywords as map keys, no destructuring, no bracket variety.
+So every rule has to be added by hand and the binding-vector bug is simply the first one hit. Clojure's rules already
+cover brackets-mean-binding, pairs-align, maps, keywords, `#_`, and reader conditionals — the last two now wanted in
+their own right.
 
-Against, and this is what decided it:
+Where Flan diverges it diverges deliberately rather than by discovery: `defn` carries a return type between the
+parameters and the body; field access is `(.x v)`; field labels are moving from `:x` to `.x`, so `{.x 1.0}` is a struct
+literal and not a map with symbol keys. Those get written on purpose.
 
-- `flan-mode` currently depends on **nothing outside stock Emacs**, and it ships inside this repo. Deriving adds an
-  external package to something distributed with the compiler.
-- **The divergence is growing.** `defn` carries a return type between the parameters and the body, which Clojure has no
-  concept of; field access is `(.x v)`; and the decision to move field labels from `:x` to `.x` means `{.x 1.0}` would
-  read to `clojure-mode` as a map with symbol keys. Inheriting rules then means overriding them, which is usually more
-  work than writing the few that are wanted.
-- That community is mid-transition to a tree-sitter mode, so the base would be a moving target.
-
-**So: stay independent and copy `clojure-mode`'s binding-vector algorithm**, which is small, known-good, and the only
-piece actually missing. If a second or third gap appears later that is real evidence for deriving; one is not.
+Deriving at runtime stays rejected — it would add an external dependency to a mode that ships inside this repo and
+currently needs nothing beyond stock Emacs, and that community is mid-transition to a tree-sitter mode, so the base is
+moving.