Module	Target	Plans
`src/Checkout.jsx`	`purchase.checkout.block.render`	Plus only — native in-checkout date/time picker
`src/ThankYou.jsx`	`purchase.thank-you.block.render`	all plans
`src/OrderStatus.jsx`	`customer-account.order-status.block.render`	all plans

The picker calls this app's own checkout.scheduling.availability / checkout.scheduling.hold routes (session-token auth) and draws from the same capacity pool as the storefront widget and POS. It only collects a selection into checkout attributes — the validation-slot Function is still what enforces it, so the extension is not a security boundary.

The all-plan confirmation is also covered by the theme block extensions/datetime-widget/blocks/order-confirmation.liquid; the Thank you / Order status modules here are the Plus-native version of the same thing.

Before deploy

npm --prefix extensions/checkout-datetime install (pulls @shopify/ui-extensions + preact).
In the extension's settings (Partners dashboard or shopify.extension.toml defaults), set App backend URL to the same value as application_url in shopify.app.toml — the extension runs on a different origin and needs the absolute URL to reach the backend.
shopify app deploy.

The previous build output under dist/ is gitignored and regenerated on deploy — this src/ tree is the source of record.

Type checking

tsconfig.json ships with checkJs: false because this source hasn't yet been iterated against the live @shopify/ui-extensions checkout component types (that needs the extension's deps installed and, ideally, a real checkout to verify runtime shapes — same caveat pos-datetime carries). Before deploying: npm install in this folder, flip checkJs back to true, run npm run typecheck, and reconcile the <s-*> component props against the real typings. The decision logic it depends on (resolveAvailabilityRequest, resolveHoldRequest) is already fully tested on the server side.