prose-mention rule matches the SUFFIX of multi-segment ids: 'CM-TR-001' warns about 'TR-001' (false trace suggested) and is never itself checked

[avrabe]

Found while working in synth (RQ-68-ORACLEABI, pulseengine/synth#1277), rivet 0.32.0; the regex is unchanged on main at v0.37.0.

What happens

rivet-core/src/validate.rs:116:

static ID_MENTION_RE: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"\b[A-Z][A-Z0-9]*-[0-9]+\b").unwrap());

The pattern only allows a single-segment prefix. A hyphen is a word boundary, so when prose mentions a multi-segment id, the regex matches the id's suffix instead of the id. That gives two failures:

1. False positive. synth has both TR-001 and CM-TR-001. Prose in CM-TR-002 that says "as CM-TR-001" produced:

   WARN: [CM-TR-002] prose mentions 'TR-001' but no typed link to it; add a link in `links:` or remove the mention
   

   The remediation it suggests (link to TR-001) would create a false trace to an unrelated requirement. Friction marking requirements implemented in a real project (rivet 0.13.3): silent file-skip, validate baseline noise, loop-modify no-op #353's suppression was added to prevent exactly that.
2. False negative. An id like CM-TR-001 or CM-VER-001 is never matched whole, so a real prose mention with no typed link is never reported.

Repro

In any project with artifacts TR-001 and CM-TR-001 where both types allow a link type between them: put the text see CM-TR-001 in the description of a third artifact with no links, then run rivet validate. You get a warning naming TR-001 and none naming CM-TR-001.

Measured in synth: adding "as CM-TR-001" to three artifacts and "See CM-VER-001" to one moved warnings from 439 to 443. All four new warnings named the suffix (TR-001, VER-001).

Suggested shape

