Here's the PR body:
## Summary
Checkout called the FX provider on every cart render. During Friday's sale that went over the provider's 1,000 requests/minute limit, and checkout started returning 429 errors. `get_rate` now keeps each rate in memory for 5 minutes.
```diff
get_rate(base, quote)
+ if base:quote was fetched less than 300s ago
+ return the saved rate
GET api.example-fx.com/latest
raise on HTTP error
+ save rate for base:quote with time.monotonic()
return rate
Evidence
-
Before:
pytestshows 14 passed. Everyget_ratecall makes its own HTTP request.
After:pytestshows 15 passed. Addedtest_get_rate_uses_cache_within_ttl:get_rate("USD", "EUR") get_rate("USD", "EUR") assert provider was called once
Merge Danger
Door: two-way
The cache only lives in memory, with nothing persisted and no schema change. To roll back, revert the commit.
Blast Radius: checkout
- Stale rates: prices can use a rate up to 5 minutes old. Confirm that's acceptable for checkout pricing.
- Per-process cache: each worker keeps its own cache. Provider calls per 5 minutes are roughly workers × currency pairs, so the limit could still be reached with many workers.
- No size limit or eviction: this is fine for a fixed set of currency pairs.
- No locking: two requests that miss the cache at the same moment can both call the provider. The only cost is an extra request.
- Test isolation:
_cacheis module-level, so it carries over between tests unless a fixture clears it.
- **No `GLOSSARY.md`:** the repo doesn't have one, so I used the wording from your context and the code.
- **Check this before merging:** `test_get_rate_returns_quote` already caches `USD:EUR`. If nothing clears `_cache` between tests, the new test should see 0 provider calls and fail. Since it passes, the `mock_get` fixture probably resets the cache, but I couldn't see the fixture to confirm. If it doesn't, the test result depends on the order tests run in, and I'd add an autouse fixture that calls `_cache.clear()`.
Real run recorded with claude-code / claude-opus-5-5. Output is shown verbatim, unmodified. The only change: the trial machine's temp-folder path was replaced with a generic placeholder.
What it does
Writes a pull request description that is quick to review, in three parts.
How it works
- Summary: the smallest visual that makes the point. It can be pseudocode, a call tree, a component tree, a file tree, a Mermaid diagram or a diff sketch, placed next to the short text it supports.
- Evidence: a concrete before and after. Screenshots are best when the change is visual; otherwise the exact test that now fails and passes.
- Merge Danger: whether the change is a one-way or two-way door (can it be rolled back?), and its blast radius, such as layout shift or breakage for consumers.
- Skips preambles and keeps prose brief, using your
GLOSSARY.mdwording if the repo has one.
Good for
Pull requests where reviewers need to see what changed and how risky it is.
Worth knowing
In our trial it also flagged a risk it could not verify from the diff, a test-isolation question, instead of hiding it.
Pure instruction files: no scripts and no network access. The Summary section's menu of visuals is adapted from the show-me skill by Dex Horthy (HumanLayer, MIT licence); the package includes that licence as LICENSE-show-me and a CREDITS.md note. It only writes text and does not run git or open the pull request. The package also contains the original MIT LICENSE and agents/openai.yaml (display name for Codex).