Retire "handle" from functional-spec prose in favour of "ID"

[vjovanov]

What is missing

The functional spec still says handle where §FS-terms.terms.1 says ID. Sweep it, in one pull request that answers for this word and for nothing else.

• Row: §FS-terms.terms.1 — "ID — The stable name: kind and slug, with a number where the format has one. Displaces handle."

• Size: 24 occurrences across 8 functional-spec file(s), 2 of them in a heading title. Measured at 4b2b647aaa. The raw grep -c is 29 and is not the number to plan from. Per file: FS-fmt.md (7), FS-config.md (6), FS-rules.md (4), FS-values.md (2), FS-workspace.md (2), FS-check.md (1), FS-lsp.md (1), FS-show.md (1).

• Carve-outs: The verb is kept — "check handles a missing file", "handling a refusal" — which is most of the raw count. And there is a live second sense to rule on before rewriting: §FS-config.3.2.7 is titled "named_sections — the gate for section handles" and §FS-fmt.6.2.4 "A named heading's anchor carries its handle", and the AGENTS.md managed block itself says "handles are letter-first lowercase names". A named section's handle is not an ID, so either the row means only the ID-as-a-whole sense and this compound is a carve-out, or the named-section vocabulary is renamed with it. Settle that first; it is exactly the cross-reference trap in a different word.

• Heading titles this renames:

  • FS-config.md:343: #### 3.2.7 named_sections — the gate for section handles
  • FS-fmt.md:331: #### 6.2.4 A named heading's anchor carries its handle

  Each one invalidates every Markdown link fragment reaching it. grund fmt --write repairs them in the same change (§FS-fmt.6.3). No coordinate moves — no retired word appears in a named section handle — so every §ID.section citation still resolves.

• Also in scope: whatever this change breaks, wherever it lives, including README.md (§FS-examples.4 → §REQ-readme.2). Prose in docs/architecture/, in a released changelog under docs/changelog/, and in the frozen GOAL, REQ and decision-record texts is not — those keep the words they have (§FS-terms, FS-terms.md:38-45); grund fmt --write still repairs their link fragments.

• Claims: this word and nothing else. It makes no claim about any other retired word, and certifying the completeness of unchanged prose beyond it is not part of the review (§FS-terms, FS-terms.md:62-64).

• Bucket: B — bounded judgement: one dominant retired sense with a named carve-out to respect. Each occurrence is read, but the rule for reading it is stated above.

Why it belongs in this tool

§FS-terms is grund's own specification of what its words mean, and a grund spec that uses a word it retired is the drift that declaration exists to close. FS-terms.md:38-45 says a commissioned pass is a permitted way to pay this debt and that it answers for the words it names — this is one such pass, for one word.

Two things a reviewer should not mistake. grund check exits 0 over every stale link fragment a heading rename leaves behind — an anchor is not a coordinate — so "grund check is green, therefore nothing broke" is wrong here. grund fmt --check names them, --write repairs them, and lychee reports Cannot find fragment independently. And a raw grep -c overstates this sweep by roughly 3× overall (37× on ref), which is why the size above is the measured residual.

What you do today instead

Nothing: the word is retired on paper and stands in the prose. A reader who takes the cheap lead read of a section gets a word the shared vocabulary says is not the word, and has to open FS-terms to find that out — the second file §GOAL-token-economy.1 charges for, and the exact failure §FS-terms says it exists to close.

Worked example: PR #306 (point size → coordinate-size: 11 files, +20/−18, including the heading rename, the nine fragment repairs and README.md). Parent: #291.