Retire "diagnostic" from functional-spec prose in favour of "finding"

[vjovanov]

What is missing

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

• Row: §FS-terms.terms.5 — "finding — one item of a report, or the single item a failed ID query emits on stderr … Displaces diagnostic in prose except where FS-lsp names the protocol object; the internal Diagnostic type is unchanged."

• Size: 148 occurrences across 16 functional-spec file(s), 10 of them in a heading title. Measured at 4b2b647aaa. The raw grep -c is 187 and is not the number to plan from. Per file: FS-check.md (36), FS-lsp.md (34), FS-errors.md (21), FS-output-shapes.md (17), FS-workspace.md (11), FS-cli.md (5), FS-values.md (5), FS-rules.md (4), FS-config.md (3), FS-refs.md (3), FS-show.md (3), FS-distribution.md (2), FS-init.md (1), FS-inline-citation-style.md (1), FS-list.md (1), FS-non-goals.md (1).

• Carve-outs: The row names its own carve-out: FS-lsp.md keeps the word where it names the LSP protocol object (publishDiagnostics, a Diagnostic in the wire sense), and the internal Rust Diagnostic type is untouched. So FS-lsp.md needs reading occurrence by occurrence rather than rewriting, and FS-errors.md is where the prose sense lives.

• Heading titles this renames:

  • FS-check.md:196: ### 1.4 Selecting diagnostics with --onlyand--ignore``
  • FS-check.md:1318: #### 4.11.5 Under --format=json, one warning diagnostic on stderr
  • FS-errors.md:263: ### 4.2 Diagnostic selection
  • FS-errors.md:302: #### 5.2.3 Run-level diagnostics in check's report
  • FS-errors.md:317: ### 5.4 Value diagnostics
  • FS-lsp.md:29: ### 1.1 Diagnostics
  • FS-lsp.md:41: #### 1.1.1 Where a diagnostic anchors
  • FS-lsp.md:69: #### 1.2.2 No preview for a citation with a diagnostic
  • FS-output-shapes.md:12: ## 1. Diagnostic object
  • FS-values.md:107: ## 5. Resolution, diagnostics, and exit status

  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.