Add in paper number and cleanup 4125

Author: MungoG

CLAUDE.md

@@ -17,13 +17,23 @@ Rules for all work on WG21 papers in this repository.
    not read, write, or modify any file in that folder
 7. Padded tables with aligned pipe characters in every table on every rewrite
 8. WG21-appropriate style
-9. `[P####R#](https://wg21.link/p####r#)` link convention for all paper references
+9. Paper reference links must be versioned
+   (e.g. `[P4003R0]` not `[P4003]`). Use
+   `[P####R#](https://wg21.link/p####r#)` when the wg21.link
+   URL resolves. If wg21.link gives a 404 for a specific
+   version (e.g. pre-mailing papers), use the isocpp.org URL
+   instead (e.g. `https://isocpp.org/files/papers/P4007R1.pdf`).
+   All paper links must be verified to return a non-404 response
+   before the paper is considered complete
 10. Paper titles on first mention
 11. Backticks for code identifiers in headings
+12. All hyperlinks in the document must resolve to a non-404
+    response before the paper is considered complete. This
+    applies to all URLs, not only WG21 paper references
 
 ## Front Matter
 
-12. Every paper begins with a valid YAML front matter block
+13. Every paper begins with a valid YAML front matter block
     delimited by `---`. Required and optional fields:
 
     ```yaml
@@ -45,58 +55,64 @@ Rules for all work on WG21 papers in this repository.
       strings in the form `"Name <email>"`
     - `audience` - required, unquoted comma-separated
       target audience (e.g. SG1, LEWG)
-13. Do not add front matter fields that the Pandoc template
+14. Do not add front matter fields that the Pandoc template
     (`tools/wg21.html5`) does not consume
 
 ## Language and Grammar
 
-14. American English unless otherwise specified
-15. Follow the Chicago Manual of Style unless otherwise specified
-16. Use the Oxford comma
-17. Avoid dangling "This" - every sentence beginning with "This" must
+15. American English by default. If a paper already uses
+    British/Irish English consistently (e.g. "organisation",
+    "behaviour", "generalise"), preserve that convention -
+    do not convert to American English. When in doubt, check
+    the existing spelling in the file before editing.
+    Papers where Mungo Gill is the sole author use Irish
+    English
+16. Follow the Chicago Manual of Style unless otherwise specified
+17. Use the Oxford comma
+18. Avoid dangling "This" - every sentence beginning with "This" must
     have a clear, unambiguous antecedent. If "This" could refer to
     more than one thing, replace it with a specific noun phrase
-18. Do not end sentences with a preposition in formal papers -
+19. Do not end sentences with a preposition in formal papers -
     e.g. "worth building upon" not "worth building on"
-19. "bound" = attached/tied to; "bounded" = limited -
+20. "bound" = attached/tied to; "bounded" = limited -
     e.g. "an allocator bound to that tenant's quota"
-20. Possessive before a gerund -
+21. Possessive before a gerund -
     e.g. "coroutines' interacting" not "coroutines interacting"
-21. "may" = permitted/possible; "might" = hypothetical/enabled but
+22. "may" = permitted/possible; "might" = hypothetical/enabled but
     not currently supported. Use precisely
-22. Prefer "deeper" or "more thorough" over "full" for appendix
+23. Prefer "deeper" or "more thorough" over "full" for appendix
     cross-references. Understatement is better than hyperbole
-23. Headings must not contain a dangling "This" - replace with a
+24. Headings must not contain a dangling "This" - replace with a
     specific noun phrase. e.g. "ABI Lock-In Makes the Architectural
     Gap Permanent" not "ABI Lock-In Makes This Permanent"
-24. Transitive verbs must not leave their object implicit when the
+25. Transitive verbs must not leave their object implicit when the
     referent is not immediately obvious. Supply the object explicitly.
     e.g. "forgetting to forward the allocator" not "forgetting to
     forward"
-25. Avoid ambiguous prepositional attachment. When a prepositional
+26. Avoid ambiguous prepositional attachment. When a prepositional
     phrase could modify either a nearby noun or the main verb,
     restructure to make the attachment clear.
     e.g. "The allocator - along with its state - must be
     discoverable" not "The allocator - with its state - must be
     discoverable" (where "with its state" could attach to
     "discoverable")
-26. Place "only" immediately before the word, phrase, or clause it
+27. Place "only" immediately before the word, phrase, or clause it
     modifies to avoid ambiguity.
     e.g. "provides only one mechanism" not "only provides one
     mechanism"
-27. Do not use contractions (it's, they're, don't, etc.) in formal
+28. Do not use contractions (it's, they're, don't, etc.) in formal
     papers. Use the expanded form
 
 ## Code Examples
 
-28. Consistent comment style within a code block - either all
+29. Consistent comment style within a code block - either all
     comments are sentences (capitalized, with terminating punctuation)
     or all are fragments (lowercase, no period). Do not mix
-29. Consistent capitalization in groups of code comments that
+30. Consistent capitalization in groups of code comments that
     summarize arithmetic or data
-30. Align trailing comment columns when consecutive lines have
+31. Align trailing comment columns when consecutive lines have
     trailing comments
-31. Fenced code blocks must not exceed 90 characters per
+32. Fenced code blocks must not exceed 90 characters per
     line. This rule does not apply to mermaid blocks -
     never reformat mermaid source. When wrapping is
     needed, follow the conventions for the block's
@@ -113,7 +129,7 @@ Rules for all work on WG21 papers in this repository.
       before the operator, align operators vertically
     - Trailing comments: shorten the gap between code and
       comment rather than wrapping the code, but keep
-      grouped comments aligned with each other (rule 30)
+      grouped comments aligned with each other (rule 31)
     - If a trailing comment still exceeds 90 characters
       after tightening the gap, wrap the comment text to
       a second line. The continuation `//` must align
