Name the collation for the reference-definition sort order

[ptr727]

"Alphabetized by reference name" is ambiguous wherever one label is a prefix of another, and the two readings disagree on that pair alone. Sorting the bare label puts [governance] first, while sorting the whole definition line puts [governance-branching-model] first, because - (0x2D) precedes ] (0x5D). A block ordered either way is internally consistent, so a reviewer reads the other one as a defect and asks for a re-sort on every pull request that touches a definition block.

The reading is already in the tree

Every reference-definition group this repository carries, twelve of them across ten files, sorts by the bare label. [governance] above [governance-branching-model], [repo-config] above [repo-config-settings], [vscode-tasks] above [vscode-tasks-python]. None sorts by the line. The rule's own wording says "by reference name", so the bare label is both what the sentence says and what the corpus does, and the line reading would mean re-sorting README.md, AUDIT.md, CODESTYLE.md, STANDUP.md, TODO.md, and five more against a rule that never asked for it.

GOVERNANCE.md now names the key rather than leaving it inferred: the text inside the brackets, never the whole line, so a shorter name sorts above one it prefixes. It also records the trap, which is that a plain sort -c over the block passes on the inverted order, since that command compares the line. A block can therefore be mechanically "sorted" and still be wrong, which is how a consistent block reaches review.

spec/readme-structure.md restates the same rule for a repository that reads the spec without the governance file, so it carries the key too. Leaving it at "alphabetized within each group" would hand the same guess to exactly the reader who has nothing else to check against.

Two blocks were unsorted under either reading

WORKFLOW.md and docs/repo-config-carry.md each carry a <!-- Repo --> group ordered by neither collation. Both are fixed here, so the canonical satisfies the rule it states.

Verification

prose_lint.py --diff, repo_gate.py, and markdownlint-cli2 are clean over the change, and a scan of every definition group in the tree reports zero violating the stated order.

GOVERNANCE.md is verbatim-carried, so a fleet re-vendor is owed.

Fixes #583.

[Copilot]

Pull request overview

This PR removes ambiguity in how reference-link definition blocks are alphabetized by explicitly naming the collation key (the reference name inside [], not the full definition line), and it brings a couple of existing definition groups into compliance with that clarified rule.

Changes:

• Clarify in GOVERNANCE.md that reference-link definitions are sorted by the reference name alone (so prefix pairs sort with the shorter name first).
• Mirror the same clarification in spec/readme-structure.md for spec readers who may not consult governance text.
• Fix two <!-- Repo --> definition blocks (WORKFLOW.md, docs/repo-config-carry.md) to match the stated ordering.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
WORKFLOW.md	Reorders <!-- Repo --> reference definitions to match the clarified reference-name collation.
spec/readme-structure.md	Specifies the exact sort key for reference-link definition blocks (reference name only).
GOVERNANCE.md	Defines the collation rule explicitly and documents why line-sorting is a trap for prefix pairs.
docs/repo-config-carry.md	Reorders <!-- Repo --> reference definitions into correct reference-name sort order.