Zurich | STEP 1 closed, Own Photo | `

💡 Topic overview
STEP 1 is closed, Own Photo is live, and the low-stock trigger line has been changed to 20. Tonight's 22:15 chef Queue was sent out naturally by the official scheduler, with no manual trigger.
**STEP 1 — Production source code provenance**
`G2_SOURCE_FILES`: `RecruitmentPublicationWorker.cs`, `ShortcutIntakeService.cs`, `nginx/nginx.conf`, `scripts/test_shortcut_intake_contract.sh`, and the corresponding G2 minimal documentation.
`TESTS`: G2 / shortcut intake contract passed.
`COMMIT`: `33ae563`
`PUSHED`: yes
`LIVE_SOURCE_REPRODUCIBLE=yes` (behaviour can be rebuilt; a newly compiled DLL will not be byte-identical to the old G2)
**STEP 2 — Own Photo**
**READY_FOR_ONE_PHONE_RETEST=yes**
Please test only once: iPhone Choose Photo → publish immediately, using one normal portrait image. Expected: you first see "Received, matching an image", and in the end it is still the user's original image, not a searched image.
**STEP 3 — Low-stock trigger line**
| Parameter | Actual value before change | This time |
|---|---|---|
| InventoryThreshold | 3 | **20** |
| TargetInventory | 6 | **Not changed** |
| HighWatermark | No such parameter | **Not changed** |
| BatchSize | No separate field; enqueue amount = target − stock | **Not changed** |
Boundaries: 0/1/18/19 trigger; 20/21 do not trigger; Autonomous 19 + Shortcut 100 still triggers; Failed/Unknown/Shortcut are not counted; if there is already a RUNNING one, it is not started again.
Live stock:
- `AUTONOMOUS_READY_STOCK=4`
- `SHORTCUT_READY_STOCK=0`
- `MANUAL_READY_STOCK=0`
4 < 20, so restocking will run; but target is still 6, so this round will restock to 6 at most, not to 20. After that, as long as autonomous READY is still < 20, it will collect again once the cooldown is up, but the enqueue will still only fill up to 6. To avoid 19↔20 jitter and really restock to above 20, raising `TargetInventory` (the current code upper limit is 9) or adding a high watermark would need to be approved later; this was not changed this time.
Live DLL SHA-256 `e8419817b2f53da05e840ecbd7804268295deee2cce3a4fc8388e7e24c3ce33e`
Commits: `bec4700` Own Photo, `c11977b` threshold=20, both pushed.
Health: 200 JSON. logrotate / Xiaohongshu cloud collection not done.

📍 Location information
Two root causes have been fixed: the long edge is no longer first compressed to 1600 and then checked against the 800 short edge; user-supplied images now go through `CheckUserSelectedOriginal` and no longer require the image-search evidence JSON. RECEIVED temporarily stores the original image in `/app/Data/original-photo-stage`, and the Worker restores it as `authorized_original` / `iphone_original` / `user_selected_original_v1`; it will not be changed to a searched image or MiniMax.

📩 Contact
The 22:15 Zurich chef Queue `849102700249093` has naturally become **SUCCEEDED**. Only after that was the application restarted. UNKNOWN `845746018025477` was not touched.