"Interviews This Week" is a boot-weekday number, but the screenshot set and the #8 evidence pin it as a fixed 6

[os-sam]

Found while re-taking 03-hiring-home-overview.png for #78. Not caused by that card — #78 changes tile geometry and two titles, and does not touch a dataset, a widget filter or a seed row.

What happens

ats_employer_hiring's interviews_this_week tile counts a fixed calendar week — scheduled_at >= {current_week_start} and < {next_week_start}, i.e. Monday 00:00 up to next Monday. The demo seed schedules interview rounds relative to boot time (daysFromNow(1..14)). The two disagree by construction: how many seeded rounds land inside the current calendar week depends on which weekday the boot happens.

Measured today (2026-09-08, a Tuesday), memory driver, --fresh, after [Seeder] Seed loading complete {"inserted":818,...}, signed in as admin@quillstone.example:

all Quillstone-visible interviews: total=10 records=10 hasMore=false
  2026-09-09T09:00:00.000Z  status=scheduled  Wed  daysFromBoot=0.97  inThisWeekWindow=true
  2026-09-10T10:30:00.000Z  status=scheduled  Thu  daysFromBoot=2.03  inThisWeekWindow=true
  2026-09-11T11:00:00.000Z  status=scheduled  Fri  daysFromBoot=3.05  inThisWeekWindow=true
  2026-09-12T13:30:00.000Z  status=scheduled  Sat  daysFromBoot=4.16  inThisWeekWindow=true
  2026-09-13T14:00:00.000Z  status=scheduled  Sun  daysFromBoot=5.18  inThisWeekWindow=true
  2026-09-14T13:00:00.000Z  status=scheduled  Mon  daysFromBoot=6.14  inThisWeekWindow=false   <- one day outside
  ... four more, all later
count in Mon 2026-09-07 .. Mon 2026-09-14 window, not cancelled = 5
counterfactual, same rows shifted -1 day (a Monday boot)        = 6

Both paths agree on 5, so nothing is broken in the tile:

• dataset query — POST /api/v1/analytics/dataset/query, datasetName: ats_interview_metrics, selection.runtimeFilter = the widget's own filter → [{"interview_count":5}]
• independent list count — GET /api/v1/data/ats_interview?$filter=...&$count=true → total=5, records=5, hasMore=false

The compiled statement the analytics NativeSQLStrategy produced (logged by the memory driver as it refuses raw execution):

SELECT COUNT(*) AS "interview_count" FROM "ats_interview"
WHERE ((status IS NULL OR status != ?) AND scheduled_at >= ? AND scheduled_at < ?)
  AND ("ats_interview"."application" IN (?, ...))

Why it matters

Three places pin 6 as if it were a property of the seed:

• docs/screenshots/README.md — the 03 caption (ats_employer_hiring has a 3 + 1 tile layout since the fourth KPI landed, which pushes Pipeline by Stage below the fold #78 rewrites this one to say the number is boot-weekday dependent, which is the only reason that card noticed).
• docs/evidence/issue-8/README.md — "Hiring Overview · open jobs · awaiting action · interviews this week | Quillstone admin | 3 · 18 · 6", and 18 platform-wide / 1 for Harborline in the rows around it.
• Any future card that re-verifies those numbers: an agent booting on a Wednesday measures 4, finds it does not match the documented 6, and has no way to tell a regression from the calendar.

The other four numbers on that dashboard (3 · 18 · 30.0 · pipeline 10 / 8 / 5 / 2 / 1 + 1 rejected) are boot-day stable; this is the only one that moves.

Options

1. Seed relative to the week, not to the boot — schedule the "this week" rounds at {current_week_start} + n days so the count is the same every day. Touches src/data/ and changes what 04/05 photograph; the interview calendar shot would then always show the same week.
2. Document the dependence everywhere the number appears — cheapest, keeps the seed honest about being relative, but leaves every future re-measurement to re-derive the arithmetic.
3. Pin the docs to a Monday boot — state that the screenshot set and the evidence tables are captured on Mondays, and make that part of the re-take recipe.

No recommendation from here: which one is right depends on whether the demo seed is meant to look "live" on every boot (option 1 removes some of that) — a maintainer call.