feat: headless Slack workflow runner via Cursor ACP

[m2ux]

Problem Statement

The current workflow execution model requires one Cursor IDE window per active workflow. The IDE window, git working tree, and agent context are all shared within a single session, creating a serialization bottleneck: only one workflow can run at a time. To run a second workflow concurrently, the user must open a separate IDE window, manually configure it, and manage coordination between sessions.

This coupling between the workflow execution engine and the IDE presentation layer also limits where and how workflows can be triggered — only from a developer's desktop, only when the IDE is open, and only with direct visual attention on the session.

Current state:

• One workflow execution per IDE window
• Parallel workflows require manual setup of multiple IDE windows
• Workflow checkpoints (user decisions) require IDE interaction
• No way to trigger or monitor workflows from mobile or non-desktop contexts

Desired state:

• Multiple workflows execute concurrently, each in an isolated environment
• Workflows can be triggered and monitored from Slack (desktop and mobile)
• Workflow checkpoints are presented as interactive Slack messages
• No IDE window required for workflow execution

Goal

Enable parallel, headless workflow execution driven from Slack, removing the requirement for a dedicated IDE window per workflow run.

Scope

In Scope

• Headless agent runtime for workflow execution without an IDE window
• Slack-based trigger mechanism for starting workflows
• Checkpoint interaction via Slack interactive messages (buttons, selects)
• Filesystem isolation between concurrent workflow runs
• Progress streaming to Slack threads
• Graceful lifecycle management (startup, shutdown, cleanup)

Out of Scope

• Persistent state storage (in-memory sufficient for initial release)
• Error recovery and automatic agent restart
• Alternative agent runtimes (e.g., Claude Code)
• Multi-repository base configurations
• Rate limiting and concurrent session caps
• Observability infrastructure (structured logging, metrics dashboards)

User Stories

US-1: Trigger Workflow from Slack

As a developer, I want to start a workflow execution from a Slack slash command so that I don't need to open an IDE window or be at my desktop.

Acceptance Criteria:

• A Slack command initiates a workflow run with specified parameters
• The workflow executes to completion without IDE interaction
• Progress updates appear in a dedicated Slack thread

US-2: Parallel Workflow Execution

As a developer, I want to run multiple workflows concurrently so that different work packages can progress in parallel without blocking each other.

Acceptance Criteria:

• Multiple workflow runs execute simultaneously without interference
• Each run operates on an isolated copy of the repository
• Runs targeting different components do not conflict

US-3: Checkpoint Interaction via Slack

As a developer, I want to respond to workflow checkpoints through Slack interactive messages so that I can guide execution from anywhere, including mobile.

Acceptance Criteria:

• Workflow checkpoints appear as Slack messages with interactive buttons
• Clicking a button resumes the workflow with the selected option
• The checkpoint message updates to reflect the chosen response

US-4: Workflow Monitoring

As a developer, I want to see workflow progress streamed to a Slack thread so that I can monitor execution status without switching context.

Acceptance Criteria:

• Agent activity streams to the workflow's Slack thread
• Workflow completion or failure is clearly indicated
• Resources are cleaned up after workflow completion

Context

A proof-of-concept implementation exists on branch feat/headless-slack-runner (commit 6c054ff). The PoC covers the core module structure and unit tests (19 tests passing). Live validation against a real Slack workspace and Cursor ACP runtime is pending.

Constraints

• Runtime dependency: Requires Cursor CLI (agent binary) on the execution host
• Slack App setup: Requires a configured Slack App with Bot Token, App-Level Token, slash command, and interactivity enabled
• Network: Slack Socket Mode (outbound WebSocket only — no public URL or ingress required)

[m2ux]

Open Assumptions

All code-resolvable assumptions have been resolved through code analysis during planning. The following require stakeholder judgment or live validation:

• ACP cursor/ask_question params and response format match Cursor IDE schema (no public schema; requires live validation)
• Cursor CLI agent binary is available on PATH on the target host
• Agent streaming output via session/update with agent_message_chunk is frequent enough for meaningful Slack status posts
• cursor/create_plan can be auto-approved without user review
• SQLite is sufficient for session state persistence at single-user scale
• node:sqlite DatabaseSync API is stable enough for session persistence at single-user scale
• pino-roll v4 daily rotation and count-based retention are sufficient for log management
• Startup worktree sweep with wf-runner-* prefix is safe (plan changes prefix from run- to wf-runner-)
• Installing logging (pino) before persistence (SQLite) is the correct task ordering

Engineering Artifacts

Planning artifacts