Attribution
Understand why a finding belongs to your change, even when the analyzer needs to inspect more than your diff.
What Swarm inspects is not what it blames
A TypeScript check may need a whole project. A dependency check needs the module graph. Finding duplicated code requires looking beyond the lines you edited.
Swarm separates that analysis scope from attribution: the evidence connecting a finding to the selected change. It compares results where the check requires a baseline, then uses changed lines, changed functions or other syntax entities, and project-level changes to identify new or worsened responsibility.
Existing unrelated findings do not become blockers just because an analyzer found them. Attribution is about the proposed code change, not a person’s identity or Git blame history.
Compare analysis coverage across checksworkspace or complete file
selected target changes
new or worsened issues
Which two versions are compared?
The baseline is the starting state. The target is the proposed state. The command you run determines both; your current editor contents do not substitute for either snapshot.
| Command | Baseline | Target |
|---|---|---|
npx zedbee scan | The current committed HEAD | The exact Git index: what you have staged |
npx zedbee scan --base origin/main | The unique merge base of origin/main and HEAD | The current committed HEAD |
For a local scan, stage the version you want inspected. Later unstaged edits are outside the scan. In CI base mode, both versions come from commits, so staged, unstaged, and untracked working files do not replace the target.
The CI comparison starts at the shared ancestor, not necessarily the latest commit on main. Changes made only on the base branch after the branches diverged do not become your branch’s changes.
How a finding connects to a change
Different checks need different evidence. Swarm does not treat “this file changed” as a universal reason to block every finding in that file.
| Evidence | What it connects | How to read it |
|---|---|---|
| Changed range | A reported location overlaps added or modified target lines. | The finding is connected to lines in the selected diff. |
| Changed syntax entity | A finding belongs to a changed function or another identified syntax entity. | The relevant unit can be larger than one edited line. |
| Baseline comparison | A target observation has no matching baseline observation and has supporting change evidence. | Being new and being attributable are separate checks. |
| Project or repository change | A check connects a new result to changed project inputs or repository state. | A graph or project regression can matter beyond the exact lines you edited. |
| Metric delta | A changed entity crosses a configured limit or worsens above it under the selected policy. | Compare the old score, new score, and limit, not just the final score. |
These mechanisms are selected by the check. A finding reported elsewhere in a workspace is not automatically unrelated, and a finding on an edited file is not automatically new. Read the attribution evidence alongside the check’s coverage and diagnostic.
New, unchanged, and worsened are different
For a changed function with a cyclomatic complexity limit of 20 and blockWorsening: true, these examples show how the metric comparison behaves. Assume the check’s severity is error.
| Baseline → target | Result for this metric | Reason |
|---|---|---|
| 18 → 21 | Blocks | The changed function crosses the limit of 20. |
| 24 → 24 | Does not block | The existing above-limit score did not worsen. |
| 24 → 25 | Blocks | The score worsened while already above the limit. |
| 24 → 23 | Does not block | The score improved, even though it remains above the limit. |
| New function → 21 | Blocks | A new function starts above the limit. |
Setting blockWorsening: false stops the above-limit worsening case from blocking, but a newly above-limit function or a score that crosses the limit can still block. This policy applies to the supported complexity checks, not every kind of finding.
“Does not block” here refers only to this metric. Other findings or incomplete required analysis can still stop the scan.
Read the evidence, then choose the next step
JSON and SARIF reports include attribution evidence alongside findings and repository-relative locations. Use a complete export when you need to investigate a result; the terminal preview may show only a subset of findings.
If a result is surprising, first check the selected Git state, then the check’s scope and attribution evidence. For local scans, git diff --cached shows the proposed change. For CI, confirm the checked-out commit and comparison base.
Attribution and severity answer different questions. Attribution connects the finding to the change; repository policy determines whether an attributable finding warns or blocks.
If required analysis cannot complete, Swarm reports an incomplete result. Do
not interpret exit code 2 as proof that the change introduced no problems.
npx zedbee scan --format json > zedbee-report.json