Problem
Most planner quantities are currently entered and displayed as per-second rates. That is mathematically consistent, but it is awkward for common planning cases:
- science targets are easier to think about as
5/min or 10/min - slow bootstrapping goals may be
1/hr or 0.5/hr
Desired behavior
Allow users to choose a time window/unit for rate goals instead of forcing per-second input everywhere. At minimum, support seconds, minutes, and hours. The solver can continue normalizing rates internally, but the UI should preserve the user-facing unit so saved goals remain understandable.
Examples:
10 science/min5 science/min1 building/hr0.5 building/hr
Questions to resolve
- Is this only a display/input unit preference, or should saved block goals store their selected rate window?
- Should the solver keep one canonical rate unit and only convert at boundaries?
- How should mixed units appear in block summaries and assistant output?
Acceptance criteria
- A user can enter and view goals in per-second, per-minute, or per-hour terms.
- Existing per-second blocks continue to load and solve unchanged.
- Saved goals remain understandable after reload, including their selected unit/window where applicable.
Note
The low-throughput "stock / coverage" use case (keep N in stock, make sure required intermediates and building materials are produced) was previously folded in here. It is now tracked on its own in #38, since it needs distinct goal semantics rather than a units preference.
Problem
Most planner quantities are currently entered and displayed as per-second rates. That is mathematically consistent, but it is awkward for common planning cases:
5/minor10/min1/hror0.5/hrDesired behavior
Allow users to choose a time window/unit for rate goals instead of forcing per-second input everywhere. At minimum, support seconds, minutes, and hours. The solver can continue normalizing rates internally, but the UI should preserve the user-facing unit so saved goals remain understandable.
Examples:
10 science/min5 science/min1 building/hr0.5 building/hrQuestions to resolve
Acceptance criteria
Note
The low-throughput "stock / coverage" use case (keep N in stock, make sure required intermediates and building materials are produced) was previously folded in here. It is now tracked on its own in #38, since it needs distinct goal semantics rather than a units preference.