SPEC.md: note new-sprint form weeks-drop + task list row hover

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

SPEC.md

@@ -1046,6 +1046,23 @@ with a `BOOTSTRAP_ADMIN` audit row.
       unchanged. *New sprint* stays in the header as the one
       quick-action admins reach for from any page.
 
+- [x] **New sprint form: drop weeks input + task list row hover**
+      (`3728106`). The `/sprints/new` form no longer collects an
+      `n_weeks` value — the week count is derived from `start_date` /
+      `end_date` exactly as Phase 21's `PATCH /sprints/{id}` does
+      (`floor((end−start)/7) + 1`, capped at 26; above that the form
+      now redirects with `?error=dates_too_long`). `SprintController::
+      create` drops `n_weeks_invalid` / `n_weeks_range`, gains
+      `dates_too_long`, and calls the existing static
+      `weeksBetween()` helper to seed `materializeWeeks`. The legacy
+      `POST /sprints/{id}/weeks` JSON endpoint still accepts
+      `n_weeks` for back-compat (UI doesn't call it). Task-table
+      `<tr>` rows in `views/sprints/_task_list.twig` (used by both
+      `show` and `present`) gain `hover:bg-slate-50
+      dark:hover:bg-slate-700` so the row tints under the cursor the
+      same way the sprints table on `/` does — also mirrored on
+      JS-built rows in `sprint-planner.js::buildTaskRow`.
+
 ### Upcoming
 
 Nothing scheduled.
@@ -1144,6 +1161,7 @@ before acting — nothing here is load-bearing once it grows stale.
 ## 13. Git history (as of this writing)
 
 ```
+3728106 New sprint form: drop weeks input + task list row hover
 fe78f45 Header: move Import link into the admin dropdown menu
 8e8b8fd Sprint settings: secured Delete sprint action
 be91620 SPEC.md: mark Phase 22 shipped (per-task hamburger menu)