Design the object model and public APIs for the calculation core of a spreadsheet: the classes that hold a grid of cells, parse a formula a user types into a cell, track which cells depend on which, and recompute the smallest correct set of cells whenever a value or formula changes. This is the engine a UI or a file layer would drive, not the rendering surface, toolbar, or persisted file format.

Operating context. A single workbook held in memory, one sheet to start (but keep an eye on multi-sheet references such as another sheet's cell). A cell holds either a literal (number, text, boolean), a formula that begins with '=', or nothing. A formula can reference other cells (B2), rectangular ranges (A1:A20), arithmetic and comparison operators, and named functions like SUM, IF, or AVERAGE. Editing one cell can cascade: everything that transitively reads it must be brought up to date, and only those cells, without recomputing the whole grid. The engine must refuse to enter an inconsistent state when a user creates a reference cycle (A points at B which points back at A) and must surface an error value in the offending cells rather than loop forever. Assume one editor at a time; no undo history, no styling.

Out of scope. The rendering / UI layer (grid widget, selection, copy-paste), the on-disk file format and its serializer, collaborative or multi-user editing and conflict resolution, undo/redo history, cell formatting and styles, and charts / pivot tables — model the in-memory calculation object graph, not the application around it.

What to produce. The class hierarchy (entities such as Workbook, Sheet, and Cell; the parsed-formula representation such as an expression tree of literal / reference / range / function-call nodes; and the services that evaluate an expression and schedule recomputation), the public API each class exposes, and the state a cell moves through (empty, literal, formula-computing, computed, error). Be explicit about: how a formula string becomes an evaluable expression tree, how the engine records the dependency graph and inverts it to find dependents, how it detects a reference cycle before or during evaluation and marks the ring with an error rather than looping, how a change triggers recomputation of only the affected cells in a correct order, the trade-off between recomputing eagerly on edit versus lazily on read, and how a new worksheet function is added without editing the parser or the evaluator's core.