feat(quiz): weight generation toward an approaching exam (#555) by AndresL230 · Pull Request #573 · SaplingLearn/Sapling

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

AndresL230 · 2026-08-22T09:15:48Z

Closes#555. Workstream H3 of epic #537.

assignments.due_date is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two.

Dates only

No grade value is read, stored, or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and nothing here selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model — this feature doesn't need to test that boundary, so it doesn't.

The heuristic is extracted, not re-written

As the issue asks. services/exam_proximity.py::is_exam is now the single definition and routes/study_guide.py calls it. A second copy would drift — which is the failure #557 spent a workstream undoing, one issue earlier in this same workstream.

Shape of the answer

0 means the exam is TODAY, and is deliberately distinct from None ("no upcoming exam, or we couldn't tell"). Collapsing them — or writing if exam_days_away: — drops the single most actionable value the feature produces. Pinned by test on both the prompt string and the stored row.
Resolved once per generation, then both prompted and stored. Computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads.
min() over upcoming exams, not "first row of a due_date.asc query". The ordering is requested, but relying on it makes the answer wrong-and-silent if it's ever dropped or degraded, and the minimum costs nothing here.
Never raises. It runs inline on the generation path; one optional prompt line is not worth failing a generation over.

The prompt line

States the deadline and lets the model decide what it implies. It deliberately does not say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely rather than spending tokens to say "unknown".

Migration

20260822090747 adds a nullable exam_days_away to quiz_attempts, because the issue's point is to be able to ask later whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure.

No DEFAULT: 0 would make every legacy row and every unknown look like exam day.

Applied to staging and verified before this code ships — integer, is_nullable = YES, no default, 2 existing rows NULL. The write omits the key when unknown (mirroring apply_graph_update's rule), so an environment that takes the code first keeps generating instead of 400ing on a column PostgREST's schema cache doesn't have.

Verification

Hermetic 2200 passed / 9 skipped, ruff clean, oracles 0 findings, integration 56 passed, Playwright 46 passed.

Two failures, neither from this PR: landing-drag-field.spec.ts:332 (#566, red on main, fixed by #568) and gradebook.spec.ts:35 (#569, the intermittent — 0 failures across 4 clean-main full-suite runs and 6 isolated runs).

🤖 Generated with Claude Code

`assignments.due_date` is plaintext and indexed, and nothing anywhere computed "exam in N days" — so a quiz taken the night before a midterm was generated exactly like one taken in week two. **Dates only.** No grade VALUE is read, stored or prompted on this path. Proximity is a property of the calendar, not of performance; the points columns are encrypted (#521) and this code never selects them. The audit flags that the current ToS and privacy policy don't clearly cover feeding grades to a model, and this feature does not need to test that. The exam heuristic is EXTRACTED rather than re-implemented, as the issue asks: `services/exam_proximity.py::is_exam` is now the single definition and `routes/study_guide.py` calls it. Writing a second copy is the failure #557 spent a workstream undoing, one issue earlier in this same workstream. Shape of the answer: * `0` means the exam is TODAY and is deliberately distinct from `None` ("no upcoming exam, or we could not tell"). Collapsing them — or writing `if exam_days_away:` — drops the single most actionable value the feature produces. Pinned by test on both the prompt and the stored row. * Resolved ONCE per generation and then both prompted and stored: computing it twice could report one number to the model and a different one to the analytics row if an exam were entered between the reads. * `min()` over the upcoming exams rather than "first row of a due_date.asc query" — the ordering is asked for, but relying on it makes the answer wrong-and-silent if it is ever dropped or degraded, and the minimum costs nothing to compute here. * Never raises: it runs inline on the generation path, and one optional prompt line is not worth failing a generation over. The prompt line states the deadline and lets the model decide what it implies. It deliberately does NOT say "make it harder" — that would contradict the difficulty the student actually chose, and adaptive mode already owns that decision. When proximity is unknown the line is omitted entirely, rather than spending tokens to say "unknown". Migration `20260822090747` adds a nullable `exam_days_away` to `quiz_attempts`, because the issue's point is to be able to ASK LATER whether deadline-aware quizzes perform differently — a value that only reached a prompt leaves nothing to measure. No DEFAULT: `0` would make every legacy row look like exam day. Applied to staging and verified before this code ships (nullable, no default, 2 existing rows NULL); the write omits the key when unknown, so an environment that takes the code first keeps generating. Hermetic 2200 passed / 9 skipped, ruff clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

cloudflare-workers-and-pages · 2026-08-22T09:15:53Z

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	`47d5555`	Commit Preview URL Branch Preview URL	Aug 22 2026, 09:26 AM

supabase · 2026-08-22T09:16:33Z

This pull request has been ignored for the connected project ybgqdonkoqftwrmweuyv because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

coderabbitai · 2026-08-22T09:18:21Z

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:3 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7be65e6e-d910-4ed9-9433-f3d34991f6e4

📥 Commits

Reviewing files that changed from the base of the PR and between e139954 and 47d5555.

📒 Files selected for processing (6)

backend/db/migrations/20260822090747_quiz_attempts_exam_days_away.sql
backend/routes/quiz.py
backend/routes/study_guide.py
backend/scripts/benchmark_quiz.py
backend/services/exam_proximity.py
backend/tests/test_exam_proximity.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

CI was red: I ran `ruff check` BEFORE adding the wiring tests and reported it clean in the previous commit message. Three violations in the new test file (two dead imports and an unused `Quiz`); the repeated agent-run construction is hoisted into a helper rather than rebuilt per test. **The heuristic was too loose for a decision.** `is_exam` was written for a user-visible picker, where a false positive costs one extra row. Reused verbatim it drove a prompt AND `quiz_attempts.exam_days_away` — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft - essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group becomes "any course with weekly quizzes". Added `is_exam_strict` for the decision path: no "quiz" keyword, word-anchored matching, `assignment_type == "exam"` still wins. The picker keeps the loose form, which is right for a list. **No proximity horizon.** A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on EVERY quiz for the semester — no proximity signal, and it steers week-two practice toward exam questions, which is what the code comment claims to be avoiding. The prompt line is now bounded by `PROMPT_HORIZON_DAYS`; the stored column is deliberately NOT clamped, because the analytics want the real distance. **Four serial round-trips, fully additive, outside the safety net.** The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It is now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. `_quiz_via_agent` returns a `GeneratedQuiz` so the value it used for the prompt is the one stored on the attempt, rather than being resolved twice. **The attempt insert could 500 a quiz that already ran.** Omit-when-None does not make a pre-migration environment safe: it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed — quiz lost, no attempt row, no `quiz.generation_failed`, no refund. `_insert_attempt` retries once without the key and re-raises anything else, so a genuine write failure still surfaces. Also: UTC (`_today` was naive local time, a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics); `datetime` checked before `date` in `_parse_date` (datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup); enrollment resolution via `services/academics.py::user_enrollment_ids`, which CLAUDE.md names as its single home and which had already read those rows a line earlier. Hermetic 2207 passed / 9 skipped, ruff clean — verified after the tests, this time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AndresL230 · 2026-08-22T09:28:39Z

Review round — eight findings, all fixed in `47d5555d`

Starting with the one that was my fault twice over: CI was red and my "ruff clean" claim was stale. I ran ruff checkbefore adding the wiring tests and then reported it clean in the commit message. Three violations in the new test file. Fixed, and the repeated agent-run construction is hoisted rather than rebuilt per test.

Two findings changed behaviour materially:

The heuristic was too loose for a decision.is_exam was written for a user-visible picker, where a false positive costs the student one extra row to look at. Reused verbatim, it drove a prompt andquiz_attempts.exam_days_away — so a course with weekly "Quiz 3"/"Quiz 4" rows has an "exam" within a week all semester, and "Final draft — essay 2" is a final. That poisons the exact question the column exists to answer, because the treatment group for "do deadline-aware quizzes perform differently?" silently becomes "any course with weekly quizzes". Added is_exam_strict for the decision path (no quiz keyword, word-anchored, assignment_type == "exam" still wins); the picker keeps the loose form, which is correct for a list.

No proximity horizon. A final dated 87 days out put "there is an exam coming, weight toward what an exam tests" on every quiz for the whole semester — no proximity signal at all, and it steers week-two practice toward exam-style questions, which is what my own comment claimed to be avoiding. The prompt line is bounded by PROMPT_HORIZON_DAYS now; the stored column is deliberately not clamped, because the analytics want the real distance.

The rest:

Four serial round-trips, fully additive, outside the safety net. The lookup ran before the try block and before the existing gather, so its latency added to every generation and a failure there consumed a rate-limit slot with no refund. It's now the third leg of the gather that already runs grounding and the recently-asked read concurrently — it is best-effort context exactly like those two. _quiz_via_agent returns a GeneratedQuiz so the value used for the prompt is the one stored on the attempt, rather than resolved twice.
The attempt insert could 500 a quiz that already ran. Omit-when-None does not make a pre-migration environment safe — it protects the no-exam case and breaks precisely the students the feature is for, so it presents as a random partial outage. And it lands after the agent has been billed: quiz lost, no attempt row, no quiz.generation_failed, no refund. _insert_attempt retries once without the key, and re-raises anything else so a genuine write failure still surfaces.
UTC._today was naive local time — a day out from study_guide/calendar on any non-UTC deployment, and off-by-one for the analytics.
datetime before date in _parse_date: datetime subclasses date, so the obvious order returned it unconverted and the later subtraction raised into the outer catch, silently degrading the lookup to None.
Enrollment resolution through services/academics.py, which CLAUDE.md names as its single home — and which had already read those rows one line earlier.

Also fixed the return-type ripple the review didn't flag: scripts/benchmark_quiz.py returned _quiz_via_agent(...) straight through to a list[dict] caller, which a NamedTuple would have broken silently — no test covers that offline script.

Verification

Hermetic 2207 passed / 9 skipped, ruff clean (verified after the tests this time), oracles 0 findings, integration 56 passed, Playwright 47 passed — the one failure is #566, fixed by #568. CI green.

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

github-code-qualityBot found potential problems Aug 22, 2026
View reviewed changes

Comment threadbackend/tests/test_exam_proximity.py Fixed

AndresL230 merged commit 8626903 into mainAug 22, 2026
7 checks passed

AndresL230 mentioned this pull request Aug 23, 2026
ci: give the integration lane the function-mode env it demands #583
Merged

Uh oh!

Conversation

AndresL230 commented Aug 22, 2026

Dates only

The heuristic is extracted, not re-written

Shape of the answer

The prompt line

Migration

Verification

Uh oh!

cloudflare-workers-and-pagesBot commented Aug 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying with Cloudflare Workers

Uh oh!

supabaseBot commented Aug 22, 2026

Uh oh!

Uh oh!

coderabbitaiBot commented Aug 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

AndresL230 commented Aug 22, 2026

Review round — eight findings, all fixed in 47d5555d

Verification

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

AndresL230 commented Aug 22, 2026

Dates only

The heuristic is extracted, not re-written

Shape of the answer

The prompt line

Migration

Verification

Uh oh!

cloudflare-workers-and-pagesBot commented Aug 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying with Cloudflare Workers

Uh oh!

supabaseBot commented Aug 22, 2026

Uh oh!

Uh oh!

coderabbitaiBot commented Aug 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

AndresL230 commented Aug 22, 2026

Review round — eight findings, all fixed in 47d5555d

Verification

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

AndresL230 commented Aug 22, 2026

Dates only

The heuristic is extracted, not re-written

Shape of the answer

The prompt line

Migration

Verification

Uh oh!

cloudflare-workers-and-pagesBot commented Aug 22, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

cloudflare-workers-and-pagesBot commented Aug 22, 2026•
edited
Loading

coderabbitaiBot commented Aug 22, 2026•
edited
Loading

Review round — eight findings, all fixed in `47d5555d`

cloudflare-workers-and-pagesBot commented Aug 22, 2026•
edited
Loading

coderabbitaiBot commented Aug 22, 2026•
edited
Loading

Review round — eight findings, all fixed in `47d5555d`

cloudflare-workers-and-pagesBot commented Aug 22, 2026•
edited
Loading

coderabbitaiBot commented Aug 22, 2026•
edited
Loading

Review round — eight findings, all fixed in `47d5555d`

cloudflare-workers-and-pagesBot commented Aug 22, 2026•
edited
Loading

coderabbitaiBot commented Aug 22, 2026•
edited
Loading

Review round — eight findings, all fixed in `47d5555d`