feat: clarify booking summary participant count

docs/service-simplification-plan.md

@@ -1,7 +1,7 @@
 # Service Simplification Plan
 
 Status: draft
-Last updated: 2026-04-05
+Last updated: 2026-04-13
 
 ## Purpose
 
@@ -71,6 +71,62 @@ Concrete next steps:
 Decision rule:
 - if a registry owns actual workflow behavior, treat it as a boundary rather than a smell
 
+## Implementation Backlog
+
+### 1. Keep the summary count contract explicit
+
+Goal: make the booking summary read clearly without duplicating equivalent count fields.
+
+Tasks:
+- use a single summary-facing count field for the sidebar and step summary views
+- keep the room-capacity-derived meaning explicit in the field name and docblock
+- keep the participant-shaping count logic separate if the code still needs it internally
+- remove template branching that compares two equivalent summary counts
+
+Acceptance criteria:
+- the summary template reads one count field, not two equivalent ones
+- the field name makes the room-capacity meaning obvious to a new developer
+- participant-shaping logic can still use its own internal count without leaking that distinction into the view layer
+
+### 2. Reduce `BookingService`
+
+Primary goal: make the booking create/edit flow easier to read by splitting unrelated concerns.
+
+Concrete next steps:
+- keep booking session lifecycle in one place
+- extract baseline room snapshot handling into a narrower helper or dedicated service
+- separate return URL handling if it stays conceptually unrelated
+- keep `startFreshBooking()` focused on booking bootstrap rather than general session utilities
+- keep hydration behavior obvious and local to the booking session path
+
+Decision rule:
+- if a method only forwards to DTO/session behavior, prefer removing the wrapper
+- if a method is a genuine workflow owner, keep it and narrow the surrounding API instead of splitting it into generic helpers
+
+### 3. Keep pricing calculation focused
+
+Primary goal: keep pricing code about pricing, not rendering.
+
+Concrete next steps:
+- keep `BookingPriceCalculatorService` as the pricing boundary
+- continue removing display formatting from pricing code paths
+- keep any remaining view-specific formatting in the presentation layer or a dedicated UI helper
+- avoid introducing another service that only formats values already known to the view
+
+Decision rule:
+- if a value is only needed for display, prefer exposing the raw numeric/domain value and formatting it as close to the UI as possible
+
+### 4. Leave the field-handler registry in place
+
+Primary goal: avoid unnecessary churn in a class that is already a meaningful orchestration layer.
+
+Concrete next steps:
+- do not refactor `ParticipantFieldHandlerRegistry` in this pass
+- revisit only if a later change can split ordering, mutability, and synchronization into clear collaborators without making the flow harder to trace
+
+Decision rule:
+- if a registry owns actual workflow behavior, treat it as a boundary rather than a smell
+
 ## Follow-Up Queue
 
 After the booking service pass, the next likely candidates are: