feat: flesh out SOLUTION.md for all 15 level-0 projects

Replace skeleton placeholders with complete, pedagogically rich
solution guides for every project in projects/level-0/:

- Full working solution code with extensive WHY comments on every
  non-obvious line explaining design decisions
- Design decisions tables with real trade-offs from each project
- Alternative approaches with concrete code and when to prefer them
- "What could go wrong" tables covering common beginner mistakes,
  edge cases, and their prevention strategies
- Key takeaways connecting each project to future concepts and
  real-world applications

Projects covered (01-15):
  Terminal Hello Lab, Calculator Basics, Temperature Converter,
  Yes/No Questionnaire, Number Classifier, Word Counter Basic,
  First File Reader, String Cleaner Starter, Daily Checklist Writer,
  Duplicate Line Finder, Simple Menu Loop, Contact Card Builder,
  Alarm Message Generator, Line Length Summarizer, Mini Toolkit

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

Author: travisjneuman

projects/level-0/01-terminal-hello-lab/SOLUTION.md

@@ -0,0 +1,157 @@
+# Solution: Level 0 / Project 01 - Terminal Hello Lab
+
+> **STOP** — Have you attempted this project yourself first?
+>
+> Learning happens in the struggle, not in reading answers.
+> Spend at least 20 minutes trying before reading this solution.
+> If you are stuck, try the [Walkthrough](./WALKTHROUGH.md) first — it guides
+> your thinking without giving away the answer.
+
+---
+
+
+## Complete solution
+
+```python
+"""Level 0 project: Terminal Hello Lab.
+
+Practice printing to the terminal, using variables, and
+understanding how Python sends text to your screen.
+
+Concepts: print(), variables, string concatenation, f-strings, escape characters.
+"""
+
+
+# WHY greet is a function: Wrapping the greeting in a function makes it
+# reusable and testable.  Tests can call greet("Ada") directly without
+# running the whole script or simulating user input.
+def greet(name: str) -> str:
+    """Build a personalised greeting string."""
+    # WHY f-string: f"..." lets us embed variables directly inside the string.
+    # It is cleaner than "Hello, " + name + "! Welcome to Python."
+    return f"Hello, {name}! Welcome to Python."
+
+
+# WHY width defaults to 40: Default arguments let callers skip the parameter
+# when the common case is fine.  A 40-character banner fits comfortably in
+# most terminals.
+def build_banner(title: str, width: int = 40) -> str:
+    """Create a decorative banner around a title."""
+    # WHY "*" * width: String repetition creates a horizontal rule.
+    # The * character repeated `width` times makes one border line.
+    border = "*" * width
+
+    # WHY .center(): It pads the title with spaces so it sits in the middle.
+    # This keeps the output visually balanced regardless of the title length.
+    centered_title = title.center(width)
+
+    # WHY join with \n: We build all three lines and combine them with
+    # newline characters so the function returns one complete string.
+    return f"{border}\n{centered_title}\n{border}"
+
+
+# WHY build_info_card returns a dict: Dictionaries label each piece of data
+# with a key, making the output self-documenting.  Code that receives the
+# dict can access card["name"] instead of guessing what index 0 means.
+def build_info_card(name: str, language: str, day: int) -> dict:
+    """Collect key facts into a dictionary."""
+    return {
+        "name": name,
+        "language": language,
+        "learning_day": day,
+        # WHY call greet() here: Reusing the greet function avoids duplicating
+        # the greeting logic.  If the format changes, we only fix it once.
+        "greeting": greet(name),
+    }
+
+
+# WHY run_hello_lab exists: It groups all the "do stuff" steps into one
+# callable unit.  The script's __main__ block stays tiny, and tests could
+# call this function to verify the full workflow.
+def run_hello_lab(name: str, day: int) -> dict:
+    """Execute the full hello-lab workflow and return results."""
+    # --- Terminal output (side effects) ---
+    banner = build_banner("TERMINAL HELLO LAB")
+    print(banner)
+    print()  # WHY blank line: Visual breathing room between sections.
+
+    greeting = greet(name)
+    print(greeting)
+
+    # WHY \t: The tab character indents the text, showing how escape
+    # characters control formatting inside strings.
+    print(f"\tDay {day} of your Python journey.")
+    print()
+
+    # WHY \n inside the string: Demonstrates that escape characters work
+    # inside f-strings too — this prints on two lines from one print() call.
+    print("Fun fact: Python is named after Monty Python,\nnot the snake!")
+
+    # --- Build summary ---
+    summary = build_info_card(name, "Python", day)
+    return summary
+
+
+# WHY __name__ == "__main__": This guard means the code below only runs
+# when you execute the file directly (python project.py), NOT when
+# another file imports it.  Tests import greet() and build_banner()
+# without triggering the interactive input prompts.
+if __name__ == "__main__":
+    name = input("What is your name? ")
+    day_text = input("What day of your Python journey is it? ")
+
+    # WHY int(): input() always returns a string.  We need an integer
+    # for the day number so we can do math with it later.
+    day = int(day_text)
+
+    summary = run_hello_lab(name, day)
+
+    print("\n--- Your Info Card ---")
+    # WHY .items(): Iterating over key-value pairs lets us print
+    # every field without knowing the exact keys in advance.
+    for key, value in summary.items():
+        print(f"  {key}: {value}")
+```
+
+## Design decisions
+
+| Decision | Why | Alternative considered |
+|----------|-----|----------------------|
+| `greet()` as a standalone function | Makes the greeting testable in isolation — tests call `greet("Ada")` without running the whole script | Inline the greeting with `print(f"Hello, {name}!")` directly — simpler but untestable |
+| `build_banner()` uses a `width` default parameter | Callers get a sensible 40-char banner without passing extra arguments, but can customise when needed | Hard-code the width to 40 — less flexible if the title is very long |
+| `build_info_card()` returns a `dict` | Keys like `"name"` and `"language"` make data self-documenting; any code can access fields by name | Return a tuple `(name, language, day)` — shorter but relies on positional order, which is fragile |
+| `run_hello_lab()` both prints and returns | Lets the interactive script show output AND lets tests inspect the returned dict | Print-only with no return — tests would have to capture stdout, which is harder for beginners |
+
+## Alternative approaches
+
+### Approach B: String concatenation instead of f-strings
+
+```python
+def greet(name: str) -> str:
+    # Using + to join strings instead of f-strings.
+    return "Hello, " + name + "! Welcome to Python."
+
+def build_banner(title: str, width: int = 40) -> str:
+    border = "*" * width
+    # Using .format() instead of f-strings.
+    centered_title = "{:^{}}".format(title, width)
+    return border + "\n" + centered_title + "\n" + border
+```
+
+**Trade-off:** String concatenation with `+` is the most basic approach and works in all Python versions. However, f-strings (available since Python 3.6) are easier to read when mixing text and variables. You can see at a glance what the output looks like. The `.format()` method is a middle ground — more powerful than `+` but less readable than f-strings. For beginners, f-strings are the recommended default.
+
+## What could go wrong
+
+| Scenario | What happens | Prevention |
+|----------|-------------|------------|
+| User presses Enter without typing a name (empty string) | `greet("")` returns `"Hello, ! Welcome to Python."` — an awkward blank space | Add a guard: `if not name.strip(): name = "friend"` before calling `greet()` |
+| User types letters for the day number (e.g. "seven") | `int("seven")` raises `ValueError` and the program crashes | Wrap `int(day_text)` in a `try/except ValueError` and ask again |
+| User types a negative day number (e.g. "-3") | `int("-3")` succeeds, and the program says "Day -3" — technically wrong | Check `if day < 1:` and ask again or default to 1 |
+| User types only spaces as their name | `greet("   ")` returns `"Hello,    ! Welcome to Python."` — looks messy | Use `.strip()` on the name and check if it is empty after stripping |
+
+## Key takeaways
+
+1. **Functions make code testable.** By wrapping logic in `greet()` and `build_banner()`, tests can verify each piece independently without simulating user input. This is why every project from here on uses functions.
+2. **f-strings are your go-to for mixing text and variables.** The syntax `f"Hello, {name}!"` is clearer than concatenation and will be used in nearly every Python project you encounter.
+3. **The `if __name__ == "__main__"` guard separates "library code" from "script code."** This pattern appears in every project going forward and becomes essential when you start importing modules in Level 1+.
+4. **Dictionaries bundle related data with meaningful labels.** The `build_info_card()` function previews a pattern you will use constantly — returning structured data from functions instead of just printing it.

