steep/ROADMAP.md

Roadmap

1.2 — Sandboxed reviews — delivered

• Run each pull request review in an ephemeral Dev Container.
• Let the model explore the checked-out repository through read-only tools instead of sending the source code in the prompt.
• Anchor review comments to changed lines and classify findings by severity.

1.2.1 — Default Dev Container — delivered

• If a repository has no Dev Container configuration, run its review in a default container based on debian:stable-slim.
• Use /workspace as the workspace path for the default container and as the fallback when workspaceFolder is not specified.

1.3 — Durable jobs & resumption — planned

• Persist review jobs and their progress in PostgreSQL so in-flight work survives a restart and can be resumed instead of being lost.
• Expose an API to retrieve the list of jobs by state: running, pending, and review done.
• Stream job events over Server-Sent Events (SSE) so clients see status changes in real time.

1.4 — YAML configuration — planned

• Add a YAML configuration file as the primary way to configure Steep, replacing part of the current environment variables.
• Move non-secret settings such as the model, timeouts, concurrency limit, and sandbox iterations into the file, and keep secrets (API keys, tokens, webhook secret, database URL) in environment variables.

2.0 — Typed action routing and implementation requests — planned

• Introduce a type-safe model output for the action Steep should take, such as Review or Implementation.
• Route review requests (for example, “@steep, review this PR”) to the existing review flow.
• Recognize implementation requests (for example, “@steep, rename method XXX to YYY”) and route them to the implementation workflow.
• For a request on an issue, clone the repository from its default branch and implement the requested features on a new branch.
• For a request on an existing pull request, clone its branch and implement the requested modifications there.
• When the agent's iteration loop ends, the orchestration layer automatically pushes the resulting changes: it opens a pull request for issue-based work, or updates the existing pull request branch. The agent does not receive or invoke a push tool.
• Keep implementation work isolated in a sandbox; do not modify the default branch directly.

2.1 — AGENTS.md support and multi models — planned

• Read applicable AGENTS.md files from the repository and use their project-specific instructions when carrying out implementation requests.
• Allow configuring a dedicated model for pull request reviews and another for implementation requests.
• Route each action type to its configured model, with a clear fallback when only one model is configured.

2.2 — Sub-agents — planned

• Let the agent delegate well-scoped parts of a task to sub-agents that run their own iteration loop.
• Run independent sub-agents in parallel and have the main agent consolidate their results.

3.0 — Autonomous Sentry fixes — planned

• Automatically discover project errors reported by Sentry, without waiting for a user comment.
• Investigate the errors in an isolated sandbox, implement candidate fixes, and validate them before reporting the results.