git » homepage.git » commit 79e38bb

diff --git a/md/_GridCalc.md b/md/_GridCalc.md
index 0a7d89e..10865cb 100644
--- a/md/_GridCalc.md
+++ b/md/_GridCalc.md
@@ -12,9 +12,15 @@ Created Friday 20 February 2026
 - [Demo video](https://youtu.be/M0HwzrGGuyc)
 - [App Store](https://apps.apple.com/no/app/gridcalc/id6759011187)
 
-I built GridCalc because I wanted a spreadsheet that felt native to a phone and native to my brain, combining the efficiency of RPN with the reusability of spreadsheets.
+I built GridCalc because I wanted a spreadsheet that felt native to a phone and native to my brain.
 
-What follows is a retrospective on how that happened, why it looks the way it does, and what is going on inside the app.
+Traditional spreadsheets are powerful, but on mobile they feel cramped and indirect. RPN calculators are efficient, but ephemeral. I wanted something that combined:
+
+- The clarity of Reverse Polish Notation
+- The reusability of spreadsheets
+- A visible, persistent program
+
+The result is a grid where every input and operation becomes a cell. The grid is not a table of data interspersed with opaque formulas; the grid *is* the formula.
 
 ## The seed: Forth and touchscreens
 
@@ -26,38 +32,40 @@ I never prototyped that idea, but it never went away.
 
 ## The notebook sketch
 
-Then, in early February 2026 I woke up and drew a sketch in a tiny 3x5 notepad. The idea was a grid that represents time. Left to right, top to bottom, every entry or operation becomes a persistent cell. The grid is not a table. It is a linear program with a 2D view so references are easy.
+In early February 2026 I woke up and drew a sketch of a grid on a tiny 3x5 notepad. The idea was simple:
+
+- Computation flows left to right, then top to bottom.
+- Each entry is permanent.
+- The grid is a linear program with a 2D coordinate system.
+
+Unlike a free-form Forth editor like I'd imagined previously, in the grid, only structurally valid manipulations are possible. The grid records both the data and the operations. History is not hidden behind an "equals" key.
 
-The grid is also not a free form touch-editing interface for Forth like I'd previously imagined, because only structurally valid manipulations are possible. Furthermore, the the manipulations themselves are represented on the grid. The grid is the data, the program, and the historical timeline all in one.
+That sketch clarified and unified the three ideas defining the model:
 
-The sketch shows the basics: inputs and operations flow left to right and then top to bottom, and because the program sits on a 2D grid you can reference earlier results by cell coordinates the same way you do in a spreadsheet.
+1. RPN for efficiency, but augmented with a persistent and visible history
+2. Spreadsheet grid that allows for intuitive retroactive input tweaking, and cell references for reusability later in a program
+3. Combining these affordances visually into a single compact grid
 
 <figure style="float: left; margin: 0 1.5rem 1rem 0; width: 306px;">
   <img src="./_GridCalc/notebook_idea.jpg" alt="GridCalc notebook sketch" width="100%" />
   <figcaption style="font-size: 0.9em; font-style: italic;">The original 3x5 notebook sketch.</figcaption>
 </figure>
 
-That sketch gave me the core unification:
-
-- RPN for clarity and lack of parentheses.
-- Spreadsheet-style references for reusability.
-- A visible, persistent history of computation.
-
-GridCalc is a calculator, but the program is the sheet. You do not toggle between "value view" and "formula view." The grid is both the data and the formula.
-
 ## Why mobile spreadsheets feel wrong
 
-Spreadsheets are reactive systems. Change a cell and everything downstream recomputes. That is the good part. A classic use case is scratch forecasting. You have a small formula for a rate, a payment, a tip, or a physical quantity. You want to reuse the work you already did so you can tweak the inputs and see new results without retyping the whole thing.
+Spreadsheets are reactive systems. When you change a cell, everything downstream recomputes immediately. That's excellent.
+
+Technically, spreadsheets on phones deliver this. In practice, though, traditional spreadsheets are punishing as mobile interfaces. You tap into a formula bar. You scroll sideways. You lose context. The sheet is there, but the program is buried, and editing an infix formula on a phone keyboard can be particularly frustrating. Mobile spreadsheets are tolerable for data entry or viewing, but frustrating for scratch modeling.
 
-Technically, spreadsheets on phones deliver this. Unfortunately, traditional spreadsheets are punishing as mobile interfaces. You tap into a formula bar. You scroll sideways. You lose context. The sheet is there, but the program is buried, and editing an infix formula on a phone keyboard can be particularly frustrating. I've only ever used mobile spreadsheets for data entry, or to refer to existing sheets with formulas I made on my desktop.
+In GridCalc, the program is always visible because the grid *is* the formula. It economizes the creation of formulas on the go. Every input, and every operation, inhabit a visible cell. The grid provides a coordinate system that can be used to refer to previous values, linking them to new calculations. Much of the power of a spreadsheet is thus delivered directly to the mobile user.
 
-In contrast, GridCalc keeps the program visible because the grid *is* the formula. It economizes the creation of formulas on the go. Every input, and every operation, inhabit a visible cell. The grid provides a coordinate system that can be used to refer to previous values, linking them to new calculations. Much of the power of a spreadsheet is thus delivered directly to the mobile user.
+## UI evolution
 
-## Mobile UI evolution
+My first UI model appended two cells for every operation: one cell for the op label and a second cell for the numeric result. It was clear, but wasteful.
 
-My first UI model appended two cells for every operation: one cell for the op label and a second cell for the numeric result. It was clear, but it wasted precious space.
+My friend Micha Niskin pushed me to combine them, so that every operation shared a cell with its result. That gave the grid a lot more breathing room. Later, another friend, Jesse Lundberg, suggested putting the op in a small badge that lives in the gutter between cells. That change preserved legibility while dramatically improving density.
 
-My friend Micha Niskin pushed me to combine them, so that every operation shared a cell with its result. That gave the grid a lot more breathing room. Later, another friend, Jesse Lundberg, suggested putting the op in a small badge that lives in the gutter between cells. That kept the value legible and made the grid readable at a glance. The combination of these two visual enhancements gave me the compact but legible layout I had been groping toward.
+Between these two visual enhancements I had the compact but legible layout I had been groping toward.
 
 ## Where RPN fits
 
@@ -74,8 +82,8 @@ But it wasn't until I encountered Christian Lawson-Perfect’s excellent [Nice C
 
 ## Under the hood
 
-- Exact arithmetic using [Constructive Reals](https://chadnauseam.com/coding/random/calculator-app) in native Swift. I learned about Constructive Reals years ago and could not not use them. The engine evaluates lazily and caches precision requests instead of relying on floating-point shortcuts.
-- Spec-generated state machines. The interaction modes, file workflows, and save states are modeled as [hierarchically nested states](https://en.wikipedia.org/wiki/UML_state_machine#Hierarchically_nested_states) with generated runtime and tests. I credit the introduction of this approach to an early tester, my son William, who is three years old. Within 10 seconds of my handing him the phone, he spammed the screen with enough keypresses that the UI entered some kind of deadlock, making it clear I needed a better approach. 
+- Exact arithmetic using [Constructive Reals](https://chadnauseam.com/coding/random/calculator-app) in Swift. I learned about Constructive Reals years ago and could not not use them. The engine evaluates lazily and computes only as much precision as needed.
+- Spec-generated state machines. The interaction modes, file workflows, and save states are modeled as [hierarchically nested states](https://en.wikipedia.org/wiki/UML_state_machine#Hierarchically_nested_states) with generated runtime and tests. This became necessary after a three-year old beta tester (my son) managed to deadlock the UI within seconds.
 - Aggressive unit testing with [XCTest](https://developer.apple.com/documentation/xctest) and [Maestro](https://maestro.mobile.dev/).
 
 ## Note on AI and execution