#2948 data get --workflow silently returns an arbitrary step's data when several steps share a data name

Summary

swamp data get --workflow <name> [--run <id>] <data_name> returns whichever matching item it finds first when more than one step in the run produced data with that name. It gives no ambiguity error and has no way to pick a step, so the caller gets another step's output with no indication it is the wrong one, and the other matches cannot be reached through this command at all.

Root cause

WorkflowDataService.findByNameInWorkflowRun (src/domain/data/workflow_data_service.ts:231) collects every item in the run whose name matches (falling back to the specName tag), then calls selectVersion (line 63). With no version requested, selectVersion keeps the item with the highest version, so when the matches tie on version (the common case: every step writes version 1) it returns the first one in iteration order. Neither the CLI nor libswamp accepts a step or job to narrow the match.

Reproduction

Any workflow where several command/shell steps run, since each writes data named result and log. Seen with the repo's own verification workflow:

SWAMP_WORKFLOWS_DIR=verification swamp workflow run verify-reviews --input commit=<sha> --input branch=<branch>
SWAMP_WORKFLOWS_DIR=verification swamp data get --workflow verify-reviews --run <run-id> log --no-content --json

The run holds 10 items named log or result (checkout, diff, changed-files, code-review, adversarial-review, ux-review, ...). The command returns the log from the setup job's checkout step (tags.step = checkout), not from any review step, and exits 0.

Expected

• When several items in the run match the name, either fail with an error that lists the candidates (job, step, model) or require the caller to narrow it.
• Provide a way to choose, for example --job / --step flags on swamp data get --workflow.
• An unambiguous name keeps working as it does today.

Impact

This is the only CLI route to data whose model definition no longer exists. verify-reviews deletes its per-run review model definitions in its cleanup job, so swamp data get review-code-<run-id> log fails with Model not found, and the workflow-scoped get returns the checkout log instead. In practice the review logs and verdicts are reachable only by reading .swamp/data on disk, even though agent-constraints/verification-conventions.md documents the workflow-scoped get for exactly this purpose.

Related

• #2501: a different way data becomes unreachable (model type migration).