Explain empty slot lists and minimum-notice gaps

[distronode-com]

Fixes #20

Two silences on the booker-facing surfaces, both now answered on all three of them
(book.html, manage.html, embed.js).

1. An empty day says which day it is

no_available_times now takes the date, and a new no_available_times_host adds the host:

Alex has no available times on Monday, 15 June.

The host is named only when there is exactly one — the event type's single host, or on
the manage page the booking's single assigned host. HostsLabel can be
Alex, Sam & 2 others, which cannot be the subject of that sentence in any of the eight
locales without a plural verb no key can supply, so the surfaces fall back to the
date-only form instead of mangling it. SoleHostName on both page-data structs carries
that decision server-side.

2. The minimum-notice policy explains itself

When min_notice_minutes is what removed the nearest starts, the surfaces say so:

Bookings must be made at least 4 hours in advance.

(The issue suggests "Bookings require 4 hours' notice"; the possessive does not survive
composing the duration from the existing duration_* keys, so this is the same statement
in plainer words. It is one locale key if you would rather have different wording.)

It renders on the day the policy actually thinned, whether or not later times remain —
a day showing 2pm onwards but nothing this morning is exactly the reported case — and
also in the "pick a day" state, because a day the policy emptied completely is greyed
out in the calendar and so can never be clicked for an explanation.

Where the decision is made

Server-side, in the engine that already knows it, rather than re-derived in three front
ends. slots.GenerateDetailed(req, slots.Extras{NoticeGap: true}) reports the starts the
notice rule removed, collected during the main walk (the cutoff is evaluated there anyway)
rather than by a second pass like taken. Generate and GenerateWithTaken keep their
signatures and delegate.

Two exclusions are what make the answer honest rather than merely plausible:

• A start already in the past is never reported. It would have gone with no policy at
  all. Blaming the policy for it would put the message on every event type by dinnertime.
• A start a booking took away is never reported. Busy intervals are applied on the way
  in, so NoticeGap and Taken are structurally disjoint and no start is ever explained
  two ways.

Routing rules are applied to the withheld starts too, so a collective start that only
one host could have made is not blamed on the notice policy either.

API

GET /v1/event-types/{slug}/slots gains:

"min_notice": { "minutes": 240, "dates": ["2026-06-15"] }

dates are booker-local YYYY-MM-DD keys, matching what the surfaces already group slots
by. Only the day travels: the individual withheld times would describe the host's working
hours at a finer grain than the feature needs. The field is absent when the event type
sets no minimum notice and present with an empty dates when it sets one that cost
this range nothing — the same distinction taken draws, for the same reason.

GET /v1/event-types/{slug}/public gains min_notice_minutes and min_notice_label, and
the two page-data structs gain MinNoticeLabel. The translated duration is rendered
server-side via the existing durationLabel because the /slots call the surfaces make
carries no ?lang= — a label built from that response would silently ignore a language
override. minutes still travels for a client with no label of its own.

Translations

Three keys across all eight locales: no_available_times (now takes %s),
no_available_times_host (%[1]s/%[2]s, indexed so a translation can put the date
first — German and Swedish do), and min_notice_hint. The non-English values are LLM
drafts in the register of their neighbours, consistent with the project's stated position
on them; a native speaker's corrections are welcome and cheap to apply.

One thing worth knowing: embed.js does not load booking-logic.js

assets/booking-logic.js's own header said it was "prepended to embed.js (so
BookingLogic is a page global)", and ARCHITECTURE §8 said all three surfaces share it.
Neither is true: EmbedJS serves the embedded file unmodified, so BookingLogic is
undefined inside the widget — which is why the widget already carries its own dowLabels,
timeLabel and day grouping. Wiring BookingLogic.fmt into it would have thrown a
ReferenceError on customers' sites and nothing in the tree would have caught it.

So: the widget gets its own fmt beside its other local helpers, the module header and
ARCHITECTURE §8 are corrected, and TestEmbedJSDoesNotDependOnBookingLogic fails on any
non-comment reference to BookingLogic in embed.js, so a well-meant de-duplication
cannot ship that bug. CLAUDE.md makes the same claim; I have left it alone as it is your
file.

Testing

go test ./... green (26 packages); gofmt -l . empty; go vet ./... clean;
go test ./internal/i18n/ green, including same-keys, printf-verb parity and the CLDR date
cross-check across all eight locales; node --test internal/handler/assets/booking-logic.test.js
14/14. I also ran node --check over embed.js and over every inline script block of both
templates with the template actions stubbed. Nothing under frontend/ changed, so the
admin-UI visual suite is not implicated.

New tests:

• internal/slots/notice_gap_test.go — the gap is exactly what min notice removed and the
  same starts are absent from Free; it carries no host ids; a start already in the past
  is not blamed on the policy (the 16:00-with-one-hour-notice case); a booked start is not
  either, with NoticeGap/Taken asserted disjoint; no policy means no gap; the output is
  opt-in and the Generate wrappers still agree; routing modes are respected; the starts
  are rendered in the booker's timezone.
