Finish Setting Up¶

A shop can switch a feature on and still not be able to use it. A restaurant can give staff the till before any store is linked to Stripe Terminal. Central sign-in can be on with no sign-in client. Delivery can be on with no delivery area. Nothing used to point this out. The Finish setting up list does. It shows on the admin home page, on the Settings tiles and in the MCP ops inbox. For each feature the shop uses, it says what is still missing and where to fix it.

What it checks¶

A check only shows when the shop uses its feature. Each item is to do, waiting on another item, or done.

Linking to Stripe Terminal waits on Stripe being connected. The card reader item asks Stripe for the store's readers, and the answer is cached for five minutes per location. If Stripe can't be reached, that item is left out rather than shown wrong. The other items use data the site already has; Stripe's account.updated webhook keeps chargesEnabled current.

There is no custom-domain check: a domain is checked by DNS when it's added and refused if the check fails, so a site never holds an unverified one.

Not needed¶

Some items don't fit every shop. A café that only takes Tap to Pay has no card reader to register. Not needed takes such an item off the list. It moves under "Show done" with Put back, and stops counting towards the badges and the progress bar. These choices are the only thing stored, as item ids in the hidden setup-dismissed setting (Settings › Advanced). Only ids that are on the current list are accepted.

Where it shows¶

• Admin home page: a Finish setting up card above the sales figures, for people who can change settings. It shows what's still to do (the first item's button is the primary one), what is waiting, a progress bar, a "Show done" fold and a link to any waiting platform upgrades. The card goes away once nothing is outstanding.
• Settings: each section tile has a "N to set up" badge, and the section's page lists its items at the top.
• MCP: opsInbox has a setup count. Its setup list holds each outstanding item with fixWith (the tool call, when an agent can fix it) and adminPage. Stripe onboarding, Terminal links and central sign-in can only be fixed by a person in the admin.

How it works¶

Nothing is computed ahead of time. SetupChecklistService.checklist(siteContext) asks every SetupCheck bean in turn whenever a page or tool wants the list, so the list is always current and there is no job to keep it up to date. A check that throws is logged and left out, and the other checks still show. Items are sorted to do, then waiting, then done, then not needed. Within each group, checks keep their @Order and their own item order.

Adding a check¶

1. Write a @Component that implements SetupCheck, in the feature's own package. Give it an @Order to place it among the others.
2. In appliesTo, return true only when the shop uses the feature. A shop that doesn't use it should see nothing.
3. In check, return one SetupItem per thing to do, done or not, so the progress bar has something to count. Give each item a stable id (add :<code> for per-location items), since dismissals are stored by id. Write the text as one sentence for the merchant: what's wrong and why it matters, with no class or config names. Give the Action an admin URL, plus an MCP call when an agent can do the fix. Set the section to the SettingsSections id the item belongs to. Use blocked with a waitingOn when another item has to be done first.
4. Read through services, never repositories, and take SiteContext from the caller. Cache anything that calls an outside service for a few minutes. Log site and location ids, never customer data.
5. Add a unit test for each state the check can report.