A composed operation must name a collection it may never touch

Type

Debt — a validation rule wider than the thing it validates

Found while

SAPE-20

Triage

Defer

Status

Open

Severity

Low — a required field with no meaning, which is a documentation problem that looks like an API

Description

validateOperation resolves the operation's collection before it branches on the action, for every action there is:

// internal/store/ops.go:486 — before any switch on operation.Action
collection, err := s.Collection(operation.Collection)
if err != nil {
	return err
}

A composed operation whose every step names another operation never uses that collection. It still has to name one that exists, or the declaration is refused with sapedb/store: no such collection: "" (internal/store/store.go:322).

Evidence

• The resolved collection is consumed by the per-action branches — ActionGet, ActionScan/ActionCount via scanFields, ActionTotals via totalsAcross, and the four writes. The ActionBatch branch (ops.go:747) does not use it at all: it walks operation.Steps and each step resolves its own (validateStep → s.Collection(step.Collection), ops.go:914).
• At run time the same holds: runStep uses step.Collection (internal/store/batch.go:183) and a composed leg uses the callee's own declaration. Nothing reads the parent's Collection.
• The one place a batch's collection could matter is keyTypeOf (internal/store/compose.go:167-185) — and its ActionBatch case resolves the last step's collection, never the parent's.
• So for a purely composed batch, operation.Collection is write-only metadata that the validator insists is real.

Triage

Does it lose data, break a promise on a public surface, or stop somebody installing and running? No. A declaration that names any existing collection works perfectly; the field is ignored, not misused. Nobody is blocked from installing, running, or declaring.

Defer. The interesting part is what the fix would be, because the obvious one is a trap. Making Collection optional for batch relaxes a rule, which is the direction that is safe to do later: a declaration accepted today stays accepted tomorrow. Doing it now buys nothing and risks the opposite mistake — deciding a composed batch's collection is meaningful and giving it a meaning nobody needs.

There is also an argument for leaving it exactly as it is: an operation names one collection because that is the product's story about what a declaration is, and a batch of plain steps genuinely has one. Whether a composed batch should be exempt is a question about the model, and it should be answered deliberately rather than by loosening a validator.

If deferred, what it costs to wait

• Nothing on compatibility, in the direction that matters: relaxing a required field later accepts everything that is accepted today. This is one of the few items here that is strictly cheaper to postpone.
• The cost is confusion, paid by every person who writes a composed declaration and by the desktop workbench's compose screen, which has to put a collection picker on a form where the answer does not matter.
• The cheap step now is truthfulness, not code: say in the composed-operations documentation that a composed batch's collection is required and unused, so nobody reads meaning into their choice and builds on it.
• If it is ever relaxed, the refusal for a missing collection on every other action must stay exactly as strict — the value of the rule is that a flat operation says what it touches.