Sprint 6 — Cross-validation visual + hardening da Sprint 7

[lucasjosee]

Objetivo

PR aberto para viabilizar o review automatizado (/code-review ultra). Contém os dois commits que ainda não estavam no origin.

Commits

• 71f6b9e — feat: implement visual cross-validation and sprint 7 hardening
• b1e52af — docs: record current MVP status and remaining work

Escopo

68 arquivos, +4.178 / −1.513.

Backend

• Módulo diagnosis/ completo (novo): service, repository, schema, controller, rotas e 3 arquivos de teste
• POST /api/v1/diagnosis/cross-validate — segunda opinião do LLM multimodal, ancorada no resultado do CV local
• sync.service.ts — guard de reconciliação: payload offline antigo não sobrescreve cross-validation já em estado terminal
• Ajustes nos providers Claude e Gemini
• scripts/audit-s3-security.ts — validação dos 4 controles de Public Access Block

Frontend

• app/camera.tsx (+606) — máquina de estados da cross-validation na UI (PENDING/CONFIRMED/ENRICHED/DIVERGENT/SKIPPED)
• lib/crossValidationService.ts (novo) — upload presigned + chamada + persistência local
• lib/diagnosisFeedbackService.ts (novo) — feedback human-in-the-loop com opção de escolher a opinião do LLM
• db/security.ts (novo) + db/sqlite.ts — gate de boot do SQLCipher (falha fechado, sem fallback em memória)
• db/sqlite.ts — migration v5 com os campos de cross-validation
• lib/secureStorage.ts — bloqueio de storage web fora de __DEV__

Pontos que merecem atenção no review

• Máquina de estados da cross-validation em camera.tsx, dentro de um arquivo de 1.969 linhas
• Guard de reconciliação em sync.service.ts — regressão ali causa perda de segunda opinião
• Idempotência por diagnostic_local_id + usuário autenticado
• Checagem de posse do image_s3_key (prefixo diagnosticos/{userId}/)
• Tratamento de 504 LLM_TIMEOUT e 502 LLM_UNAVAILABLE

Nota

Não mergear antes do review. Dívida estrutural pré-existente (modelos mortos em assets/, ausência de migrations no backend, WebDatabaseDriver) está fora deste diff e será tratada em mudanças próprias.

🤖 Generated with Claude Code

[lucasjosee]

Claude Code review — 7 finding(s)

normal — frontend/app/camera.tsx:283-311

Retaking a photo leaves the previous diagnostic PENDING in fila_diagnosticos. persistDiagnosticAndStartCrossValidation() (camera.tsx:375) now INSERTs a row immediately after inference, but handleResetCamera (camera.tsx:466) and the reset block at the top of processDiagnostic (camera.tsx:270-280) only clear React state — no DELETE. On the next runFullSync, every abandoned capture is uploaded to the server. Fix: DELETE the row (and cancel any in-flight cross-validation upload) whenever the user retakes.

normal — frontend/lib/syncService.ts:101-112

Special diagnostics (Saudável/Fitotoxicidade) are persisted with doenca_id = NULL in fila_diagnosticos, and syncService.ts forwards that null straight into ai_result.doenca_id, which the server's Zod schema requires to be z.string().uuid(). A single such row poisons the whole batch — Zod .parse() throws on the first invalid item, Fastify returns 400, and up to 49 valid diagnostics riding in the same request never sync. This is pre-existing, but the PR meaningfully worsens it: now runs on every capture (fire-and-forget), so every online capture of a healthy or phytotoxic leaf becomes a permanent poison item in the sync queue. Fix: filter specials out of the payload before syncing (or don't insert them into the queue in the first place), or make doenca_id nullable server-side with a sentinel for specials.

normal — backend/src/modules/sync/sync.service.ts:20-49

The sync endpoint (backend/src/modules/sync/sync.service.ts) accepts item.image_s3_key verbatim on both the INSERT branch (line 75) and the newly added UPDATE branch (line 36), while the sibling cross-validation endpoint and the PR description both require image_s3_key to start with diagnosticos/{userId}/. This lets an authenticated user B poison their own diagnostic row with a key pointing into user A's prefix (via a leaked key), bypassing the ownership invariant this PR is explicitly claiming to establish. Fix by applying the same startsWith(diagnosticos/${userId}/) check inside syncDiagnostics (per-iteration or as a schema refinement bound to the JWT sub).

nit — frontend/lib/crossValidationService.ts:59-88

The try/catch in crossValidateDiagnostic (lib/crossValidationService.ts:51-88) wraps both api.post and the local dbDriver.execute UPDATE, so any error thrown by the SQLite UPDATE (realistic case: FK violation on llm_doenca_id when the local catalog is stale — migration v5 declares REFERENCES doencas(id) and initDatabase sets PRAGMA foreign_keys = ON) is coalesced into CrossValidationRequestError('LLM_UNAVAILABLE'). camera.tsx then calls markCrossValidationSkipped(localId, 'LLM_UNAVAILABLE'), and because sync.service.ts guards CONFIRMED/ENRICHED/DIVERGENT against overwrite, the client shows SKIPPED permanently while the server retains the real second opinion. Fix: move the DB UPDATE outside the try/catch (or wrap it in its own catch) so DB failures do not masquerade as LLM failures.

nit — frontend/db/sqlite.ts:530-549

Migration v5 backfills every pre-existing row in fila_diagnosticos with cross_validation_status='PENDING' because SQLite's ADD COLUMN ... NOT NULL DEFAULT 'PENDING' fills the default into all existing rows. Those legacy diagnostics predate cross-validation and will never be processed by the new flow, so when syncService.ts later ships them (the r.cross_validation_status ?? 'SKIPPED' fallback resolves to 'PENDING', not null), they land server-side as 'PENDING' indefinitely — semantically they should be 'SKIPPED'. Fix: use DEFAULT 'SKIPPED' or run UPDATE fila_diagnosticos SET cross_validation_status='SKIPPED' WHERE cross_validation_status='PENDING' right after the ADD COLUMN and before bumping user_version.

nit — backend/src/modules/diagnosis/cross-validation.service.ts:85-100

Idempotent retry loses llm_doenca_nome when the LLM names an off-catalog disease for a DIVERGENT result. The first response returns the raw LLM string via the catalogDisease?.nome ?? result.llm_doenca_nome fallback, but saveResult never persists that name; on retry, the early-return path re-derives the name from findDisease(record.llmDoencaId) which is null, so the same request returns null on subsequent calls. Fix by either persisting llm_doenca_nome or normalizing the first response to null when the disease is off-catalog so both paths agree.

nit — backend/src/modules/diagnosis/cross-validation.repository.ts:51-65

createPending() writes latitude=0, longitude=0 (Null Island — a valid GPS coordinate in the Gulf of Guinea) when the cross-validation endpoint is called before Store & Forward sync (backend/src/modules/diagnosis/cross-validation.repository.ts:56-57). The normal path self-heals because sync.service.ts rewrites lat/lng unconditionally when the offline batch arrives, but any diagnostic whose sync never lands (crash, uninstall, extended offline before the sync batch runs) is permanently mislocated. Fix by accepting an optional location in the cross-validate payload or making latitude/longitude nullable until the sync hydrates them.

---

Generated by Claude Code