projects/level-0/02-calculator-basics/SOLUTION.md

@@ -0,0 +1,184 @@
+# Solution: Level 0 / Project 02 - Calculator Basics
+
+> **STOP** — Have you attempted this project yourself first?
+>
+> Learning happens in the struggle, not in reading answers.
+> Spend at least 20 minutes trying before reading this solution.
+> If you are stuck, try the [Walkthrough](./WALKTHROUGH.md) first — it guides
+> your thinking without giving away the answer.
+
+---
+
+
+## Complete solution
+
+```python
+"""Level 0 project: Calculator Basics.
+
+A four-operation calculator that takes input from the user
+and computes results interactively.
+
+Concepts: arithmetic operators, float/int conversion, input validation, functions.
+"""
+
+
+# WHY separate functions for each operation: Each function does exactly one
+# thing, making it trivial to test.  assert add(2, 3) == 5 is crystal clear.
+def add(a: float, b: float) -> float:
+    """Return the sum of two numbers."""
+    return a + b
+
+
+def subtract(a: float, b: float) -> float:
+    """Return the difference of two numbers."""
+    return a - b
+
+
+def multiply(a: float, b: float) -> float:
+    """Return the product of two numbers."""
+    return a * b
+
+
+def divide(a: float, b: float) -> float:
+    """Return the quotient of two numbers.
+
+    WHY check for zero? -- Dividing by zero crashes the program with
+    ZeroDivisionError.  Checking first lets us raise ValueError with
+    a clear message that explains what went wrong.
+    """
+    if b == 0:
+        raise ValueError("Cannot divide by zero")
+    return a / b
+
+
+def calculate(expression: str) -> dict:
+    """Parse a simple expression like '10 + 5' and return the result.
+
+    WHY split on spaces? -- We expect the format 'number operator number'.
+    Splitting on whitespace gives us exactly three pieces to work with.
+    """
+    parts = expression.strip().split()
+
+    # WHY check length: If the user typed "5" or "1 + 2 + 3", we cannot
+    # parse it as a simple binary expression.  Return an error dict
+    # instead of crashing.
+    if len(parts) != 3:
+        return {"expression": expression.strip(), "error": "Expected format: number operator number"}
+
+    raw_a, operator, raw_b = parts
+
+    # WHY try/except: float() raises ValueError if the string is not a
+    # number.  Catching it lets us return a helpful error instead of
+    # a scary traceback.
+    try:
+        a = float(raw_a)
+        b = float(raw_b)
+    except ValueError:
+        return {"expression": expression.strip(), "error": f"Invalid numbers: {raw_a}, {raw_b}"}
+
+    # WHY a dict mapping operators to functions: This replaces a long
+    # if/elif/else chain.  Adding a new operator means adding one line
+    # to the dict instead of another elif branch.
+    operations = {
+        "+": add,
+        "-": subtract,
+        "*": multiply,
+        "/": divide,
+    }
+
+    if operator not in operations:
+        return {"expression": expression.strip(), "error": f"Unknown operator: {operator}"}
+
+    # WHY another try/except: divide() can raise ValueError for zero
+    # division.  We catch it here so calculate() always returns a dict,
+    # never crashes.
+    try:
+        result = operations[operator](a, b)
+    except ValueError as err:
+        return {"expression": expression.strip(), "error": str(err)}
+
+    return {"expression": expression.strip(), "result": result}
+
+
+if __name__ == "__main__":
+    print("=== Calculator ===")
+    print("Type an expression like '10 + 5' or 'quit' to exit.\n")
+    print("Supported operators: +  -  *  /\n")
+
+    # WHY while True with break: This is the standard "loop until quit"
+    # pattern.  The loop runs forever; only the break statement exits it.
+    while True:
+        expression = input("Enter expression: ")
+
+        if expression.strip().lower() in ("quit", "exit", "q"):
+            print("Goodbye!")
+            break
+
+        result = calculate(expression)
+
+        if "error" in result:
+            print(f"  ERROR: {result['error']}")
+        else:
+            print(f"  {result['expression']} = {result['result']}")
+
+        print()
+```
+
+## Design decisions
+
+| Decision | Why | Alternative considered |
+|----------|-----|----------------------|
+| Separate `add`, `subtract`, `multiply`, `divide` functions | Each is independently testable with a single `assert`. Tests read naturally: `assert add(2, 3) == 5` | One big `calculate()` that does everything — harder to test individual operations |
+| `operations` dict maps operator strings to functions | Adding a new operator (like `%` or `**`) requires one new dict entry instead of another `elif` branch | `if/elif/else` chain — works but gets long as operators grow; does not demonstrate dict-as-dispatch |
+| `calculate()` returns a dict with either `"result"` or `"error"` | The caller checks one key to know if it worked. No exceptions leak out of `calculate()` | Raise exceptions for errors — forces the caller to use try/except, which is more complex at Level 0 |
+| `divide()` raises `ValueError` instead of returning a special value | Exceptions are Python's standard way to signal errors. The caller in `calculate()` catches it and converts to an error dict | Return `None` or `float('inf')` — hides the error, and the caller may not notice |
+
+## Alternative approaches
+
+### Approach B: if/elif chain instead of dict dispatch
+
+```python
+def calculate(expression: str) -> dict:
+    parts = expression.strip().split()
+    if len(parts) != 3:
+        return {"expression": expression.strip(), "error": "Expected format: number operator number"}
+
+    raw_a, operator, raw_b = parts
+    a = float(raw_a)
+    b = float(raw_b)
+
+    # Direct if/elif chain — no dict needed.
+    if operator == "+":
+        result = a + b
+    elif operator == "-":
+        result = a - b
+    elif operator == "*":
+        result = a * b
+    elif operator == "/":
+        if b == 0:
+            return {"expression": expression.strip(), "error": "Cannot divide by zero"}
+        result = a / b
+    else:
+        return {"expression": expression.strip(), "error": f"Unknown operator: {operator}"}
+
+    return {"expression": expression.strip(), "result": result}
+```
+
+**Trade-off:** The if/elif approach is easier for an absolute beginner to read because it uses no advanced concepts like "storing functions in a dict." However, the dict dispatch approach scales better — adding modulo or exponentiation is one line instead of another branch. In real codebases, dict dispatch is the standard pattern for this kind of routing.
+
+## What could go wrong
+
+| Scenario | What happens | Prevention |
+|----------|-------------|------------|
+| User types `10 / 0` | `divide()` raises `ValueError("Cannot divide by zero")`, caught by `calculate()` — returns error dict | Already handled; the outer try/except catches it |
+| User types `hello + world` | `float("hello")` raises `ValueError`, caught in the try/except — returns error dict | Already handled by the input validation block |
+| User types just `5` (no operator) | `parts` has length 1, not 3 — returns "Expected format" error | Already handled by the length check |
+| User types `10+5` (no spaces) | `split()` gives `["10+5"]` — length 1, returns format error | Document that spaces are required; alternatively, use regex to parse |
+| User types `10 + 5 + 3` | `parts` has length 5, not 3 — returns format error | Only binary expressions are supported; extending to multi-operand requires a proper parser |
+
+## Key takeaways
+
+1. **Dict dispatch replaces long if/elif chains.** Mapping `"+"` to `add` and `"*"` to `multiply` is cleaner and more extensible than branching for every operator. This pattern appears in web frameworks, CLI tools, and game engines.
+2. **`float()` and `int()` convert strings to numbers, but they crash on bad input.** Always wrap them in `try/except ValueError` when the data comes from a user or file. You will use this pattern in every project that reads numeric input.
+3. **Returning error dicts keeps the caller simple.** Instead of raising exceptions that force try/except everywhere, `calculate()` returns `{"error": "..."}` so the caller just checks `if "error" in result`. This is a beginner-friendly version of the "Result type" pattern used in many languages.
+4. **Functions that do one thing are easier to test.** `assert add(2, 3) == 5` is a one-line test. If `add` also handled parsing and printing, the test would need to set up input and capture output — much harder.