@@ -126,22 +142,22 @@ Rules for all work on WG21 papers in this repository.
 
 ## Lists
 
-32. Always insert a blank line before a bullet or numbered list.
+33. Always insert a blank line before a bullet or numbered list.
     Pandoc does not recognise a list that immediately follows a
     prose line without a separating blank line - the items render
     as inline text in both HTML and PDF
 
 ## Structure
 
-33. Sections with subsections should have at least one introductory
+34. Sections with subsections should have at least one introductory
     sentence between the section heading and the first subsection
     heading - do not leave an empty section heading
-34. Every paper must contain a `## Revision History` section,
+35. Every paper must contain a `## Revision History` section,
     placed immediately after the Abstract's trailing `---` and
     before Section 1. Each revision is an H3 subheading in the
     form `### R<n>: <Month> <Year> (<pre-Meeting mailing>)`
     followed by a bullet list of changes
-35. References and citations - for readers of printed copies:
+36. References and citations - for readers of printed copies:
     - Every hyperlink in the document body must also appear
       in the References section
     - Every hyperlink in the document body must have a
@@ -154,7 +170,7 @@ Rules for all work on WG21 papers in this repository.
       `eel.is/c++draft/` sections, one entry for the NB
       ballot repository covering individual issue links
     - Use `wg21.link` short URLs for WG21 papers - do not
-      use `open-std.org` long-form URLs (see rule 9)
+      use `open-std.org` long-form URLs (see rules 9 and 12)
     - Links inside markdown tables are exempt from citation
       markers (tables are dense reference lists where
       superscripts would harm readability)
@@ -167,7 +183,7 @@ Rules for all work on WG21 papers in this repository.
 
 ## Proposed Wording Sections
 
-36. Proposed wording uses Pandoc fenced divs and HTML
+37. Proposed wording uses Pandoc fenced divs and HTML
     `<ins>`/`<del>` elements styled by `tools/paperstyle.css`.
     Three div classes are available:
 
@@ -189,7 +205,7 @@ Rules for all work on WG21 papers in this repository.
     code blocks for code changes. Always use the inline
     `<ins>`/`<del>` convention described here instead
 
-37. Fenced div formatting rules:
+38. Fenced div formatting rules:
 
     - No space between `:::` and the class name:
       `:::wording` not `::: wording`
@@ -201,7 +217,7 @@ Rules for all work on WG21 papers in this repository.
     - Markdown formatting (`*italic*`, `` `code` ``)
       works normally inside wording divs
 
-38. Code diffs in wording sections use raw HTML
+39. Code diffs in wording sections use raw HTML
     `<pre><code>` blocks (not fenced `` ``` `` blocks)
     inside a `:::wording` div, with `<ins>` and `<del>`
     for inline changes. Angle brackets in code must be
@@ -223,18 +239,18 @@ Rules for all work on WG21 papers in this repository.
 
 ## Tone
 
-39. Do not present options as predetermined conclusions. When
+40. Do not present options as predetermined conclusions. When
     recommending alternatives to a committee, present them as options
     to contemplate, not dictated outcomes
-40. Avoid politically charged comparisons - do not invoke other
+41. Avoid politically charged comparisons - do not invoke other
     contentious features as analogies unless the comparison is
     structurally precise. If the structures being compared are
     fundamentally different, the analogy will be perceived as
     political
 
 ## Abstract
 
-41. Every abstract opens with a single sentence on its own line -
+42. Every abstract opens with a single sentence on its own line -
     the brutal summary. No citations, no paper numbers, no
     hedging. The sentence must be true, complete, and
     unsentimental. It is the sentence a reader remembers after