[KesterJJ]

Adds VIP visitor automation for standalone vip-visitor bookings. The driver emails the assistant an invitation with a QR code and confirmation link, emails the submitted details to configured VIP handlers, and creates a Planner plan through the existing Calendar driver after explicit confirmation.

Creates To Do, In Progress and Done buckets and up to nine tasks based on the selected services. Supports current AECB form field aliases, configurable task assignments, optional arrival/departure notices, duplicate suppression, refreshed invitations after edits, and checkpointed recovery from partial Planner failures.

Validation

• Driver harness: docker exec placeos-drivers report drivers/place/vip_visitor_automation.cr — 1 tested, 0 failures, 0 timeouts.
• Specs cover invitation/JWT claims, explicit acceptance, booking filtering, all conditional tasks, field aliases, duplicate events, partial-failure recovery, invitation edits and lifecycle notices.
• Crystal formatting and diff checks passed. Tests use mocked services; no live email or Microsoft Graph resources were created.

Integration requirements

• The external confirmation app needs a scoped backend endpoint and must save extension_data.vip_confirmed: true. Existing guest tokens cannot PATCH the general booking endpoint.
• Planner uses an existing Microsoft 365 group; this driver does not provision a Team. Grouped child bookings are excluded.
• The README documents settings, templates, permissions and recovery limits. The companion VisitorMailer exclude_booking_types change is outside this new-driver-only PR, following the ai-env-drivers contribution process; deployments using both mail workflows need that exclusion support.

[w-le]

Seems like it would be a good idea to add a spec for the visitor_planner logic driver right? Unless the testing of that is already covered by the upstream logic driver's spec.

Other than that. Looks good to e2e test on a dev or uat server, assuming it compiles?