## Prompt Specify an object-oriented storage class with initialization, `store`, and `retrieve` methods. Items carry a weight and expiration timestamp, and storage is split into ordered capacity levels. Retrieval scans levels from top to bottom, skips a level unless at least half of its capacity remains free, removes expired items, and returns the heaviest eligible item. Provide deterministic tie-breaking and testable method contracts. ### Constraints & Assumptions - Capacities and level priority are immutable after initialization. - An item whose expiration is at or before the retrieval time is expired. - Equal weights are resolved by earlier insertion, then lexical item ID. - Each active item ID is unique and retrieving an item removes it. ### Clarifying Questions to Ask - Which level receives a new item when several have enough capacity? - Is the half-capacity condition measured before selecting the item? - Can expiration cleanup occur during store as well as retrieve? ```hint Use one source of truth Heap entries can be stale, so an authoritative record map must decide whether an entry is still active before counters change. ``` ### What a Strong Answer Covers - Unambiguous APIs, invariants, and error behavior. - Capacity accounting that remains correct under expiration and lazy heap removal. - Priority structures for level order, weight, and expiration. - Operation complexity and a policy for accumulated stale entries. - Boundary tests for 50% free space, ties, expired maxima, and no eligible level. ### Follow-up Questions 1. How would the API support peeking without removing an item? 2. What locking granularity preserves correctness while allowing stores into different levels? 3. How would you persist and restore this structure after a process restart?