14. Operational Boundaries

What the signup → first-login → onboarding journey does not do, so the frontend team and future maintainers don't assume more automation than actually exists:

• Registration does not create the tenant's application database. It only writes to the shared/root database. Provisioning happens later, at first login (see Chapter 8).
• Registration does not send the frontend a resolved list of names for location/package — it accepts and validates GUIDs only. Any name-to-ID resolution must happen client-side via the prerequisite APIs.
• Onboarding apply does not create inventory quantities, chart-of-accounts entries, cost centers, or product catalog rows. It only writes tenant AppSettings values. All of that is the Starter Kit's job — a separate, admin-only, explicit Preview/Apply flow (see Chapter 11 and the full Tenant Starter Kit & Product Catalog guide).
• The starter product catalog (when a SaaS admin does apply the Starter Kit) does not create real prices, barcodes, or stock quantities — those remain the tenant's own responsibility once they start entering real purchase/sales documents. See the Starter Kit guide's own operational-boundaries chapter for the full statement of this.
• Onboarding never blocks login. isRequired/status only drive whether the client shows the survey — a tenant can always reach the dashboard via skip (where canSkip allows it) or after apply, and login itself is never gated on onboarding completion.
• This guide's live verification never touched production. All registration, verification, login, and onboarding calls in this task ran against a local Shumoul.Api process pointed at the dev database reachable via DatabaseSettings__ConnectionString — no production tenant, credential, or connection string was read, printed, or written to.