Summary
/playground now exposes a manual fallback path that creates a new playground session directly from the web app. That POST currently creates a new SQLite row with no abuse protection.
Why
The MCP-first landing flow is correct, but the manual session endpoint can still be spammed by repeated requests. We already have per-IP rate limiting patterns in the reviews flow, so playground session creation should have a similar guardrail.
Suggested direction
- add per-IP rate limiting for manual session creation
- keep MCP-driven create_playground behavior unchanged unless we explicitly want the same protection there
- reuse or extract the existing reviews rate-limit approach where it makes sense
- return a clear user-facing error when the limit is hit
- add tests covering the allowed window and the rejection case
Context
Follow-up from PR #77 review comment 4 so the concern is tracked without expanding that PR's scope.
Summary
/playground now exposes a manual fallback path that creates a new playground session directly from the web app. That POST currently creates a new SQLite row with no abuse protection.
Why
The MCP-first landing flow is correct, but the manual session endpoint can still be spammed by repeated requests. We already have per-IP rate limiting patterns in the reviews flow, so playground session creation should have a similar guardrail.
Suggested direction
Context
Follow-up from PR #77 review comment 4 so the concern is tracked without expanding that PR's scope.