[vyncint]

What is wrong

check-dependency-licenses.sh builds its required set from two manifests:

required="$(
    {
        declared_crates Cargo.toml
        declared_crates crates/rustc-codegen-cuda/Cargo.toml
    } | LC_ALL=C sort -u
)"

and the comment above it says "Both first-party workspaces, not just the root one." There are three. cargo metadata stops at a [workspace] boundary, so one pass per root is the only way to reach them all, and crates/cuda-macros/tests/device-only declares its own [workspace] on purpose — the fixture exists to prove a graph that does not contain cuda-host (#701/#702), so it must resolve independently rather than share the root lock. That boundary puts it outside both passes.

The gap is live

Its member device-only-kernels has no row in dependency-licenses.csv, and adding the third pass says so immediately:

error: dependency-licenses.csv is missing a row for:
  device-only-kernels

publish = false is not what excluded it — cuda-intrinsics-gen and reserved-oxide-symbols are both unpublished root members and both have rows. The only reason it was absent is that no pass ever looked at that workspace.

Why this guard specifically

This is #1043's gap in the sibling guard. That fix taught cargo deny check the third root, which governs the license policy over the resolved graph. This guard covers the other half, stated in its own header: "that the human-readable inventory does not silently fall behind what the workspace declares." Both halves need all three roots, and until now only one had them.

The fixture is treated as a peer root elsewhere in the tree too — #1050's FIXED_FMT_SCOPES lists exactly these three directories for cargo oxide fmt. This guard was the outlier.

What it protects going forward: the fixture currently declares nothing but two first-party path dependencies, so the one missing row is the whole of today's drift. But a third-party dependency added there would have been recorded nowhere — cargo-deny would judge its policy and the inventory would stay silent, which is exactly the asymmetry this pair of guards exists to prevent.

Changes

1. The third declared_crates pass, plus a rewritten comment enumerating all three roots and why each is separate — so the next reader does not have to rediscover that cargo metadata stops at the boundary.
2. The device-only-kernels row, matching the column layout of the other first-party rows and inserted in sort position.

Verification

All local, no GPU needed. Both directions:

state	result
third pass, no CSV row	fails, naming device-only-kernels
CSV row, no third pass	OK: ... all 58 declared crates — blind to that workspace
both (this PR)	OK: dependency-licenses.csv records all 59 declared crates

scripts/check-example-license-policy.sh, the other consumer of the CSV, still reports OK: deny.toml holds over every example workspace. bash -n clean.

Two files. Checked against every open PR's file list via gh api --paginate .../pulls/N/files — no open PR touches either, including #1102, which edits many manifests but not the CSV.

[nihalpasham]

• Reproduced all three claims: the guard on main passes blind at 58 crates while the device-only fixture workspace root is never read; the third pass requires exactly one new name (device-only-kernels); the fixture's committed Cargo.lock makes the --locked metadata pass CI-safe.
• Same mechanism as the deny-side fix for the same root (ci: cargo-deny reaches two of the three non-example workspace roots #1043): per-root enumeration through the script's existing declared_crates pass; the 9-field CSV row matches the header and survives the cut -f1 parse.
• This drift has now happened twice (ci: verify dependency-licenses.csv covers what the workspace declares #662, here), so a self-check comparing the pass list against on-disk [workspace] manifests is follow-up material.