test: E2E coverage for agent, deploy, doctor, config, server; tag-selected suites and a local-OSS-server CI job

[ambiorix2099]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe): tests + documentation

NOTE: ./gradlew spotlessApply is not applicable — this repository is Go. go build,
go test ./... and gofmt are clean; no Go sources are modified by this PR.

Changes in this PR

Adds E2E coverage for five commands that had none, selects the suite by tag instead of by
hand-maintained file lists, and adds a CI job that tests against a locally built OSS server.

Coverage: 129 → 177 tests. Per-PR test executions: 111 → 266.

New suite	Tests	Covers
agent.bats	17	scaffolding, CRUD, execution search, live runs
config.bats	9	profile save/list/delete, --profile precedence
doctor.bats	7	runtime, server and AI provider reporting
deploy.bats	7	Python agent discovery and deployment
server.bats	8	local server status/logs and mutual-exclusion guards

Brings api_gateway.bats back into a job. Its 18 tests appeared in no job's file list, so they
ran nowhere. Tag selection picks them up automatically, and future suites cannot go missing the same
way.

An early revision of this PR described that as recovering tests orphaned by oversight. The first CI
run suggests otherwise: the Enterprise server CI targets does not have API Gateway enabled, and all
18 fail there with 404 No static resource api/gateway/.... They were most likely dropped from the
file list deliberately. Re-including them without a guard simply reinstated 15 failures.

They are now guarded: the suite runs wherever API Gateway exists and skips with a stated reason
where it does not. That is better than being silently absent from every job — the gap is now visible
in the run output rather than invisible in a file list — but it is a skip on this server, not
recovered coverage.

New CI shape. Three jobs replace one:

Job	Trigger	Selection	Tests
e2e-enterprise	PR	unauthenticated	5
		tier:pr,!oss-only,!unauthenticated	152
e2e-local-server	PR	tier:pr,!orkes-only	109
e2e-nightly	manual	tier:nightly,needs:agentspan / needs:llm	7 / 5

e2e-local-server closes gaps the Enterprise job could not, even in principle: CI pinned
CONDUCTOR_SERVER_TYPE=Enterprise, so OSS code paths were never exercised — the OSS schedule
support added in #86 was untested anywhere — and it tested a server of unknown version rather than
what is being released.