• internal/handler/slots_notice_test.go — the /slots payload: dates present and
  confined to the notice window, min_notice absent with no policy, present with empty
  dates when the policy cost the range nothing, and keyed to the requested timezone.
  Every assertion is phrased relative to the real clock, since computeSlots calls
  time.Now itself — nothing here holds only during office hours.
• booking_surfaces_contract_test.go — extends your existing three-surface net: all three
  reference the new keys and the min_notice field, and en.json actually defines them
  (Locale.T falls back to the key itself, so a rename would show min_notice_hint to a
  visitor).

Not included

• No CSS. A day the policy emptied stays greyed out in the calendar rather than becoming
  clickable-but-empty, which would have needed a new day-cell state in the shared
  booking.css and a third meaning for the "available" class. The explanation is reachable
  in the pick-a-day state instead.
• The booking assistant and MCP are unchanged. They pass includeTaken: false today and
  the same reasoning applies here: an agent needs bookable times, not prose about why
  others are missing.

[github-actions]

All contributors have signed the CLA. ✅
_{Posted by the CLA Assistant Lite bot.}

[distronode-com]

I have read the CLA Document and I hereby sign the CLA

[pullfrog]

ℹ️ No critical issues — two rough edges worth a look.

Reviewed changes in this run: full diff of PR #23 (empty-day copy + min-notice gap explanations across booking surfaces).

• Slot engine NoticeGap — GenerateDetailed / Extras collect min-notice-withheld starts in the main walk; past and busy starts excluded; routing applied; Generate wrappers unchanged.
• Slots + public API — min_notice: {minutes, dates} on /slots; server-rendered min_notice_label / SoleHostName on book, manage, and /public.
• Three surfaces — empty-day host/date messages and notice hints on thinned days and pick-a-day; embed keeps a local fmt and a regression test against BookingLogic.
• i18n + tests — three keys in all eight locales; engine, handler, and three-surface contract coverage.

ℹ️ Pick-a-day notice is one-shot after the first day pick

On book.html, renderNoticeHint only shows when !pickedDate. Once any day is chosen, the standalone hint stays hidden for the rest of the session, and a day the policy emptied completely remains grey and unclickable — so that explanation is no longer reachable. Manage has the same shape once a day is chosen. Fine if the primary case is a thinned day (notice still appears in fillSlots); if fully emptied greys are common, consider keeping a non-list notice visible whenever noticeDates is non-empty and the open day is not already showing the line.

Technical details

# Pick-a-day notice lifetime

## Affected sites
- `internal/handler/templates/book.html` — `renderNoticeHint` (`show = !pickedDate && …`)
- `internal/handler/templates/manage.html` — `renderPickDayHint` early-returns when `pickedDate`
- `internal/handler/embed.js` — notice in pick state only when `!st.day`

## Required outcome
- A visitor who first picks an unaffected later day can still learn why a fully emptied near day is grey, without a full page reload.

## Suggested approach (optional)
- Keep the standalone hint visible when `noticeDates` has entries and the selected day is absent from that set (or always show it under the calendar).

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Grok ｜ 𝕏}

[distronode-com]

Thanks — the flake is real and I have pushed the fix (a612b68).

You were right about the mechanism: seedNoticeEventType opens availability at 00:00, so
tomorrow's first slot is midnight, and in the last minute of a UTC day a one-minute notice puts
the cutoff past it. About 59 seconds a day where the test fails for a reason unrelated to what
it asserts. The window now starts at +2 days, so every candidate slot is at least 24 hours
beyond any cutoff that policy can produce, whatever the clock says.

On the pick-a-day notice being one-shot: you have read it correctly, and it was a deliberate
choice I should have written down. The hint is suppressed once a day is picked because the
thinned-day case already carries its own line inside fillSlots, and repeating a standalone
banner above it read as duplicated. The gap you have found is the fully-emptied day, which
stays grey with no explanation reachable after the first pick.

I would rather not fix that by keeping the banner permanently visible, since it would sit above
days it does not apply to. The better shape is probably making a fully-emptied notice day
clickable and letting the empty-day message explain itself, which is a slightly larger change to
day-cell state than this PR should carry. Happy to do it here if you would prefer it in one go,
or to leave a follow-up issue and keep this PR to the copy it set out to add. Your call.

[pullfrog]

✅ No new issues found.

Reviewed changes since the prior pullfrog review on 8228988: one test-only commit that stabilizes the empty-dates notice assertion.

• Clock-safe empty-dates window — TestGetSlots_minNoticeDatesEmptyWhenThePolicyCostThisRangeNothing now queries +2/+4 days instead of +1/+3, with a comment documenting why a 1-minute notice can still withhold tomorrow’s midnight slot at the end of a UTC day.

Prior flaky-test thread resolved. No product or runtime behavior changed in this delta.

  ^{｜ View workflow run ｜ Using Grok ｜ 𝕏}