Why

Downstream adopters must not infer from scheduling-kit that it is the owner of Acuity booking semantics. That ownership belongs to scheduling-bridge for the Acuity path.

Deliverables

• identify and isolate package surfaces that currently blur generic checkout UI with Acuity-specific orchestration assumptions
• make it explicit where scheduling-kit stops and a bridge-backed adopter must take over
• ensure docs and examples do not imply that scheduling-kit is the sole Acuity booking source

Completion Metrics

• generic package surfaces can be used with explicit app-provided capabilities
• Acuity-specific flow ownership is documented as bridge-owned
• docs/examples/tests no longer encourage hidden Acuity ownership drift

Related Work

• child of Jesssullivan/scheduling-kit#41
• paired with Jesssullivan/scheduling-kit#43
• paired with MassageIthaca#124