Summary

Thanks to the Workspace API, modules can discover dynamic sets of related objects (tests by name, packages by path, services by label). But they can't present them to clients without losing features like check, generate, keyed selection, and batching.

Collections fix this. Annotate a module type with @collection / +collection, and the engine projects it into a public type with standard operations: keys, list, get, subset, and batch.

Design doc covers the problem, proposal, interfaces, and edge cases in detail.

What it looks like

// +collection
type GoTests struct {
	Keys []string
}

func (t *GoTests) Get(name string) *GoTest {
	return &GoTest{Name: name}
}

The engine projects this into:

type GoTests {
  keys: [String!]!
  list: [GoTest!]!
  get(name: String!): GoTest!
  subset(keys: [String!]!): GoTests!
  batch: GoTestsBatch!
}

CLI tools understand collections natively:

dagger check --go-tests=TestLogin,TestSignup

What's included

• Engine: collection typedef metadata, validation, schema projection, collection-aware traversal for check and generate, canonical get IDs
• All four SDKs gain collection authoring annotations (Go struct tags, TS/Python decorators, Java annotations)
• CLI: dagger check and dagger generate accept collection key filters
• Go toolchain models discovered Go modules as a collection (first real consumer)

Bundled fix

withExec cache keys now include the call ID (dc87b2cf). Without this, collection items sharing the same exec could incorrectly share cache entries.