6 Commits

Include renames

Author	SHA1	Message	Date
rmancinasandClaude Opus 5	022d1935ad	feat(policy-ocr): set policyTypeId and insuranceProviderId on confirm ... The BACKLOG claimed this was blocked on incomplete `policy_types` rows. Querying the dev database says otherwise: AUTO (1316 policies) and LICENCIAS (306) are both live and healthy, so ANA's two faces were never blocked at all. Three separate things had been conflated. What the parser now emits is a NAME, not an id -- it is a pure function over text and must not reach for the database: ANA AUTOMOBILE -> AUTO ANA DRIVER'S POLICY -> LICENCIAS GMX (both documents) -> MULT `resolveLookups()` turns that into a foreign key at confirm, and does the same for the carrier off the parser's provider code. It resolves, never creates: a missing `policy_types` row means a human deleted it, and silently recreating it would undo that with no record. An explicit `policyTypeId` / `insuranceProviderId` on the confirm payload always wins. GMX is MULT rather than INCENDIO because the caratula's own header reads "Multiple Policy / Home" and the especificación is "PVL Hogar" -- one product, two artifacts. MULT is the live row carrying 769 of them; INCENDIO is fire-only and no policy in the book has ever used it. The parser's provider code is not the carrier's row name, so PROVIDER_ROW_NAME maps ANA onto "ANA SEGUROS", which is where the office's 738 ANA policies already are. --- the actual defect underneath ----------------------------------------- `policies.policyTypeId`, `policies.insuranceProviderId` and `claims.adjusterId` are all ON DELETE SET NULL, and the lookups screen deleted unconditionally. So deleting a lookup row returned 200 and silently blanked the field on every row referencing it -- no error, nothing in the UI. That is how M_EMPR disappeared and left 5 policies with no ramo, found months later only by querying. All three deletes now refuse while the row is in use, naming it and the count ("El tipo de póliza «M_EMPR» está en uso por 5 póliza(s)"). The schema-level `onDelete: Restrict` the spec once recommended is deliberately not used: a raw FK error is not something the operator can act on. `20260815160000_policy_type_repair` cleans up what already happened: - restores M_EMPR and re-points its 5 policies, scoped to `policyTypeId IS NULL AND legacySourceTable = 'm_empr'` so it can never claim a policy blanked for some other reason - merges the duplicate "ANA" carrier (1 policy) into "ANA SEGUROS" (738). OCR is about to start assigning the carrier automatically and two rows would keep splitting the book. Written as joins, not subqueries, so both statements are no-ops when either row is absent -- a subquery form would resolve to NULL and blank the carrier off every ANA policy. - does NOT restore INCENDIO. It is the other row the migration would have produced, but the legacy INCENDIO table has 1 row that never loaded, so the type has zero policies and restoring it would only put a dead option in the type picker. Verified by running the repair against the real broken dev data inside a transaction and rolling back: 5 orphans -> 0, ANA/ANA SEGUROS -> one row with 739, and a second run in the same transaction changes nothing. The DDL half matches `prisma migrate diff` exactly. 186 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 01:28:26 -07:00
rmancinasandClaude Opus 5	d645ba51d3	feat(policy-ocr): read A.N.A. Seguros' two policy faces ... A.N.A. is the Rosarito office's tourist auto book and the second carrier the policy OCR pipeline reads. It ships two unrelated faces, and the split is different from GMX's: GMX ships two documents about one policy, A.N.A. ships two products. AUTOMOBILE (SPECIAL POLICY FOR TOURISTS) insures a car; vehicle table, 9 numbered sections, one LIMIT OF LIABILITY column DRIVER'S POLICY (the office: "licencia") insures up to 5 named drivers; no vehicle at all, 6 unnumbered sections in a different order, SUM INSURED + PREMIUM columns The four automobile products the office sells (amplia / responsabilidad civil, annual / by-the-day) are the same layout with different numbers, so they get one parser rather than four. These are born-digital portal PDFs, so pdftotext -layout returns exact columns and the driver's-policy parser uses that: its two value columns print the same shape (100,000.00 usd. / 18.70 usd.) with no per-row label, so horizontal position is the only thing separating them. The split comes from the header's own offsets, not a constant, because they shift between products; when it can't be read every amount is reported as a sum insured and the reviewer is told, rather than half the premiums being filed as coverage limits. Three things the layout will punish a naive read for: - Each PDF prints its face two or three times (ORIGINAL, AGENT COPY, then a receipt and three travel cards) and the pipeline concatenates every page before parsing. The coverage walk is bounded to the first copy and the driver list to the first POLICY HOLDER block. Unbounded, the licencia returns the same person three times, which reads as a three-driver policy rather than as a bug. - The money row is read positionally off its header. An unused DISCOUNT prints as a bare "-", so "find the six amounts" shifts every value one column left on a discounted policy. - Two five-digit numbers sit in the header band and only one is the agent clave; the agent's street address is "BENITO JUAREZ 25 No.50 INT 38", three lines above the No. cell holding the policy number. Sections 6-8 print a PREMIUM where the others print a limit, so ParsedCoverage gains an optional `premium` (GMX never fills it) and the review table a column: $40 is what legal aid cost, not a $40 liability limit. Exclusions follow the GMX rule and go in the risk label with a null amount -- which matters more here, since a responsabilidad-civil policy prints 0.00 for material damage and the two are identical on the page. Also in this change: - coveragePeriodDays is parsed and written. A.N.A. sells 3- and 4-day policies; Policy.coveragePeriodDays defaults to 365, so a weekend policy left at the default sits in the renewals window a year out. Derived from the dates, cross-checked against the printed DAYS cell, disagreement noted not resolved. - Vehicles and named drivers are parsed, shown read-only in review, and written as Vehicle / InsuredDriver rows on confirm, skipping any already on the policy (VIN then plate; licence then name). The case that forces the skip is confirming a renewal onto an existing policy. Nothing is ever updated or deleted -- a changed plate lands as a second row for a human. - Batch.provider is set from what the parsers actually claimed instead of being hardcoded "GMX", so a mixed upload is labelled as mixed and the header can never contradict its own documents. PolicyDocument.documentType follows the same rule (was hardcoded GMX_POLICY). - matchNote becomes TEXT. It was VARCHAR(191) and the note trail was sliced to 190 chars, which cut the tail notes -- the "could not read X" ones. - The policy detail page renders an array coveragesJson as a table. Both shapes have always been possible there, but the object renderer was the only one, so an OCR-confirmed policy showed a row per array index labelled "0", "1", "2" with [object Object] as the value. ANA makes that routine. GMX is untouched behaviourally; its two parsers now spread a shared empty base instead of listing every null field. 29 new parser cases against verbatim pdftotext output of three real ANA PDFs, 53 in the suite. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 01:09:16 -07:00
rmancinasandClaude Opus 5	14c4d44acb	docs(policy-ocr): vigencia/agente/prima are keyed in by hand on the PVL layout ... Confirmed with Luz, who handles GMX policies at the office: the three fields the especificación does not carry are entered manually. The review screen already supports it — all three are editable and `postPremium` enables off the typed premium, so no code change was needed. The parser's note said "esos datos están en la carátula de la póliza", which now sends the reviewer looking for the wrong document. It says "captúrelos a mano" instead, and names the consequence of leaving the vigencia blank: `Policy.policyTo` is nullable and the renewals window filters `policyTo: { gte, lte }`, so a policy confirmed without one never matches and never gets a renewal notice — silently, permanently, with nothing downstream erroring. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 00:20:09 -07:00
rmancinasandClaude Opus 5	45be0ad77d	feat(policy-ocr): read GMX's Spanish PVL especificación layout ... GMX ships two unrelated documents for the same policy and the office downloads both from the same portal. The parser only knew the English caratula, so a `…-CondicionesParticulares.pdf` parsed to an almost entirely empty row — including the policy number, which the matcher needs. `parseGmx` becomes a dispatcher over `parseGmxCaratula` (unchanged behaviour) and the new `parseGmxEspecificacion`. Both still report `provider: "GMX"`: the matcher keys on the policy number alone and must not care which artifact was uploaded. The especificación has no tables. Coverages are found by anchoring on `Límite … Responsabilidad:` and walking backwards for the heading, where a heading is a short line *preceded by a blank line* — length alone cannot tell one from the wrapped tail of the paragraph above it, and without that condition coverages get named after the last word of the preceding prose. Also fixed, both pre-existing: - The policy number's group widths are not the same across the two families (`007-037-…-0000-02` vs `07-037-…-00000-01`). The pinned-width regex is replaced by a shape, so both read. - The caratula's ZIP fallback pushed a note saying it had read the ZIP from the address, then never assigned it. Verified against the full ten-page real document: all 17 coverages, amounts, deductibles and the excluded earthquake section match what is printed. 24 parser tests (was 8), four of them regressions for ways this layout can silently attach the *wrong* value rather than none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 00:10:26 -07:00
rmancinasandClaude Opus 5	ec139737be	docs: as-built reference for the statement OCR capture ... Gives receipt capture the same treatment policy OCR just got: a doc that records what is in the code, separate from the spec that records what was designed. RECEIPT_CAPTURE_SPEC.md §2 had accumulated three BUILT notes totalling ~120 lines of findings, which is the right place for the evidence but the wrong place to look up how the matcher picks a column. docs/STATEMENT_OCR.md covers the pipeline, the OCR seam and its text-layer-first rule, all eight parsers and the ordering constraints between them, the matcher's two governing rules and the scopedRefField table, confirm-through-BillingService, the learning write-back, and the API surface. Weight goes to the things that are load-bearing and invisible from the code shape: brand detection must run to completion before layout because Tijuana bills predial and zona federal off the same treasury header; scopedRefField is exported because three call sites must agree or a reference gets learned into a column nothing searches; FEDERAL_ZONE's accountNumber holds a peso amount, so it fails the null-guards as well as the lookup; a misread `$` is the dangerous failure, not a missing one. Also records that CFE/CESPT/Telnor have no unit suite — they predate the gas/predial extension and were only verified end to end. Cross-linked from the spec, POLICY_OCR.md, PLAN.md, README and RESUME.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 13:02:14 -07:00
rmancinasandClaude Opus 5	872a661051	docs: document policy OCR capture, the feature no spec proposed ... Policy OCR shipped 2026-08-01 (5e9cb12) and was documented nowhere. It is not in INSURANCE_FEATURES_SPEC.md because it did not come from that meeting — it came out of building the utility statement OCR pipeline in RECEIPT_CAPTURE_SPEC.md §2 and noticing the same shape fits carrier policy PDFs. A reader had no way to find that lineage. New docs/POLICY_OCR.md covers it end to end, with weight on the three things that are not obvious from the statement side: - **One PDF = one policy.** Statements arrive bundled one customer per page, so there a page is a document. A GMX certificate is one policy across two pages, so the pages are concatenated and the parser runs once per file — which is why `pageNumber` is a file ordinal and `storageKey` is the source PDF, not a page image. - **The GMX certificate carries no premium at all** — it lives on a separate recibo PDF. Hence the null-preserving confirm and the double-gated ledger write. - **OcrModule was extracted out of StatementsModule to make this possible**, and that was blocking rather than cosmetic. Cross-referenced from RECEIPT_CAPTURE_SPEC.md §2 (where it came from), INSURANCE_FEATURES_SPEC.md (which never proposed it, and whose §4 carrier API it partly overlaps), PLAN.md step 11, README and RESUME.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 12:56:25 -07:00