bug(issue-ref): a URL fragment after a path segment is read as owner/repo#12 and names an issue nobody meant #2435

Written-by: Delivery-1

issueRefs reads a URL fragment as a repository-qualified issue reference when the URL's path has a segment before the #, so a documentation link names an issue that does not exist. groups.js dispatchOf → work-dispatch.js workDispatch uses that ref to write a card for the issue the line names.

Reproduce (base delivery/ai-centric-development-service @ 5e71a07)

cd core && node -e "
import('./src/shared/issue-ref.js').then(m => {
  for (const t of [
    'see https://example.com/page#123 for details',
    'https://example.com/docs/guide#12',
    'read https://docs.example.org/a/b#42 then',
  ]) console.log(JSON.stringify(t), '->', m.issueRefs(t));
});
"

Actual:

"see https://example.com/page#123 for details" -> [ '#123' ]
"https://example.com/docs/guide#12" -> [ '#12' ]
"read https://docs.example.org/a/b#42 then" -> [ '#42' ]

Expected: [] for all three — the module's own rule is that a word character, ., - or / in front makes a # part of an identifier, a version, a hex colour or a URL fragment, and only #1234, owner/repo#1234 and a GitHub /(issues|pull)/<n> link name an issue (core/src/shared/issue-ref.js:5-10, #1392).

Where

core/src/shared/issue-ref.js:10: the first alternative (a bare #12) carries the lookbehind (?<![\w./-]), but the repository-qualified alternative (?:github\.com\/)?([\w.-]+)\/([\w.-]+)#(\d{1,7}) has none. In https://example.com/page#123 the engine matches com/page#123 — host segment as "owner", path segment as "repo" — and the fragment becomes #123. The third alternative (the GitHub issue/pull URL) is not involved.

The existing test suite misses it because its URL-fragment case has no path segment: https://example.com/help/#123 (core/test/issue-ref.test.js:13), where no owner/repo pair exists to match. A fragment after one path segment, which is what documentation links normally look like, was never tested.

User impact

work-dispatch.js:29-34 turns @Dev1 <issue id> rebase and push into a card for the id it reads, and tasks.js:956 matches an open card with cardNamesIssue. A message that carries a docs link and an imperative near it — e.g. @Dev-2 read https://example.com/docs/guide#12 then rebase — names issue #12 and writes/updates a card for it, which is the failure class the module header names: a card that names an issue which does not exist (#1360, #1392).

Red first

core/test/issue-ref-url-fragment.test.js (4 tests) on the base above: # tests 4 / # pass 0 / # fail 4 — the three URL cases return the fragment as an issue, and namesIssue('https://example.com/docs/guide#12', 12) is true. With the source change the same file is # tests 4 / # pass 4 / # fail 0, and the existing issue-ref, face-mentions and work-dispatch suites stay green (# tests 44 / # pass 44 / # fail 0 together).