Accounts

Without a session, only the sign-in screens and the legal texts will open

There is no way to look around the app first and register later. A routing check runs before a screen is drawn, and it allows exactly two areas to a visitor who has not signed in: the sign-in and registration group, and the legal screens. Anything else returns you to the welcome screen.

What opens for a visitor who has not signed in

The app decides what a signed-out visitor may see with a single routing check rather than with per-screen permissions. The check looks at the area a destination belongs to and allows two of them: the group that holds the welcome, sign-in and registration screens, and the group that holds the legal texts. Every other destination is redirected to the welcome screen. The rule is one line in apps/jewelry-mobile/src/features/auth/auth-route-guard.ts, and it reads: return segments[0] === '(auth)' || segments[0] === 'legal';

Because the rule is written on areas rather than on screens, there is no partial access to hold on to. It is not the case that the library opens but generation is withheld, or that examples can be browsed and saving cannot. A destination is either inside one of the two allowed areas or it is not, and if it is not, the app puts you back where you started.

One qualifier keeps that statement accurate. The same function carries a branch used by development and preview builds, which opens one further route there. That route is not a public path and is not a way into the app; its existence is only the reason the two-area description is written as a statement about a store build rather than as an absolute.

The legal screens are the second open area. This page reports only that they open without a session; it does not interpret what those texts say or what they grant.

The controls on the welcome, sign-in and registration screens are not a fixed set. One block is conditional, and when its condition is not met it disappears without saying so.

The Google button has a condition in front of it.: It is drawn only when the build was supplied with a public Google client identifier. Where that value is absent the button is not rendered at all. Verified in apps/jewelry-mobile/src/features/auth/components/google-auth-button.tsx, at if (!isGoogleConfigured()).
The absence is silent.: No message, no disabled control and no placeholder is shown in place of the button. From the seller's side there is nothing to distinguish a build without the button from a build that never had one.
On Android the whole block can go, not just one button.: The buttons, the divider and the terms and privacy note beside them are one unit. On a platform that is not Apple's, with no Google client identifier present, the unit is skipped and email and password remain. Verified in apps/jewelry-mobile/src/features/auth/components/social-auth-buttons.tsx, at if (!isApplePlatform() && !isGoogleConfigured()).
Three screens change together.: The same block is used by the welcome, sign-in and registration screens, so whatever it does, it does on all three. A seller who sees email and password on one of them will see email and password on the other two.
Email and password are the constant.: They are what remains when the conditional block is not drawn, which makes them the only entry route that written instructions can safely assume.

Reading the controls that are actually in front of you

The screen reports what your build drew. Each situation below is a reading of that screen, not an inference about which providers are switched on anywhere.

Situation	Choose	Why
You see email and password, a divider, and one or more buttons above them.	Use whichever entry you prefer; they are entry points on the same screen.	The block is conditional, and on your device it was drawn. This page cannot tell you what any particular build was given, and does not try to.
You see only email and password on an Android device.	Register or sign in with an email address and a password.	When the block's condition is not met the buttons, the divider and the note beside them are skipped together, and no error is raised in their place.
You are hunting for a guest, trial or skip-for-now entry.	Stop looking and create an account.	Every destination outside the sign-in group and the legal screens is redirected to the welcome screen, and no screen offers a guest identity to start from.
A screen you opened closes back to the welcome screen.	Read it as the absence of a session rather than as a failure of that screen.	The redirect is the routing guard doing its one job. Nothing about the destination screen is reported by it.

Each item below can be settled from the screen in front of you, without support and without a second device.

Confirm the app returned you to the welcome screen rather than closing: a redirect there is the signed-out routing rule, not a crash.
Check whether email and password are present. If they are, the screen is working, whatever else is missing from it.
If a social button is missing, check the same for the sign-in and registration screens. The block is shared, so it is absent on all three or present on all three.
Do not wait for an error to explain a missing button. When the block's condition is not met, nothing is drawn in its place.
Do not look for a guest or skip entry before deciding the app is broken. The interface has no such step to offer.
If you are comparing two devices, record which device drew which controls, and treat the difference as a difference between builds rather than between accounts.

What this page does not answer about accounts

The evidence behind this page is the mobile client's own routing and rendering behaviour. Several neighbouring questions sit outside it.

Whether Google or Apple sign-in is switched on in the build you downloaded. The code shows the drawing rule, not the value it reads, so no claim either way is made here.
What happens after the registration form is submitted, including where the app sends you next. That handoff is covered separately and is not derived here.
What an account whose address has not been verified can and cannot do inside the app. That state is a separate subject and is not opened on this page.
Server-side identity rules — how verification codes are produced, how long a session lasts, how many attempts are allowed. This surface only reports what the client draws.
The meaning, scope or effect of the legal texts. This page reports that those screens open without a session and stops there.
Account behaviour on the website, in the admin panel or in any other application. The scope is the Jewelry AI mobile client.

Questions

Can I look around the app before creating an account?

No. For a visitor without a session the app allows the sign-in and registration group and the legal screens; every other destination is redirected to the welcome screen. That description covers a store build; a development build carries one further route which is not a public path.

Why do I only see email and password, with no other sign-in buttons?

The social sign-in block is conditional. On Android, when the build was not supplied with a public Google client identifier, the buttons, the divider and the note beside them are skipped together and nothing is drawn in their place. The client code does not reveal what any particular build was given, so a missing button is not evidence about a provider.

Is there a guest mode I can upgrade to a full account later?

No screen in the app offers a step that turns a guest or device identity into a permanent account. Plan on the account existing before the first upload, since there is no earlier state to carry work out of.

Can I read the legal texts before signing up?

Yes. The legal screens are the second area the routing guard leaves open to a visitor without a session. What those texts mean or grant is not something this page interprets.