polytypo 1.1.0 → 1.3.0

data/lib/polytypo/data/rules/dashes.md

@@ -1,8 +1,10 @@
 # Rule: `dashes`
 
-**Order:** 30. **Default:** on. **Modes:** text, html, markdown.
+**Order:** 30. **Default:** on. **Modes:** text, html, markdown, yaml.
 **Spec version:** 0.6.0 (0.2.0 for everything except the 0.5.0/0.6.0 changes noted inline and in
-§8 History).
+§8 History), amended in **1.3.0**: §1 and §3.4's statement of what belongs to `ranges`, §3.2a's
+re-entry condition, and §3.2 steps 7 and 8, all for [ranges.md](ranges.md) §3.2a's closed-up
+symbols.
 
 ---
 
@@ -25,9 +27,13 @@ a retired one.
 
 `dashes` does not touch the ordinary hyphen inside a compound word — which, in the few
 morphological forms where the hyphen must additionally be protected from a line break, belongs
-to `hyphen` at order 35 — and does not touch a digit-flanked stroke at all: that shape belongs to
+to `hyphen` at order 35 — and does not touch a **range candidate** at all: that shape belongs to
 `ranges` exclusively, and `dashes` declines it **unconditionally**, whether or not `ranges` is
 enabled (operator decision, spec 0.5.0; see §3.2's note after step 7, and ranges.md §3.2's G1-G5).
+"Range candidate" is [ranges.md](ranges.md) §3.2's term, and as of spec 1.3.0 it is wider than
+"digit-flanked": a closed-up symbol on a flank is walked over first (ranges.md §3.2a), so
+`$15-$20` and `35%-50%` are `ranges`' tokens too, and a token `dashes` used to convert by default
+is now one nothing touches unless the caller enables `ranges`.
 `dashes` never reinterprets a digit-flanked hyphen as a parenthetical dash — that was already true
 in every prior spec version, since the two branches were always mutually exclusive per token; the
 0.5.0 split makes that exclusivity a boundary between two rules instead of two branches of one.
@@ -80,6 +86,7 @@ Input is a code-point array `cp[0 … n-1]`.
 | `ROMAN`         | the seven uppercase Roman-numeral letters only: U+0049 `I`, U+0056 `V`, U+0058 `X`, U+004C `L`, U+0043 `C`, U+0044 `D`, U+004D `M`. Lower-case forms are **not** members — see §3.4 P4                               |
 | `INERT-DASH`    | U+00AD (soft hyphen), U+2011 (non-breaking hyphen), U+2012 (figure dash), U+2015 (horizontal bar), U+FE58, U+FE63, U+FF0D                                                                                            |
 | `JOINER`        | U+2060 (word joiner) only. As of spec 0.5.0, produced exclusively by `ranges` (ranges.md §3.3.1) — `dashes` itself never emits one, but still reads through an adjacent run of them (§3.2a, §3.2b), since a `ranges`-produced joiner can sit next to a `dashes` candidate token                                                                                                                    |
+| `CLOSED-SYMBOL` | **Defined normatively in [ranges.md](ranges.md) §3.2a** (spec 1.3.0), not here: the symbols conventionally written closed up to a number. `dashes` never emits one and never reads one as a candidate, but §3.2 steps 7-8 and §3.4 depend on the class, so it is listed here for a reader transcribing this table. There is exactly one enumeration of it, in ranges.md — do not restate it                                                                       |
 
 `INERT-DASH` members are **never** candidates and are **never** produced. Two of the seven are
 protective markers owned by someone else — U+00AD is invisible formatting, and U+2011 is
@@ -183,8 +190,8 @@ U+2011 they meant it.
      something this rule should be rewriting.
 7. **Cluster guard.** Define a **dash cluster** as a maximal span of code points every one of
    which is in `DASH` ∪ `INERT-DASH` ∪ `DIGIT` ∪ `JOINER` (§3.2b — a joiner `ranges` emitted on
-   an earlier pass must not split a cluster it sits inside). (Spaces, letters and punctuation all end a
-   cluster.) Let `C` be the cluster containing this token's run. **If `C` contains two or more
+   an earlier pass must not split a cluster it sits inside). (Spaces, letters and punctuation all
+   end a cluster.) Let `C` be the cluster containing this token's run. **If `C` contains two or more
    maximal runs of `DASH` ∪ `INERT-DASH`, emit nothing for every token in `C`** — the whole
    cluster is inert.
    This covers idempotency defect (a), §8.2: the classification of a range token reads
@@ -193,6 +200,13 @@ U+2011 they meant it.
    verdict on the next run.
    `2026-08-15`, `978-3-16-148410-0`, `212-555-1234`, `a—0–0` and `1914-1918—annexation` are
    all single clusters with more than one dash run, and are all inert in their entirety.
