Replace the capstone's hardcoded due date 2026-07-15 with relative dates #30

New Issue

2026-06-22T14:23:52-04:00

claude commented

2026-06-22 14:23:52 -04:00

Problem

The lab and feature section hardcode --due 2026-07-15 for the "not overdue" example and assert it should NOT appear in overdue. With the current date near 2026-06-22 it barely holds; any learner running after 2026-07-15 sees "file taxes" listed as overdue, contradicting the printed expected output and making a correct implementation look broken. The whole due-today/due-future boundary lesson depends on dates relative to the run date.

Evidence

capstone/README.md (~lines 49, 170-172): python cli.py add "file taxes" --due 2026-07-15 … python cli.py overdue # should list "renew domain", not "file taxes". The past-date example (2020-01-01) is not volatile.

Why it matters

A self-inverting printed assertion in the exact lab whose point is date-boundary correctness; short shelf life and time-sensitive (about to break).

Proposed change

Instruct the learner to pick dates relative to their own today: "a date a few months in the future" for not-overdue, "a date in the past" for overdue (the 2020-01-01 example can stay).
Add a Verify-before-publish note to refresh example dates.
Leave the genuine "due today" boundary trap (in the test/review steps) untouched.

Acceptance criteria

The not-overdue example uses a date relative to "today," not a fixed near-future date.
The printed expected overdue output holds whenever the lab is run.
A Verify-before-publish note covers the example dates.

Affected files

capstone/README.md

References

Source finding F46 (realVotes 3/3). Current date context: 2026-06-22.

Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.

## Problem The lab and feature section hardcode `--due 2026-07-15` for the "not overdue" example and assert it should NOT appear in `overdue`. With the current date near 2026-06-22 it barely holds; any learner running after 2026-07-15 sees "file taxes" listed as overdue, contradicting the printed expected output and making a correct implementation look broken. The whole due-today/due-future boundary lesson depends on dates relative to the run date. ## Evidence `capstone/README.md` (~lines 49, 170-172): `python cli.py add "file taxes" --due 2026-07-15` … `python cli.py overdue # should list "renew domain", not "file taxes"`. The past-date example (`2020-01-01`) is not volatile. ## Why it matters A self-inverting printed assertion in the exact lab whose point is date-boundary correctness; short shelf life and time-sensitive (about to break). ## Proposed change 1. Instruct the learner to pick dates relative to their own today: "a date a few months in the future" for not-overdue, "a date in the past" for overdue (the `2020-01-01` example can stay). 2. Add a Verify-before-publish note to refresh example dates. Leave the genuine "due today" boundary trap (in the test/review steps) untouched. ## Acceptance criteria - [ ] The not-overdue example uses a date relative to "today," not a fixed near-future date. - [ ] The printed expected `overdue` output holds whenever the lab is run. - [ ] A Verify-before-publish note covers the example dates. ## Affected files - `capstone/README.md` ## References Source finding F46 (realVotes 3/3). Current date context: 2026-06-22. --- *Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*