Persist runtime tags on workflow run records

[stack72]

Problem

When running a workflow with --tag flags, the tags are applied to data artifacts produced during the run, but they are not stored on the workflow run record itself. The workflow run YAML at .swamp/workflow-runs/{workflow-id}/{run-id}.yaml has no record of which runtime tags were used.

This means there is no way to filter workflow run history by tags. You cannot ask "show me all runs of deploy-pipeline for prod" — the workflow run history has no concept of the environment or any other runtime tag.

Current State

Data artifacts produced during a tagged run correctly carry the tags:

# .swamp/data/.../result/8/metadata.yaml
tags:
  type: resource
  specName: result
  workflow: deploy-pipeline
  step: deploy-app
  environment: prod          # from --tag

But the workflow run record does not:

# .swamp/workflow-runs/{id}/{run-id}.yaml
id: ...
workflowId: ...
workflowName: deploy-pipeline
status: succeeded
startedAt: ...
completedAt: ...
# no tags field

Why This Matters

Workflow run history is important for operational visibility — teams need to answer questions like:

• "When was the last time we deployed to prod?"
• "Show me all failed staging runs this week"
• "What's the deployment frequency per environment?"

Today, the only way to get environment information about a run is to look at the data artifacts it produced and check their tags. But data artifacts may have been garbage-collected, and querying indirectly through data is cumbersome compared to filtering runs directly.

Proposed Solution

Store runtime tags on the workflow run record:

id: ...
workflowName: deploy-pipeline
status: succeeded
tags:
  environment: prod
  image_tag: v1.2.3

And support filtering in workflow history commands:

swamp workflow history search --tag environment=prod
swamp workflow history search --tag environment=prod --json

Use Case

An SRE team operates a deployment pipeline across multiple environments. During an incident, they need to quickly find:

• The last successful prod deployment (to identify what changed)
• All failed runs for a specific environment (to spot patterns)
• Deployment frequency per environment (for capacity planning)

Without tags on run records, this information is either unavailable or requires manual correlation across data artifacts.

[stack72]

Implementation Plan

Context

When running a workflow with --tag flags, tags flow through to data artifacts but are not stored on the WorkflowRun record itself. This means workflow history search cannot filter by tags (e.g., "show me all prod deploys"). The fix stores merged workflow-level + runtime tags on the run record and adds --tag filtering to history search.

Changes

1. Add tags field to WorkflowRun entity

File: src/domain/workflows/workflow_run.ts

• Add tags: z.record(z.string(), z.string()).default({}) to WorkflowRunSchema — .default({}) ensures backward compat with existing YAML files
• Add private readonly _tags: Record<string, string> as last constructor param
• Update create(): add optional tags?: Record<string, string> param, pass to constructor
• Update fromData(): pass validated.tags to constructor
• Add get tags(): Readonly<Record<string, string>> getter
• Update toData(): include tags in output (omit when empty for clean YAML)

2. Merge and pass tags during execution

File: src/domain/workflows/execution_service.ts

• Merge workflow.tags and options?.runtimeTags (runtime takes precedence), pass to WorkflowRun.create(workflow, mergedTags)

const mergedTags: Record<string, string> = {
  ...(workflow.tags ?? {}),
  ...(options?.runtimeTags ?? {}),
};
const run = WorkflowRun.create(workflow, mergedTags);

3. Add tags to search item type

File: src/presentation/output/workflow_history_search_output.tsx

• Add tags?: Record<string, string> to WorkflowHistorySearchItem
• Include tags in the fzf selector string so they're searchable in interactive mode
• Display tags inline in the interactive UI result items when present

4. Add --tag filter to workflow history search

File: src/cli/commands/workflow_run_search.ts

• Add parseTags to the existing import from data_search.ts
• Add tags?: Record<string, string> to RunSearchFilterOptions
• Add tag filtering to applyFilters() using AND logic (same pattern as data search): tagEntries.every(([k, v]) => r.tags?.[k] === v)
• Update toSearchItem(): include tags from run.tags
• Parse --tag options and pass to applyFilters() in the action function
• Add --tag <tag:string> CLI option with { collect: true } to the command definition

5. Tests

src/domain/workflows/workflow_run_test.ts:

• create() with tags stores them; without tags defaults to {}
• toData() includes tags when present, omits when empty
• fromData() / toData() roundtrip preserves tags
• fromData() with missing tags field (backward compat) defaults to {}

src/infrastructure/persistence/yaml_workflow_run_repository_test.ts:

• Save/load roundtrip preserves tags

src/cli/commands/workflow_run_search.ts (or sibling test file):

• applyFilters with --tag filters correctly using AND logic
• Items without tags don't match tag filters

File Summary

File	Change
src/domain/workflows/workflow_run.ts	Add tags to schema, constructor, create, fromData, toData, getter
src/domain/workflows/execution_service.ts	Merge workflow+runtime tags, pass to WorkflowRun.create()
src/presentation/output/workflow_history_search_output.tsx	Add tags to search item type, display in UI
src/cli/commands/workflow_run_search.ts	Add --tag CLI option, tag filtering, include tags in search items
src/domain/workflows/workflow_run_test.ts	Unit tests for tags
src/infrastructure/persistence/yaml_workflow_run_repository_test.ts	Roundtrip test for tags

Backward Compatibility

• Zod .default({}) means existing YAML files without tags parse to {}
• WorkflowRun.create() second param is optional — existing callers unaffected
• tags is optional on WorkflowHistorySearchItem — existing consumers unaffected