+   **`CLOSED-SYMBOL` is deliberately not in this alphabet (spec 1.3.0).** Widening a range
+   member (ranges.md §3.2a) does reach this guard — `a—$15-$20` is two clusters where `a—15-20`
+   is one — but the resulting defect is closed by step 8 instead, and at a strictly smaller cost:
+   the cluster guard is unconditional, so adding `CLOSED-SYMBOL` here would also make
+   `price--$50--drop` inert in an `em-tight` locale that has no such defect to fix. Step 8 fires
+   only on the tight-to-spaced transition that can actually disturb a neighbour. See §3.2 step 8
+   and [ranges.md](ranges.md) §3.2a.
    **This guard is not sufficient on its own, and it does not subsume G2.** A cluster ends at
    the first space-like code point, so a _spaced_ token's cluster contains only its own run:
    its `cp[L]` is a digit in a neighbouring cluster and its `before` is a dash in a third one,
@@ -206,14 +220,65 @@ U+2011 they meant it.
    - the chosen form is `em-spaced` or `en-spaced` — the replacement will insert a U+0020 on
      each side.
 
-   In that case, for each side independently:
+   In that case, for each side independently — reading `L`/`R` and the outward walk as
+   **`CLOSED-SYMBOL`-transparent**, per the amendment immediately below:
    - **left:** if `cp[L]` is in `DIGIT`, let `D` be the maximal `DIGIT` run ending at `L` and
      starting at index `d`. Reading **effective neighbours** (§3.2b) outward from `d`: if the
      first is in `DASH` ∪ `INERT-DASH`, **or** the first is in `SPACE` ∪ `NOBREAK-SPACE` and the
      second is in `DASH` ∪ `INERT-DASH`, emit nothing for this token.
    - **right:** if `cp[R]` is in `DIGIT`, let `D` be the maximal `DIGIT` run starting at `R`
