work-items: no tracking-issue resolver for Dependabot alerts — the lane's dedupe pre-flight is title-scoped, so a tracked alert reads as untracked (medley alert #29 vs medley#1658)

[kyle-sexton]

This was generated by AI — observed live by autonomous /work-items:work-loop lane instance MELO-LAP-001-worker-202607290838, cycle 1.

The miss

This lane concluded that melodic-software/medley Dependabot alert #29 was tracked by no
issue, and came within one step of filing a near-duplicate. It is tracked:
melodic-software/medley#1658 — "Dependabot #29: js-yaml 5.2.2 blocked by markdownlint-cli2
exact pin and npm cooldown" — open, needs-human, with a full analysis of why the alert cannot
be closed yet.

Consequence, in two parts:

1. A near-duplicate issue was almost filed against an alert already carrying a considered,
   human-gated resolution plan.
2. A real, open, high-severity alert reads as untracked — so the same wasted investigation
   recurs for free on every future cycle, and any "untracked alerts" count is wrong.

Root cause: title-scoped search, not a title pattern

The originally suspected cause was a title-shape mismatch — detection matching
Dependabot alert #N: while #1658 is titled Dependabot #29:. That is wrong as a root cause.
Measured against the live repository:

Query	Result
gh issue list --search 'in:title "Dependabot alert #29"'	0 hits
gh issue list --search 'in:title "Dependabot #29"'	#1658
gh issue list --search 'Dependabot alert 29' (unscoped)	#1658, #1640, #1659, #1568

The unscoped search finds #1658 even using the "wrong" phrasing, because the alert number is
durably present in the body:

Dependabot alert #29 — …

So the defect is not that the title pattern is wrong. It is that the search was scoped to
titles at all, discarding the body — where the alert number and its canonical
/security/dependabot/<N> URL actually live, in a form no title convention has to agree on.

There is no single title convention to fix

melodic-software/medley currently uses at least two title shapes for the same concept:

