Force Copilot Workspace through spec, plan, and pilot before it writes real code

Open this issue in GitHub Copilot Workspace. Workspace has three distinct stages —
specification, plan, and implementation — and each one is individually editable before you
advance to the next; do not let it collapse straight to a diff. Stop at the end of each stage
below and wait for explicit approval before Workspace proceeds to the next one.

ISSUE
Users on the free tier can currently export more than 3 reports per month by editing the request payload directly.

ACCEPTANCE CRITERIA
1. Free-tier requests past the 3rd export in a rolling 30 days return a 403 with a clear error message. 2. Paid tiers are unaffected. 3. The limit is configurable, not hardcoded.

CONSTRAINTS
Must use the existing rate-limit middleware in lib/middleware/rate-limit.ts, not a new library.

OUT OF SCOPE
Billing-plan changes, upgrade prompts in the UI, and retroactive enforcement on exports already made this month.

SPECIFICATION STAGE
When Workspace proposes the spec, check that it restates the problem in its own words rather than
echoing the issue text back verbatim, names every file it currently believes it will touch, and
flags — rather than silently resolves — any place the acceptance criteria above are genuinely
ambiguous. If the spec resolves an ambiguity without flagging it, reject it and ask specifically
which interpretation it chose and why, before moving on.

PLAN STAGE
Once the spec is approved, check the plan against these two things before approving it in turn:
first, that its steps map one-to-one onto the numbered acceptance criteria, so nothing in the plan
exists that the acceptance criteria did not ask for and nothing the acceptance criteria did ask
for is missing a corresponding step; second, given the rough scope of Roughly 4 files: the middleware, a new config constant, the export route handler, and one new test file., that
foundational files — shared types, config, anything another file in the plan depends on — are
scheduled before the files that depend on them, not in whatever order Workspace happened to list
them.

CHECKING CONSTRAINTS SPECIFICALLY
Before approving the plan, go back through every item in Must use the existing rate-limit middleware in lib/middleware/rate-limit.ts, not a new library. individually and confirm
the plan actually satisfies it rather than simply not contradicting it outright — a constraint
that says an existing helper must be reused is violated just as much by a plan that quietly writes
a new parallel helper next to it as by one that removes the existing helper entirely, and only the
second version is likely to be caught by skimming.

IMPLEMENTATION STAGE
Implement lib/middleware/rate-limit.ts's export-count check first as the pilot — it is the foundational piece everything else calls into.
If this issue touches more than two or three files, ask Workspace to implement only the single
file named above first and stop, so a wrong approach costs one file's diff to revert rather than
the full change. Once that file's diff looks right against the approved plan, allow the rest to
proceed.

THROUGHOUT ALL THREE STAGES
Do not let Workspace treat a stage as a formality to click through quickly on its way to the code
— an unread spec approved out of habit gives you nothing more than skipping it entirely would,
except the appearance of having reviewed it. If any stage's output does not actually match what
was asked for in this brief, say so and regenerate that stage rather than accepting a close-enough
version and correcting it later once code already depends on it.