[E1] Decouple ExecutionResponse from Copilot SDK + Multi-Agent Engine Support

[spboyer]

Migrated from spboyer/waza#195

Summary

Abstract ExecutionResponse away from copilot.SessionEvent types to enable multi-agent executor support. Then add engines for additional agents (Claude Code, Codex, generic CLI agent).

Problem

ExecutionResponse in internal/execution/engine.go directly imports and uses copilot.SessionEvent — tightly coupling the execution interface to a single agent SDK. This prevents adding executors for other agents (Claude Code, Codex, OpenCode, etc.).

SkillsBench supports 5+ agents via their Harbor framework. While our primary audience targets Copilot, cross-agent validation is increasingly valuable as skills become platform-agnostic.

Proposed Solution — Two Phases

Phase 1: Interface Decoupling (P1 — do now)

1. Define generic event types in internal/execution/ that mirror the needed fields from copilot.SessionEvent without importing the Copilot SDK
2. Update ExecutionResponse to use these generic types
3. Copilot engine adapts SDK events → generic events internally
4. No behavioral change — just cleaner abstraction

Phase 2: New Engines (P2 — do later)

1. Claude Code engine: CLI wrapper that shells out to claude CLI, passes prompt, captures output
2. Generic CLI agent engine: Configurable command template for any CLI-based agent
3. Each engine: ~300-500 lines implementing AgentEngine interface (Initialize, Execute, Shutdown)

Implementation Notes

• AgentEngine interface in engine.go is already well-abstracted — the issue is ExecutionResponse coupling
• ExecutionResponse.Events []copilot.SessionEvent is the main coupling point
• ExtractMessages() method checks evt.Type == copilot.AssistantMessage — needs generic equivalent
• New engines will need API keys for each provider, which complicates getting-started experience

Acceptance Criteria

Phase 1

• ExecutionResponse uses generic event types (no copilot import)
• Copilot engine converts SDK events to generic types
• All existing tests pass unchanged
• No behavioral regression

Phase 2

• At least one non-Copilot engine implemented (Claude Code recommended)
• executor field in eval.yaml supports engine selection
• Generic CLI engine supports configurable command templates
• Documentation updated with multi-agent usage examples

Assignee Notes

Richard Park has explored supporting other engines — assign Phase 2 to him. Phase 1 (decoupling) can be done by anyone on the team as a prerequisite.

[spboyer]

Originally by @github-actions on 2026-02-18:

📋 Assigned to Richard Park (Go Engineer)

Issue: #195 — [E1] Decouple ExecutionResponse from Copilot SDK + Multi-Agent Engine Support

Richard Park will pick this up in the next Copilot session.

For Copilot coding agent: If enabled, this issue will be worked automatically.
Otherwise, start a Copilot session and say:
Richard Park, work on issue #195

[github-actions]

⚠️ No squad member found matching label squad:richard park. Check .ai-team/team.md for valid member names.

[spboyer]

Audit note: this is partially covered by open work, but should stay open.

• feat: add codex executor config support #233 adds Codex executor config support.
• feat: wire BYOK providers #240 wires custom-provider support for the Copilot SDK executor.
• The remaining gap is the core decoupling work: ExecutionResponse still exposes Copilot SDK event types, so the execution API is not fully engine-neutral yet.

[spboyer]

Audit note: this is partially covered by open PR #233, which adds Codex executor support and starts extending Waza beyond the Copilot SDK-only path. The remaining gap is the broader abstraction work: ExecutionResponse still exposes Copilot SDK event types, so the execution result model is not fully decoupled yet.

[spboyer]

Follow-up plan from issue audit

Open PR #233 adds Codex executor support, so this is partially covered, but the execution abstraction is still coupled to Copilot SDK event types.

Missing items

• Merge or supersede PR feat: add codex executor config support #233's executor support after review.
• Introduce provider-neutral execution event/result types so ExecutionResponse no longer exposes copilot.SessionEvent directly.
• Add adapter code that converts Copilot SDK events into the provider-neutral model.
• Update graders, transcripts, telemetry, and dashboard consumers to use the neutral model.
• Add tests proving Copilot and at least one non-Copilot engine can produce equivalent Waza outcomes.