# Opening Hours Display

## Objective

Say whether you are open right now and when you next open.

A live open or closed state alongside the weekly hours, with holiday closures folded in.

## Before You Begin

This feature is being added to an application that already exists and already
works. Do not scaffold a new project, and do not assume a blank slate.

Inspect the codebase first and establish:

- The existing application structure and where code of this kind already lives.
- The framework and version in use.
- The existing design system — colours, spacing, typography, and component conventions.
- Existing UI components you can reuse instead of writing new ones.
- The existing database structure, if this feature needs to persist anything.
- The existing authentication and authorization system, if this feature is user-scoped.
- Dependencies already installed, so you don't add a library that duplicates one.
- The existing test setup and conventions.

Only start writing code once you understand the above. If the application
already implements part of this feature, extend it rather than replacing it.

## Implementation Instructions

1. Lead with the current state in plain words and follow it with the next transition: open until a time, or closed until a day and time. The weekly table is supporting detail, not the headline.
2. Store hours as intervals against the business's own zone, and keep holiday and one-off closures as overrides that win over the regular week rather than as edits to it.
3. Compute the state on the server for the first render so the page does not briefly claim the wrong thing, then let the page update itself as the clock crosses a boundary without a reload.
4. If the app already has a Recurring Schedule Builder or Quiet Hours, reuse its interval storage and its editing screen for the weekly pattern instead of building a second hours editor that will drift out of agreement.
5. Do not compute open or closed from the viewer's device clock and zone. A visitor abroad will be told a shop is closed while its doors are open.

## UI and UX Requirements

Match the application's existing design system exactly. Reuse its components,
spacing, and typography. This feature should look like it was always there.

## Responsive Requirements

Works on mobile, tablet, and desktop. Touch targets are large enough to hit on a
phone, and nothing overflows horizontally at 320px.

## Accessibility Requirements

- Fully keyboard navigable.
- Correct semantic elements and ARIA roles.
- Visible focus states.
- Meets WCAG AA contrast.
- Dynamic changes are announced to screen readers.
- Respects prefers-reduced-motion.

## Edge Cases

- Open or closed is always evaluated in the business's zone, never the viewer's, and the displayed times should say which zone they are in when the two differ.
- A holiday or one-off closure must override the regular schedule and be surfaced before it happens, so someone reading on Thursday learns that Friday is closed.
- Inside the final part of an open window, say closing soon with the closing time rather than a bare open. A customer told only open will set off for a place about to shut.
- Hours that run past midnight belong to the day they started on. Treating them as two separate days makes a late-night window read as closed at one minute past twelve.
- When the schedule is missing, incomplete, or the current state cannot be determined, fall back to a plain list of hours with no claim about right now. A confident wrong answer is worse than none.
- Daylight-saving transitions must not shift the stored opening times. Store local wall-clock intervals plus the zone, not fixed instants.
- A permanently closed or temporarily suspended location needs its own state rather than being rendered as closed until an opening that will never come.
- The state must be conveyed in text, not by a coloured dot alone, and must be readable by a screen reader.

## Testing

Exercise the feature end to end in the running application. Cover every edge case
above, then run the existing test suite and confirm nothing regressed.

## Acceptance Criteria

- [ ] The current open or closed state appears above the weekly hours, with the next transition named.
- [ ] State is computed in the business's zone and is correct for a viewer in any other zone.
- [ ] Holiday and one-off closures override the regular schedule and are surfaced in advance.
- [ ] A closing-soon state appears inside the final window of an open period.
- [ ] Hours crossing midnight display and evaluate as one continuous window.
- [ ] An unknown or incomplete schedule degrades to a plain hours list with no live claim.
- [ ] The feature matches the existing design system.
- [ ] No existing functionality is broken.

## Adaptation Rules

- Match the existing design system. Do not introduce a new colour palette,
  spacing scale, or component library.
- Reuse existing components and utilities wherever they fit.
- Follow the naming, file layout, and code style already present.
- Do not upgrade, replace, or remove existing dependencies to make this
  feature fit. Adapt the feature to the app, not the app to the feature.
- Do not break existing functionality. If a change is genuinely required in
  existing code, make the smallest one that works and say so.
- If something in these instructions conflicts with how the application is
  built, follow the application and explain the deviation.

## Final Verification

Before you report the work as done:

1. Re-read the acceptance criteria above and check each one against what you
   actually built.
2. Run the application and exercise the feature end to end.
3. Run the existing test suite and confirm you have broken nothing.
4. Check the feature on mobile, tablet, and desktop widths.
5. Check keyboard navigation and focus handling.
6. Summarize what changed: files added, files modified, and anything you
   deliberately did differently because of how this application is built.

If any acceptance criterion is unmet, fix it before reporting completion.