#4540 Ambient tags: set tags once per repo/worktree (env or .swamp), add them to every run and everything downstream, filter run history by tag

Problem

Work on one task (an incident, an investigation, a lab issue) spans many swamp invocations in several places: a local repo, a bootstrap repo with its own datastore, and a remote serve (--server), each with method runs, workflow runs and reports. Today there's no native way to say "everything I do in this worktree belongs to task X" and later ask swamp for all of it.

--tag KEY=VALUE gets close. Checked on 2026-11-09 against a remote serve:

• swamp model method run <model> <method> --tag activity=tag-probe --server … tags the data the run produces on the server (tags.activity: "tag-probe", next to initiatedBy), and swamp data query 'tags.activity == "tag-probe"' finds it.
• But it has to be passed on every command.
• It labels data only: run history and workflow history search have no tag filter, so "which runs belonged to this task" can't be answered.

Proposal: ambient tags that add, never replace

1. Default tags from the environment or the repo. Tags set once and applied to every command run in that directory:

• SWAMP_TAGS="activity=lab-4536,env=prod", and/or
• a tags: map in the repo's (or worktree's) .swamp/ config, set with something like swamp tag set activity=lab-4536 / swamp tag unset activity / swamp tag show.

Each worktree then carries its task with no flags, and CI can set the env var.

2. Cumulative: ambient tags only ever add. They merge into whatever a run, its data and its downstream content already carry, and never remove or replace an existing tag:

• They are added alongside model tags, system tags (initiatedBy, workflowRunId, specName, _swamp.*, …) and explicit --tags.
• On a key clash, the more specific source wins: an explicit --tag on the command beats the env var, which beats the repo file. Reserved system tags can never be overridden. Ambient tags never change a model's own definition tags.
• Several ambient tags at once (e.g. activity=lab-4536 and incident=2026-11-08) are all applied, so one piece of work can be grouped several ways.

3. Tags on runs, inherited downstream.

• Record the invocation's effective tags (ambient plus explicit) on the method run and workflow run records themselves, not only on produced data.
• A workflow run's tags are inherited by every step, including steps dispatched to workers, and by everything those steps produce: data, files, reports, and child or nested workflow runs.
• Through serve: with --server, the effective tags travel with the request and are applied server-side the same way.
• Filters: add --tag KEY=VALUE (repeatable, AND) to swamp run history and swamp workflow history search, and make tags available to data query CEL as today.

Example

cd worktrees/lab-4536
swamp tag set activity=lab-4536          # or: export SWAMP_TAGS=activity=lab-4536

swamp model method run prod-debug investigate --input …   --server https://ops.example
swamp workflow run release-workload --input …            --server https://ops.example
swamp model method run grafana-db get                     # local datastore

swamp run history --tag activity=lab-4536 --server https://ops.example
swamp workflow history search --tag activity=lab-4536 --server https://ops.example
swamp data query 'tags.activity == "lab-4536"' --server https://ops.example

Because a tag is just a key and value, the same activity=lab-4536 started in different repos and against different servers groups the work in each of them, with no coordination.

Acceptance

• With SWAMP_TAGS or the repo tags: set, every method run, workflow run (and each of its steps, local or on workers), report and produced data record carries those tags, locally and through --server.
• Existing tags are never removed or replaced. On a key clash, an explicit --tag beats the env var, which beats the repo file. System tags can't be overridden.
• run history and workflow history search accept --tag filters.
• swamp tag show prints the effective ambient tags and where each comes from.

Nice to have

Derive the W3C trace id from a chosen tag (e.g. activity) when no TRACEPARENT is set, so the CLI's and serve's spans for one task share a trace in the telemetry backend.