-     and ending at index `d`. If `cp[d+1]` is in `DASH` ∪ `INERT-DASH`, **or** `cp[d+1]` is in
-     `SPACE` ∪ `NOBREAK-SPACE` and `cp[d+2]` is in `DASH` ∪ `INERT-DASH`, emit nothing.
+     and ending at index `d`. Reading **effective neighbours** (§3.2b) outward from `d` — the
+     same reading the left branch uses, and the one §3.2b already requires of "the two-code-point
+     reach of T1"; through spec 1.2.0 this branch was written with raw `cp[d+1]`/`cp[d+2]`, which
+     disagreed with §3.2b and with every shipped implementation (see below) — if the first is in
+     `DASH` ∪ `INERT-DASH`,
+     **or** the first is in `SPACE` ∪ `NOBREAK-SPACE` and the second is in `DASH` ∪ `INERT-DASH`,
+     emit nothing.
+
+   **`CLOSED-SYMBOL` transparency (spec 1.3.0).** [ranges.md](ranges.md) §3.2a made a symbol
+   written closed up to a digit run part of a **range member**, so the digit run whose verdict
+   this guard protects can now sit one code point further out than it used to — on either end.
+   At **two** positions per side, one `CLOSED-SYMBOL` is therefore stepped over rather than read:
+
+   - **p1, between the token and the run.** If `cp[L]` (resp. `cp[R]`) is in `CLOSED-SYMBOL` and
+     the code point beyond it is in `DIGIT`, the branch proceeds as though `L` (resp. `R`) were
+     that digit. Without p1 the branch is skipped outright, because its gate is `cp[L]`/`cp[R]`
+     ∈ `DIGIT`: `a--$1 - $1` is the witness.
+   - **p2, at the far end of the run.** The outward walk from `d` steps over one `CLOSED-SYMBOL`
+     before reading its first and second neighbours. Witness: `a--15% - 20%`, where the walk
+     from `d` finds `%` and the dash it exists to find is one code point further out.
+
+   The two compose on a single side (`a--$15% - $20%` exercises p1 and p2 at once) and are
+   independent across sides.
+
+   **The right branch's raw reading, and what §3.2a changed about it.** The raw text disagreed
+   with §3.2b from the start, and the disagreement was always live on the **second** sub-branch:
+   a U+0020 ends a cluster, so step 7 never declined `a--15⁠ - 20`, and a port reading raw
+   `cp[d+1]` sees the joiner, does not fire, and drifts. (It was unreachable on the first
+   sub-branch only — with no space, the token, the digit run, the joiner and the far dash all sat
+   inside one cluster, since step 7's alphabet contains `JOINER` and `DIGIT`.) What §3.2a added
+   is a second way in: p1 admits `cp[R]` ∈ `CLOSED-SYMBOL`, which is deliberately **not** in the
+   cluster alphabet, so `a--$15⁠-⁠$20` splits into two clusters and step 8 stands alone there too.
+   Both shapes are now pinned by fixtures, for the same reason §3.2a's re-entry amendment needed
+   one: nothing else in the suite separates the two readings. Every shipped implementation
+   already read effective neighbours — this is the text catching up, not a behaviour change.
+
+   **Why two positions are enough, and there is no third.** §3.2a consumes **at most one**
+   `CLOSED-SYMBOL` per side — a two-code-point prefix such as `US$` defeats candidacy rather
+   than the guard — so each position can hold at most one symbol. A `-spaced` replacement inserts
+   exactly one U+0020, so the "first or second neighbour" reach is unchanged in length; the
+   symbol shifts *where* that reach starts, never how far it goes. p1 and p2 are the only two
+   places a symbol can sit between this token and the far dash, so the amended reach is closed.
+
+   **The cost, and why it is this guard rather than step 7.** In a locale whose
+   `dash.parenthetical` is **spaced**, a tight token next to a closed-up range member no longer
+   converts: `Anstieg--50%--war` is left alone in `de-DE`, where spec 1.2.0 produced
+   `Anstieg – 50% – war`. That is precisely what the all-digit `Anstieg--50--war` has always
+   done, so the two shapes agree, and the cost stops there — a locale with a **tight**
+   parenthetical form never reaches this guard at all, so `price--$50--drop` still becomes
+   `price—$50—drop` in `en-US`. Putting `CLOSED-SYMBOL` in step 7's cluster alphabet would have
+   closed the same defect and taken the `en-US` case with it, because that guard is
+   unconditional; it was tried and rejected for exactly that reason.
 
    Read plainly: **a tight token must not become spaced when doing so would insert a space
    between itself and a digit run that has another dash on its far side.** That inserted space
@@ -279,12 +344,18 @@ A `JOINER` adjacent to the token is examined before the branch is chosen:
   across a maximal run of `JOINER`. If either walk runs off the array, emit nothing.
 - If no joiner was crossed, `L* = L` and `R* = R` and nothing about the rest of the algorithm
   changes.
-- If a joiner **was** crossed and `cp[L*]` and `cp[R*]` are both in `DIGIT`, the token is a
-  bound range `ranges` produced on an earlier pass ([ranges.md](ranges.md) §3.3.1): continue with
-  `L*`/`R*` in place of `L`/`R`, and extend the token's span to cover the crossed joiners. `dashes`
-  itself never reaches this shape as a candidate — extending the span here only ever feeds the
-  digit-flanked check that routes the token to `ranges`' exclusive territory (§1, §3.3), never to
-  this rule's own parenthetical branch.
+- If a joiner **was** crossed and `cp[L*]` and `cp[R*]` are both in `DIGIT` — **or, as of spec
+  1.3.0, are `DIGIT` after `ranges`' closed-up-symbol walk** ([ranges.md](ranges.md) §3.2a), so
+  that `$15⁠–⁠$20` and `35%⁠–⁠50%` reach this clause the same way `1914⁠–⁠1918` does — the token is
+  a bound range `ranges` produced on an earlier pass ([ranges.md](ranges.md) §3.3.1): continue
+  with `L*`/`R*` in place of `L`/`R`, and extend the token's span to cover the crossed joiners.
+  `dashes` itself never reaches this shape as a candidate — extending the span here only ever
+  feeds the flank check that routes the token to `ranges`' exclusive territory (§1, §3.3), never
+  to this rule's own parenthetical branch. **Without the 1.3.0 clause a bound range carrying
+  symbols would fall to the fourth bullet below and be declined by both rules** — stable, but
+  wrong in one observable way: a hyphen an author typed between an existing joiner pair,
+  `$15⁠-⁠$20`, would never convert. The amendment is what makes that input reach `ranges`, and a
+  conformance case pins it, because nothing else in the suite separates the two readings.
 - If a joiner was crossed in any other configuration, **emit nothing**. An author who typed
   U+2060 next to a dash meant it, exactly as with `INERT-DASH` (§3.1).
 
@@ -340,9 +411,10 @@ is [ranges.md](ranges.md) §3.2-§3.3.1 in full** — the admissibility test (`c
 verbatim, still reading the same `dash.range` locale field under the same key.
 
 **What stays true here, restated because it is `dashes`' own contract now rather than a
-consequence of one rule's two branches:** a digit-flanked dash token (`cp[L]` and `cp[R]` both
-`DIGIT`) is never processed by `dashes` — not converted, not declined-and-then-reconsidered,
-simply never reached. This holds **unconditionally**, whether `ranges` is enabled or not (§1).
+consequence of one rule's two branches:** a range candidate (`cp[L']` and `cp[R']` both `DIGIT`,
+after ranges.md §3.2a's closed-up-symbol walk — through spec 1.2.0 this read `cp[L]`/`cp[R]` and
+meant digit-flanked) is never processed by `dashes` — not converted, not
+declined-and-then-reconsidered, simply never reached. This holds **unconditionally**, whether `ranges` is enabled or not (§1).
 `ranges` disabled does not mean the token falls back to parenthetical treatment; it means nothing
 in the pipeline touches it at all, and `5-10`, `Figure 5-10`, `9-11` and `7-11` are all
 byte-identical no-ops with default options.
@@ -356,10 +428,10 @@ still occupies its number costs less than a renumbering would.
 
 ### 3.4 Parenthetical branch
 
-Reached for every token this rule sees — a digit-flanked token (both `cp[L]` and `cp[R]` in
-`DIGIT`) is never handed to `dashes` at all (§3.3, §1), not merely excluded from this branch, so
-"is not a range candidate" (i.e. at least one of `cp[L]`, `cp[R]` is not a `DIGIT`) is true of
-every token that reaches here by construction. Additional guards:
+Reached for every token this rule sees — a range candidate (ranges.md §3.2, §3.2a) is never
+handed to `dashes` at all (§3.3, §1), not merely excluded from this branch, so "is not a range
+candidate" (i.e. at least one flank is not a `DIGIT`, and is not a closed-up symbol matched to
+its opposite member) is true of every token that reaches here by construction. Additional guards:
 
 - **P5 (spec 0.6.0) — authored en-dash mark-identity veto.** If `k = 1` and `cp[s]` is U+2013,
   emit nothing — **unconditionally**: every locale, tight or spaced, regardless of
@@ -525,10 +597,14 @@ of being falsified by another rule, which is then named.
 - **[P] A negative number.** `-5` has no space to the left of the digit and a letter/space to
   the left of the hyphen → asymmetric → rejected. This holds for U+002D, U+2010 and U+2212
   alike — the same asymmetry guard, not a glyph-specific one.
-- **[P] Every digit-flanked stroke, unconditionally** — `5-10`, `Figure 5-10`, `9-11`: never
-  reached by `dashes` at all, let alone reinterpreted as parenthetical (§1, §3.3). This holds
-  regardless of whether `ranges`' own guards would have accepted or declined the token —
-  `dashes` does not evaluate them and does not need to.
+- **[P] Every range candidate, unconditionally** — `5-10`, `Figure 5-10`, `9-11`, and since
+  spec 1.3.0 also `$15-$20`, `$15 - $20` and `35%-50%`, where a matched `CLOSED-SYMBOL` sits
+  between the stroke and a digit run (ranges.md §3.2a): never reached by `dashes` at all, let
+  alone reinterpreted as parenthetical (§1, §3.3). This holds regardless of whether `ranges`'
+  own guards would have accepted or declined the token — `dashes` does not evaluate them and
+  does not need to. **`$15 - $20` is the one shape this cost anything**: through spec 1.2.0 it
+  was `dashes`' token and converted with default options; it is `ranges`' now, and `ranges` is
+  off by default.
 - **[P] URLs, code spans, fenced code, HTML attributes.** Removed by the mode adapter before this
   rule sees them. This rule has no notion of a URL and must not grow one.
 - **[P] Line terminators**, which are never inserted, deleted or crossed.
@@ -537,8 +613,9 @@ of being falsified by another rule, which is then named.
 
 ## 5. Idempotency argument
 
-Write `T` for `dashes`. `T` edits only **parenthetical dash tokens**: at least one of `cp[L]`,
-`cp[R]` is not `DIGIT` (§1, §3.3) — a digit-flanked token is never reached by `T` on any pass, so
+Write `T` for `dashes`. `T` edits only **parenthetical dash tokens**: tokens that are not range
+candidates (§1, §3.3) — at least one flank is neither a `DIGIT` nor a `CLOSED-SYMBOL` matched on
+the opposite member (ranges.md §3.2a). A range candidate is never reached by `T` on any pass, so
 nothing below needs to reason about one. Each edit `T` makes replaces a span consisting of one
 maximal `DASH` run plus at most one space-like code point on each side, with a span of the same
 shape (`space? dash space?`). So every edit is one of:
@@ -566,9 +643,10 @@ U+2013/U+2014 no token-level special case, §3.2 step 2a, so this holds regardle
 glyph the token holds). A spaced form is re-admitted the same way, with `lsp = rsp = 1` read back
 by §3.2 step 3. A token `nbsp` has since promoted (`ru`: U+00A0 before an em dash) is not
 recomputed at all — §3.2 step 3 makes a no-break-space neighbour space-like, so the isolation
-guard (step 6) declines it and nothing is emitted (§3.6). A digit-flanked token stays outside `T`'s
+guard (step 6) declines it and nothing is emitted (§3.6). A range candidate stays outside `T`'s
 domain on every pass, by construction, so it is trivially a fixed point of `T` regardless of what
-`ranges` does to it.
+`ranges` does to it — including after `ranges` has bound it, since the binding leaves the flanks
+(and any `CLOSED-SYMBOL` on them) exactly where they were.
 
 ### 5.2 A declined token stays declined
 
@@ -619,17 +697,25 @@ them, and all three are current:
   Range binding ([ranges.md](ranges.md) §3.3.1) is exclusively `ranges`' emission; an interrupting
   parenthetical dash is exactly where a line *may* break, so there is nothing for `dashes` to bind
   (§3.6).
-- **A digit-flanked token is never reinterpreted as parenthetical, on any pass.** The `isDigit`
-  test that routes a token to `ranges` instead of `dashes` (§1, §3.3) is evaluated after the
-  joiner-crossing walk (§3.2a), so a token `ranges` bound on an earlier pass — where the walk
-  re-enters across the `JOINER` pair and finds `DIGIT` on both effective neighbours — presents to
-  `dashes` with digit-flanked `leftCp`/`rightCp` exactly as an unbound one would, and `dashes`
-  declines it on the same unconditional test. `dashes` cannot strip a binding it never
-  reconsiders, and cannot create one, since it never emits `JOINER`.
+- **A range candidate is never reinterpreted as parenthetical, on any pass.** The candidacy test
+  that routes a token to `ranges` instead of `dashes` (§1, §3.3, [ranges.md](ranges.md) §3.2,
+  §3.2a) is evaluated after the joiner-crossing walk (§3.2a), so a token `ranges` bound on an
+  earlier pass — where the walk re-enters across the `JOINER` pair and finds a candidate on both
+  effective neighbours — presents to `dashes` exactly as an unbound one would, and `dashes`
+  declines it on the same unconditional test. Since spec 1.3.0 that test reads `cp[L']`/`cp[R']`,
+  so a bound range carrying closed-up symbols re-enters on the same footing as an all-digit one.
+  `dashes` cannot strip a binding it never reconsiders, and cannot create one, since it never
+  emits `JOINER`.
 - **`dashes`' own edits cannot flip a *neighbouring* range token's guard verdict on the next
   pass, even though `dashes` itself never reads that token's guards.** The one edit shape that
   could — a tight token becoming spaced, inserting a U+0020 next to a digit run that has another
   dash on its far side — is exactly what the spacing-transition guard (T1, §3.2 step 8) declines.
+  **This clause is true of spec 1.3.0 only because step 8 was amended with it**: ranges.md §3.2a
+  widened "next to a digit run" to "next to a range member", which may carry one `CLOSED-SYMBOL`
+  at either end, and an unamended T1 reads that symbol as the neighbour and stops one code point
+  short of the dash. Four witnesses made the gap concrete — `a—$15-$20`, `35%-50%—b`, `a--15% - 20%` and
+  `$1 - $1--a`, one per position and side — each of which drifted on the second pass before the
+  amendment and each of which now behaves exactly as its all-digit analogue always has.
   This is `dashes`' composition obligation *toward* `ranges`, symmetric to the rule-order argument
   in [ranges.md](ranges.md) §4: `ranges` must not see an adjacency `dashes` disturbed, and T1 is
   how `dashes` upholds that on every subsequent pass. The full historical derivation of why this
@@ -1097,7 +1183,12 @@ form to be `-spaced`. In other words: `A` is tight, `A` is about to become space
 only, the configuration T1 (§3.2 step 8) declares inert. The mirrored argument gives the `after`
 side. T1's two-code-point reach is exactly what the case requires and no more: `T`'s dash sits at
 distance 1 from `Lrun` if `T` is tight and distance 2 if `T` is spaced, and a `-spaced` replacement
-inserts exactly one U+0020, so no other distance is reachable. The reverse flip — `before` going
+inserts exactly one U+0020, so no other distance is reachable. **Spec 1.3.0 leaves that reach at
+two code points and makes it transparent to one `CLOSED-SYMBOL` at each of two positions**
+(§3.2 step 8): the symbol moves where the reach starts, never how far it goes, because
+ranges.md §3.2a consumes at most one symbol per side. `JOINER` does not add a position either:
+it is transparent to this reach by §3.2b, on both branches, so a joiner run between the symbol
+and the dash collapses rather than counting. The reverse flip — `before` going
 from a space to a dash — is benign and needs no guard: it turns a G2 admission into a G2
 rejection, and a rejection emits nothing, so a token converted on an earlier pass simply keeps the
 form it was given.

data/lib/polytypo/data/rules/ellipsis.md

@@ -0,0 +1,271 @@
+# Rule: `ellipsis`
+
+**Order:** 20. **Default:** on. **Modes:** text, html, markdown, yaml.
+**Spec version:** 0.1.0.
+
+---
+
+## 1. Purpose
+
+`ellipsis` replaces a typed run of full stops with the single character U+2026 (…), and
+implements the abbreviated form that some locales use when an ellipsis follows terminal
+punctuation — Russian writes `?..` and `!..` with two dots rather than three, because the
+question mark or exclamation mark already occupies the first position of the three-dot
+group. The rule is intentionally narrow: a run of exactly two full stops is _never_ touched,
+because `..` occurs in relative paths, in version ranges and in numeric ranges written by
+programmers, and converting it would be a false positive of exactly the class that blocks
+the ship gate (PLAN.md M4). Everything this rule does is a pure function of a maximal run of
+dot-like characters plus, at most, the one code point to its left.
+
+---
+
+## 2. Locale data consumed
+
+- `ellipsis.abbreviatedAfterTerminal` — boolean, required by `locale.schema.json`.
+
+**Evidence for locale data.** A locale attests **membership** — which tokens, which enum value, which boolean — and the rule owns the **mechanism** applied to them. A `sources` citation is not required to name a code point or a behaviour the locale file has no way to vary. Stated once, normatively, in [nbsp.md](nbsp.md) §2.1; it governs every locale field.
+
+Nothing else. In particular this rule does not read `nbsp` or `quotes`.
+
+---
+
+## 3. Algorithm
+
+Input is a code-point array `cp[0 … n-1]`.
+
+### 3.1 Character classes
+
+| Class      | Members                      |
+| ---------- | ---------------------------- |
+| `DOT`      | U+002E (full stop)           |
+| `ELL`      | U+2026 (horizontal ellipsis) |
+| `DOTLIKE`  | `DOT` ∪ `ELL`                |
+| `TERMINAL` | U+0021 (!) and U+003F (?)    |
+
+No other character is examined. U+2025 (‥, two-dot leader), U+22EF, U+FE19 and the CJK
+leaders are **not** members of any class and are never produced or consumed.
+
+### 3.2 Ordering dependency
+
+`spaces` (order 10) has already run and has deleted every U+0020 that stood immediately before
+a **lone** U+002E. Consequently the spaced form `". . ."` reaches this rule as `"..."` and is
+handled by the ordinary run logic. This rule therefore never needs to look across spaces, and
+must not try to.
+
+The word _lone_ is load-bearing and was added after a defect. `spaces` does **not** strip a
+space before a run of two or more dots (`spaces.md` §3.4), so `"e.g. .."` and `"See ../docs"`
+arrive here with their spaces intact. Before that condition existed the space vanished, the
+two-dot run merged with the abbreviation's full stop into a three-dot run, and this rule then
+correctly converted it — producing `e.g…` from input that §4 below promised to leave alone.
+Neither rule was misbehaving; the protection simply was not true of the pipeline.
+
+### 3.3 Scan
+
+1. Set `i = 0`.
+2. If `cp[i]` is not in `DOTLIKE`, set `i = i + 1` and repeat. Terminate at `i = n`.
+3. Find the maximal run: `s = i`; `e` = the smallest index `> s` with `cp[e]` not in
+   `DOTLIKE` (or `e = n`). Let `k = e - s`, and let `d` = the number of `DOT` members and
+   `q` = the number of `ELL` members in the run (`d + q = k`).
+4. **Classify the run.**
+   - `k = 1` and `d = 1` → an ordinary full stop. Emit nothing. Go to 7.
+   - `k = 1` and `q = 1` → an existing ellipsis. Go to 6 (it may still need the abbreviated
+     form).
+   - `k = 2` and `q = 0` → **two full stops.** Go to 5.
+   - `k ≥ 2` and `q ≥ 1` → a mixed or repeated run (`"…."`, `"……"`, `"..…"`). Normalise:
+     emit an edit replacing `cp[s … e-1]` with one U+2026. Set the run to that single
+     U+2026 and go to 6.
+   - `k ≥ 3` and `q = 0` → three or more full stops. Emit an edit replacing
+     `cp[s … e-1]` with one U+2026. Set the run to that single U+2026 and go to 6.
+5. **The two-dot case.** Let `left = cp[s-1]` if `s > 0`, else `NONE`.
+   - If `ellipsis.abbreviatedAfterTerminal` is `true` → emit nothing, unconditionally. In
+     such a locale `"?.."` is the _correct_ output form and must survive re-processing.
+   - If `ellipsis.abbreviatedAfterTerminal` is `false` **and** `left` is in `TERMINAL` →
+     emit an edit replacing `cp[s … e-1]` with one U+2026. (`"?.."` in an English text is a
+     typing slip for `"?…"`.) Go to 7; step 6 cannot fire because the locale flag is false.
+   - Otherwise → emit nothing. This is the branch that protects `"../"`, `"1..5"` and
+     `"a..b"`.
+     Go to 7.
+6. **Abbreviated-after-terminal form.** The run is now a single U+2026 at position `s`
+   (either pre-existing or just produced by step 4).
+   - If `ellipsis.abbreviatedAfterTerminal` is `false` → emit nothing. Go to 7.
+   - Let `left = cp[s-1]` if `s > 0`, else `NONE`. If `left` is **not** in `TERMINAL` →
+     emit nothing. Go to 7.
+   - Otherwise emit an edit replacing the single U+2026 at `s` with the two code points
+     U+002E U+002E. Steps 4 and 6 are stages of one decision about one span: the rule emits
+     **exactly one edit per run**, whose replacement is the final form. `"?..."` is therefore
+     a single edit replacing three U+002E with two U+002E, not two chained edits.
+7. Set `i = e` and go to 2.
+
+### 3.4 Interaction with `!?` and `?!`
+
+`left` in step 6 is a single code point. For `"?!..."` the character left of the ellipsis is
+U+0021, which is in `TERMINAL`, so the abbreviated form fires: `"?!.."`. This matches the
+Russian convention (`«Что?!..»`). No lookbehind beyond one code point is required or
+permitted.
+
+---
+
+## 4. Must not touch
+
+**Scope.** Per [pipeline-idempotency.md](pipeline-idempotency.md) §5.2 each bullet is **[P]** —
+a guarantee of `transform` as a whole — or **[R]** — true of this rule alone. Every bullet here
+is [P], and two of them only became true when `spaces` gained the lone-dot condition.
+
+- **[P] A single U+002E.** Sentence full stops, decimal points, abbreviation dots (`p.`, `z.`),
+  and the dot in `"1.2.3"` are all runs of length 1.
+- **[P] A run of exactly two U+002E**, except in the one narrow case in step 5 where the locale
+  does _not_ use the abbreviated form and the run directly follows `!` or `?`. This protects
+  `"../"`, `"./.."`, `"1..5"`, `"e.g. .."` and every other two-dot idiom.
+  _[P] only since `spaces` gained the lone-dot condition. `"e.g. .."` previously became `e.g…`
+  and `"See ../docs"` lost its space — the run itself was untouched throughout, which is exactly
+  what made the claim look true while the pipeline falsified it._
+- **[P] U+2025 (‥) and the CJK dot leaders.** Not in any class; never produced, never consumed.
+- **[P] Two `DOT` runs separated by anything at all.** Runs are maximal and are never joined
+  across an intervening character. After `spaces` has run, a surviving separator between
+  dots is a no-break space or a tab, i.e. something the author put there deliberately.
+- **[P] Anything in a skipped region.** `"..."` inside a code span or a URL never reaches this
+  rule; the mode adapter removes it. This rule has no code-awareness and must not acquire
+  any.
+- **[P] The spacing around an ellipsis.** Whether `"word …"` should carry a no-break space is
+  `nbsp`'s decision, driven by `nbsp.beforePunctuation` / `nbsp.narrowBeforePunctuation`,
+  which may list U+2026.
+
+---
+
+## 5. Idempotency argument
+
+Write `T` for the rule. The output of `T` contains, at every position where `T` acted, one
+of exactly two forms:
+
+- **Form A: a lone U+2026** whose left neighbour is either absent or not in `TERMINAL`, or
+  whose locale has `abbreviatedAfterTerminal = false`.
+- **Form B: exactly two U+002E** whose left neighbour is in `TERMINAL`, in a locale with
+  `abbreviatedAfterTerminal = true`.
+
+Re-running `T`:
+
+- Form A is a run with `k = 1`, `q = 1`. Step 4 sends it to step 6. Step 6 emits nothing
+  because either the flag is false or `left` is not in `TERMINAL` — both of which are exactly
+  the conditions under which Form A was produced. No edit.
+- Form B is a run with `k = 2`, `q = 0`. Step 5 is reached, and the first branch applies
+  (flag is `true`) → emit nothing, unconditionally. No edit.
+- Runs the rule declined to touch (single dot, two dots outside the special case) are
+  classified identically on the second run, because classification depends only on the run
+  itself and on one left neighbour, neither of which this rule altered — the rule never
+  edits a character outside a `DOTLIKE` run, and a `DOTLIKE` run is never adjacent to
+  another `DOTLIKE` run after `T` (runs are maximal, so merging cannot occur).
+
+Hence `T(T(x)) = T(x)`.
+
+**What had to be fixed.** The naive formulation is _"`...` → `…`, and in Russian `?…` →
+`?..`"_. That is not idempotent, because the output `?..` is a two-dot run which the same
+naive rule's companion clause _"collapse repeated dots"_ would then re-expand — or, in the
+formulation used by several existing libraries, `?..` → `?…` → `?..` → … oscillating.
+Two changes fix it:
+
+1. The two-dot run is **unconditionally inert** when `abbreviatedAfterTerminal` is true. The
+   output form is a fixed point by construction rather than by luck.
+2. The two-dot → ellipsis conversion exists **only** in the complementary locale setting and
+   **only** after terminal punctuation, so the two branches can never both apply to the same
+   text under the same locale. The flag partitions the behaviour; it does not layer it.
+
+---
+
+### Composition obligation
+
+Per [pipeline-idempotency.md](pipeline-idempotency.md) §5. This rule is **R₂**, so the
+obligation runs against `spaces` (R₁) only.
+
+**What this rule emits.** One U+2026 replacing a run of U+002E/U+2026, or two U+002E replacing
+one U+2026. Nothing else: no spaces, no letters, no dashes, and never a code point outside
+`DOTLIKE`.
+
+**Against `I₁` (`spaces`).** Discharged. This rule never emits U+0020, so violations S-a, S-c
+and S-d are unreachable. S-b — a U+0020 whose right neighbour is in `STRIP-BEFORE` — deserves a
+second look, because U+002E and U+2026 are both in `STRIP-BEFORE` and this rule moves them
+about. But every replacement starts at the first code point of the run and the code point to
+its left is unchanged; if that neighbour were a U+0020, `spaces` would already have deleted it
+in the same pass, since the run began with a `DOTLIKE` character then too. Shortening a run
+cannot bring a space into contact with a dot that was not already in contact with one.
+
+**`I₂` in the other direction** is preserved by every later rule trivially: none of them emits
+U+002E or U+2026, and none deletes a code point standing between two dot runs.
+
+---
+
+## 6. Worked examples
+
+`⟶` = no change. Both locale settings are shown because the rule is one of only two whose
+output differs on a boolean.
+
+### `ellipsis.abbreviatedAfterTerminal = false` (en, fi, sv, de, fr, el)
+
+| #   | Input           | Output        | Why                                                                                                                                                                                              |
+| --- | --------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1   | `Wait... what?` | `Wait… what?` | `k = 3`, `q = 0` → single U+2026                                                                                                                                                                 |
+| 2   | `Wait…… what?`  | `Wait… what?` | mixed run normalised                                                                                                                                                                             |
+| 3   | `Really?.. `    | `Really?… `   | two dots after `?` in a non-abbreviating locale                                                                                                                                                  |
+| 4   | `See ../docs`   | ⟶             | two-dot run, left neighbour U+0020 not in `TERMINAL`. **The space also survives**, which is `spaces.md` §3.4's doing, not this rule's — before that condition the pipeline returned `See../docs` |
+| 4a  | `e.g. ..`       | ⟶             | likewise: the space survives, so no three-dot run is ever formed. Previously `e.g…`                                                                                                              |
+| 5   | `Version 1..5`  | ⟶             | two-dot run, left neighbour is a digit                                                                                                                                                           |
+| 6   | `He left…`      | ⟶             | already a lone U+2026                                                                                                                                                                            |
+| 7   | `Hmm.....`      | `Hmm…`        | `k = 5` → one U+2026                                                                                                                                                                             |
+| 8   | `Yes. No.`      | ⟶             | two independent runs of length 1                                                                                                                                                                 |
+
+### `ellipsis.abbreviatedAfterTerminal = true` (ru)
+
+| #   | Input        | Output     | Why                                               |
+| --- | ------------ | ---------- | ------------------------------------------------- |
+| 9   | `Что?...`    | `Что?..`   | run → U+2026 → abbreviated after `?`              |
+| 10  | `Что?…`      | `Что?..`   | existing U+2026 after `?` rewritten               |
+| 11  | `Что?..`     | ⟶          | already the target form; step 5 first branch      |
+| 12  | `Что?!...`   | `Что?!..`  | left neighbour of the run is U+0021               |
+| 13  | `Он ушёл...` | `Он ушёл…` | left neighbour is a letter → ordinary ellipsis    |
+| 14  | `см. ../`    | ⟶          | two-dot run, unconditionally inert in this locale |
+
+Cases 4, 5, 6, 8, 11 and 14 are "no change" cases.
+
+---
+
+## 7. Open questions
+
+1. **Four dots.** Chicago (and several book styles) write `"….",` an ellipsis followed by a
+   sentence-ending period, for an omission at the end of a sentence. This rule collapses
+   `"...."` to a single `"…"`, losing that distinction. Distinguishing the two requires
+   knowing whether the omission ends the sentence, which is not decidable from the code
+   points. I chose collapse; an alternative is to leave runs of exactly four alone. Needs an
+   operator decision and a fixture either way.
+2. **`abbreviatedAfterTerminal` is a single boolean**, so a locale cannot say "abbreviate
+   after `?` but not after `!`". No known locale needs that, but the schema forecloses it.
+   Recorded, not proposed.
+3. **The `!..` / `?..` order.** Russian also uses `"..?"` and `"..!"` in some sources for an
+   ellipsis _preceding_ terminal punctuation. This rule does not implement that direction,
+   and `"..?"` is left alone (two-dot run). Whether Мильчин requires the leading form is a
+   locale-research question, and if the answer is yes, the schema needs a second flag.
+4. _(Partly settled.)_ The `nbsp` asymmetry recorded here is fixed on the `nbsp` side: U+2026
+   is now accepted right context for N1/N2 (`nbsp.md` §3.3 step 2), so French `Vraiment?…`
+   takes its narrow space just as `Vraiment ?` does. What remains open is the original
+   observation — **The interaction with `nbsp` is unspecified from this side.** If a locale lists U+2026 in
+   `nbsp.beforePunctuation`, then `"word …"` gains a no-break space, but the abbreviated
+   Russian form `"?.."` ends in U+002E and would not. That asymmetry may or may not be
+   correct; it is a question for the `ru` locale file, not for this rule.
+5. **Two dots in a non-abbreviating locale after `?`/`!`** (case 3) is the only place this
+   rule converts a two-dot run. It is conservative and safe, but it is also the only asymmetry
+   in the rule. If it produces a false positive in real content, deleting the branch costs
+   nothing.
+6. **Greek forbids a space before the ellipsis; polytypo preserves it anyway.** The EU
+   Interinstitutional Style Guide (Greek edition) §10.1.9 ii) — «Μεταξύ των αποσιωπητικών και της
+   λέξης που προηγείται δεν αφήνουμε διάστημα» — is verified against the source and is not
+   honoured. `spaces.md` §3.4 preserves a space before a dot run in every locale, so `Πράγματι …`
+   comes back as typed.
+
+   The full argument is in `spaces.md` §7.9 and is not repeated; the part that belongs **here** is
+   why this rule does not fix it instead. This rule reads locale data and could carry an
+   `ellipsis.noSpaceBefore` flag, which the schema can express and which fits the declarative-data
+   line of PLAN.md §6. What that would cost is a change of kind, not of degree: **this rule
+   currently only ever replaces one span of dot-like code points with another, and it would become
+   a rule that deletes a character outside its own run.** Deleting brings in `modes.md` §3.3's
+   edge-test clause (a deleting rule must treat a span edge as the end of the text), a new
+   discharge against `I₁`, and a re-derivation of §5's idempotency argument, which currently
+   depends on the run being the only thing touched. That is not worth it for one locale, and it is
+   worth it for two. Recorded so the option is costed rather than forgotten.