Match the longest id-shaped token, e.g. \b[A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-[0-9]+\b, then resolve it against the store. A test pairing TR-001 and CM-TR-001 pins both directions: no suffix warning, and the whole id is detected.

[avrabe]

Triage note (scheduled routine, first pass on this issue — filed 2026-09-17, zero prior comments).

Well-scoped bidirectional regex bug: the ID_MENTION_RE at rivet-core/src/validate.rs:116 — r"\b[A-Z][A-Z0-9]*-[0-9]+\b" — allows exactly one segment of prefix, so a hyphen inside a multi-segment id becomes a word boundary. Two symmetric failures fall out: (a) prose mentioning CM-TR-001 yields a warning suggesting a link to TR-001 — a false trace to an unrelated requirement, which is precisely the failure #353's suppression logic was added to prevent; (b) genuine mentions of multi-segment ids (CM-TR-001, CM-VER-001) are never matched whole, so real prose-mention-without-typed-link violations go unreported. Measured in synth: adding "as CM-TR-001" to three artifacts and "See CM-VER-001" to one moved warnings 439 → 443, all four naming the suffix (TR-001, VER-001), none the whole id. Found in synth (v0.32.0), regex unchanged on rivet main at v0.37.0. Fix shape stated: match longest id-shaped token, \b[A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-[0-9]+\b, then resolve against the store.

There's no ## Acceptance Criteria block on the body a routine pass can gate on. The fix is a two-line regex change plus a longest-match preference in the walker, so the AC's regression fixture is where most of the discipline lives. Sketch matching the kill-criterion shape used across adjacent triage threads (#951, #952, #955, #962, #968, #971, #973):

## Acceptance Criteria — prose-mention matches multi-segment ids whole

- [ ] `ID_MENTION_RE` at `validate.rs:116` becomes `\b[A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-[0-9]+\b` (or an equivalent that matches an id with any number of `[A-Z][A-Z0-9]*`-prefix segments before the numeric tail). Overlapping matches resolved longest-first — the pass walks matches by descending length, and skips a match whose byte range is subsumed by a longer already-accepted one.
- [ ] Regression fixture (the synth-derived one from the body): a project with `TR-001` and `CM-TR-001` where both types allow a link between them. Test 1: an artifact's description containing "as CM-TR-001" with no `links:` entry. Pre-fix: warning names `TR-001`. Post-fix: no warning about `TR-001`, AND a warning naming `CM-TR-001` (if the target-type check demands a link, per the schema rules).
- [ ] Symmetric test: an artifact's description containing "as TR-001" with no `links:` entry to `TR-001`. Pre-fix: warning names `TR-001`. Post-fix: warning still names `TR-001` (single-segment case unchanged).
- [ ] Symmetric test: an artifact's description containing "as CM-VER-001" — the never-matched-whole case from the body. Pre-fix: no warning. Post-fix: warning names `CM-VER-001` (proves the false-negative half is closed).
- [ ] Corpus check: on the rivet repo itself, `rivet validate` warning count changes are enumerated pre-vs-post fix. Any residual multi-segment-id false-positive is captured as a follow-up.
- [ ] Suppression heuristic at `validate.rs:1254-1256` (which uses `source-types`/`target-types` restrictions) continues to work correctly with the new longer matches — assert one of the suppression cases stays suppressed after the fix (regression against #353's original fix accidentally regressing).
- [ ] `cargo test --workspace` green; `rivet validate` on rivet repo — post-fix warning count recorded, delta explained.
- [ ] Commit trailers: `Fixes: REQ-004` (validation) + `Refs: #972, #353`.

## Explicitly out of scope for the first slice (file separately if wanted)

- [ ] A `--dry-run-regex` or `rivet validate --explain-mention <id>` surface that would help a maintainer understand why a warning fires — useful, larger scope.
- [ ] The wider "regex-based prose scanning is a heuristic and misses/miscalls edge cases" thread — if AsciiDoc / Markdown inline code spans should suppress mentions, that's a separate class.
- [ ] Cross-project scanning (e.g., `synth`-style suffix collision would be caught by the same fix; that repository would need its own bump).

Two coordination items worth a maintainer call before AC is locked:

• Overlap resolution. The fix is a regex broadening; when CM-TR-001 and TR-001 both exist as ids, a prose mention of CM-TR-001 will produce matches for BOTH under a naive regex walk (longest-first walker handles it; leftmost-longest at the regex level may not, depending on engine). Pinning walker vs regex semantics before implementation avoids subtle test flakes.
• Compatibility. Projects using rivet whose prose relies on the current suffix-only matching (unlikely but possible) would see behaviour changes on their own corpus. Worth a beat before landing — either a soft-launch behind --strict-prose-mentions, or lands as a plain fix with the corpus-check bullet above documenting the delta.

Adjacent state worth flagging:

• Friction marking requirements implemented in a real project (rivet 0.13.3): silent file-skip, validate baseline noise, loop-modify no-op #353's suppression heuristic is the direct antecedent — this fix closes the case that heuristic exists to warn about (a false trace suggestion), so the two land as a pair in the changelog.
• Audit umbrella: gates that pass vacuously (traceability, cargo-vet, conformance suites, Playwright) #957's item 6 (unknown-field is Info severity) is a different lens on the same class: validation surfaces that fire quietly (Info) or wrongly (this issue) both erode the gate's meaning. Not the same fix, worth cross-linking.
• The synth-side impact is measured; whether synth CI needs a companion bump depends on how tight rivet's pin on synth is.

Process side-rail: https://pulseengine.eu/blog/ fetched at the start of this run — no post speaks to per-issue AC shape or regex convention, so the kill-criterion posture used across adjacent triage threads remains the working default.

Not implemented this run — no PR opened; the AC block on the body is the gating input.

---

Generated by Claude Code

[avrabe]

PR #974 addresses this. The regex is widened to \b[A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-[0-9]+\b — greedy matching picks the longest id-shaped token, so CM-TR-001 matches whole and TR-001 is not extracted from inside it. The store lookup that follows is unchanged. Added prose_mention_matches_multi_segment_id_not_its_suffix pairing TR-001 and CM-TR-001 in one store to pin both directions.

---

Generated by Claude Code