38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
# 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 — Typed action routing — 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 establish their dispatch path. Execution of implementation requests is planned for 2.0.
|
|
|
|
## 2.0 — Implementation requests — planned
|
|
|
|
- Use the typed action from 1.3 to route explicit implementation requests to an 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.
|
|
|
|
## 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.
|