Remove emdashes from all READMEs

Replace with periods, colons, commas, or parentheses for cleaner,
more natural prose throughout all exercise documentation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: georgeglarson

CashRegister/README.md

@@ -45,10 +45,10 @@ Without `--verbose`, output matches the spec format exactly (`3 quarters,1 dime,
 
 ### Flags
 
-- `--divisor N` — Change which transactions get randomized denominations (default: 3). If `owed` in cents is divisible by N, the change is randomized. Use `--divisor 0` to disable randomization entirely.
-- `--seed N` — Seed the random number generator for reproducible output. Useful for testing.
-- `--currency USD|EUR` — Select the currency denomination set (default: USD).
-- `--verbose` — Show transaction context alongside the change output. Labels random lines.
+- `--divisor N` changes which transactions get randomized denominations (default: 3). If `owed` in cents is divisible by N, the change is randomized. Use `--divisor 0` to disable randomization entirely.
+- `--seed N` seeds the random number generator for reproducible output. Useful for testing.
+- `--currency USD|EUR` selects the currency denomination set (default: USD).
+- `--verbose` shows transaction context alongside the change output. Labels random lines.
 
 ## The Problem
 
@@ -58,7 +58,7 @@ Without `--verbose`, output matches the spec format exactly (`3 quarters,1 dime,
 
 ### Integer cents everywhere
 
-All money is represented as `u32` cents. The string `"2.13"` is parsed via string manipulation into `213u32` — no floating-point arithmetic is ever used. This eliminates an entire class of rounding bugs (e.g., `0.1 + 0.2 != 0.3` in IEEE 754).
+All money is represented as `u32` cents. The string `"2.13"` is parsed via string manipulation into `213u32`, with no floating-point arithmetic anywhere. This eliminates an entire class of rounding bugs (e.g., `0.1 + 0.2 != 0.3` in IEEE 754).
 
 ### Strategy trait with concrete types
 
@@ -70,11 +70,11 @@ A `ChangeStrategy` trait defines the contract. `GreedyStrategy` minimizes denomi
 
 ### Injectable randomness
 
-`RandomStrategy<R: Rng>` is generic over its RNG source. Tests inject `StdRng::seed_from_u64()` for deterministic assertions. Production uses `StdRng::from_entropy()`. Zero-cost abstraction via monomorphization — no `Box<dyn Rng>`.
+`RandomStrategy<R: Rng>` is generic over its RNG source. Tests inject `StdRng::seed_from_u64()` for deterministic assertions. Production uses `StdRng::from_entropy()`. Zero-cost abstraction via monomorphization, no `Box<dyn Rng>`.
 
 ### No heavy dependencies
 
-CLI argument parsing is a 5-line generic function, not a 50KB dependency. The only runtime dependencies are `thiserror` (structured errors) and `rand` (randomization) — both are well-established, minimal crates.
+CLI argument parsing is a 5-line generic function, not a 50KB dependency. The only runtime dependencies are `thiserror` (structured errors) and `rand` (randomization), both well-established, minimal crates.
 
 ### Property-based testing
 
@@ -87,7 +87,7 @@ src/
   main.rs         CLI wiring: arg parsing, file I/O, exit codes
   lib.rs          Module re-exports
   error.rs        Error types with line numbers (thiserror)
-  currency.rs     Denomination definitions — USD, EUR configs
+  currency.rs     Denomination definitions (USD, EUR configs)
   parse.rs        String → cents conversion, line → Transaction
   strategy/
     mod.rs        ChangeStrategy trait, Breakdown type alias
@@ -104,15 +104,15 @@ tests/
 
 > What might happen if the client needs to change the random divisor?
 
-Pass `--divisor N` at the command line. The divisor flows through `rules::make_change_for` as a parameter — no code changes needed. Setting `--divisor 0` disables randomization entirely.
+Pass `--divisor N` at the command line. The divisor flows through `rules::make_change_for` as a parameter, so no code changes are needed. Setting `--divisor 0` disables randomization entirely.
 
 > What might happen if the client needs to add another special case (like the random twist)?
 
 Add a new strategy struct implementing `ChangeStrategy` (one file), then add a branch in `rules.rs`. Existing strategies and tests are untouched. For example, a "round up to nearest quarter" strategy would be ~20 lines of code and one new match arm.
 
 > What might happen if sales closes a new client in France?
 
-Pass `--currency EUR`. The EUR denomination table is already defined and wired into the CLI. Try it: `cargo run -- sample_eur.txt --currency EUR`. The denomination table drives all formatting — singular/plural names, values, everything. One caveat: France uses commas as decimal separators (`2,13` not `2.13`), which conflicts with the comma-delimited input format. A real deployment would need a configurable delimiter or a different input format (e.g., TSV, JSON).
+Pass `--currency EUR`. The EUR denomination table is already defined and wired into the CLI. Try it: `cargo run -- sample_eur.txt --currency EUR`. The denomination table drives all formatting (singular/plural names, values, everything). One caveat: France uses commas as decimal separators (`2,13` not `2.13`), which conflicts with the comma-delimited input format. A real deployment would need a configurable delimiter or a different input format (e.g., TSV, JSON).
 
 ## Testing
 

GildedRose/README.md

@@ -4,7 +4,7 @@ A Go solution for the Gilded Rose inventory management system.
 
 ## Approach
 
-Each item category's degradation rules are encapsulated in a separate **Updater implementation** behind a common interface. A **Registry** maps category names (and item names for special cases like Aged Brie) to their updater. Adding a new special-case item type means adding one file and one registry entry — no existing code changes.
+Each item category's degradation rules are encapsulated in a separate **Updater implementation** behind a common interface. A **Registry** maps category names (and item names for special cases like Aged Brie) to their updater. Adding a new special-case item type means adding one file and one registry entry, with no changes to existing code.
 
 ## Structure
 
@@ -34,11 +34,11 @@ make run
 ```
 
 Interactive commands:
-- `list` — show all inventory
-- `item <name>` — show details for a single item
-- `next` — advance to the next day
-- `trash` — list items with Quality = 0
-- `quit` — exit
+- `list` show all inventory
+- `item <name>` show details for a single item
+- `next` advance to the next day
+- `trash` list items with Quality = 0
+- `quit` exit
 
 ## Test
 
@@ -59,5 +59,5 @@ make test
 
 - **Interface-based extensibility**: New item types implement the `Updater` interface (one method: `Update(*Item)`). The registry wires them in. Existing updaters and tests are untouched.
 - **Two-tier dispatch**: The registry checks item name first, then category, then falls back to Normal. This handles both category-wide rules (Conjured, Backstage Passes) and one-off items (Aged Brie) without special-casing in the logic.
-- **Invariant tests**: The test suite runs the full inventory through 100 simulated days and asserts that quality constraints are never violated — a safety net against future regressions.
+- **Invariant tests**: The test suite runs the full inventory through 100 simulated days and asserts that quality constraints are never violated, serving as a safety net against future regressions.
 - **Copy semantics**: `Items()` and `FindByName()` return copies, preventing callers from accidentally mutating inventory state.

MissingNumber/README.md

@@ -4,7 +4,7 @@ A Zig solution for finding the missing number in sequential series.
 
 ## Approach
 
-Uses the **arithmetic sum formula** — the expected sum of a contiguous range `[min, max]` is `(max + min) * (max - min + 1) / 2`. Subtracting the actual sum of the provided numbers gives the missing value in O(n) time with O(1) extra space.
+Uses the **arithmetic sum formula**: the expected sum of a contiguous range `[min, max]` is `(max + min) * (max - min + 1) / 2`. Subtracting the actual sum of the provided numbers gives the missing value in O(n) time with O(1) extra space.
 
 The solution is structured as a library (`root.zig`) with a thin CLI driver (`main.zig`), making the core logic reusable and independently testable.
 
@@ -27,4 +27,4 @@ make test
 
 - **Library separation**: Core logic is decoupled from I/O, enabling integration into larger systems or alternative frontends.
 - **Allocator-driven**: All allocations go through Zig's allocator interface, giving callers full control over memory strategy.
-- **Extensibility**: `parseLine` and `findMissing` are independent — the parser could be swapped for streaming input, and the algorithm could be extended to handle multiple missing values.
+- **Extensibility**: `parseLine` and `findMissing` are independent. The parser could be swapped for streaming input, and the algorithm could be extended to handle multiple missing values.

MorseCode/README.md

@@ -4,7 +4,7 @@ A Perl solution for translating between Morse code and English.
 
 ## Approach
 
-Splits input on the delimiter hierarchy — `||||` for word boundaries, `||` for letter boundaries — then maps each Morse sequence through a lookup table. The encoder reverses the process. Clean string splitting, no regex needed for the core logic.
+Splits input on the delimiter hierarchy (`||||` for word boundaries, `||` for letter boundaries), then maps each Morse sequence through a lookup table. The encoder reverses the process. Clean string splitting, no regex needed for the core logic.
 
 ## Structure
 
@@ -42,6 +42,6 @@ make test
 
 ## Design Considerations
 
-- **Alphabet isolation**: The lookup table is a standalone module — swapping to a different encoding (e.g., NATO phonetic) means replacing one file.
+- **Alphabet isolation**: The lookup table is a standalone module. Swapping to a different encoding (e.g., NATO phonetic) means replacing one file.
 - **Bidirectional symmetry**: Encoder and decoder are full mirrors of each other, both backed by the same alphabet. `decode(encode(text)) == text` is verified for every character.
-- **Extensibility**: The delimiter scheme is handled in the encoder/decoder modules, separate from the alphabet — changing the wire format doesn't touch the character mappings.
+- **Extensibility**: The delimiter scheme is handled in the encoder/decoder modules, separate from the alphabet. Changing the wire format doesn't touch the character mappings.

OnScreenKeyboard/README.md

@@ -4,7 +4,7 @@ A Python solution for scripting cursor paths on a grid-based on-screen keyboard.
 
 ## Approach
 
-Builds a coordinate index from the keyboard layout, then computes the Manhattan distance path (U/D/L/R) between successive characters. The layout is data, not code — swapping to a different keyboard arrangement means changing a single list.
+Builds a coordinate index from the keyboard layout, then computes the Manhattan distance path (U/D/L/R) between successive characters. The layout is data, not code. Swapping to a different keyboard arrangement means changing a single list.
 
 ## Structure
 
@@ -36,6 +36,6 @@ make test
 
 ## Design Considerations
 
-- **Layout as data**: The keyboard grid is a plain list of strings — no hardcoded positions. Changing from alphanumeric to any other layout is a one-line change. The `build_index` function dynamically maps characters to coordinates from any grid shape.
+- **Layout as data**: The keyboard grid is a plain list of strings, no hardcoded positions. Changing from alphanumeric to any other layout is a one-line change. The `build_index` function dynamically maps characters to coordinates from any grid shape.
 - **Separation of concerns**: `keyboard.py` owns the layout, `navigator.py` owns the movement logic, `main.py` is pure I/O. Each has a single reason to change.
-- **Input flexibility**: The core functions accept strings and dicts — the file-reading is only in `main.py`. Switching from file to stream means changing only the driver, not the logic.
+- **Input flexibility**: The core functions accept strings and dicts. The file-reading is only in `main.py`. Switching from file to stream means changing only the driver, not the logic.

README.md

@@ -10,10 +10,10 @@
 |----------|----------|-------------------|-------|
 | [CashRegister](./CashRegister) | **Rust** | Financial calculations demand zero-cost abstractions and type safety. Integer-cent arithmetic eliminates floating-point rounding bugs entirely. The trait system maps naturally to the strategy pattern the problem calls for. | 94 |
 | [MissingNumber](./MissingNumber) | **Zig** | A tight algorithmic problem suited to a systems language. Zig's explicit allocator model and comptime features show well on small, performance-sensitive code. Demonstrates range beyond Rust while staying in the systems tier. | 70 |
-| [MorseCode](./MorseCode) | **Perl** | A text-processing problem at its core — splitting on delimiters and mapping through a lookup table. Perl is *the* language for this domain, and using it signals that language choice is driven by fit, not comfort zone. | 232 |
-| [OnScreenKeyboard](./OnScreenKeyboard) | **Python** | If this were production code, it would be scripting device input on a DVR or smart TV — a space where Python dominates. Clean data modeling (layout as a list, index as a dict) makes the solution readable and extensible. | 94 |
-| [GildedRose](./GildedRose) | **Go** | An OOP/business logic problem centered on polymorphism and rule engines. Go's interface system is a natural fit — each item category implements a single `Updater` interface, and the registry pattern makes new rules a one-file addition. Go's simplicity forces clean design without hiding behind language features. | 107 |
-| [RestaurantReviews](./RestaurantReviews) | **TypeScript/React** | TrueFit's core stack — they maintain the `bach` React composition library and a React-heavy open source portfolio. The most substantial exercise doubles as a unified control panel integrating all 5 other exercises as live panels. | 371 |
+| [MorseCode](./MorseCode) | **Perl** | A text-processing problem at its core: splitting on delimiters and mapping through a lookup table. Perl is *the* language for this domain, and using it signals that language choice is driven by fit, not comfort zone. | 232 |
+| [OnScreenKeyboard](./OnScreenKeyboard) | **Python** | If this were production code, it would be scripting device input on a DVR or smart TV, a space where Python dominates. Clean data modeling (layout as a list, index as a dict) makes the solution readable and extensible. | 94 |
+| [GildedRose](./GildedRose) | **Go** | An OOP/business logic problem centered on polymorphism and rule engines. Go's interface system is a natural fit: each item category implements a single `Updater` interface, and the registry pattern makes new rules a one-file addition. Go's simplicity forces clean design without hiding behind language features. | 107 |
+| [RestaurantReviews](./RestaurantReviews) | **TypeScript/React** | TrueFit's core stack. They maintain the `bach` React composition library and a React-heavy open source portfolio. The most substantial exercise doubles as a unified control panel integrating all 5 other exercises as live panels. | 371 |
 
 ## Prerequisites
 
@@ -62,10 +62,10 @@ make test-all
 
 ## DavesSnackShack
 
-DavesSnackShack is a QA/testing exercise. Rather than treat it as a standalone item, the QA mindset is embedded throughout every exercise above — exhaustive test suites, boundary conditions, error paths, and property-based testing where applicable. The RestaurantReviews dashboard also includes a dedicated security test suite covering injection, XSS, and input validation.
+DavesSnackShack is a QA/testing exercise. Rather than treat it as a standalone item, the QA mindset is embedded throughout every exercise above: exhaustive test suites, boundary conditions, error paths, and property-based testing where applicable. The RestaurantReviews dashboard also includes a dedicated security test suite covering injection, XSS, and input validation.
 
 ## Philosophy
 
-- **Single Responsibility Principle** enforced throughout — parsing, logic, orchestration, and I/O are always in separate modules.
-- **Exhaustive testing** — edge cases, error paths, boundary conditions, and round-trip verification. The goal is that a reviewer has nothing left to question.
-- **Language as a design decision** — each choice is deliberate, not default. The portfolio demonstrates breadth and the ability to pick the right tool for the job.
+- **Single Responsibility Principle** enforced throughout. Parsing, logic, orchestration, and I/O are always in separate modules.
+- **Exhaustive testing.** Edge cases, error paths, boundary conditions, and round-trip verification. The goal is that a reviewer has nothing left to question.
+- **Language as a design decision.** Each choice is deliberate, not default. The portfolio demonstrates breadth and the ability to pick the right tool for the job.