markdown formatting

organize/unsorted/FINDINGS_AUSWERTUNG_SOL.md

@@ -28,8 +28,8 @@ I would:
 - Add store and handshake tests for this sequence.
 
 This restores the intended "tombstone prevents resurrection for the rest of the
-session" invariant. I would fix the semantics, not merely downgrade the
-repeated warning.
+session" invariant. I would fix the semantics, not merely downgrade the repeated
+warning.
 
 ### 2. Distinguish missing game directory from peer startup
 
@@ -39,22 +39,21 @@ becomes true.
 
 I would:
 
-- Model directory readiness as `checking | missing | ready`, rather than
-  passing only a boolean that conflates hydration with a known missing
-  directory.
+- Model directory readiness as `checking | missing | ready`, rather than passing
+  only a boolean that conflates hydration with a known missing directory.
 - Pass that prerequisite state into `useCallToPlay`.
 - Show folder guidance only for the confirmed `missing` state.
 - Preserve the current connecting message for `checking` or
   `ready-but-peer-starting`.
 - Test both states and the transition after a valid directory is selected.
 
-That finishes the original finding's full intent without returning to
-misleading folder advice during normal startup.
+That finishes the original finding's full intent without returning to misleading
+folder advice during normal startup.
 
 ### 3. Add a local Launch action to Running receipts
 
-Fable's UX point is persuasive. Participants currently reach the key moment
-and see only that the game is running.
+Fable's UX point is persuasive. Participants currently reach the key moment and
+see only that the game is running.
 
 I would add a local-only Launch button when:
 
@@ -63,9 +62,9 @@ I would add a local-only Launch button when:
 - No conflicting operation prevents launch.
 
 This would not violate the read-only terminal invariant: launching the local
-game does not mutate the replicated call. I would use a dedicated play
-callback rather than the generic primary action, so a button labelled "Launch"
-cannot unexpectedly initiate an install or update.
+game does not mutate the replicated call. I would use a dedicated play callback
+rather than the generic primary action, so a button labelled "Launch" cannot
+unexpectedly initiate an install or update.
 
 ### 4. Make terminal receipts visually static and correct the spec
 
@@ -79,8 +78,8 @@ The terminal receipt details are small but real:
 
 I would:
 
-- Freeze participant readiness at `terminalAt`, or render terminal
-  participants without countdown tags.
+- Freeze participant readiness at `terminalAt`, or render terminal participants
+  without countdown tags.
 - Suppress empty roster slots on terminal cards.
 - Change Ready ticker text to name the creator.
 - Update the ticker specification to match the actual visible-call and ranking
@@ -106,8 +105,8 @@ React test stack or waiting five real minutes:
   fixtures could be a later improvement.
 - **Full-store cloning per merge:** acceptable under the 4,096 unresolved-event
   cap.
-- **Substring-matched frontend errors:** brittle, but currently pinned by
-  tests; a proper fix requires a typed peer-to-Tauri error contract and is
+- **Substring-matched frontend errors:** brittle, but currently pinned by tests;
+  a proper fix requires a typed peer-to-Tauri error contract and is
   disproportionate for finishing this branch.
 - **Missing component-test infrastructure:** inspection plus pure reducer tests
   is adequate here; I would not add a UI test framework solely for these
@@ -126,4 +125,3 @@ The recommended finish scope is:
 3. A Running-card Launch action.
 4. Terminal-receipt polish and specification corrections.
 5. Targeted replication tests.
-