Triage citation health check reports every citation as `file not found in workspace` against files that exist — second occurrence

Start by locating the citation health check implementation and its workspace/file-resolution entry point; the issue does not name those files. Reproduce against the triage comments on #5497 and #5463, then inspect how bare basenames such as Hl2RxDsp.cpp are resolved. Done means existing files resolve and missing files are distinguished from ranges that no longer match.

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

The citation health check in the footer of aethersdr-agent[bot]'s published
triage reports every citation as unresolved, with the reason
file not found in workspace, against files that are in the repository.

On #5497 the footer reads 0 resolved, 13 unresolved. The 13 citations
name three distinct files:

file named in the citation	path in the repository
Hl2Backend.cpp	src/core/backends/hl2/Hl2Backend.cpp
Hl2RxDsp.cpp	src/core/backends/hl2/Hl2RxDsp.cpp
WdspChannel.cpp	src/core/dsp/WdspChannel.cpp

All three exist. All three are the files the triage is about, and the triage's
own reasoning quotes them correctly.

This is the second occurrence. The triage on #5463 reported 15
unresolved citations by the same mechanism. All 15 resolved cleanly when
checked against a local checkout, and that was recorded at the time.

What we could check, and what we could not

We cannot see your workspace, your checkout state, or the checker itself, so
this reports a symptom and its recurrence rather than a cause. What we can show
is that the citations are correct.

Checked against 63a4a2e9 — a tree older than the main the footer names —
five of the thirteen ranges land exactly on the code the triage describes:

citation	what it lands on at 63a4a2e9
Hl2RxDsp.cpp:77-83	the filter-length comment through wc.filterTaps = kRxFilterTaps;
Hl2RxDsp.cpp:307-430	Hl2RxDsp::processIqBlock — signature at 307, closing brace at 430
Hl2RxDsp.cpp:374-401	the block loop — while (m_iqBuffer.size() - consumed >= block) at 374 through the end of the mute branch at 401
WdspChannel.cpp:256-277	the AGC mode switch — SetRXAAGCAttack at 256 to SetRXAAGCHangThreshold at 277
WdspChannel.cpp:363-390	the noise-blanker hold branch at 363 through the in-place ANB comment at 390

The eight Hl2Backend.cpp citations do not resolve in our older tree, because
that file moved between 63a4a2e9 and 293240a7. That is ordinary line
drift and it is not what is being reported here — the checker did not report
a range mismatch on any of the 13. It reported file not found in workspace,
which is a statement about the file.

One observation, offered as an observation and not a diagnosis: every
citation in the footer table is written as a bare basename with no directory
component (Hl2Backend.cpp:1150-1153, not
src/core/backends/hl2/Hl2Backend.cpp:1150-1153). Whether that is what the
checker is given or how it renders what it was given, we cannot tell from
outside.

Why this is worth a maintainer's time

Every triage published while this holds carries a visible
0 resolved, N unresolved flag against citations that are, so far as we can
check them, correct. A reader who trusts the footer will discount reasoning that
is sound — which is the opposite of what a citation check is for. It devalues a
mechanism built to add confidence, and it does so on every issue, not only ours.

The triage on #5497 in particular is careful and correct on the substance: it
overturned a mechanism we had reported and it was right to. Its footer says none
of its evidence could be located.

What did you expect?

That the citation health check resolves citations to files that exist in the
repository, and that when it cannot, the failure distinguishes "this file is not
in the workspace" from "this range no longer matches".

Steps to reproduce

1. Open the aethersdr-agent[bot] triage comment on
   #5497 and expand the
   Unresolved citations block in the footer.
2. Observe 13 rows, every one with the reason file not found in workspace.
3. Confirm the three distinct files named in those rows are present in the
   repository at src/core/backends/hl2/Hl2Backend.cpp,
   src/core/backends/hl2/Hl2RxDsp.cpp and src/core/dsp/WdspChannel.cpp.
4. For the recurrence, repeat on the triage comment on
   #5463: 15 rows, same
   shape.

AetherSDR version

Not applicable — this is about the triage tooling, not a build of the
application. The tree the citations were checked against here is 63a4a2e9; the
footer names origin/main at /Users/aetherclaude/workspace/AetherSDR, which
is not visible to us.

Radio model & firmware

Not applicable. No radio is involved.

Operating system

macOS

OS version and hardware

macOS 26.6.2, Apple M2 — the machine the citations were verified on. The machine
the checker runs on is not known to us.

---

What was NOT measured

• The checker's implementation, configuration, working directory or checkout
  state. None of it is visible from outside the published comment. Nothing
  here says why the lookup fails.
• Whether every triage is affected. Two are known: #5497 (13 of 13) and
  #5463 (15 of 15). We have not surveyed the rest.
• The eight Hl2Backend.cpp ranges. They do not resolve against our older
  tree and we make no claim that they are right or wrong against 293240a7 —
  only that the file they name exists, which is what the reported failure
  denies.
• Anything about the substance of the triage on either issue. #5497's is
  answered separately and on its merits.

🤖 Generated with Claude Code

https://claude.ai/code/session_014TtnKQu6QGrSeBirGeAsAs