qpismont
7493de6952
ci/woodpecker/push/tests Pipeline was successful
Expose /jobs, /dedup, and /events routes backed by a new EventBus that broadcasts job lifecycle and per-job progress over SSE. Serve a static dashboard from front/ that lists pending and in-progress jobs, streams agent activity, and shows completed reviews. Also add migrate-apply/migrate-generate scripts that load .env, update the Containerfile to ship the front assets and use the apply script, and refresh the roadmap.
50 lines
3.2 KiB
Markdown
50 lines
3.2 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 — 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.
|