The server is built from conductor-oss/conductor main, because releases are cut from main and
no artifact is published from it: Maven Central carries only tagged RCs and the S3 latest jar has
not moved since 3 June. The trade-offs (a Gradle build per run; this repo's CI becoming sensitive to
the server repo's build health) are tracked in #105.

Defects found by this work, all reproduced against a main build, not just a tagged RC:

• schedule pause/resume broken on OSS Conductor: SDK sends GET where server requires PUT (405) #101 — release-blocking. schedule pause/resume are completely broken on OSS. The SDK
  issues GET where the server requires PUT (probe: GET→405, PUT→200). Invisible to CI
  because Orkes tolerates GET. A workaround exists in this repo, so the release need not wait on
  an SDK bump.
• agent stream never exits on a terminal execution: parseSSE has no terminal-event or idle termination #102. agent stream never exits on a terminal execution — it hangs any script or CI job that
  calls it.
• Stale hardcoded model catalogue: doctor advertises nonexistent Anthropic models; agent init defaults to openai/gpt-4o regardless of configured providers #103. doctor advertises two Anthropic models that return 404, and agent init defaults to
  openai/gpt-4o regardless of configured providers, so the documented init→run flow fails out of
  the box.
• server start has no datasource control: silently creates c123.db in the current working directory #104. server start writes c123.db into the current working directory with no way to
  override it.

Also re-confirmed #96, #97 and #98 still reproduce on main. main resolves none of them — the
rc.23→main diff touches zero scheduler files, and SchedulerResource still declares @PutMapping.
Worth stating because main does contain fix: 404 on SSE stream for nonexistent execution IDs,
which reads like #102 but is already in rc.23 and addresses a different case.

Corrects venue-naive tests. auth.bats is Orkes-only by design — it asserts that
unauthenticated calls fail, which is untrue against OSS where anonymous access is legitimate — and
task.bats tests 9, 10, 13 and 14 exercise task signal, which OSS refuses outright. These
previously would have failed against any OSS server.

Documentation. Adds CONTEXT.md (the repo had none, though docs/agents/domain.md says it
should), docs/adr/0001-... recording the testing decisions, and test/e2e/README.md with the
runnable commands. Also drops conductor code from CLAUDE.md, which #95 removed without removing
its docs, and corrects the help-group listing against actual --help output.

Issue #
Found #101, #102, #103, #104; follow-up tracked in #105. Recovers coverage relevant to #86.
Re-verified #96, #97, #98 as still reproducing.

Alternatives considered

k6. Explicitly proposed and rejected on capability rather than preference: k6's JavaScript
runtime has no subprocess API — no child_process, no os.exec — so it cannot invoke a CLI binary
at all. It would need a custom build with xk6-exec to drive a shell from inside a load-testing VM.
k6 remains right for load-testing the Conductor server's HTTP API, which is a different project.

Go integration tests via os/exec. Genuinely attractive: one toolchain, structured JSON
assertions, idiomatic gating via build tags. Rejected because 129 bats tests already existed and
worked, so this would mean two E2E idioms to maintain and teach for a real but not decisive benefit.

Positive tagging. Rejected after finding that bats file_tags can be added to by test_tags
but never subtracted from. Expressing "valid everywhere except these two tests" positively would
mean tagging ~150 tests explicitly. Only exceptions are tagged, and selection uses negation.

Pinning a published RC instead of building from source. RCs are cut from main, so an RC is a main
snapshot — main was 8 commits ahead of rc.23 when this was written, none of them CLI-facing. Faster,
cached and reproducible, and it isolates this repo from the server repo's build health. Deferred
rather than rejected: the ask was to test what will actually ship. Tracked in #105.

Scheduling the nightly tier. Deliberately not enabled. An unattended cron that spends model
tokens and reports to nobody is worse than no coverage. The cron line is present but commented.

Covering worker and code. Both were excluded because #92 and #93 proposed reworking and
removing them. Both have since merged (#94, #95): code is gone, so its exclusion is now permanent
and correct, but worker is converged and stable, so it is worth covering in a follow-up.

Known limitations

• The CI has now run (it had not when this was first opened). All three jobs are green: test,
  E2E (Enterprise), E2E (local OSS server); the nightly job correctly skips on pull requests.
  Building the server from source took 3m56s including a cold Gradle cache.
• 6 of server.bats's 8 tests skip in CI. conductor server start can only download published
  versions, so a source-built jar must be launched with java -jar; with no CLI-managed pid file
  those tests skip with a stated reason rather than failing. Revisit building the Conductor server from source in E2E CI (and the 6 server.bats tests it skips) #105 proposes a --jar flag to close it.
• 20 tests skip on the Enterprise server, which has neither the Agents API nor API Gateway
  enabled: agent (5) and api_gateway (15). Green on that job therefore means "nothing failing",
  not "everything exercised". Both are covered on the local OSS server, which has both capabilities.
• The first CI run of this PR failed with exactly those 20 tests before the capability guards were
  added; the CLI's own error messages were correct throughout.
• worker, code and TypeScript deploy are not covered — see above.
• The nightly tier runs only on manual dispatch, so deploy coverage is "when someone remembers".

🤖 Generated with Claude Code

[ambiorix2099]

@mp-orkes as promised, added ADR-0002 in 9cabb23 recording this decision.

It states plainly that pinning was the preferred option and the original plan, and that it was not taken for one narrow factual reason: nothing is published from main — Maven Central carries tagged releases only, and the S3 latest jar has not moved since 3 June. So a pinned version cannot validate the code the release is cut from.

It also records that in this instance pinning would have been adequate — main was 8 commits ahead of rc.23, all UI/CI/token-usage, nothing CLI-facing — but that this is a property of that particular gap, not a guarantee, and only knowable after the fact.

Consequences are listed without softening, including the two you'd care about most: a Gradle build on every PR run, and this repo's CI becoming sensitive to the server repo's build health. Plus explicit triggers for switching back, the first being "a red CI run traced to the server build rather than the CLI".

One practical note: the earlier revision of this PR already implemented your pinned form with a CI parameter, so reverting is recoverable from git history rather than a redesign. CONDUCTOR_SERVER_REF is the single knob.

Tracked for revisit in #105.