ElanoryaJewelry AI
Who decides where the jewelry sits on the model
You do not position the piece. The on-model flow runs five steps and placement is not one of them, so the value that leaves the app is automatic placement. The server still accepts a manual placement object, which is why the parameter still appears at the endpoint and in the server configuration.
The flow never asks you where the piece should sit
There is no control anywhere in the on-model flow that lets you move the piece. The flow runs five steps — category, jewelry input, model source, review, processing — and placement is not among them; the step was taken out of the flow definition (tool-flows.ts:42-48, verified 2026-08-18).
The sequence is what the app walks you through, and this one goes from the model source to the review with nothing in between.
The consequence reaches the request itself. The app writes a manual placement only when the run already carries placement === "manual", and otherwise writes auto (store.tsx:215). With no step that could set that value, what is submitted in practice is automatic placement.
What the code records, layer by layer
The places in the source that touch placement do not say the same thing. Each reference below was checked against the repository on 2026-08-18.
- The step was removed, and the reason was written down next to the removal.
- The comment beside the flow definition records that the active provider took manual placement only as a text hint and, because the coordinate was not applied reliably, the run produced the same output as automatic placement (tool-flows.ts:37-40).
- The editor files were kept rather than deleted.
- placement-step.tsx and manual-placement-editor.tsx are still in the tree; repo-wide, the only reference to either is its own definition, so nothing renders them (tool-flows.ts:39-40). This page does not read that retention as a plan, a date, or a route.
- The endpoint still accepts the manual mode.
- The generation controller accepts placement=manual and, when it is sent, requires a manualPlacement object with it (generation.controller.ts:69,78-81).
- The server configuration still reports both modes as enabled.
- The creation configuration returns automatic and manual placement as enabled modes (creation-config.service.ts:143-148). It describes what the server would take, not what the app puts in front of you.
Open at the back, closed at the front
The same feature reads as available or unavailable depending on which layer you look at. The step sequence is the one that decides what you can reach.
| Layer | What it says about placement | Where it is written |
|---|---|---|
| Flow definition (app) | Five steps; the placement step was taken out | tool-flows.ts:42-48 |
| Placement editor files (app) | Present in the tree, referenced only by their own definitions | tool-flows.ts:39-40 |
| Submitted value (app) | manual only if the run already carries manual, otherwise auto | store.tsx:215 |
| Generation endpoint (server) | Accepts placement=manual, and then requires a manualPlacement object | generation.controller.ts:69,78-81 |
| Creation configuration (server) | Returns both placement modes as enabled | creation-config.service.ts:143-148 |
Why the removed step would not have sent a coordinate
This is the background to the removal, not a path you can take. If a manual placement were sent, it would not travel as a parameter: the centre from the left and from the top and the width of the piece are written as whole percentages, the rotation to one decimal place, and all of it becomes one English sentence inside the request (model-generate-provider.ts:106-109).
The reason recorded in the code follows from that shape — the active provider took the manual placement only as a text hint and did not apply the coordinate reliably, so the result matched what automatic placement produced (tool-flows.ts:37-40). That is what the code gives as the reason for pulling the step.
What such a sentence does at the provider is not something this page establishes, and it makes no claim that a coordinate you chose would have changed a picture. The contents of the outgoing request are settled on the page that owns them, linked below.
The decisions the flow does hand you
Position is not on this list. Everything the flow asks you for is on it (tool-flows.ts:42-48). What comes back is one image per submission, and an on-model result cannot carry transparency — both are settled on the page about what leaves your phone, not here.
- The category of the piece, asked first.
- The photograph of the jewelry you send.
- Where the model comes from.
- Whether to go ahead at the review step, which is what follows the model source.
What this page does not settle
These are open, and they are left open deliberately rather than filled in with a guess.
- How automatic placement arrives at a position. The code establishes which mode is submitted, not how that mode decides.
- Whether a placement you chose by hand would have produced a different picture.
- Whether the provider follows a placement written into a sentence.
- Whether the removed step comes back, and if so when. Files kept in the tree are not a schedule and are not read as one here.
- Whether anything outside the defined flow reaches the removed step. The step sequence is the only authority used on this page.
- What the outgoing request carries and what the reply is asked to be — that belongs to the page on what leaves your phone.
- How apparent size and length behave in an on-model frame — that belongs to the page on sized and fitted pieces.
Questions
Can I drag the piece into position before generating?
No. The on-model flow runs five steps — category, jewelry input, model source, review, processing — and the placement step was taken out of that sequence (tool-flows.ts:42-48, verified 2026-08-18). Nothing later in the run asks you for a position.
The API accepts a manual placement. Does that mean the feature exists for me?
The endpoint does accept placement=manual, and requires a manualPlacement object when it is sent (generation.controller.ts:69,78-81); the server configuration also reports both modes as enabled (creation-config.service.ts:143-148). Neither makes a step appear in the flow. The app writes manual only when the run already carries that value, so what is submitted is auto (store.tsx:215).
Why was the placement step taken out?
The reason is written next to the flow definition: the active provider took manual placement only as a text hint and did not apply the coordinate reliably, so the run produced the same output as automatic placement (tool-flows.ts:37-40). That is the recorded reason, and this page does not extend it into a claim about what the provider does with such a sentence.
Two placement editor files are still in the source. Will the step return?
This page cannot tell you. placement-step.tsx and manual-placement-editor.tsx are still present, and repo-wide the only reference to either is its own definition, so nothing renders them (tool-flows.ts:39-40). A file that is not rendered is not a step, and no date or commitment follows from its presence.