Define the 38 issue link references the CHANGELOG used but never declared

[erikdarlingdata]

What

CHANGELOG.md uses Markdown shortcut references like ([#2794]) throughout, with the definitions collected in append-ordered blocks toward the bottom. Some are used in prose but never defined, so GitHub renders them as literal [#1696] bracket text instead of links. This PR adds the missing definitions.

This is worst where the reference is the citation and there is no other link to the work:

plan_correction collector: OPTION(RECOMPILE) restored ... - [#2760] removed both hints on the theory that ...

The count is 38, not 37 — re-derived on current dev

The original measurement (37) was taken at 13:06Z. dev has since moved by eleven merges. Re-derived on dev at 6e9d9a1b:

$ git show origin/dev:CHANGELOG.md | tr -d '\r' > dev.md
$ grep -o -P '^\[#[0-9]+\]:'  dev.md | grep -o -P '[0-9]+' | sort -u > defined.txt
$ grep -o -P '\[#[0-9]+\](?!:)' dev.md | grep -o -P '[0-9]+' | sort -u > used.txt
$ wc -l < defined.txt   # 1061
$ wc -l < used.txt      # 1097
$ comm -23 used.txt defined.txt | wc -l
38

38 undefined, not 37. The new one is [#2847], cited by the [#2902] bullet that merged to dev today without its own definition. The other 37 are unchanged:

1696, 1944, 2018, 2026, 2061, 2266, 2538, 2543, 2544, 2545, 2547, 2561, 2565, 2566, 2567, 2593, 2595, 2599, 2603, 2612, 2617, 2623, 2625, 2626, 2629, 2630, 2633, 2636, 2638, 2640, 2641, 2643, 2645, 2651, 2686, 2689, 2760, 2847

On the merged result: 1097 used; 1099 defined; 0 undefined.

All 38 confirmed to exist via the API — 34 issues, 4 pull requests (#2018, #2026, #2547, #2686), none missing. No false positives: zero [#N](url) inline links anywhere in the file, and zero of the 38 appear only inside code fences, so all 38 really were rendering as dead text.

Note grep -E (and git grep -E) do not implement \b/\s here and return zero matches silently; every count above was taken with grep -P and cross-checked against an independent Python pass, each with a positive control.

Why uniform /issues/NNNN, including for the 4 PRs

The file holds both forms (770 /issues/, 294 /pull/ on current dev) and the distinction is not maintained: /issues/ definitions that are themselves PRs are routine (#2773, #2785, #2792, #2796, #2803, #2822). GitHub redirects /issues/N to /pull/N, so all 38 resolve either way, and uniform /issues/ matches the file's dominant practice.

Correction to the earlier revision of this description, which claimed the /pull/ form "stops at #2770": that is no longer true. dev now carries [#2890]: .../pull/2890 and [#2901]: .../pull/2901. The form is still not consistently applied, so the reasoning above stands, but the specific claim did not.

Merged dev in and resolved additively

dev was merged in (this repo's convention — no rebase, no force-push). The single conflict was in CHANGELOG.md, where both sides appended to the tail definition block: this branch 37 definitions, dev 10. Resolution keeps every definition and every bullet from both sides. Net effect versus dev is 38 insertions, 0 deletions, 1 file.

Bullet resolution takes dev's wording wholesale, which is the correct additive result here and worth spelling out: this branch is a byte-exact 37-line pure append onto the merge base and changes no bullet, so its bullet set is the base's. A literal union-of-content would therefore have reverted four bullets dev has since edited — and two of those still carry fleet identifiers that dev has since scrubbed. Verified structurally: zero conflict markers (CR-tolerant grep, positive control passed), [Unreleased] retains exactly one each of ### Added / ### Changed / ### Fixed, bullet set equality against both merge parents, definition set equality against both parents with exactly one addition ([#2847]), and byte-identical first three bytes (232043, no BOM) against origin/dev.

What was deliberately left alone

• Pre-existing duplicate definitions are untouched. There are three, not two: [#828], [#887], and [#2860]. [#2860] is duplicated on dev itself (absent from the merge base and from this branch before the merge), so it arrived from dev today; both of its lines are byte-identical. Not in scope here.
• Nothing reordered or deduped. The definitions are appended at the end, after dev's own newest ones, preserving the file's append order.
• No CHANGELOG entry for this change. An entry would add another [#NNNN] reference needing its own definition, which is the thing being fixed; a link-reference repair with no behaviour change doesn't warrant one.

Line endings

Staged with a plain git add, no hash-object escape hatch — that hatch re-commits a CRLF blob and would reintroduce what #2858 fixed. Verified: blob stays pure LF (0 CR bytes, 3244 → 3282 lines), working copy stays pure CRLF per .gitattributes * text=auto eol=crlf (3282 of 3282 lines), and the file gains no BOM.

Provenance

Pre-existing; found incidentally while landing #2885, not caused by it. Docs-only — no code, no tests, no schema rung.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

🤖 Generated with Claude Code

[claude]

Reviewed. This is a docs-only, purely additive change to CHANGELOG.md (37 insertions, 0 deletions per the raw diff) — no code, so the T-SQL style guide and Lite/Darling parity requirements don't apply here.

Verified independently:

• All 37 newly-defined [#NNNN]: references land inside the existing (already non-numerically-sorted) trailing link-reference block, consistent with how that block is already ordered elsewhere (e.g. #2871, #2828, #2837, #2870, #2884, #2864... right before this addition) — appending in ascending order isn't a deviation from any enforced convention.
• No new duplicate definitions introduced: grep -oE '^\[#[0-9]+\]:' CHANGELOG.md | ... | uniq -d still returns only the pre-existing #828/#887 dupes called out in the PR description.
• All 37 added numbers are present in the file's definition list, and the diff contains zero removed lines, matching the PR's stated intent of leaving prior bytes untouched.

No correctness, security, or performance concerns. Nice reproducible verification script in the description.

[claude]

Reviewed. This is a clean, low-risk, docs-only fix — no T-SQL, no Lite/Darling code touched, so the usual style/parity/security/perf checks don't apply here.

Verified independently:

• git diff origin/dev HEAD -- CHANGELOG.md is exactly 38 insertions / 0 deletions, all appended at the tail — matches the PR description precisely.
• None of the 38 new numbers collide with an existing [#NNNN]: definition (no new duplicates introduced).
• Spot-checked several of the newly-defined refs (#1696, #2547, #2760) against their prose usage — they're genuine in-text citations that were previously rendering as dead [#NNNN] text, now correctly resolve.
• File stays pure CRLF (file CHANGELOG.md confirms), consistent with the .gitattributes policy from Renormalize the five CRLF blobs to match .gitattributes (Fixes #2857) #2858.

One minor nit on the PR description, not the diff itself: it says "[#828] and [#887] are still duplicated" as the only pre-existing dupes left alone. There's actually a third one, [#2860], also pre-existing on dev (confirmed via git show origin/dev:CHANGELOG.md), also untouched by this PR, also a harmless dupe (identical URL both times). Doesn't affect the change — just flagging so the description's inventory is accurate if anyone relies on it later.

No blocking issues found.