66 Commits

Include renames

Author	SHA1	Message	Date
rmancinasandClaude Opus 5	c6feae9522	fix(customers): the customer file's balances are the statement's balances ... The /clientes/:id ledger card is titled "Estado de cuenta" and links straight to the statement, but its per-line tiles came from a groupBy with `voidedAt: null` and nothing else — no balance floor, no source exclusion, no outstanding rule. It was a raw lifetime sum, double-counting the pre-cutover history that each BALANCE FORWARD row already absorbs, and the card said so in its own footnote rather than being fixed. Importing prior periods turned that from wrong into badly wrong. Every closed year is now also held as its own tagged copy, so an unfloored sum adds each one a second time on top of the opening balance that contains it. NUMid 501 read -7,119.29 before the archives landed and -15,270.59 after, against a true -10,715.29 — the gap being exactly the 2024 and 2025 closing balances. The tiles now take the same three rules the statement takes, and agree with it for all 600 customers sampled. Two places needed the archives excluded explicitly, because the balance floor does not do it: - A customer whose newest BALANCE FORWARD lives inside an archive floors at that archive's own January 1, so every row of it clears the floor. One customer, 28 rows. - The archives are not cleanly bounded. datos2@2024 carries rows dated 2022, 2023, 2025 and one in 2026; datos2@2025 two more. Those clear any floor and land in the current year next to the live ledger's own copy of them. That second point is a defect in 93f8171, not only in this card: statement() and the edo-cuenta-datos report were both filtering the current period by source and date without excluding the period tags, so four customers on the dev book would have read a closed year's rows as current. Both are fixed here. The portal already had it right. The year's movement list on the card keeps showing every non-archive row, as before — it is a list of what happened, not a balance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 16:19:06 -07:00
rmancinasandClaude Opus 5	93f817158e	feat(statements): a year selector, reading each closed year from its archive ... The statement has been pinned to the calendar year in progress since bc74905. Now that prior years are imported, the year becomes a choice: the current one still reads the live ledger, and any earlier one reads that year's archive. A period is selected by its `datos2@YYYY` tag, not by a date range. That is how legacy addressed it — one table per closed year, `SELECT ... FROM `2025`` — and the distinction is load-bearing: the archives carry rows dated a day or two into the following January, so a date window would file them under the wrong year in one direction and drop them in the other. Two things the archive branch must not inherit: - The balance floor. It exists to stop a later opening balance double-counting the history it summarizes; for a period view that history is precisely what is being asked for, so applying it would return nothing at all. - The cash-source exclusion. It reproduces legacy's DATOS2-only datosfreak, and an archive is DATOS2 rows already. No fold into an opening balance either — the archive holds its own Jan-1 BALANCE FORWARD row, which is the carry, listed exactly as legacy listed it. The current period stays deliberately open-ended at the top. A period is a table in legacy, not a date range, so whatever the office filed in it belongs to it, including the future-dated rows the live ledger carries out to 2028. Bounding it would hide them from every view. `availableYears` reports the periods a customer actually has, so the picker never offers a year that would render empty — "you had no activity in 2019" is a different claim from "2019 was never imported", and only one of them is true. The selector hides itself entirely for a customer with a single period, and a year outside the list is a 404 rather than a silent fall back to the current one. The same period rule lands on the printable twin (edo-cuenta-datos gains a "Periodo (año)" parameter) and on the portal, where fetchLedgerRowsPlatform was also filtering by date with no source exclusion at all — so period=2025 would have returned the archive rows on top of that year's EFECTIVO receipts, counting every prior-year payment twice. The portal's allowlist is now built per data source and validated at the point of use: DreamHost holds the current year plus one archive table, the platform holds however many were imported, and fetchLedgerRowsLegacy interpolates the period as a table name, so a platform-only year must not reach it — including on the fallback path when the platform is unreachable. Left alone: the /clientes/:id ledger card still shows the current year. It reads transactionYear off the customers endpoint rather than the statement, it is a summary that links to the full statement, and giving it its own year state would duplicate the page it links to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 15:48:25 -07:00
rmancinasandClaude Opus 5	29ae9fa5bc	feat(migration): import prior periods so a closed year can be shown on its own ... Legacy ran a year-end corte: it summed the closing year, wrote that total back as each customer's Jan-1 BALANCE FORWARD, and started the next year clean. The platform inherited those opening rows but never the years behind them — only the current year's charges were ever staged, so every prior year held receipts and no bills. Rendering one would have shown a customer credits with nothing owed against them, which is worse than showing nothing. The archives are whole-database Access snapshots named for the period they hold, so `2025.accdb` is discovered by filename, staged, and loaded through the existing DATOS2 branch — a snapshot's `datos2` is the identical shape, one year older. Only the ledger and DATGRAL come out of a snapshot; everything else in it is a year-stale copy of a live table. The cash side is deliberately left behind: EFECTIVO is a lifetime journal, so the snapshot's copy is a subset of the live one and importing it would double-book every prior-year receipt. Period travels with the row, in legacySourceTable as `datos2@2025`. That tag, not the date, is what a year view should filter on: the archives are not cleanly bounded (2025 carries ten undated rows and two dated into 2026) and legacy never filtered by date either — its reader is `SELECT ... FROM \`2025\``. The tag also keeps legacyId safe, since it is a positional ordinal that restarts at 0 in every archive and would otherwise collide row-for-row. Two guards, because attaching a prior year by NUMid is the one thing here that can go quietly wrong: - Reissued numbers are skipped, not imported. Comparing each archive's DATGRAL against the live one, 13 names moved since 2025 and 40 since 2024; most are the same customer re-described, but a few are a different household holding a recycled number, and filing their ledger under the new owner would show a stranger's charges. Sharing any word of three or more characters separates a rename from a reissue. Names are compared legacy-to-legacy: `customers.name` has been through blank-name recovery, and comparing to it reported 121 drifts where there are 13. - Every period is checked against the corte identity it must satisfy — SUM(year N) == BALANCE FORWARD(N+1) — and the result is reported per year. A truncated export, a file dropped under the wrong year, or a botched customer match all fail loudly here. 2025 reconciles 1,159/1,167 (99.3%) and 2024 1,144/1,156 (99.0%); the recycle guard raised 2024 from 98.2%. Balances are untouched: BALANCE_FLOOR_JOIN floors on the newest BALANCE FORWARD per customer, so rows behind it are already excluded from every balance read. Uploads go through the existing ingest endpoint, allowlisted by an anchored `AAAA.accdb` pattern that also keeps a caller-supplied name inside the ingest directory. The Operaciones page grows an entry point for an archive that has no row yet, reading the period off the chosen file's own name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 15:26:58 -07:00
rmancinasandClaude Opus 5	9929a9a3ac	feat(customers): the customer file's estado de cuenta follows the same year rule ... `/clientes/:id` carries its own "Estado de cuenta" card, fed by CustomersService.detail rather than by BillingService.statement, so the previous commit left it reading the old way: the last 100 movements of all time, newest first. Two pages, one label, two orders. It now covers the current calendar year oldest-first, like the statement and like the sheet the office prints. The `take: 100` is gone with it — capping a descending list hid the oldest rows, but capping an ascending one would hide the newest, and a single year is small (365 rows for the heaviest customer in the book). The per-domain totals above the list are untouched and still historical: they are an unfloored groupBy, so they double-count every customer's opening balance. That is a separate bug from this one; the card now says out loud that those figures are lifetime, not this year's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 20:21:51 -07:00
rmancinasandClaude Opus 5	bc749055e7	feat(statements): scope the estado de cuenta to the current year, oldest-first ... The office's EDO CUENTA sheet has always been a *year* statement: a balance forward line dated January 1st, then that year's movements in the order they happened. Both of ours read the other way — every year the customer ever had, newest first — so staff comparing the screen against the printed sheet were reading two different documents. Movements are now bounded to the calendar year and returned ascending, on the screen (/estado-cuenta/[id]) and in the printable `edo-cuenta-datos` report alike. Earlier rows are dropped from the *list*, not from the arithmetic. The balance floor normally lands on January 1st already, so for most customers nothing extra is dropped at all; when it doesn't — a customer the last legacy publish skipped, or one that never had an opening balance — the earlier rows are folded into a carried balance and shown as a single "saldo anterior" line. Discarding them instead would restart every balance at zero on January 1st and nothing would throw; the numbers would just be wrong, which is how the double-counting bug survived for years. `opening` is exposed per currency and per business line so the totals still reconcile against the last running balance printed. Two things the report was missing on its own are fixed while it is being touched, since it must agree with the screen to the peso: - it never applied the balance floor, so every pre-cutover row was counted twice — once inside the opening balance and once as itself; - its source-table exclusion used a bare `notIn`, and `NULL NOT IN (...)` is NULL rather than true, so every app-captured row (which has no legacySourceTable) silently vanished from the printout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:45:15 -07:00
rmancinasandClaude Opus 5	75e9f582b4	feat(policy-ocr): store the IVA A.N.A. already prints ... The parser has been reading A.N.A.'s `TAX` cell since the ANA layout landed, but `ParsedPolicy` had nowhere to put it, so the figure only ever reached a review note and every OCR-confirmed policy was written with `tax` null — even though the paper states it. `TAX` now flows parser -> `extractedTax` -> `Policy.tax`, alongside the premium fields beside it. GMX stays null: its certificate carries no premium at all, so there is no tax on it either. The other two cells stay out, for reasons worth keeping: - `LOCAL TAX` is a separate levy with no destination column, and summing it into `tax` would produce an IVA that no longer divides back to a rate — which is the whole reason to store the figure. It reads 0.00 on every policy seen so far; a non-zero one now raises a note saying the total will not reconcile, instead of quietly inflating the IVA. - `DISCOUNT` has no column and prints as a bare "-" when unused, which is what makes the row positional rather than "find six amounts". `taxRate` is left null by confirm. A.N.A. prints the amount, not the rate, and back-dividing it would mint a rate the document never stated; the capture form resolves one from the line of business instead. The review screen gains derecho de póliza next to the new IVA field. It was already parsed and already written on confirm, but never shown — and an IVA with no fee beside it leaves the reviewer unable to see why premium + fee + tax equals the printed total. The spec's assertion moved off the note and onto the field, plus a check that the row reconciles: 298.61 + 30.00 at 8% is 26.29, totalling 354.90. That agreement is what proves the positional mapping landed on the right cells rather than merely on six numbers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 07:38:23 -07:00
rmancinasandClaude Opus 5	48e01ddd21	feat(policies): capture the full premium breakdown ... The capture form only ever had prima neta, derecho de póliza and comisión. The Access form it replaces has seven figures, and the four that were missing are the ones that make a policy paid in installments add up. Adds recargo, IVA, prima total and forma de pago to the policy header, the same breakdown per installment, and a per-line-of-business IVA rate. IVA and prima total are the only derived figures: base = prima neta + recargo + derecho de póliza IVA = round(base * tasa) total = base + IVA The recargo is inside the taxable base. That is not a guess — policy 7006785 prints IVA 52.03 on 610.86 + 8.55 + 31.00, and leaving the recargo out gives 51.35, which matches nothing on the page. Both of its money rows are asserted in premium.spec.ts. The recargo itself is never derived: the carrier quotes it, so staff key it in, and the field is disabled on ANNUAL/SINGLE. Both derived figures are stored rather than recomputed on read, and stay editable, because the printed policy is the record of truth and a later rate change must not silently restate what was issued. The rate lives on PolicyType (seeded to 0.08, editable in Catálogos), which is the legacy one-row IMPUESTOS / IMPUESTOS_AUTOS tables made configurable. The rate applied is stamped on the policy so an old one reads back at its original rate. Per-installment, not two fixed slots on the header: a policy split into several exhibiciones prices each payment separately — that is why the Access form drew the money row twice — and a trimestral policy needs four, which the Access layout could not hold. Also fixes two losses in the ETL, which is how these went missing: - `forma_pago` was marked consumed by the coverage sweep and then never written to any column, so FORMA PAGO existed nowhere in the platform. - `recargo` and the whole second money row fell into `coveragesJson` as loose strings, mislabeled as coverage amounts. transform_policies.py now writes all of it directly; backfill_policy_premium_breakdown.py recovers it on a database that must not be re-imported, and strips the migrated keys back out of coveragesJson. Both are COALESCE-only, so a figure a human has corrected in the app wins. IVA and TOTAL are NOT backfilled: they were unbound calculated controls on the Access form, never columns, so there is nothing to recover and every migrated policy reads null until it is edited. The backfill warns on 5 annual policies that carry a non-zero recargo — a contradiction that predates this change and is left for a human, not silently corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 00:24:22 -07:00
rmancinasandClaude Opus 5	4f2f064955	fix(web): OCR batch review returns to capture, not the policy list ... "Volver a pólizas" on /polizas/captura/[id] dropped the reviewer at /polizas, so getting back to the batch queue meant navigating in again. Points at /polizas/captura and reads "Volver a captura", matching the statement review screen, which returns to /recibos. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 13:04:14 -07:00
rmancinasandClaude Opus 5	2f99bd5f98	fix(web): define the layout utilities the screens were already using ... The policy OCR review header read "Para revisarPágina 1700489616· PAMELA DENISE WAGONERLICENCIASANA". `.row`, `.stack`, `.tag`, `.page-sub` and `.state-warn` are used across the app but no rule ever defined them. Without `display: flex` the `gap` those call sites pass does nothing, and JSX drops the newline between sibling elements, so the header's spans concatenated. `.tag` rendered as prose rather than as a chip for the same reason. Defined against the existing design tokens: `.tag` takes `.badge`'s shape, `.state-warn` is the gold sibling of `.state-error`, and `p.page-sub` keeps the block margin while the inline form drops it so a flex row still centres. Also dropped the hand-rolled "· " separator and margin from the OCR header — the flex gap does that now, and the literal dot was left floating in it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 12:58:25 -07:00
rmancinasandClaude Opus 5	81938877ed	feat(policy-ocr): suggest the customer from the printed insured name ... The office books customers surname-first ("WAGONER, PAMELA") and carriers print them given-name-first ("PAMELA DENISE WAGONER"), so the review screen made staff retype a name the parser had already read. Comparing normalized token sets makes the two orderings the same thing. Only on the zero-hit path, where the policy number found nothing and a human has to pick a customer anyway. The suggestions are written to a new `customerSuggestions` column rather than `matchCandidates`, which the review screen reads as policy-number hits, and they never set `matchedCustomerId` or `confident` — matching on `Policy.policyNumber` is unchanged. Two tiers, drawn where the real book has cliffs: EXACT (identical token sets) and PARTIAL (containment, >=2 shared tokens, surname present). Of 1536 customers, 1487 have a distinct token set, so EXACT cross-person collisions are ~0; loosen to surname + first given name and 131 (8.5%) collide, and 185 surnames are shared by 524 customers, which is why one token is never enough and the surname must be printed explicitly. Replaying every book row as a carrier would print it: 97.9% top-ranked correct, 1.2% a different row, all but two of those the same human on a duplicate or variant row. Normalization folds accents (OCR's MUNOZ reaches the book's MUÑOZ), drops initials, Spanish particles, JR/S.A. DE C.V., and any token with a digit — ANA prints the phone hard against the name as `Ph.3102001538`. Names over 8 tokens or 80 characters are refused outright, because GMX's especificación has no field labels and the parser has handed its whole first page over as `insuredName`. Not used for utility statements: there the registrant genuinely is not the customer, so the same trick would be wrong rather than noisy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 12:37:23 -07:00
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	14c6183aa2	feat(deploy): derive the API origin from the page, not from a pinned env var ... The browser hard-required API_ORIGIN, so every move of the server — tailnet today, the 192.168.1.0 office LAN later, a temporary demo domain in between — meant editing the deploy env and redeploying. Worse, an http:// API origin on a page served over TLS is blocked outright as mixed active content, which is what broke the demo on https://jorgecuadros.freakma.com. The browser now derives the origin from window.location the way a PHP app would: same host on port 3001 over plain HTTP, or the same-origin /api path under https (the reverse proxy strips the prefix). API_ORIGIN survives as an optional override for a deployment that genuinely splits the two hosts, and SSR still reads process.env because a derived origin is browser-only. WEB_ORIGIN becomes a comma-separated list to match: one deployment is now reached under several origins, and a credentialed fetch from an unlisted one gets no CORS headers and fails. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 12:55:32 -07:00
rmancinasandClaude Opus 5	2169ffa78d	feat(ops): verify the replica against the master, not just its own status ... Every field the replication card showed was self-reported by the replica, and the two most reassuring ones lie in the same failure. Seconds_Behind_Source reads 0 when the I/O thread is disconnected — with no incoming event there is nothing to measure staleness against — and Replica_IO_Running only says the network thread is alive, not that it is receiving. Two checks that ask the master instead: - GTID drift, folded into the polled status. GTID_SUBTRACT(master, replica) counts transactions the master executed that the replica has not, so a silent disconnect shows up as a number that climbs instead of a lag that stays 0. It also isolates transactions carried under the replica's OWN server UUID — writes that exist nowhere on the master. There are currently 518 of them, residue of the seed dump load; inert while log_replica_updates is off, and a real divergence the day anyone promotes that box. - A full row-by-row comparison behind a button, over the eight tables my.jorgecuadros.com reads. GTIDs prove the replica applied everything the master sent; they say nothing about rows changed here by another route, which is the one failure the rest of the card cannot see. The comparison hashes CONVERT(col USING binary), not CAST(col AS CHAR). CAST transcodes into the connection character set, and the two servers do not agree on it: the client inside the master's container negotiates latin1, the replica's utf8mb4. Every accented character in a Mexican name, street or note then hashes differently and the tool reports a permanent mismatch on exactly the tables that hold free text. Caught by building it and running it — customers.name gave 3344437324815 against 3339150372121 under CAST, and 3339150372121 on both under CONVERT. All eight tables now match byte for byte. Verify is POST and audited despite reading nothing: it full-scans both servers, so a prefetch or a refresh must not be able to start one. Tests cover the GTID interval arithmetic, which is inclusive at both ends and easy to get wrong by one in the direction that hides a gap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 21:38:22 -07:00
rmancinasandClaude Opus 5	17d83291c3	feat(migration): refuse a full re-import that would delete native rows ... A full run_all.py pass truncates and rebuilds every table it owns from the Access extract. That was harmless while the platform was a read-only mirror -- every row came from the extract, so wiping and rebuilding lost nothing. It stopped being harmless once the platform started minting rows Access has never heard of: allocated portal NUMids, customers created in the staff UI, OCR-captured policies, app-booked ledger rows, uploaded documents. REIMPORT is a button in /operaciones, so that was one click away. native_guard.py counts what only exists here and exits 3; run_all.py runs it before the first truncate and stops. Detecting an allocated NUMid needs the staged Parquet -- the customer holds an ordinary-looking (utilities, DATGRAL, '1172') ref, so "customer has no refs" cannot see it and only comparing against the extract can. Missing staging is therefore treated as blocking rather than as "nothing to protect". The guard does not teach full mode to preserve anything: --sync already upserts legacy rows against the existing refs and leaves the rest alone, and rebuilding that inside full mode would re-implement it. --force-full (checkbox in the REIMPORT confirm, recorded in the audit log) deletes them deliberately. Verified against dev: clean before, exit 3 listing utilities/1172 with a synthetic ref present, clean again after removing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 21:01:01 -07:00
rmancinasandClaude Opus 5	6a97242fc3	feat(customers): allocate portal NUMids, with an audit for reusable ones ... Customers created in the staff UI had no NUMid and so could not log in to my.jorgecuadros.com at all: the id is a CustomerLegacyRef row, not a column, and create() deliberately writes none. Allocation is a staff action (POST /customers/:id/portal-access, MANAGER) rather than part of create, because insurance is expected to move to the platform before utilities and an insurance-only customer has no reason to spend a utilities id. The audit that decides which ids are reusable took three passes. "Owns no rows" matches nobody -- migration gave all 1,171 NUMids a property and a transaction. "No transaction in N years" also matches nobody -- every customer carries a synthetic Jan-1 opening-balance row, so everyone looks active this year. Subtracting that row is what makes dormancy measurable, and it leaves 4 never-used ids and 10 dormant ones on dev. Two further traps are encoded in the queries: insurance/DATGRAL is a separate id space that reuses the sourceTable name and runs past 4,000, and ACCOUNT CANCELED is a transaction line type, not an account state -- all 8 customers carrying it have current-year activity. Recycling ships switched off (numid.recycleEmpty, default false). Every reusable id still exists in Access DATGRAL, and a --sync run reassigns refs with ON DUPLICATE KEY UPDATE customerId, so an id recycled before the utilities cutover is silently handed back to its Access owner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 20:04:13 -07:00
rmancinasandClaude Opus 5	fe761e119e	feat(ops): show relay apply progress on the replication card ... Seconds_Behind_Source cannot answer "is it moving?". While the SQL thread works through one large transaction the lag counter holds still — often at 0 — even though the replica is not caught up. The relay backlog does move, and it comes out of the SHOW REPLICA STATUS the panel already runs, so this costs no extra query and no connection to the source. Adds applyProgress(), which reads Source_Log_File / Read_Source_Log_Pos vs Relay_Source_Log_File / Exec_Source_Log_Pos and reports the fetched-but-not- applied byte delta plus a percentage. Both positions are source binlog coordinates, so they are only comparable while the two threads are on the same file; across files the delta is meaningless (positions restart at ~4 in each new file) and is reported as null rather than as a huge negative number. The percentage deliberately stops at 99.99 while any backlog remains — binlog positions are large enough that a real backlog of a few KB rounds to 100% and would render a lagging replica as caught up. Not folded into `healthy`: a non-zero backlog is the normal state of a working replica between fetch and apply, so alarming on it would cry wolf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 21:35:39 -07:00
rmancinasandClaude Opus 5	66d0d071b0	feat(ops): show step progress for reimport and sync jobs ... A REIMPORT takes ~110 seconds and, until now, showed only a scrolling log — there was no way to tell "halfway" from "wedged", which mattered the day one actually did wedge. run_all.py emits "[paso i/N] name" before each step and the API derives progress from the job log. Emitting the marker from the Python rather than having the UI count STEPS itself means the step count is stated in exactly one place; adding a step cannot desync the display. Progress is derived, not stored, for the same reason: the log is already the record of what happened, and a separate counter could contradict it, which is precisely the confusion a progress display exists to remove. While RUNNING, step i is IN PROGRESS rather than finished, so only i-1 count as done. Counting i would show 100% while the final step was still working — and the final step (blob_extract) is the slowest, so the bar would sit at "100%" for the longest stretch of the job. BACKUP and RESTORE are a single mysqldump with no steps and deliberately render no bar; a fabricated percentage would be worse than none. The safety backup that precedes a REIMPORT is likewise named explicitly instead of showing 0%, which reads as stuck. Pinned by job-progress.spec.ts, including the literal line run_all.py emits, so a change to the Python format fails a test rather than silently blanking the panel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 17:53:10 -07:00
rmancinasandClaude Opus 5	dac1f1982f	feat(ops): show read-replica health on the Operaciones screen ... my.jorgecuadros.com serves customer balances from the Oracle VPS replica. A replica whose SQL thread has stopped does not error — it keeps answering, with data frozen at the moment it stopped — so nothing on the customer site looks wrong and the only signal is a customer complaining about a stale balance. This puts the failure somewhere a human sees it. Deliberately does not trust the two fields an operator reaches for first. Replica_IO_Running reports Yes while the SQL thread is stopped, because the network thread keeps downloading binlog it will never apply; verified by stopping SQL_THREAD and watching IO stay Yes. Seconds_Behind_Source reads NULL whenever EITHER thread is down, so the card renders "sin dato" rather than "0 s" — showing zero there would report an outage as perfect health. The problem string is resolved most-specific-first for the same reason. Shells out to the mysql client because the API has no MySQL driver and the image already ships one. --ssl is required (the replica sets require_secure_transport); --ssl-verify-server-cert=0 is deliberate and is NOT the trade-off the website makes: this hop never leaves Tailscale and the replica's firewall admits only this host, so WireGuard authenticates the peer, whereas the DreamHost leg crosses the public internet and pins the CA. The account behind it holds REPLICATION CLIENT and nothing else — it cannot read a single row. REPLICA_DB_* unset is a supported state and renders "no configurada", which is correct in dev and before cutover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 17:22:15 -07:00
rmancinasandClaude Opus 5	89611da202	feat(notificaciones): global send flags + editable schedules ... The "Flags del envío" panel lived inside the Servicios tab and only governed the four bulk jobs. The pólizas half had no debug at all, so there was no way to test a renewal notice without mailing a real customer. The panel now lives in the /notificaciones shell above the tabs and both halves read it. `debug` on the renewal path diverts to the same override inbox as the servicios jobs and deliberately does NOT write the `RenewalNotice` row or advance the sweep's `lastSuccessfulAt` — the customer was not notified, so nothing may gate the letter they are still owed. `ignoreDayRestriction` and `useEmailLimit` stay estado-de-cuenta-only and are labelled as such. Both automatic sweeps are now operator-editable. The renewal cadence was a `@Cron("0 6 * * *")` literal and servicios had no automatic run at all; both now resolve through `NotificationScheduleService`, which stores the cadence in `app_settings` and reinstalls the cron job on save — no redeploy, no restart. Defaults preserve current behaviour: pólizas 06:00 daily, servicios off. A scheduled run never inherits the UI flags; it always sends for real. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 12:23:19 -07:00
rmancinasandClaude Opus 5	a491ef3eed	feat(notificaciones): edit summary recipients in the UI ... NOTIFICATION_ADMIN_EMAILS made "add Beto to the summaries" a redeploy — the wrong unit of work for a list that changes when office staff change. Adds `app_settings`, a key/value table for the configuration staff must be able to change without a deploy, and `SettingsService`, which resolves every key db -> env -> default and reports which of the three a value came from. That ladder is what makes the move safe: a deployment behaves exactly as before until somebody saves in the UI, and the screen can say "this is still coming from the deployment" rather than implying somebody chose it. - new ability `setting:manage` (ADMIN) — deliberately above `notification:send`, since redirecting the audit summaries is how someone would quietly stop them being read - GET/PUT /notifications/settings/admin-emails; read is open to any logged-in user so the UI can display the list, write is gated - resolved per job, not cached at boot, or we would reintroduce exactly the restart-to-apply behaviour being removed - a saved empty list means "nobody" and does NOT fall through to the env, or clearing the field would keep mailing the people just removed Credentials stay in env — see the model doc for where the line is drawn. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 11:58:42 -07:00
rmancinasandClaude Opus 5	33833c3af9	feat(notificaciones): one send log across servicios and pólizas ... Renewal avisos left behind only a `RenewalNotice` row, whose sole job is gating: a row with `sentAt` drops the policy off the pending list. It cannot represent a failed send or a customer with no address, so the Pólizas tab had no "Registro de envíos" to show and a sent notice simply vanished from the list. Renewals now write `email_notification_log` — the same table the four bulk jobs write — as `RENEWAL_NOTICE` / `POLICIES`, with rows for failures and no-email skips too. `RenewalNotice` keeps its gating role unchanged; the two are complementary, not redundant. - extend `EmailNotificationType` (+RENEWAL_NOTICE) and `EmailNotificationServicio` (+POLICIES); `level` now carries the aviso generation on renewal rows, so every reader must branch on the type first (`notificationLevelLabel()` is the one place that lives) - backfill emailed notices (`channel = 'EMAIL'`) into the log; MAIL-channel rows are legacy printed letters and are deliberately left out - extract `NotificationLogService`/`NotificationLogModule` as the single writer, so a feature that sends mail records it without pulling the bulk-job pipelines into its module - `GET /notifications/log` and `/stats` take a comma-separated `servicio` list; each tab reads its own slice. This also fixes the "Omitidos" view, which mapped to no filter at all and showed every row - share one `NotificationLogPanel` between both tabs - pass SES_* / NOTIFICATION_ADMIN_EMAILS through the galactus compose, which was missing them entirely — mail is runtime config, not a CI secret, and the prod image sets NODE_ENV=production so a blank config fails loudly instead of falling back to stdout Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 03:01:03 -07:00
rmancinas	c0cc0d2ac2	feat(renovaciones): send renewal notices from the list, drop manual marking ... The Pólizas tab now sends. Each pending row gets an "Enviar aviso" button backed by POST /renewals/send, which renders, mails and records the notice through the same path the daily sweep uses — so a hand-sent letter is marked exactly like a swept one and drops off the pending list. Sending is now the only way a notice gets marked as sent. Remove the manual "Marcar impreso" / "Marcar EMAIL" buttons and the endpoint behind them (POST /policies/:id/renewal-notices, PoliciesService.markRenewalNotice, MarkRenewalNoticeDto): they wrote a sentAt with no mail behind it, which let the list claim a customer was notified when nothing was sent. sendOne refuses a generation that already has a sentAt (409) so a double click cannot mail the customer twice, and 400s when the customer has no email on file. Sweep and single send share the new deliver() helper.	2026-08-02 02:40:38 -07:00
rmancinas	53a5fe8076	feat(notificaciones): ejecutar todos for servicios jobs ... Add POST /notifications/run-all: runs the four notification jobs (outstanding, payment confirmation, account status, trust confirmation) sequentially with one shared set of flags from "Flags del envío". Sequential rather than parallel — the jobs share the SES transport and account status can self-throttle via useEmailLimit. A job that throws is captured and the sweep continues, so one bad query cannot swallow the other three envíos; the aggregate response carries per-job results plus summed sent/skipped/failed and an errors count. Audited as a single notification.run-all.run entry so one staff click is one audit row. UI adds the button to the flags card, with a confirm when debug is off, and a per-job summary in "Última respuesta".	2026-08-02 02:32:13 -07:00
rmancinasandClaude Opus 5	0332292ae9	fix(notificaciones): merge renewals into one screen, fix MailModule DI ... MailModule's provider used a `useFactory` with no `inject`, so the factory received `undefined` and `new MailService(config)` threw on `config.get`, taking the whole API down at boot. The module also wasn't actually `@Global()` even though both NotificationsModule and RenewalsModule inject MailService without importing it — that would have failed next. Replaced the factory with a plain provider (ConfigModule is already `isGlobal`) and marked the module global. On the web side, mass email and renewal notices were two menu entries doing the same job — telling a customer something by email. They are now two tabs of `/notificaciones` (Servicios and Pólizas), following the Captura pattern: `/renovaciones` still resolves, opening the same screen on its Pólizas tab so existing bookmarks keep working. The notifications page was also the last screen written in raw inline styles, with blue buttons and filter pills that appear nowhere else in the app. It now uses the shared design system: btn-primary/btn-outline, the seg segmented control, card, tx-table, pager, and the servicios/fideicomiso badges. Two supporting fixes found on the way: NOTIFICATION_STATUS_COLORS hardcoded hex instead of the theme's positive/negative/muted vars, and `.small` was referenced in 19 places across the app but never defined in globals.css. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 02:21:51 -07:00
rmancinas	ec0e9c2a5d	Merge branch 'massive-email-notification' into master ... # Conflicts: # .env.example # apps/api/src/app.module.ts	2026-08-02 02:05:36 -07:00
rmancinas	a52e59cbc5	feat(notificaciones): mass email notifications over SES ... Replaces the four legacy PHP scripts under email.notifications/send*.php with a single NestJS module. Four jobs (outstanding payments, payment confirmations, account-status alerts with day-of-week gates, trust payment confirmations) share one MailService modelled on StorageService: env-driven SES client, null fallback in dev with console logging, refuses to send in production when unconfigured. Schema adds email_notification_log (every attempt, sent/failed/skipped) and account_status_history (one row per threshold hit, Job 3). Enums encode the legacy wire shape so external log scrapers keep parsing notificationType keys verbatim. Web adds /notificaciones with four trigger cards, a flags panel, and a paginated log browser. New notification:send ability gates all four endpoints at MANAGER, matching the renewal:send trust tier.	2026-08-02 02:04:14 -07:00
rmancinas	87d8743251	feat(renovaciones): renewal notification emails over SES ... INSURANCE_FEATURES_SPEC §1. The office printed and mailed renewal letters from the legacy CONTROL <ramo> RENEW[2/3] paper log; 91% of policyholders have an email on file, so send the notice instead and keep the paper log as the fallback. A daily cron (06:00 America/Tijuana) sweeps three generations off policyTo — 30 and 15 days before expiry, 7 days after — sends each through SES, and upserts RenewalNotice by [policyId, generation] so a policy is never notified twice for the same milestone. RenewalNotice now records providerMessageId, so a later bounce or complaint webhook can be traced back to the row that sent it. - customers.emailOptOut excludes a customer from every sweep; editable from the customer form - scheduled_job_states holds the sweep's lock and last successful run; the window is widened to cover days the job did not run, so a weekend outage does not silently drop a generation - SES unconfigured is not an error outside production — messages are logged and skipped, so dev and CI never send - /renovaciones (renewal:send, MANAGER+) lists what is pending per generation, runs the sweep by hand, and marks a notice sent by mail for the customers with no email - POST /policies/:id/renewal-notices records that manual mark - the aviso-renovacion report and the emails now share one projection (reports/renewal-letter.ts) instead of two copies of the mapping	2026-08-02 02:00:02 -07:00
rmancinas	3125b52057	feat(ocr): discard abandoned capture batches ... A bad scan, the wrong PDFs or a duplicate upload used to leave a batch sitting in READY_FOR_REVIEW forever, because the only exits were confirm (posts to the books) or rejecting every page one at a time. Add a DISCARDED terminal status to both OCR domains and a single endpoint per domain that rejects every page still pending in one shot. Discarding is refused once anything has landed: statements once a page is POSTED, policies once a page is APPLIED. Those batches did real work and have to be settled page by page. - POST /statements/batches/:id/discard - POST /policy-ocr/batches/:id/discard - shared DiscardBatchCard on both review screens, gated the same way	2026-08-02 02:00:02 -07:00
rmancinasandClaude Opus 5	5e9cb12fba	feat(polizas): OCR capture for insurance policy PDFs ... Mirrors the utility statement intake on the insurance side: a policy_ocr batch/document pair of tables, a GMX parser, a matcher keyed on Policy.policyNumber, and a "Captura" screen under /polizas that proposes policy -> customer for staff to confirm. Lifts the OCR seam out of StatementsModule into its own OcrModule so PolicyOcrModule can inject OCR_PROVIDER without taking on the rest of the statement pipeline; StatementsModule now imports it and binds nothing itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 14:07:29 -07:00
rmancinasandClaude Opus 5	5bce0e4c94	feat(recibos): OCR capture for zona federal (ZOFEMAT Tijuana) ... Adds the ZONA FEDERAL TIJUANA parser to the statement intake, measured against 8 pages of real "Zona Federal Marítimo Terrestre" receipts — the federal maritime-zone occupancy fee the municipality bills on beachfront lots. Provider read on 8/8, amount on 8/8 (each verified against the paper), concession clave on 6/8, period on 8/8, deadline on 2/8. Four things the corpus forced: - Tijuana bills predial and zona federal from the same treasury: same header, same Paseo del Centenario address, same ATB-541201 RFC. Every predial discriminator matches a zona federal page too, so whichever rule is asked first wins it. The only words exclusive to this layout are "Marítimo Terrestre", so its brand rule is asked ahead of all three predial ones — and its structural rule, anchored on the stub's "Derechos de ocupación", ahead of theirs. - FEDERAL_ZONE.accountNumber is an amount, not a reference. It holds DATMEX.zfed, whose 77 values include 246.06, 2369.09, 22653.94 and a negative -1679, while the concession claves these receipts are keyed by appear nowhere in the database. Matching on that column could never hit — and because every row already has a value, the `[field]: null` guards on learnAccountRefs and on the review blank-service fill would never fire either, so every page would return to the queue every bimester forever. The clave moves to meterNumber, joining gas and Tijuana predial, and the first confirm teaches the match. - The payable figure is not the printed subtotal. The municipality rounds to whole pesos and prints the difference on its own "Ajuste Ley Hacienda Mpal" line (-$0.05 against a 591.05 subtotal, $0.21 against 2,872.79). The "Total a pagar" box carrying the rounded figure sits on a grey fill and OCR'd on 1 of 8 pages; the SubTotal row read on 8 of 8. So the amount is the rounded subtotal, cross-checked against the printed box wherever it survives — where it did, it agreed. - The clave is 2 digits, a letter and 3 digits (12-T -012), not the cadastral shape, and the letter is kept as printed: toDigits maps D to 0, which turns a real 14-D -014 into 140014. It is printed twice, which rescued a page whose heading was struck through by the office's own highlighter — the failure mode behind both missing claves. Deriving the deadline from the bimester is deliberately not attempted: it is the 17th of the month after the bimester closes on a current bill, but four of these eight are late (a $1,000 Multa) and print a recalculated date, so a derived date would be wrong on exactly the pages a human most wants to see. Re-ran the earlier corpora (25 pages: predial Tijuana/Rosarito/Ensenada, CFE, CESPT, Telnor) through detection to confirm the new rules steal nothing — all 25 still read as their original provider, including the five Tijuana predial pages that share the RFC. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 14:07:21 -07:00
rmancinasandClaude Opus 5	d6501f1d74	feat(recibos): OCR capture for gas butano and municipal predial ... Adds four parsers to the statement intake — GAS TIJUANA plus one per municipality, because Tijuana, Rosarito and Ensenada issue three completely different predial documents — and a text-layer fast path for the born-digital invoices the gas company sends. Measured against a new corpus of 14 documents / 29 pages: provider read on 29/29, amount on 26/29, and 21/29 auto-matched against the dev database (22/29 identified). The eight review cases are all legitimate. Five things the corpus forced: - Not every statement is a scan. The gas invoices are born-digital CFDIs whose text layer is exact; rasterising them only loses information (one sample turned `MEDIDOR: VM01014426` into `ar (LTR): 014420`). The new `OcrProvider.textPages` reads the embedded layer via `pdftotext -bbox-layout` — same poppler package as `pdftoppm`, so no new dependency — and OCR stays the fallback for real scans. Poppler's own `<line>` grouping follows text flow rather than the page, so words are regrouped by vertical position; without that, a two-column header leaves every label separated from the value printed beside it. - The clave catastral is not two letters and six digits. Position three is a letter in 15 of the 932 stored claves, and digitising the whole tail mapped a real `MMB01041` to a nonexistent `MM801041`. - Tijuana predial prints no clave at all. Its only identifier is an 8-digit municipal account carried in a 32-digit payment barcode, which the legacy database never held, so it goes in `meterNumber` alongside gas — `accountNumber` holds `DATMEX.predial`, which is not a per-property key and must not be overwritten. Those pages start cold and are taught by the first confirm. - On Rosarito and Ensenada the clave is the primary key, not a fallback: those receipts print nothing else, so a unique hit auto-matches. On a utility bill that merely happens to print one it stays a review hint. - A misread `$` is the dangerous failure. An Ensenada receipt for $2,203.00 OCR'd as `82,203.00`, which would post a charge 37x too large and look ordinary in the ledger. Predial amounts now require a literal `$` and a page that cannot produce one goes to review. The scoped match field is now one exported function rather than three copies of `kind === "GAS" ? ... : ...`, since the lookup, the blank-service fill and the confirm write-back have to agree or a reference gets learned into a column nothing searches. First tests in this package: 23 specs over the parsers and the text-layer reader, every fixture a verbatim OCR excerpt from a real receipt. Adds the jest config they need and a build tsconfig so they stay out of dist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 12:52:20 -07:00
rmancinas	216309190c	feat(recibos): live OCR progress bar on review page ... Backend already returns per-status counts via byStatus; render a real progress bar (X% / N de M / en cola) while PENDING_OCR pages remain, using the existing progress-track CSS. Falls back to indeterminate when no docs have been reported yet.	2026-08-01 02:43:19 -07:00
rmancinasandClaude Opus 5	783ec83464	feat(ops): show upload percent, speed and ETA for ingest files ... The ingest upload used fetch(), which cannot report request-body progress, so the only feedback was a static "Cargando…" label — no way to tell a stalled 2 GB upload from a working one. Switch uploadFile() to XMLHttpRequest and expose an optional onProgress callback reporting loaded/total bytes, a smoothed transfer rate and a remaining-time estimate. The Operaciones ingest table renders a progress bar row under the file being uploaded. Once the bytes are all sent the server still has to write the file, so that tail reads "Procesando en el servidor…" rather than parking at 100%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 01:38:22 -07:00
rmancinasandClaude Opus 5	b59abda895	feat(captura): fold recibo OCR into Captura as an automatic mode ... Scanning a stack of bills and keying them in are the same daily job, ending in the same ledger path, so OCR intake becomes a mode of the capture screen instead of a second menu entry: - components/Captura.tsx holds the mode switch; the manual check form moves verbatim to components/ManualCheckCapture.tsx and the OCR intake to components/StatementIntake.tsx. - /estado-cuenta/lote opens on manual, /recibos on automatic — both render Captura, so batch-review links and old bookmarks still land right. - Nav drops "Recibos (OCR)"; "Captura" covers both, with a NavLink.aliases field so /recibos still highlights it. Also fixes the "El almacenamiento de documentos no está configurado" failure staff hit on upload. Uploading with no object storage configured used to succeed, then die on the first put minutes later, leaving a FAILED batch whose only explanation was that string. createBatch now refuses up front, GET /statements/status reports storageAvailable alongside ocrAvailable, and the intake tab explains the situation instead of offering an upload that cannot work. S3_* documented in .env.example (deploy stacks already set it). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 01:04:09 -07:00
rmancinasandClaude Opus 5	4d5008b545	feat(statements): OCR intake for scanned utility bills ... Staff key 300+ utility statements per company per month by hand. This adds the ingest -> split -> OCR -> match -> review pipeline that proposes customer and amount per page instead (RECEIPT_CAPTURE_SPEC §2), posting through the existing BillingService.createBatch seam with source=OCR and a per-document captureRef so machine and hand capture share one write path and audit trail. Everything was designed against 10 real scanned statements (46 pages of CFE, CESPT and Telnor bills) rather than from the sample-free spec. The scans have no text layer at all — they are camera images — so OCR is mandatory, and they arrive bundled one customer per page. Measured on those pages the parser identifies the provider 46/46 and reads an account reference 43/46; against the dev database that is 39/46 (85%) exact auto-match, 40/46 identified, with the rest genuine review cases. That closes the OCR-provider question in favour of self-hosted Tesseract: it clears the bar for a queue where a human confirms every row, and OcrProvider keeps a managed API a one-line swap. The samples corrected three things the spec had wrong or unknown: - Clave catastral is NOT predial. DATMEX.clave (934 rows) is what CESPT and predial bills print; DATMEX.predial, which PROPERTY_TAX.accountNumber holds, has 663 distinct values across 1135 rows and appears on no statement. The clave now lives on Property.cadastralKey as the matcher's secondary key; predial is left untouched. This had been blocking predial matching. - Gas was recoverable: 160 of 334 DATMEX.gas values are real account numbers (the rest are ESTACIONARIO/CILINDRO descriptors), now in GAS.meterNumber. - Phone is one billed line per property (534/18/1 across phone1/2/3), so the new TELEPHONE ServiceKind backfills from phone1 only, not three rows. Matching is scoped to one column per service kind and never reads the customer name — a CESPT receipt prints ARNAIZ ROSAS ELSA AURORA for an account this office holds under CATT, RANDY, because the printed name is the registrant, not the current owner. Where a provider prints a payment barcode it beats the printed label (one CFE label OCR'd a digit too many while its barcode was correct) and the two cross-check, with disagreement forcing review. Confirming a document whose service had no reference writes it back, so gas and any other cold start is a one-time cost rather than a permanent queue. Verified end to end against the live dev API and MinIO: real scans uploaded over HTTP, matched, confirmed against a check, and the resulting rows checked in MySQL (negative amounts, captureSource=OCR, concept derived from the batch kind, captureRef linking back to each page). Re-confirming a posted batch is refused. Test data was removed afterwards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 00:42:35 -07:00
rmancinasandClaude Opus 5	15f533b984	fix(web): show the full commit hash in the build footer ... The footer abbreviated to 7 characters, so the line read "v master · 19f0319". That line exists to be pasted into `git show` or compared against a registry tag, and an abbreviation makes both a manual step — while the full 40-char value was already baked into the image (build.yml passes `github.sha` whole, and /version returns it untouched). `shortSha` had no other caller, so it goes with it. The span gets `overflow-wrap: anywhere` and `min-width: 0`: hex offers no break opportunity, and the api/web mismatch branch renders two of these hashes side by side, which would otherwise push a phone into horizontal scroll. Measured at a simulated 360px with both hashes present — the span wraps, and documentElement.scrollWidth stays equal to clientWidth. Verified in the browser against the dev database: footer renders "v1.0.0 · db2bd54c0ffee1234567890abcdef0123456789a", hash length 40. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:37:48 -07:00
rmancinasandClaude Opus 5	7e3b530174	fix(deploy): pull images explicitly, and detect api/web drift by commit ... The first successful galactus deploy came up all-green while the web tier was running a build from two commits earlier. The registry held web:latest from 3ff56e6; the host still had a web:latest cached from 4ee7ec7; the deploy reported success and served the old one. The API was only current because it had been pulled by hand during earlier debugging. Two independent failures, both fixed here. 1. Images are not pulled. The deploy action's `pull: true` does not reliably refresh an already-cached moving tag on a standalone endpoint. Added a Pull images step (deploy/scripts/pull-images.mjs) that pulls each image through Portainer's Docker API with registry credentials and fails the deploy if a pull fails — note the endpoint answers 200 even when the pull errored, so the stream body has to be inspected, not just the status. 2. The drift check could not see it. Both the verify step and the web footer compared APP_VERSION, but on a branch build BOTH tiers report "master", so equality proved nothing. They now compare gitSha, which is the only field that differs between two builds of the same branch. api and web come from one matrix run, so a difference can only mean an image was not replaced. This needed a /version on the web tier too — previously its build identity was only readable by scraping window.__APP_BUILD__ out of the HTML. pull-images.mjs builds the X-Registry-Auth header as URL-safe base64 WITH padding: Node's "base64url" omits the padding and Portainer's Go decoder rejects it with "Illegal base64 data at input byte N". Verified against galactus: pulls both images, and exits non-zero on a nonexistent tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:57:44 -07:00
rmancinasandClaude Opus 5	4ee7ec71f0	feat(deploy): prisma migration history, /version, galactus standalone deploy ... Closes the gap between "what tag did I deploy" and "what is actually running", and gives the schema a history that can be reasoned about across releases. Migrations - Baseline the existing schema as 0000_init (migrate diff --from-empty). The schema had only ever been applied with `prisma db push`, so no history existed and schema state was disconnected from app version. Existing databases must be baselined once with `migrate resolve --applied 0000_init`; the workflows print this remedy on P3005. - Run `prisma migrate deploy` as a deploy STEP, not the container CMD — as a CMD, N replicas would race each other applying the same migration. Version reporting - GET /version on the API reports the APP_VERSION / GIT_SHA / BUILD_DATE that build.yml already baked into both images but nothing ever read. - The web footer shows the web build and flags an api/web mismatch. The two cannot drift at build time (one matrix run) but can at deploy time. - Both deploy workflows now fail if the running API does not report the tag that was dispatched — a stack naming a tag is not proof of what is running. - scripts/set-version.mjs stamps every package.json, which had all sat at 0.1.0 while real releases shipped as v1.x. Pre-migrate backup - deploy/scripts/pre-migrate-backup.mjs dumps the database from INSIDE the still-running old API container over Portainer's Docker API, so the file lands in the volume the Operaciones restore screen reads. A dump taken on the CI runner would be unreachable by the only restore path we have. Verifies the artefact with `gzip -t` before letting the migration proceed. galactus - deploy/galactus/*.compose.yml: standalone-Docker ports of the Swarm stacks. Plain compose silently ignores `deploy:`, so restart_policy becomes `restart: unless-stopped` — without it nothing returns after a host reboot. - .gitea/workflows/deploy-galactus.yml drives endpoint 3 with its own secrets. Fixes - deploy.yml passed `endpoint_id` and `pull_image` to cssnr/portainer-stack-deploy-action, which has no such inputs (they are `endpoint` and `pull`). The endpoint was silently never set. docs/DEPLOY_AND_MIGRATIONS.md documents expand/contract as the rule for schema changes: Prisma has no down-migrations, so a code rollback never rolls the schema back, and restoring the replication master from a dump diverges every replica. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 11:41:12 -07:00
rmancinasandClaude Opus 5	9ba5d2d09a	feat(bank): multi-bank chequera — required bankAccountId, per-account scoping ... The office keeps more than one operating account (Utilities banks in MXN, Seguros in USD), but bank_transactions was a single implicit MXN register by design. Adds Bank/BankAccount and makes every read and write in the module scoped to exactly one account. Schema: - Bank / BankAccount. Currency is fixed per account and BankTransaction has no currency column of its own — a movement inherits its account's, the way a real bank account doesn't mix currencies. - BankTransaction.bankAccountId, required. A movement with no known account isn't reconcilable against a statement. - @@index([bankAccountId, transactionDate]): every read now filters by account and orders/groups by date. Migration: - backfill_bank_accounts.py seeds Scotiabank + "Utilities — Scotiabank (MXN)" and backfills all 22,669 existing rows onto it, then promotes the column to NOT NULL and attaches the FK. Standalone because prisma db push cannot add a required column to a populated table. Idempotent; re-running once a second account exists does not re-point rows. - run_all.py runs it (both modes) before transform_bank.py, which now resolves the account by label and fails fast if it is missing. API: - ?bankAccountId= required on list/stats/facets/summary — not optional with an "all accounts" default, since summing an MXN and a USD register repeats the currency-collapsing mistake the billing module exists to prevent. Missing is 400, unknown is 404. - facets() had no account clause at all and summary() has two raw-SQL rollups; all three are now parameterised. Scoping only one of summary's queries would leave the year list and its drill-down describing different books. - New bank/accounts + bank/banks sub-resource under a MANAGER bank:manage-accounts ability. currency is absent from the update DTO: booked movements are denominated in it, so editing would re-denominate history. Capture into a closed account is rejected. Web: - /banco gains an account picker (remembered per browser) and reads every figure in the selected account's currency; the "single currency (MXN)" doc-comment and the hardcoded MXN formatting are gone. - New /banco/cuentas for banks and accounts. Accounts are closed, never deleted — the FK is required, so deleting one would destroy its register. - /inicio's chequera card names the account it is reading instead of implying a single register. Verified against dev + browser: a second USD account showed full read/write isolation from the MXN register, whose totals were unchanged (22,669 movements, net 1,014,266.97). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 23:54:16 -07:00
rmancinasandClaude Opus 5	c100dfa224	feat(web,api): scale spacing with text size, persist preference per account ... Two follow-ups to the text-size control. Spacing now scales with the text. All padding, margin, gap and min-height declarations in globals.css move from px to rem (263 declarations, converted mechanically), so --ui-scale drives the whole layout rather than just the glyphs. Deliberately left in px: border widths, which must stay hairlines; box-shadow offsets; border-radius, which reads as bloated when scaled on large cards; --shell-max, a container cap that must not outgrow the viewport; and media-query breakpoints, which are conditions rather than declarations. With spacing following along, the presets gain a 1.5 "Máximo" step and MAX_UI_SCALE rises from 1.4. The preference now lives on the account instead of only in one browser. User.uiScale (Float, default 1) is added to the schema and to the safe select, so it rides along on /auth/login and /auth/me. PATCH /auth/preferences writes it, guarded by AuthenticatedGuard only — every role including VIEWER may set their own, and the target is always the session's user id, never a body parameter, so this cannot be used to touch another account. The global ValidationPipe's whitelist rejects any extra field, so role cannot ride in alongside uiScale. localStorage stays, demoted to a pre-paint cache for the layout.tsx script; AppShell reconciles it against the account once /auth/me answers, with the account winning. FontScaleControl becomes a controlled component since the same value is now edited from the appbar and the drawer. Verified against the dev API: PATCH persists and is reflected by a subsequent /auth/me, out-of-range values are rejected 400, and an extra "role" field in the body is rejected 400. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 22:30:06 -07:00
rmancinasandClaude Opus 5	0bf97e6d2c	feat(web): group top nav, add mobile drawer and app-wide text size control ... The appbar had grown to 11 flat links with no responsive behaviour, and overflowed below ~1100px. Nav is now 7 top-level entries: Inicio, Clientes, Pólizas, Propiedades, Reportes stay one click away, while the movement screens (Captura, Estado de cuenta, Chequera) and the admin screens (Catálogos, Usuarios, Operaciones) collapse into "Cobranza" and "Admin" dropdowns. Groups are ability-filtered and disappear entirely when the user can see none of their items, so VIEWER never renders an empty Admin menu. activeHref now scans the flattened link list, and a group trigger highlights while one of its children is current. Below 980px the nav collapses to a burger drawer that lists every group expanded, closing on navigation and on Escape. Text size is user-adjustable app-wide. Every font-size in globals.css is converted from px to rem (mechanically, 133 declarations) and the root size becomes calc(100% * var(--ui-scale)), so one variable on <html> rescales the whole UI. The preference persists in localStorage and is applied by a pre-hydration script in layout.tsx to avoid a flash at the default size; the Aa control lives in the appbar and, as a segmented row, in the drawer. Spacing stays in px by design, which is why 1.3 is the largest preset. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 22:16:30 -07:00
rmancinasandClaude Opus 5	7df928c3ab	feat(billing): receipt capture — outstanding workflow, batch by check, reconciliation ... Implements docs/RECEIPT_CAPTURE_SPEC.md §1, the legacy "Editor" replacement, on top of the single-movement capture from plan step 6. No new abilities: batching and resolving are both capturing. - outstanding (legacy NOPAGO): capture flag, ?outstanding= filter, and POST /billing/:id/resolve-outstanding (gated ledger:create, not ledger:void — resolving completes a capture rather than reversing one). Outstanding rows are excluded from every balance aggregate, matching the legacy SALDOS ULTIMO 0 query's HAVING NOPAGO = 0, but still count in the movement browser's filtered totals. - POST /billing/batch: many customers' receipts against one check, in one $transaction. Deliberately not a persisted batch entity — checkNumber is already a column and grouping by it answers every legacy by-check query. - GET /billing/by-check + a cheque-count report, replacing REPORTE CHEQUE COUNT / REPORTE POR CHEQUE / EDITA CHEQUE ALF|COUNT|NUM. Print, PDF, CSV and XLSX come free from the existing /reportes/:slug machinery. - Web: /estado-cuenta/lote (the Editor screen, with live reconciliation against the physical check amount), an "Estado de pago" filter, a "sin fondos" row tag and a Resolver dialog, plus a top-level "Captura" nav entry. Integration seam for the OCR auto-capture module (spec §2), which is required to post through createBatch rather than writing Transaction rows itself: items[i] maps to lines[i] so postedTransactionId can be zipped back on; opts.refs[i] stamps captureRef with a duplicate-post guard that a voided row deliberately does not block; opts.source is service-level only, so an HTTP client cannot label hand-keyed rows as machine-captured. captureSource/captureRef are nullable so the 40,136 migrated rows stay NULL rather than being mislabelled. Fixes two pre-existing bugs found while building this: - statement() filtered legacySourceTable with `notIn`, which compiles to SQL NOT IN — and `NULL NOT IN (...)` is NULL, so every app-captured movement was invisible on the customer statement (438 rows in the movement browser vs 392 on the statement) while showing everywhere else. This would have made the whole capture feature look broken. - The balances count query omitted the void filter its own page query applied, so the total disagreed with the rows. Nav highlighting now resolves by longest match; the previous first-startsWith logic lit up both the parent and any nested entry. Verified end-to-end against the dev DB, API and browser; all test rows removed afterwards. Also corrects RESUME.md, which documented the dev ports as :3001/:3000 — they are :4501/:4500, from the env files. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 21:54:41 -07:00
rmancinasandClaude Opus 5	6dbd4a319b	fix(reports): render renewal-letter premium lines as booleans ... `r.netPremium` / `r.total` are strings, so an empty-string value leaked ""` into the JSX instead of rendering nothing. Wrap in Boolean() so the guard is a real conditional. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:07:32 -07:00
rmancinasandClaude Sonnet 5	f7ae0d5342	feat(reports): parameterized renewal-notice report + legacy report reference ... Replaces ~40 legacy Access renewal-notice report clones (one per carrier per coverage tier, e.g. AMPL/RC/LIC RENEW X MES/VENCE ATLAS 13/2013) with one parameterized aviso-renovacion report driven by real Policy/Vehicle/ coveragesJson data instead of hand-typed label text per clone. - schema.prisma: add RenewalNotice, replacing the legacy CONTROL <ramo> RENEW[2/3] X MES paper log of which notice generation was sent - reports: new "letter" ReportFormat + aviso-renovacion registry entry + LetterLayout renderer in ReportRunner.tsx - docs/RENEWAL_NOTICES.md + migration/legacy_report_defs/: extracted (via Application.SaveAsText, since the VBA project wouldn't load) and documented the legacy report/query chain this replaces Coveragesjson key names and a mark-as-sent mutation are still unverified/ unbuilt — see caveats in docs/RENEWAL_NOTICES.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-25 23:05:21 -07:00
rmancinasandClaude Opus 4.8	1b79b43a54	fix(migration): make Phase B additive sync actually work + verify end-to-end ... The --sync path had never been run and was broken in several ways. Fixed and verified against the dev DB (two consecutive syncs, both exit 0, 32/32 assertions: stable PKs, manual-row preservation, changed-row updates, legacy-delete, no child duplication, zero FK orphans; idempotent). - policies/properties: reuse each legacy row's existing id (by provenance) BEFORE building child rows, so children no longer point at a discarded fresh uuid; rebuild legacy-owned children via scoped delete + reinsert. - customers: replace zip(customers, refs) (mispaired almost every row) with a ref-grouped id remap; names now restore and no spurious customers appear. - drop the invalid Vehicle @@unique(legacySourceTable, legacyId) — one legacy policy row carries up to 3 vehicles sharing a legacyId; handle via delete+reinsert. - upsert lookup tables (policy_types, insurance_providers, type_transactions, adjusters) by natural name and remap child FKs instead of inserting fresh uuids that nothing points at. - transactions: drop updatedAt=NOW() (no such column); guard report formatting on NULL legacySourceTable (manual rows). Same report guard in bank. - add manual-safe prune (prune_empty_customers.py --sync, in SYNC_STEPS): prune only legacy-owned empties, never manually-added customers. web: customer-detail mini tx list now strikes voided rows with an "(anulado)" tag (was the last void-UI rendering gap; /estado-cuenta already handled it). docs: RESUME.md updated — Phase B sync marked verified end-to-end, void-UI browser pass recorded. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 13:37:22 -07:00
rmancinas	8802f08d4f	feat(reports): reports module + /inicio + edo-cuenta-datos prefill ... - New reports backend (registry, service, controller, outputs, types) with catalog endpoint + slug/CSV/XLSX/PDF/print outputs. - /reportes catalog + /reportes/[slug] runner; ReportRunner + ContextReports components wire pre-filtered links from domain pages. - Fix: /reportes/[slug] now reads searchParams and forwards initialParams to ReportRunner so /reportes/edo-cuenta-datos?customerId=... auto-runs instead of dropping the id and forcing a manual customer search. - /inicio landing page; root + login redirect to /inicio. - Company header env vars + logo asset for PDF/print rendering. - exceljs + pdfkit deps.	2026-07-23 23:20:41 -07:00
rmancinas	921a47cbaa	feat(web): use company logo PNG in brand mark ... Replace the JC text mark in AppShell and login with the real company_logo.png. Restyle .brand-mark to host the image (white rounded bg, object-fit contain). Appbar 38px, login panel 46px.	2026-07-23 22:17:17 -07:00
rmancinas	27b3bd9efc	feat: expand admin and data sync workflows	2026-07-23 22:00:08 -07:00
rmancinasandClaude Opus 4.8	70911e7e62	feat(deploy): app stack + manual Portainer deploy workflow ... Add the missing api/web deployment path on top of the existing image build CI. - deploy/jorgecuadros-app.stack.yml: PROD app stack (api + web) pulling the git.mancinas.io registry images. Does not ship mysql/minio (separate stacks); API reaches them via DATABASE_URL / S3_ENDPOINT. API pinned to the jorgecuadros_db node for stable ingest/backup volumes; web is stateless. - deploy/jorgecuadros-app.env.example: documented stack env template. - .gitea/workflows/deploy.yml: manual (workflow_dispatch) deploy to Portainer via cssnr/portainer-stack-deploy-action. Inputs: image tag + scope (app = web+api, full = db+minio+app, applied db->minio->app). Make the web API origin runtime-configurable instead of build-baked: the root layout injects window.__API_ORIGIN__ from the API_ORIGIN env (force-dynamic) and lib/api.ts resolves it at runtime, so one built image serves any deployment. Also: dev.sh to run both dev servers (frees stale ports first) and move local dev to ports web 4500 / api 4501. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-23 20:07:48 -07:00