#14199·dagger

capabilities_test golden command lists duplicate the generated CLI reference

Author: shykesCreated Sep 17, 2026Updated Sep 17, 2026

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.
  • commandHasCapability walks 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:

  1. Replace the five lists with one test that asserts effective capabilities per command against a single table, so inheritance is covered; or
  2. Delete them and rely on the generated CLI reference diff, which CI already enforces.