ElanoryaJewelry AI · Acceptance screen
The app holds you on one screen until you accept the updated terms
One server-side value decides whether an acceptance still counts as current. When that value moves, the acceptance you gave earlier stops counting, the app sends you to a review screen that does not let you back, and the four credit-spending actions are refused until the acceptance is recorded again.
Why the screen appeared on this launch
Nothing on your phone changed. The acceptance state is decided on the server by a single version value, and the terms and the privacy document take their version from that same value - they cannot be raised one at a time (apps/api/src/legal/legal-contract.ts). When the value moves, an acceptance recorded against the previous one is no longer counted as current, so the app asks again.
That value is not typed in by hand; it is derived from a generated manifest. This is the reason the product has no quieter option in which one document is corrected and no acceptance is requested. There is one value, and it governs the whole acceptance state.
The check itself is narrow in a different way: it only ever looks at the current version. An acceptance held against an older version is not deleted or contradicted by the screen - it simply is not what the check is counting.
What the screen does while it is open
The screen is not a dialog placed over the app. It takes the place of the route you were on.
- It replaces the route rather than covering it.
- When acceptance is required, the app performs a route replacement to the review screen, so there is no screen underneath to return to (apps/jewelry-mobile/src/app/_layout.tsx).
- It reappears rather than being dismissed.
- The condition is evaluated by the app, not by the screen, so leaving the screen without an acceptance being recorded returns you to it.
- The exemption it appears to allow does not take effect.
- The exemption list still names terms and privacy route segments, but those route files were removed - only the help and review screens remain under the legal routes - so the exemption has nothing to match.
- Accepting writes a record; the record is what the server reads.
- The acceptance is counted only when the pair of records exists together at the current version, which is a mechanism a separate page covers in full; here it matters only as the reason the block lifts (apps/api/src/legal/legal-evidence.service.ts).
Where the block is applied, action by action
Two different mechanisms are at work, and they do not cover the same ground. Reading them as one leads to wrong conclusions about what is protected.
| What you attempt | What happens | Which mechanism applies |
|---|---|---|
| Create, upscale, background removal, image edit | The request is refused and the app reports that the current terms must be accepted | Server check on the request |
| The rest of the app while the screen is open | Not reachable - the screen has replaced the route you were on | App routing |
| Reaching Help from the acceptance screen | Not available from this screen | App routing, with an exemption list that no longer matches any route |
| Free requests such as listing, favourites, deletion | They do not carry the acceptance guard on the server | No acceptance check on the request itself |
The refusal you rarely see, and why
There are two ways the block can reach you. The usual one is the routing: the app decides acceptance is required and puts the review screen in front of you before a request is ever made.
The other is the server refusing the request outright and naming the missing acceptance as the reason, which the app turns into a message asking you to accept the current terms (apps/api/src/legal/legal-acceptance.guard.ts). Because the routing normally arrives first, this refusal is what an older or bypassed client meets rather than what the current path produces.
The practical consequence is that a message about acceptance appearing in place of a generation is not a different fault from the screen. It is the same condition, reported at a later point.
What this page is not in a position to state
The evidence behind this page is the acceptance mechanism in the product code. Several nearby questions sit outside it.
- What the documents say, cover or grant, and which rules they answer to - none of that is derived from the mechanism and none of it is stated here.
- Which version is live in production at any moment, or which build is in the stores. The code shows a value; it does not report the deployed state.
- Whether purchase, subscription, credit or refund requests relate to acceptance in any way.
- What exactly the acceptance writes, how the pair of records behaves afterwards, and which language it is pinned to - a separate page owns that mechanism, and only its consequence appears above.
- Where the terms and privacy documents open and in which language they are shown.
- Anything about the age declaration beyond the fact that the acceptance is not counted unless its record is present at the same version.
Where these statements were read from
Version behaviour: apps/api/src/legal/legal-contract.ts, where the registration legal version is defined from the canonical content version constant.
The count that decides whether an acceptance is current: apps/api/src/legal/legal-evidence.service.ts, which requires both records at the current version.
The refusal and its named condition: apps/api/src/legal/legal-acceptance.guard.ts.
The four requests that carry the guard: apps/api/src/generation/generation.controller.ts, on the create, upscale, background removal and image edit endpoints.
The route replacement and the exemption list that no longer matches: apps/jewelry-mobile/src/app/_layout.tsx, with only help and review remaining under src/app/legal.
Questions
Can I skip the screen and accept later?
No. The app replaces the route you were on with the review screen and puts it back if you leave it, and the four credit-spending requests are refused on the server independently of what the app is drawing. There is no ordering of steps that gets a generation through first.
Does accepting change anything about images I already made?
Accepting is about the acceptance record. This page describes the acceptance mechanism only and makes no claim about your library, your collections or your balance - the mechanism it examines does not touch them.
Why did this happen without an app update?
Because the trigger is a server-side version value rather than anything shipped in the build. The terms and the privacy document derive their version from the same value, so it moves for the whole acceptance state at once.
Can I open Help from the acceptance screen to check first?
Not from that screen. The exemption list still names terms and privacy route segments whose files were removed, so the exemption never matches and the screen keeps the route. The help screen still exists in the app; it is simply not an exit from this one.