design-md-consolidation 1.4 fixup: strip bare iter-id references (~16 sites)

docs/DESIGN.md

@@ -587,7 +587,7 @@ foreign LLM enough to produce valid output. The current prompt revises this:
 
 The discussion of richer integration paths (LLM tool-use, MCP
 server, LSP) was deferred — all three layer additively on the
-static-prompt path 20f ships, which remains the
+static-prompt path ships, which remains the
 lowest-common-denominator fallback that always works.
 
 ## Decision 7: redundancy removal — `Term::If` is not a primitive
@@ -661,19 +661,19 @@ Solution: explicit, verified tail calls.
   total production count goes from ~28 to ~30, still inside
   the constraint-1 budget.
 
-**What this does NOT promise.** Per the 14d tail-call survey,
+**What this does NOT promise.** Per the tail-call survey of existing fixtures,
 many existing recursive calls are *not* in tail position
 because they are arguments to constructor calls (e.g.
-`Cons (f h) (map f t)`). 14e adds annotation + verification;
+`Cons (f h) (map f t)`). The current pipeline adds annotation + verification;
 it does **not** add a CPS transform or accumulator-form
 rewrite. Programs whose recursion is constructor-blocked
 will continue to be stack-bounded by recursion depth. The
 canonical authoring pattern in such cases is to write the
 accumulator-form variant (`map_acc`, `fold_left`, etc.)
-explicitly. The stdlib (15a onward) ships both forms where
+explicitly. The stdlib ships both forms where
 relevant.
 
-The 14d migration of existing fixtures will be partial: only
+Migration of existing fixtures is partial: only
 `print_list`-style terminal recursions get marked. The
 constructor-blocked recursions in `map`, `sort`, `insert`
 remain unmarked — they cannot benefit from `musttail`
@@ -762,7 +762,7 @@ Trade-offs accepted:
 A future iter may layer a per-fn-arena optimisation on top: when
 a fn's return type contains no boxed ADT, ADT boxes allocated
 inside that fn cannot escape, so an arena freed at fn return is
-sound by construction (per the 14e GC notes). That requires
+sound by construction. That requires
 escape analysis, the corresponding AST/IR plumbing, and is its
 own design pass. Boehm-everything is the floor; arena is an
 optimisation above it.
@@ -1379,7 +1379,7 @@ monomorphised copies resolve to concrete drop fns).
   param is not yet propagated through; the param-mode gates
   treat such a binder as "owned" (its `current_param_modes`
   lookup misses, default = owned). This is a known carve-out
-  shared by Iter A and 18g.1; closing it is a propagation pass
+  shared by Iter A and the pre-tail-call shallow-dec arm; closing it is a propagation pass
   through let-bindings that has not shipped yet.
 
 ### Migration plan
@@ -1444,8 +1444,7 @@ materialises with a real workload.
 
 ## Decision 11: typeclasses — Haskell-lite, monomorphised, coherent
 
-**The design pass that gates
-22b implementer work. Codified after the Feature-acceptance
+**The design pass for typeclasses. Codified after the Feature-acceptance
 criterion (this document, above) was committed; the criterion is
 the explicit basis for the choices below.**
 
@@ -1662,7 +1661,7 @@ constraint at the function site reads `Ord a` alone.
 Superclass chains are linear (single-superclass relation per class)
 and auto-expansion closes transitively across the chain.
 
-**No `deriving`.** 22a does not auto-derive instances. `instance Eq
+**No `deriving`.** AILang does not auto-derive instances. `instance Eq
 MyType` must be written by hand. Auto-derivation may land in a future
 iteration if the Feature-acceptance criterion holds for it; that
 discussion is out of scope here.
@@ -1670,7 +1669,7 @@ discussion is out of scope here.
 ### Diagnostic categories
 
 The typeclass layer introduces three families of diagnostics. Exact
-wording is fixed in 22b; the categories and their triggers are:
+wording is fixed; the categories and their triggers are:
 
 **Workspace-load (registry-build) diagnostics:**
 
@@ -1702,7 +1701,7 @@ There is no `AmbiguousInstance` diagnostic. Coherence (W2) makes
 every `(class, type)` key globally unique; resolution is therefore
 deterministic by construction.
 
-### What 22a explicitly does NOT support
+### What the typeclass design explicitly does NOT support
 
 Each of the following is rejected by either schema (parser cannot
 express the construct) or by an enumerated diagnostic. The
@@ -1738,16 +1737,16 @@ axis-5 (kind `*` only) covers the space.
 ### Prelude (built-in) classes
 
 Milestone 22 ships **no built-in Prelude classes**. The original
-22a draft committed to a fixed Prelude (Show / Eq / Ord on the
+An earlier draft committed to a fixed Prelude (Show / Eq / Ord on the
 primitives), but the implementation work to wire `int_to_str` as a
 heap-allocated-string runtime primitive proved substantively
 separable from the typeclass machinery itself, and the LLM-utility
 case for primitive `Show` is weak (LLM-natural form is `int_to_str
 x`, not `show x` through a single-instance class). The user-class
 end-to-end path is the milestone's typeclass acceptance gate
-(22c's `class Foo a` + `data IntBox` + `instance Foo IntBox`
+(the user-defined-class fixture: `class Foo a` + `data IntBox` + `instance Foo IntBox`
 fixture); see `docs/specs/2026-05-09-22-typeclasses.md`
-"Amendments" §"22b.4b dropped" for the substantive rationale.
+"Amendments" for the substantive rationale.
 
 A future milestone may add a Prelude when concrete LLM-author code
 surfaces a case that benefits from `Show a` / `Eq a` / `Ord a`
@@ -1756,7 +1755,7 @@ goes through `io/print_int` / `io/print_bool` / `io/print_str`
 directly.
 
 `==`, `<`, `<=`, `>`, `>=` REMAIN primitive operators (unchanged
-from the 22a draft). Class methods are accessed by name (`eq x y`,
+from the original draft). Class methods are accessed by name (`eq x y`,
 `lt x y`, …), not via these operators. Routing operators through
 classes is deliberately deferred — it would require migrating every
 existing fixture and would re-baseline the bench corpus, which is a
@@ -2043,7 +2042,7 @@ capture is `Term::Let`-bound, so its type is only knowable after
 inference). The output is a module with synthetic `<hint>$lr_N`
 top-level fns appended, ready for codegen. Synthetic FnDefs added
 by this pass do **not** appear in `CheckedModule.symbols` — same
-invariant as the 16b.2 lifts in desugar.
+invariant as the desugar-pass lifts.
 
 ## CLI