Update ReplayButton.md

docs/HyperlinkedInformation/ReplayButton.md

@@ -15,12 +15,12 @@ an "Action Replay" of "The Observed Epoch", and this happens in two Steps:
 So, Step 1 is "reestablish initial conditions" and Step 2 is "do it all again".
 
 ### Further Notes:
-  - In Step 1, the reset of `app-db` will trigger dominoes 4,5,6, causing
-    subscriptions and views to run as the application returns to the "prior state", 
-    but none of the trace for this is captured. It is all ignored.
-  - All trace arising in Step 2 forms a normal, new Epoch. The (original) Observed Epoch (which we are replaying) 
+  - In Step 1, the reset of `app-db` will trigger computation and trace.
+    Subscriptions and views are run as the application returns to the "prior state", 
+    but none of the associated trace is captured. It is all ignored.
+  - Trace arising from Step 2 forms a normal, new Epoch. The Observed Epoch (which we are replaying) 
     is still there, untouched.
-  - The new Epoch (Step 2) is added to the end of the existing Epoch list. It becomes the most recent Epoch. 
+  - New Epochs (Step 2) are always added to the end of the Epoch list (never inserted amongst old Epochs). 
   - The user's experience is that they click the "Replay" button 
     and immediately view the result. So, after Step 2, the user is auto-navigated to this new epoch.
 
@@ -28,18 +28,19 @@ So, Step 1 is "reestablish initial conditions" and Step 2 is "do it all again".
 
 It facilitates "The HotPlay Workflow": 
   - A. You `Observe` an Epoch (in `re-frame-trace`) to see if an event was correctly processed 
-  - B. You notice a problem, and you `Edit` (correct) the event handler (or subs handler, view, etc) via Cursive, Emacs, etc.
+  - B. You notice a problem, and you `Edit` (fix) the event handler (or subs handler, view, etc) via Cursive, Emacs, etc.
   - C. Figwheel will re-compile and `Hotload` your correction
   - D: You click the `Replay` button
   - E: Back to A
 
-Because of `Replay's` "Step 1", you effortlessly get identical "initial conditions" 
-each iteration of the workflow, which removes a lot of incidental cognative load
-(struggling around trying to put the application back into the right state for each new iteration)
-and keeps the iterations snappy. Flow.
+Because of `Replay's` "Step 1", you effortlessly get identical "initial conditions" for
+each iteration of the workflow, and this is true blessing. It removes the nagging 
+cognative load of "allowing for" slightly shifting state. Or the effort of manually 
+reestablishing identical application state before each iteration. 
 
-WARNING: obviously this works best when the state is contained in your SPA. When 
-there's remote state (a remote database?) it gets trickier to return to initial conditions.
+WARNING: obviously this only works when the state is contained in your SPA. When 
+there's remote state (a remote database?) it is more effort to return to initial conditions
+each iteration.
 
 ### The Workflow Name