Skip to main content

Expire stale seat claims at the workplace-day boundary

FeatureParent EpicDelivery statusStatus sourceOwnerApproved for Solution
3DARCH-FT-253DARCH-EP-6 — Coordinate Shared Workplace SeatingIN_BACKLOGEXACT3D Architecture Wizzard teamNo

Description​

Enable participants to start each workplace day with stale reservations cleared rather than blocked by people who did not manually release yesterday's seats.

User or operator problem​

The workplace needs stale seat claims cleared at a predictable day boundary without manual cleanup.

Expected value​

Restores fair seat availability each workplace day and makes reset failures diagnosable.

Scope​

Includes an explicit timezone/boundary, authoritative claim clearing, single multi-replica execution, client replacement, failure visibility, and safe retry.

Exclusions​

  • Advance booking, recurring reservations, administrator override, and historical occupancy reporting are excluded.

Acceptance outcomes​

  • The governing workplace timezone and daily reset boundary are explicit.
  • Every active claim becomes available with occupant and claim time cleared.
  • Available seats remain unchanged.
  • Only one reset is applied when the service has multiple replicas.
  • Connected clients replace their occupancy state from the authoritative reset without reloading.
  • A missed or failed reset is visible and can be retried safely.

Dependencies​

Risks​

  • The reset timezone, multi-replica coordination, failure visibility, and client refresh behavior are incomplete.

Human approval​

Linas approved this Feature for documentation on 2026-09-02T10:40:43.220Z. It is not Approved for Solution and has no implementation approval.

Delivery status evidence​

The Feature was separately registered at IN_BACKLOG as an accepted catalogue boundary. This records backlog retention, not design or delivery progress.

  • Event: Catalogue registration
  • Actor and authority: Linas — Human project team member
  • Reason: The Feature catalogue was accepted for governed documentation and retained in the backlog.
  • Status evidence

Architecture traceability​

  • Requirements: none derived.
  • Readiness: Not started.

Architecture solution work must not begin until a separate human Approved for Solution decision is recorded.

Tasks​

Review the Tasks group. No canonical implementation Tasks have been defined.

Original source​

Legacy implementation evidence​

The Feature boundary was mined from legacy revision c0ced47ecaf4426f47e5c2e4868677f7144b951a.