Grounded coding and review
Agents plan, write and review changes against what is really deployed, so pull requests are right for production from the first draft.
An engineer opens Codex to change the checkout service.
Before writing anything, Codex calls B.O.R.I.S over MCP: what is deployed, which versions are running, and how the services connect - instead of inferring it all from the repository.
B.O.R.I.S surfaces what the repo doesn't show: another service reads checkout's data, so Codex's plan covers both - and the code targets what is really deployed.
Fewer pull requests that looked right to the AI and broke on contact with production.
Add a per-customer rate limit to the checkout service - plan it before you touch any code.
What's deployed for the checkout service, what's it running on, and what reads its data?
The checkout-app runs on the services EKS cluster in the production AWS environment - two healthy replicas across two Availability Zones, fronted by the checkout-app gateway.
The cache is Valkey 8.0.1, not Redis. The reporting-worker reads the same orders table, so a rate limit on the write path affects it too. Application code and Terraform config live in the checkout-app repository.
Plan: rate-limit at the gateway, not in the app - and reporting-worker reads the same table, so I'll cover its path as well. Writing against Valkey 8.0.1, not Redis.