Merge pull request #4 from lf-lang/exercices

Restructure tutorial exercises to bridge each step to the next

Author: edwardalee

01-actor-model.md

@@ -155,11 +155,11 @@ That's what we explore next.
 
 ## Exercises
 
-1. Trace through a scenario: California dispatches +100 MW at time 0 ms, New York curtails −100 MW at time 1 ms. Show that both grid managers reach the same balance regardless of message arrival order.
+1. Modify `GridManager` to reject any command that would push `balance` below **−200 MW**, logging a warning instead. 
 
-2. What would happen if TCP delivery were *not* guaranteed? How would the ACID 2.0 / CRDT properties need to change?
+2. Run a scenario where both managers start at `balance = −150 MW`, California curtails −80 MW, and New York dispatches +100 MW simultaneously. What does each manager report?
 
-3. Now consider the potential effect of network delays in this example. How would network delays affect the consistency of this example?
+3. Swap the message arrival order from Exercise 2. Do `gm1` and `gm2` agree on the final balance? Explain why the result differs and which ACID 2.0 property is violated.
 
 ---
 

02-inconsistency.md

@@ -113,11 +113,8 @@ The single-node approach defeats the purpose of having two control centers. So w
 
 ## Exercises
 
-1. Construct a scenario where `gm1` logs an imbalance event but `gm2` does not, starting from `balance = -180 MW`. What does this mean operationally for a real grid?
+1. In `Step2_Inconsistency.lf`, replace every `~>` with `->` and add `@maxwait(100 ms)` to both `gm1` and `gm2`. Re-run the inconsistency scenario (`balance = −150 MW`, simultaneous curtail −80 MW and dispatch +100 MW). Do the managers now agree?
 
-2. Would the inconsistency be resolved if the network always delivered messages in the order they were sent globally (i.e., a totally ordered broadcast)? What would be the cost?
-
-3. Fixing commutativity "loses most of these nice properties." List the specific ACID 2.0 properties that are lost when we add the threshold check.
 
 ---
 

03-timestamps.md

@@ -174,11 +174,7 @@ The waiting introduced by timestamps is not a bug; it is **fundamental**. The **
 
 ## Exercises
 
-1. With `maxwait = 100 ms` and cross-continental latency of 75 ms, what is the maximum clock synchronization error you can tolerate and still guarantee correct ordering?
-
-2. If you reduced maxwait to 20 ms to improve responsiveness, what would happen if a message arrived 30 ms late? What would the LF runtime do?
-
-3. Revisit the inconsistency scenario from Step 2 (balance = −150 MW, simultaneous curtail and dispatch). Trace through the execution with timestamps. Do both grid managers reach the same balance?
+1. Change `@maxwait` on both managers to `forever` and rerun. Does the program make progress? Why or why not?
 
 ---
 

04-conservative.md

@@ -111,11 +111,11 @@ Key changes from Step 3:
 
 ## Exercises
 
-1. Trace through a scenario where California's GridServer crashes at time T = 30 s. What happens to New York's grid manager? What happens to California's grid manager?
+1. Add a `QuickDispatch` reactor (`@maxwait(30 ms)`) that handles only positive commands and acknowledges immediately, while `GridManager` (`maxwait = forever`) remains authoritative. Wire `GridManager`'s balance output back into `QuickDispatch`. Run a +100 MW dispatch — how do the two acknowledgement times compare?
 
-2. If we reduce the null message period from 1 s to 100 ms, how does this affect (a) wait time, (b) network overhead, and (c) resilience to node failure?
+2. Issue a curtailment (−80 MW). Confirm `QuickDispatch` ignores it and only `GridManager` applies it. Why is routing curtailments exclusively through the slow path the right design decision?
 
-3. Could we use `maxwait = forever` with *no* null messages at all? Under what circumstances would the system make progress?
+3. Add a `tardy` handler to `QuickDispatch` for when `true_balance` arrives late. What should it do if the stale estimate it used turns out to be wrong?
 
 ---
 

05-hybrid.md

@@ -98,11 +98,11 @@ See [`src/Step5_Hybrid.lf`](src/Step5_Hybrid.lf).
 
 ## Exercises
 
-1. Suppose an operator issues a dispatch of +50 MW on the fast path. Their display shows a new balance of +50 MW. Two seconds later, the authoritative balance arrives and shows +150 MW (because a remote operator also dispatched +100 MW). Is this a problem? How would you handle the discrepancy in the UI?
+1. Add `after 50 ms` to the `true_balance -> QuickDispatch.true_balance` connection. Does the tardy handler fire more often? How does the `after` delay shift the point where the fast-path estimate gets corrected?
 
-2. Design a `QuickCurtail` reactor that allows small curtailments (up to −50 MW) on a fast path. What maxwait values would you choose? What does the fault handler do when true_balance arrives late and shows the estimate was wrong?
+2. Add a `state fault_count: int = 0` to `QuickDispatch` and increment it in the `tardy` handler. Print the running count after each tardy event. Run with `@maxwait(10 ms)` against a 75 ms simulated delay. How quickly does the fault count grow?
 
-3. The fault handler for QuickDispatch logs a warning. In a real grid, what automated action might it trigger (e.g., alert, re-dispatch, trip breaker)?
+3. Add a `QuickCurtail` reactor (mirroring `QuickDispatch`) that fast-paths small curtailments up to −20 MW with `@maxwait(30 ms)`. What should its `tardy` handler do when `true_balance` arrives late and reveals the curtailment pushed the balance below the threshold?
 
 ---
 

06-cal-theorem.md

@@ -114,10 +114,8 @@ This tutorial focused on the core consistency mechanisms. The paper also discuss
 
 ## Final Exercises
 
-1. **Full scenario trace**: Starting from balance = −100 MW at both nodes, trace the complete execution of Step 5's hybrid design through: (a) California dispatches +200 MW, (b) New York curtails −150 MW (simultaneous), (c) California curtails −80 MW (2 seconds later). Which commands use the fast path? What does each GridManager report after each event?
+1. In `Step3_Timestamps.lf`, change one logical connection to `gi1.command -> gm1.in1 after 50 ms`. Rerun the simultaneous dispatch/curtailment scenario. Does consistency hold? How does the `after` delay change the operator wait time?
 
-2. **maxwait calibration**: You deploy the Step 3 design between London and Tokyo (network latency ~250 ms, NTP error ~50 ms). What maxwait should you choose? What is the resulting unavailability (operator wait time) for curtailment commands?
+2. In `Step5_Hybrid.lf`, set `QuickDispatch` `@maxwait` to 200 ms and `GridManager` `@maxwait` to `forever`. Run a curtailment and a dispatch simultaneously. Which path handles each, and what do the two acknowledgement timestamps tell you about the consistency-availability tradeoff?
 
-3. **Three-node design**: How would you modify Step 5's `GridManager` to require agreement from 2 out of 3 nodes instead of 2 out of 2? What should the fault handler do when a node disagrees with the majority view?
-
-4. **Real-world mapping**: Map the design from Step 5 onto a real grid control architecture. What does `GridServer` correspond to? What does `GridManager` correspond to? What role does the `QuickDispatch` fast path play in existing SCADA/EMS systems?
+3. Add a third federate `gm3` to `Step4_Conservative.lf` (copy of `gm2`). Observe that `GridManager` with `maxwait = forever` still reaches the same balance on all three nodes. What additional null-message wiring did you need?