• Dependabot #29: … (Loop-lane convention: record the fresh-context review boundary as an explicit decision #1658), Dependabot #19: … (feat(ci): mechanize the surface/clause coverage matrix for the review-disposition contract #1659) — one alert per issue
• Open Dependabot alerts (19-22): … (fix(disk-hygiene): engine gate over-gates a consumer's own engine-named script when its absolute path holds a non-keep-class character #1640) — a range, where no per-alert number appears in
  the title at all

Any fix shaped as "match the right title pattern" cannot cover #1640, and would break again the
next time a batch issue is filed. The reliable linkage keys are the body's alert number and the
/security/dependabot/<N> URL.

What is verified, and what is not

Verified:

• Loop-lane convention: record the fresh-context review boundary as an explicit decision #1658 exists, is open, and tracks alert build: Bump the github-actions group with 14 updates #29 (gh issue view).

• The three query results in the table above, run against the live repository this cycle.

• Both title conventions coexist in medley today.

• No Dependabot-specific linkage logic exists anywhere. Searched plugins/** (all plugins),
  docs/** and docs/conventions/loop-lane/, plus medley/.claude/**,
  medley/.github/workflows/**, standards, ci-workflows, github-iac, dotfiles. Every
  Dependabot hit is auto-merge policy, PR issue-linkage gating, dependabot.yml coverage, or
  branch naming. Nothing maps an alert number to a tracking issue.

The generic path the lane actually follows is specified, and it is title-similarity:

• plugins/work-items/reference/dogfood-filing.md — "The sequence", beat 1: "Dedupe first
  (mechanical search + model sameness). Before creating anything, run the search-before-create
  pre-flight … the same read track add performs."
• plugins/work-items/skills/track/actions/add.md:37 — that pre-flight: "If a potential
  duplicate is found (similar title)…"

So a lane about to file an alert issue is routed to a duplicate check whose only stated signal is
title similarity — against a repo where the alert number lives in the body and the titles follow
no single convention. dogfood-filing.md does say sameness is "a model judgment, not a string
match", but the mechanical search it feeds is title-scoped, so a body-only match never reaches
the judgment step.

Not verified — flagged explicitly: the exact query this lane issued is not recoverable. The
miss was reported to this session rather than captured with its command, so the table above shows
what title-scoped search does generally, not a replayed transcript of the failing call. Whether
the lane followed add.md:37 or improvised is therefore inference, not evidence — but both land
on the same title-scoped read.

Fix shape deliberately not chosen

Left to a human. Recording only the constraints the evidence imposes on any fix:

• The check must key on something durable — the body's alert number or the
  /security/dependabot/<N> URL — not a title pattern.
• It must handle an issue covering a range of alerts (fix(disk-hygiene): engine gate over-gates a consumer's own engine-named script when its absolute path holds a non-keep-class character #1640), since one exists today.
• If the fix lands in the generic add.md:37 pre-flight rather than a Dependabot-specific path,
  note that widening that search from titles to bodies changes dedupe behavior for every lane
  that files through dogfood-filing.md, not just security work. That blast radius is a reason
  this is human-gated rather than a mechanical patch.

Related

• melodic-software/medley#1658 — the issue that was missed
• melodic-software/medley#1640 — the range-titled issue that breaks any per-alert title pattern
• work-items: lane-telemetry issue #1248 carries the raw triage marker, and /work-items:triage's attention view has no lane-infrastructure exclusion #1739 — lane-machinery defect from the same cycle (telemetry issue carries the raw triage marker)
• work-items(work-loop): fixed telemetry title and sentinel make two lanes on one repo clobber durable state, including first_drain_complete #1295 — lane-machinery defect from the same cycle (telemetry marker drift and durable-state clobber)

[kyle-sexton]

Reframing this issue as a GAP, and retitled accordingly. The original body already carried
the disproof of the title-pattern hypothesis; this comment records the corrected framing and adds
one thing the body did not have: the org already owns a working mechanism for exactly this
question, and alerts are simply outside it.

The gap, stated plainly

There is no tracking-issue resolver for Dependabot alerts anywhere in the org tree — not in
claude-code-plugins, medley, standards, ci-workflows, github-iac, or dotfiles, and not
in the installed claude-security plugin. No gh api .../dependabot/alerts call exists in any of
them. So no title pattern misfired, because no alert→issue matcher exists to misfire.

What actually happens: a lane asking "is this alert already tracked?" falls through to the generic
dedupe pre-flight (reference/dogfood-filing.md beat 1 → skills/track/actions/add.md:37), whose
only stated signal is "similar title". An agent then eyeballs the result. That is the whole
mechanism — a judgement call over a title-scoped search, which is why alert #29 read as untracked
while medley#1658 tracks it.

The org already has the right shape for this — alerts just are not wired into it

melodic-software/ci-workflows, .github/scripts/find-tracking-issue.sh resolves "which open
issue tracks this thing?" properly, and none of it depends on titles:

• Matches on a body marker (select((.body // "") | contains($marker)))
• Restricted to the workflow's own bot-author identity
  (select(.user.login == $author and .user.type == "Bot")) — explicitly so a hand-crafted decoy
  issue cannot be adopted
• Fails closed on ambiguity: more than one match errors out for manual reconciliation rather
  than guessing
• Exact-title matching exists only as a documented one-time migration fallback for pre-marker
  issues — i.e. the title path is the legacy path it moved away from

Verified in place; consumers are tool-version-drift-check.yml, queue-monitor-liveness.yml,
link-check.yml, selector-conformance.yml, standards-sync-stuck-automerge-alert.yml, ci.yml.
It is drift/liveness-scoped, and nothing routes a Dependabot alert through it.

So the finding is not "a mechanism is broken" but "alerts sit outside an existing, working
mechanism" — which also means the fix has a proven local precedent to follow rather than a
design to invent.

Do not re-chase the title-pattern theory

The original hypothesis — detection matching Dependabot alert #N: while medley#1658 is titled
Dependabot #29: — was investigated and disproved. Evidence is in the issue body: the
unscoped search Dependabot alert 29 finds #1658 using the "wrong" phrasing, because the alert
number lives in the body. Recording it here so nobody re-opens that line of inquiry.

Note on repo choice

Filed in claude-code-plugins rather than ci-workflows, deliberately. ci-workflows owns the
resolver script, but the defect is in what the lane does when it asks the tracked/untracked
question, and the lane's dedupe contract (dogfood-filing.md, track/actions/add.md) lives here.
A fix could well reuse or generalize the ci-workflows script; if the resolution turns out to be
purely a new workflow in ci-workflows, this should move.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave (frontier consensus).

Dual-panel drain ruling: advisory, superseded, folded into a program umbrella, or blocked on a host/design carrier without an actionable in-repo slice this session. Re-open with a concrete acceptance brief if a consumer needs the work.

KEEP set for this wave: standing telemetry; host-physical Class C (#631 family); program umbrellas #530/#531/#532/#535; live design carriers #1500/#1553/#1668/#1695/#1716/#1681/#1718; #1360.