docs-hygiene(rename-references): Form 14 is case-sensitive, so a title-cased heading falls through to a LESS safe classification

[kyle-sexton]

Observation

rename-references Form 14 (document title / declared name, added in #1386) is case-sensitive:

^#{1,6}\s+`?<old>`?\s*$
^(name|title):\s*("<old>"|'<old>'|<old>)\s*$

A container whose own README titles itself in title case — # Re-Anchor for a plugin named re-anchor, or # Testing for testing — is missed by Form 14 entirely.

The consequence is not merely a miss. Form 14 is what routes a title match through its scope rule (Certain only in container-owned files, always Ambiguous for a common-word token). When Form 14 does not fire, the line falls through to bare-token Form 2 instead, which — for a token absent from the English-verb blocklist — defaults to Certain. So a title-cased heading gets a less safe classification than a lowercase one, which inverts the intent.

Raised as a minor note during #1386's review and deliberately not fixed there.

Why it was not fixed inline

The obvious patch — make Form 14 case-insensitive — is wrong on its own. #1386 established (with verified in-repo examples) that Form 14 over-reaches on ordinary-word container names: renaming a testing plugin already matches README.md:86 (### Testing, a marketplace category heading), and architecture matches plugins/miro/README.md:39. Adding case-insensitivity widens that blast radius to every casing variant of a common word in every document, which is precisely the over-reach the scope rule was added to bound.

Fixing it correctly means the scope rule has to be load-bearing first — the constraint that keeps a title match Certain only in container-owned files must be reliable enough that widening the match set is safe. That is a design question, not a regex tweak, so it earns its own issue rather than a half-fix.

Direction (open decision — not settled)

Candidates, in rough order of preference:

1. Case-insensitive matching gated on the scope rule. Match any casing, but rate Certain ONLY inside container-owned files, and Ambiguous everywhere else regardless of token shape. Leans entirely on the scope rule being correct.
2. Case-insensitive only when the token is not an ordinary English word. A coined or hyphenated name (re-anchor) has no legitimate title-case prose sense, so widening is safe; a common word does. Needs a word-shape test the skill does not currently have.
3. Leave case-sensitive, document the gap explicitly on the form, so a reader knows a title-cased heading needs a manual pass. Cheapest, and honest, but leaves the Form 2 fall-through inversion in place.

Whichever is chosen, the Form 2 fall-through is the part that must not survive: a heading that Form 14 declines to match should not thereby become more likely to auto-apply.

Acceptance

• Form 14's casing behavior is stated explicitly in context/patterns.md, whatever the resolution.
• A title-cased heading no longer receives a less safe classification than its lowercase equivalent.
• Validated on both axes per patterns.md "Phase 6" — recall against a real fixture, precision reported beside bare-token Form 2's count on the same tree.
• An eval case covers the title-cased heading path.

Collision risk

Searched open and closed issues for rename-references, Form 14, case-sensitiv, title. Nothing covers this. #1283 is the parent (the pattern-library gap that introduced Forms 13–15); this is a follow-on from #1386's review, not a duplicate of it.

[kyle-sexton]

This was generated by AI during triage.

Triage result: verified, briefed, human-gated

Role-label resolution: .work-item-tracker.json has no config.role_labels entry — resolving human-gated to its documented default needs-human, applied below.

Verification

The claim is confirmed, but not against main — Form 14 does not exist there yet. It exists only on the still-open PR #1386 (branch fix/1283-rename-references-position-forms-v2), which introduces it:

^#{1,6}\s+`?<old>`?\s*$
^(name|title):\s*("<old>"|'<old>'|<old>)\s*$

Neither line carries an (?i) flag or case-folding, so a title-cased heading (# Re-Anchor for a lowercase re-anchor token) does not match Form 14. Per patterns.md's Phase 0 precedence rule, a line Forms 13–15 don't match falls through to Form 2's bare-token blocklist check, which defaults Certain for any token absent from the English-verb blocklist — confirming the reported inversion (title-cased heading rated less safely than the lowercase form).

Dependency correction (not a same-decision cluster)

The launch context described "two live branches." That's stale: PR #1335 (fix/1283-rename-references-position-forms, the original) is closed, superseded by PR #1386 (…-v2), which is the only open branch. There is one live branch, not two, so there's no concurrent-branch race to reconcile.

What's real is a hard dependency, not a collision: #1394 patches code (Form 14) that only exists on #1386's branch. It cannot be verified or fixed against main until #1283/#1386 lands. Recorded as a native edge: #1394 blocked-by #1283.

This is not a cluster member of #1283 despite the shared file — #1283's design is settled and shipping as-is; #1394's decision space (below) stays open after #1283 merges, so it keeps its own human-gated routing rather than riding #1283's resolution.

Why human-gated

The issue body itself frames this as an open design decision, not a mechanical fix — the author explicitly ruled out the obvious patch (blanket case-insensitivity) as unsafe on its own, since it would widen Form 14's match set to every casing variant of a common word (concrete false-positive precedent: testing, architecture already over-match on ordinary words per #1386's review). Three candidates are offered with real tradeoffs and no clear winner:

1. Case-insensitive matching, safety leaning entirely on the scope rule (container-owned-files-only) being reliable
2. Case-insensitive only for non-ordinary-word tokens — needs a word-shape test the skill doesn't currently have
3. Leave case-sensitive, document the gap — cheapest, but leaves the Form 2 fall-through inversion live

Candidate 2 requires building a capability (word-shape/part-of-speech test) that doesn't exist yet. This is exactly the "open design space" criterion for human-gated: a maintainer needs to pick a direction before an agent can implement it safely.

Agent Brief

Type: Task (no native Issue Type on this repo; no type: label axis in the live label set — omitted)

Summary: Form 14 (document-title/declared-name pattern) in the rename-references pattern library is case-sensitive, so a title-cased heading falls through to Form 2's bare-token check and gets a less-safe (Certain) classification than the same heading in lowercase would — an inversion of intent. This is a design decision on how to widen Form 14's matching, not a regex tweak; a maintainer must pick a direction (see the three candidates in the issue body) before implementation proceeds. Depends on #1283 landing first — Form 14 doesn't exist on main yet.

Current behavior: A container-title heading matching <old> in a non-matching case is missed by Form 14 entirely, falls through to Form 2, and — when the token isn't in the static English-verb blocklist — is rated Certain instead of receiving Form 14's scope-gated (container-owned-files-only) rating.

Desired behavior: A title-cased heading naming the renamed token never receives a less safe classification than its lowercase equivalent would. The chosen direction must not widen Form 14's false-positive exposure on ordinary-word container names (the exact regression #1386's review caught and scoped Form 14 against).

Key interfaces:

• Form 14's regex pair in the pattern library (document-title / frontmatter name-or-title forms)
• The scope rule that gates Form 14's triage default to Certain only in container-owned files
• The English-verb blocklist Form 2 falls through to

Acceptance criteria:

• Form 14's casing behavior is stated explicitly in the pattern library, whatever direction is chosen
• A title-cased heading no longer receives a less-safe classification than its lowercase equivalent
• Validated on both recall (against a real fixture) and precision (reported beside bare-token Form 2's count on the same tree), per the pattern library's evolution-phase validation step
• An eval case covers the title-cased heading path
• The skill's quality-check gate passes

Out of scope:

• Rebuilding Form 2's English-verb blocklist mechanism generally
• Any change to Forms 1–13, 15, or the container-position forms docs-hygiene(rename-references): pattern library misses command-argument and document-title forms (6 stale refs survived 3 sweeps in #1276) #1283 introduces
• Building a general word-shape/part-of-speech classifier beyond what candidate 2 (if chosen) strictly needs

Decision needed from a maintainer: which of the three candidate directions in the issue body to implement (or a fourth). Once picked, this becomes a bounded, delegable fix.