# Libreria componenti — porta prodotto

La libreria **non** vive dentro l’esame. È una porta a sé: pagina `/library` + API `/api/library`. L’analisi *usa* la libreria; non è l’unico modo per riempirla.

## Flusso

```text
PDF + MPN + kind (ic | passive_part | simple)
    ↓
POST /api/library/datasheets
    ↓
blob MD5 + ref MPN
    ↓
scheda componente
    IC            → library/inbox/{mpn}.json   (niente pintable inventata)
    passive_part  → library/passives/{mpn}.json
    simple        → library/models/{mpn}.json
```

Nessun progetto, nessun `MODE=run` / `MODE=pcb`. Stesso store `library/datasheets/{blobs,refs}`.

`library/extracted/` si scrive **solo** con pintable valida (`library_gate`: ≥2 pin, almeno un nome). PUT `/api/library/components/ic/{mpn}` promuove inbox → extracted.

Pintable IC: `library_gate` rifiuta pintable vuota o senza nomi (niente stub in libreria condivisa).

## Cosa non è

- Non è admin/Clerk/JWT (non si tocca auth).
- Non è DRC, non è FEM.
- Non inventa pin dal PDF. L’LLM prelim resta un mestiere a parte; la scheda c’è comunque.
- Non sostituisce `library_has_*` usati dalla pipeline (`library_has_extraction` resta falso finché non c’è pintable).

## Test

`tests/library/` — catalogo, alias MPN, import PDF senza progetto (scheda IC in inbox, passivo in passives), GET/PUT scheda, promozione pintable, rifiuto PDF non valido / kind ignoto.