--tags and --concurrency are ignored by baseline and compare

[royalpinto007]

What is wrong

--tags and --concurrency are honored by evalgate run and silently ignored by evalgate baseline and evalgate compare.

In src/cli/index.ts, cmdRun passes both through (lines 157-163):

const run = await runSuite(suite, {
  providers: registryFor(args),
  defaultProvider: strFlag(args, "provider"),
  defaultModel: strFlag(args, "model"),
  concurrency: numFlag(args, "concurrency", 1),
  filterTags: strFlag(args, "tags")?.split(",").map((s) => s.trim()).filter(Boolean),
});

cmdBaseline (lines 177-181) and the suite-running branch of cmdCompare (lines 203-207) call runSuite with only providers, defaultProvider, and defaultModel. runSuite defaults concurrency to 1 and applies no tag filter when filterTags is absent (src/runner.ts lines 557-563).

Why it matters

The baseline and the candidate are supposed to be the same suite measured twice. If a user does:

evalgate baseline suite.yaml --tags smoke --out base.json
evalgate compare suite.yaml --base base.json --tags smoke

the baseline silently covers every case in the suite while the run in compare is also unfiltered, so the flag is inert in both, and a user who has internalised that --tags works (because it does for run) gets a comparison over a different case set than they asked for. compareRuns in src/compare.ts keys deltas by case id (lines 193-216), so a mismatched case set shows up as a pile of added/removed entries rather than an error, and regressed is computed only from cases present on both sides (line 231). The failure is quiet in exactly the place where a quiet failure is worst: the CI gate.

--concurrency has the same shape of problem, less dangerous but still surprising: a baseline over a slow real provider runs strictly sequentially no matter what you pass.

Steps

1. In src/cli/index.ts, factor the shared runSuite options out of cmdRun into a small helper, for example runOptionsFrom(args), and use it in cmdRun, cmdBaseline, and the suite branch of cmdCompare. That way the three cannot drift again.
2. Consider recording the applied tag filter in the result artifact so compareRuns could later warn on a mismatch. Not required for this issue, but say in the PR if you deliberately left it out.
3. Add a test in tests/runner.test.ts or tests/integration.test.ts covering --tags narrowing a baseline run, or at minimum a unit test on the new helper asserting it returns filterTags and concurrency.

Comment below if you want to take it. A reply usually comes within a day.