Experiment ‐ upload prompt

SVGs from figma: https://www.figma.com/design/FEwO6iAGQDNbnmEKnv83VVZr/osmcz-v2?node-id=1454-218&t=ZVi1LJqTFGEkq6om-0

---

V projektu máš ./osmapp projekt z https://github.com/zbycz/osmapp a wireframy svg + jpg

Checkoutni si někde bokem branch https://github.com/zbycz/osmapp/tree/upload a podívej se na její diff. Najdeš tam server-side upload obrázků na wikimedia commons.

Chci abys udělal to udělal jinak ve složce ./osmapp:

1. UI: Pod tlačítkem UPRAVIT MÍSTO ve FeaturePanel, bude jen textové tlačítko bez ohraničení, v podstatě šedivý odkaz "Nahrát obrázek"

   • ukázat tlačítko pouze v případě, že aktuální feature má tags.name && feature.center && osm user is logged in

2. dialog:

• po kliku na tlačítko se otevře UploadDialog

• Dialog bude mít stejnou šířku jako výchozí EditDialog, nebo fullscreenově pro mobil (mrkni jak to má EditDialog)

• dle obrázku

• screen 1:

  • UI: viz upload1.jpg upload1.svg
  • implementuj přihlášení na wikipedii, pomocí libky v té větvi upload: src/server/upload/mediawiki, stačí ji trochu rozšířit.
  • Přihlášení bude přes OAuth, pomocí popup.
  • Tady je moje oauth app, ulož to do .env: client application key: 3f92eb542da5ccc5742b947de25030e5
  • přesměrování pak chci na /wikimedia-oauth-callback.html -- viz podobně to osm
  • ty loga si někde stáhni v SVG a přidej do repa - prostě logo commons a logo wikipedie i s tím textem pod zeměkoulí

• screen 2: pokud je uživatel přihlášen ukáže se rovnou screen 2: viz upload2.jpg + upload2.svg

• screen 3:

  • po výběru obrázku se ukáže ten obrázek zmenšený, max-height 222px, a pod tím:
  • pole název - použij TextField outlined.
    • jako výchozí hodnotu mrkni jak se vyráběl název ve větvi upload, je tam chytristika ohledně name, a přeložený preset label.
    • pokud tento filename je nahraný (checkni funkcí z upload větve), tak rovnou přidej suffix "(2)" - zas to okopíruj z upload větve
    • vpravo bude file extension obrázku needitovatelný, typicky jpg nebo heic, apod.
    • pokud uživatel změní název, zase po 500ms proveď kontrolu jestli je dostupný. Dej tam pak někam třeba zelený háček. Případně error propku.
  • pole kategorie
    • jedná se o autocomplete, který dohledává kategorie z wikimedia commons projektu
    • po kliku do prázdného pole se nabídnou naposledy použité hodnoty (ulož do localStorage key: usedCommonsCategories)
    • po napsání pár písmen se začne vyhledávat a uživatel si může zvolit jednu kategorii
  • tlačítko "nahrát"
    • jde na něj kliknout jedině když název je volný a kategorie vybrána
    • pak se provede ten proces z upload větve, ale čistě v prohlížeči, nějak to přeportuj. Nebude potřeba ani ten s3 bucket, prostě se to rovnou uploadne pomocí té libky src/server/upload/mediawiki pod přihlášeným wikimedia uživatelem.
    • po úspěšném nahrání na commons se pak provede request na uložení tohoto nového obrázku k aktuální featuře
      • vyrob si objekt changes: EditDataItem[], použij saveChanges()
      • udělej si jednoduchou funkci která stáhne aktuální item přes fetchFreshItem a přidá první volný tag wikimedia_commons případně wikimedia_commons:2 atd. s hodnotou File:... nahraného souboru.

• screen 4:

  • když se to povede ukáže se success screen: viz upload3.jpg + upload3.svg
  • obrázek vlevo už se bude tahat pomocí getCommonsImageUrl()

Obecně:

• na překlady použij hlášky s tags i values (viz replaceTags())
• všechen nový kód co přidáš ať je v src/components/FeaturePanel/UploadDialog - třeba tam dej i podsložku services/mediawiki z toho upload větve, apod
• dej pozor ať nepřidáš nic do src/server
• napiš i jeden happy path integrační jest test, který omockuje APIčka/fetch

obecná pravdila

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:

• State your assumptions explicitly. If uncertain, ask.
• If multiple interpretations exist, present them - don't pick silently.
• If a simpler approach exists, say so. Push back when warranted.
• If something is unclear, stop. Name what's confusing. Ask.

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

• No features beyond what was asked.
• No abstractions for single-use code.
• No "flexibility" or "configurability" that wasn't requested.
• No error handling for impossible scenarios.
• If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

When editing existing code:

• Don't "improve" adjacent code, comments, or formatting.
• Don't refactor things that aren't broken.
• Match existing style, even if you'd do it differently.
• If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:

• Remove imports/variables/functions that YOUR changes made unused.
• Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:

• "Add validation" → "Write tests for invalid inputs, then make them pass"
• "Fix the bug" → "Write a test that reproduces it, then make it pass"
• "Refactor X" → "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

</general guidelines>

## **Refactoring rules:**

1. Move derived value computations into subcomponents – values that are computed in the parent component and passed as props should be moved into the subcomponent that actually uses them.

2. Move context access into subcomponents – instead of the parent component reading from context (via hook) and passing data as props, let subcomponents call the context hook themselves.

3. Move conditional rendering (early return) into subcomponents – conditions like "render X only if Y" should be moved inside component X as an early return null, instead of the parent controlling this.

4. Extract repeated layout structure into a new named component – if there is a complex JSX structure (paper wrapper + stack layout + children) that acts as a container for a group of components, extract it into its own component.

5. Simplify component signatures – reduce number of props; components should receive only minimal input and derive what they need from the data passed in or from context.

6. Add TypeScript types – add explicit TS types for component params where they're missing. Always place the type right before the component definition.

7. Use arrow functions for React.FC.

</component refactoring rules>