Repository navigation
start sprint2 plan
Planning doc · Written October 13, 2026 · Milestone "Sprint 2" due October 27, 2026
Theme: Moving from "propose a trade" to "safely execute, schedule, and gate trades behind human approval."
In Sprint 1 we got the agent to the point where it can look at the market and propose a Buy, Sell, or Hold. This sprint we make those proposals actionable — but safely. We will build the path that actually submits an approved order to the Alpaca paper broker, run the agent on a schedule instead of only by hand, and add the hard safety rules and human sign-off that stand between a proposal and a real (simulated) order. Throughout, we keep the three-layer separation intact: the model only proposes, and deterministic code decides whether anything executes.
We've grouped this sprint's fifteen items into five themes.
Goal: Give the agent a real way to place and track orders. We will build the broker gateway so that only a fully approved order can be submitted, its fields are validated first, and both our client order ID and Alpaca's order ID are stored. We will also confirm and restore order status so a timeout or retry can't quietly create a duplicate order. Why it matters: This is the first time the system actually acts in the (paper) market. It lives in the Execution & Safety layer — nothing reaches the broker without passing validation.
Goal: Let the agent run itself and make sure what the model produces is trustworthy. We will run scheduled cycles every 15 minutes, each one checking the market clock, agent state, and kill switch before doing anything. We will validate and repair malformed model output — one repair attempt is allowed, and if the output still isn't valid the cycle ends rather than guessing missing values. We will also introduce a versioned system prompt that only permits BUY/SELL/HOLD, requires evidence, and defaults to HOLD when the data is uncertain. Why it matters: Automation is only safe if the model's output is predictable. This keeps the Reasoning layer constrained and makes sure bad output never flows downstream.
Goal: Put non-negotiable limits around the agent. We will enforce the paper-trading endpoint so a misconfiguration can never point at a real-money account, prevent duplicate and conflicting orders by checking open orders and keeping client order IDs unique, and enforce daily loss and daily order-count limits so the agent's activity stays bounded. Why it matters: These are the guardrails that must hold even if the model misbehaves — the core of the Execution & Safety layer.
Goal: Keep a person in control of what executes. We will route safe proposals into a Pending Approval state that shows the details, the policies applied, and an expiration time, and we will let an operator approve or reject them. Approvals record who acted and when, proposals can't be edited, expired approvals can't execute, and the final policy checks run again before anything is submitted. Why it matters: This is the deliberate gate between a safe proposal and execution, and the re-check on approval is the last line of the Execution & Safety layer.
Goal: Pay down the engineering debt that makes safe code harder to trust. We will centralize scattered module-level constants (for example cycle statuses, retry/watchlist settings, and the policy version) into one shared config file (#94). We will also harden how we test and check our code: add test-coverage measurement for both backend and frontend (#96), widen our Python linting in CI so it covers every backend package instead of just a slice (#97), run the frontend linter in CI (#98), and add Python type checking plus pre-commit hooks so problems are caught before they reach CI (#99). Why it matters: As the safety rules multiply, the tooling around them has to keep up. One place for the knobs keeps limits consistent and auditable, and stronger linting, typing, and coverage give us confidence that the guardrail and execution code actually does what we think. These items came out of review of PR #93 and the Sprint 1 testing-surface review.
| # | Story | Owner(s) |
|---|---|---|
| #62 | 1.3.1 Submit an approved paper order | dhruvpatel0003, ssonare |
| #63 | 1.3.2 Confirm and restore order status | sandhya1631, ssonare |
| #28 | 2.3.1 Execute scheduled decision cycles | dhruvpatel0003, ssonare |
| #27 | 2.2.2 Validate and repair malformed LLM output | ssonare |
| #67 | 2.1.2 Versioned system prompt architecture | dhruvpatel0003, ssonare |
| #70 | 3.1.1 Enforce the paper-trading endpoint | sandhya1631, ssonare |
| #73 | 3.2.2 Prevent duplicate and conflicting orders | sandhya1631, ssonare |
| #74 | 3.2.3 Enforce daily loss and order limits | dhruvpatel0003, sandhya1631 |
| #76 | 3.3.1 Request approval for safe proposals | sandhya1631, ssonare |
| #77 | 3.3.2 Approve or reject a proposal | dhruvpatel0003, sandhya1631 |
| #94 | Centralize scattered module-level constants | ssonare |
| #96 | Add test coverage measurement (backend + frontend) | jared |
| #97 | Expand Ruff lint scope in CI to all backend packages | jared |
| #98 | Run ESLint in CI (frontend-ci job) | jared |
| #99 | Add Python type checking (mypy) and pre-commit hooks | jared |
The live dashboard and broader observability work is a later sprint (Sprint 3). Sprint 2 stays focused on safe execution, scheduling, and human approval so that by the time we visualize the agent's activity, there's a safe and trustworthy execution path to show.
Expanding our integration-test coverage beyond the single live-service test — and deciding how those tests run in CI (#100) — is also planned for Sprint 3, alongside the dashboard work.