Trei probleme legate, gasite testand cu capturi reale.
1. RASPUNSURI GENERICE. Cand raspunsul nu era in documente, modelul primea
oricum top-3 chunk-uri si compunea ceva plauzibil — utilizatorul pleca cu
impresia ca a primit ajutor. Acum, daca nu avem acoperire, modelul nu mai e
intrebat deloc: intrebarea pleaca la suport, cu referinta (M-260831-A1B2) si
confirmare onesta — "am trimis" doar daca notificarea chiar a plecat, altfel
"am inregistrat, dar nu am putut trimite". Jurnalul se scrie intotdeauna, in
~/.maria-bridge/escalations/, si se vede in dashboard. Daca a fost o captura,
imaginea insasi se retrimite la suport (endpoint nou /send-image, limitat la
MEDIA_DIR).
2. ORDONARE (rank.py). Un prag pe cosinus nu putea decide "avem raspunsul?":
masurat pe indexul viu, intrebarile bune dau 0,600-0,816 si cele straine
0,534-0,685 — intervale care SE SUPRAPUN. Lipseau codurile: ORA-01722, D406,
CIF sunt tokeni exacti pe care cautarea semantica ii topeste. Acum se ordoneaza
de doua ori — embeddings si BM25 — si se fuzioneaza clasamentele (RRF), iar
decizia de acoperire se ia pe dovezi: cosinus mare, sau cosinus de mijloc cu o
fractiune din termenii distinctivi gasita chiar in chunk-uri. Fractiunea conteaza:
cu un singur termen, "cum imi resetez parola de la Windows" trecea drept
acoperita fiindca "parola" apare in documente.
Pragurile sunt masurate, nu alese: ops/calibrate-rank.py ruleaza un set de cazuri
pe indexul real si matura grila. 15/15 la strong=0.70 weak=0.58 ratio=0.5.
3. DICTIONAR DE ERORI ORACLE. 29 de erori uzuale, scrise pentru utilizatorul din
fata aplicatiei: ce inseamna, ce poate incerca singur, cand sa sune. Fara nume
de servere, IP-uri sau pasi de administrare — Maria e chatbot pentru clienti.
Fisierul din git e SAMANTA: depozitul e oglinda Drive-ului, deci trebuie pus in
document_store ca sa nu dispara la sincronizare.
Pe drum, doua lucruri gasite in log:
- fiecare mesaj din self-chat sosea de DOUA ori, pe @s.whatsapp.net si pe @lid,
deci Maria raspundea de doua ori. Dedup pe key.id in punte.
- reindexarea reface toate embeddings-urile (~7 s fiecare pe CPU): adaugarea unui
document la 170 de chunk-uri insemna 20 de minute. Acum refoloseste vectorii
chunk-urilor nemodificate din indexul precedent, fara vreun fisier nou de stare.
Textul OCR se logheaza acum INTEGRAL, cu interogarea de cautare si sursele alese
cu scorurile lor — fara asta un raspuns gresit nu se poate explica: nu stiai daca
a citit prost captura sau a cautat prost in documente.
6 fisiere de test noi/extinse, 68 pass (de la 42).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Doua lucruri cerute de utilizator, ambele pe acelasi drum: sa poti lega
puntea fara sa ai un ecran de scanat, si sa poti trimite Mariei o poza cu
eroarea in loc sa transcrii mesajul.
Asociere prin cod de 8 caractere (alternativa la QR):
- endpoint-ul /pair exista, dar nu era folosibil: fara `browser` explicit
WhatsApp refuza codul, iar dupa introducerea lui corecta serverul cere un
restart (515) care consuma din bugetul de reincercari si putea opri puntea.
Acum descriptorul e Browsers.ubuntu('Chrome') si restartRequired reconecteaza
imediat, fara sa numere.
- codul are TTL de 3 minute, iar /status il da doar cat timp e valabil —
un cod expirat afisat in dashboard trimite omul sa tasteze degeaba.
- dashboard: camp pentru numar + buton, in acelasi card cu QR-ul.
Imagini cu erori (capturi de ecran):
- puntea descarca imaginile in ~/.maria-bridge/media/ (imageMessage sau
document cu mimetype image/*, si prin ambalajele efemer/"vezi o data" —
fara despachetare pareau mesaje fara continut si se aruncau tacut).
- rag/ocr.py: tesseract ron+eng. Modelul de raspuns e strict text, deci OCR
nu e o optiune de calitate, e singura cale.
- cautarea in index merge DOAR pe liniile care arata a eroare; o fereastra
intreaga de meniuri si totaluri dilueaza embedding-ul si scoate chunk-uri
fara legatura. Modelul primeste captura intreaga, marcata ca text OCR.
- capturile se sterg imediat dupa citire (pot contine date de client).
- cand nu se citeste nimic si nu exista legenda, Maria cere textul erorii
in loc sa raspunda in gol.
16 teste noi (42 in total). install.sh verifica tesseract; README documenteaza
ambele metode de asociere si drumul unei capturi.
Separat, in docs/chatboti-si-punti.md: chatul "Eu" e vazut de AMBELE punti de pe
numar. Puntea lui Echo (LXC 110) e asociata ca dispozitiv :11 al aceluiasi cont,
momentan nelegata dar pornita — daca se reasociaza, raspunde in "Eu" langa Maria.
Notat si ca serviciile lui Echo sunt unitati de UTILIZATOR: `systemctl is-active`
ca root raspunde "inactive" desi botul ruleaza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Dupa asocierea de azi, puntea nu raspundea la niciun mesaj desi `connected: true`
si consumer-ul rula. WhatsApp livreaza self-chat-ul pe conturile noi cu un JID de
tip LID (`51947713372214@lid`), nu cu `<numar>@s.whatsapp.net`, iar filtrul
`TEST_MODE_SELF_CHAT_ONLY` compara doar cu al doilea — deci arunca tot.
- `ownLid` calculat din `sock.user.lid` (cu rezerva pe `creds.me.lid`), fara
sufixul de dispozitiv: credentialele au "51947713372214:13@lid", dar
remoteJid-ul mesajelor vine fara ":13".
- `isSelfChat` accepta acum ambele formate.
- Logul de conectare si `/status` arata si LID-ul.
Cauza pentru care a fost greu de gasit: mesajele respinse dispareau fara nicio
urma. Acum fiecare motiv de respingere se logheaza (nu e self-chat, fromMe in
afara self-chat, fara continut text), cu JID-urile comparate. Exact linia asta a
aratat problema in 30 de secunde:
[whatsapp] ignorat (nu e self-chat): remoteJid=51947713372214@lid ownJid=40723197939@s.whatsapp.net
Verificat live: "token efactura expirat" -> preluat, cautat in RAG, raspuns trimis.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4uzvgm7AyJch5WH8QHRhY
Drop the standalone maria-dashboard.service — one common panel now
controls both bridges, at the operator's request. discord-bridge's
dashboard/api.py gains a Maria section (fixed-unit start/stop/restart
for maria-whatsapp/maria-rag, WhatsApp status+QR proxy, document CRUD,
reindex, Drive sync trigger, log tail) reached via subprocess/HTTP —
no cross-module imports, to avoid colliding with discord-bridge's own
`config` module name. index.html gets a matching "Maria — WhatsApp +
RAG" section. maria-whatsapp-bridge loses its dashboard/ folder and
DASHBOARD_* env keys; install.sh/README point at the shared panel.
Co-Authored-By: Claude Agent <noreply@anthropic.com>
Move the /tmp prototype (Baileys bridge + RAG consumer) into git as a
proper sibling project to discord-bridge/: own systemd --user units
(whatsapp bridge, rag consumer, dashboard, periodic Drive sync timer),
a filesystem document store with a stdlib control dashboard (start/
stop/restart, document CRUD, reindex, Google Drive sync via rclone),
and an idempotent ops/install.sh following the same conventions.
Co-Authored-By: Claude Agent <noreply@anthropic.com>
