capabilities_test golden command lists duplicate the generated CLI reference
internal/cmd/dagger/capabilities_test.go holds five hand-written lists of command paths (around lines 244, 344, 416, 544 and 649), roughly 300 lines in total, each asserted with require.ElementsMatch. Every new command that declares a capability must be added to them by hand. They are worth replacing.
They assert the wrong thing
The lists assert declared capabilities, not effective ones.
commandsDeclaringCapability(~line 1011) reads each command's own annotation only. It ignores inheritance.commandHasCapabilitywalks up to the root.
So a new subcommand added under a parent that declares an inheritable capability acquires that capability silently and never appears in any list. That silent acquisition is the mistake most worth catching, and these tests cannot catch it. What they do catch is a command that declares a capability directly, which is the visible, intentional case.
The capability is narrow
A capability only controls flag availability. mayCallEngine is consumed at internal/cmd/dagger/main.go:474, module.go:81, shell.go:48 and workspace_grep.go:116 — all flag wiring. It does not gate engine startup, so a wrong entry does not change whether the engine runs.
A generated artifact already covers this
docs/current_docs/reference/cli/index.mdx is generated from the same FlagAvailableForCommand logic. It lists every flag of every command, it sees inherited flags, and the docs:references CI check already verifies it. The five tests are a weaker, hand-maintained duplicate of that reference.
Proposal
Either:
- Replace the five lists with one test that asserts effective capabilities per command against a single table, so inheritance is covered; or
- Delete them and rely on the generated CLI reference diff, which CI already enforces.
Source: dagger/dagger