All notable changes to this actor will be documented here.
Format: YYYY-MM-DD | version | description | author
2026-07-25 | 0.1.10 | PENDING OWNER REVIEW (not yet deployed — committed on branch fix/computrabajo-completeness). Replaced the RequestList + dynamic crawler.addRequests() mix (flagged by crawlee's own warning every run) with a single explicit RequestQueue via crawler.run([{url: startUrl, ...}]), per crawlee's documented pattern — eliminates the RequestManagerTandem code path entirely, removing a theoretical eventual-consistency race where the Apify platform's RequestQueue.isFinished() can flip true before a just-enqueued batch of detail requests (added inside the last list-page handler) is visible to the queue head. IMPORTANT — re-measurement finding: the specific "40 enumerated / 30 executed, ~25% silent loss" claim from the prior validation-agent entry below does NOT reproduce. New instrumentation (logs enumerated-vs-executed counts every run) shows the "20 jobs on page 1" + "20 jobs on page 2" = 40 raw listings include ~10 genuine duplicate job URLs that Computrabajo's own pagination returns on both pages (verified: listItemsByUrl — a plain URL-keyed Map — collapses 40 raw list-card parses down to 30 unique URLs, and all 30 were fetched and pushed, both in the OLD code's baseline run 2hUT4h64FBaXjmz2F and across 3 fresh runs on the fixed code). Stress-tested with maxItems:0 (unlimited, 13 result pages, 260 unique detail URLs): 251 pushed + 9 detail-request failures (real 403s from Computrabajo's bot protection under sustained pagination load, individually logged) + 0 silently dropped — enumerated count and accounted-for count (pushed+quarantined+failed) matched exactly. So: the RequestList/RequestQueue refactor is kept as a legitimate defensive fix (removes a real, crawlee-documented anti-pattern and its theoretical platform race), but it should NOT be described as fixing a confirmed 25%-data-loss bug — that specific loss was never observed to occur; the original diagnosis conflated cross-page URL de-duplication with request drops. Added src/completeness.ts (checkCompleteness, unit-tested) + wiring in src/crawl.ts: if items produced ever fall materially short of URLs enumerated for any unaccounted reason, a loud console.error "COMPLETENESS WARNING" fires with both numbers — makes any future silent-loss regression observable in the log instead of passing as a quiet SUCCEEDED run. Extracted crawl orchestration from main.ts into src/crawl.ts so it's testable without a live Actor.init(); output schema/field names unchanged (drop-in for existing consumers). 12 new tests (7 unit tests on checkCompleteness, 3 integration tests against a local HTTP fixture server reproducing the real 2-page/40-URL/10-overlap shape, all green: 85/85 total, tsc --noEmit clean). Verified on a temporary private actor (computrabajo-completeness-fix-verify, id I2TExLCjd4yLagGhe, deleted after verification) with 4 live runs against the real site — see LOG.md for full run ids and counts. Published actor computrabajo-jobs-scraper was NOT touched (no apify push run against it; only read-only runs for baseline measurement, which self-runs bill zero events). | Claude Sonnet (builder agent)
2026-07-25 | 0.1.9 | Live-validation fix: @money/shared's buildProxyConfig() requested a proxy group named 'DATACENTER', which doesn't exist on this account (real group: BUYPROXIES94952) — every run silently fell back to no proxy. Fixed group name in shared lib, but that alone made things worse here: routing default (non-residential) runs through the now-working shared datacenter proxy pool introduced 403s from Computrabajo's bot protection that a direct connection never hit (verified: run lf3N6JSLpnlHQQWbe, 4 blocked requests with the datacenter proxy vs 0 with none, same search). So computrabajo now deliberately requests NO proxy at all for the default case — only escalates to residential when useResidentialProxy: true — matching the actor's own documented "works from plain IPs" behavior. Re-verified clean (run gaeVSEwubyqJplAyK: 30/30 jobs, 0 failed requests, no proxy warning). Separately noted but NOT fixed (structural, needs a live-target-tested refactor): a RequestList/dynamic-RequestQueue mixing anti-pattern (crawlee warns about it every run) appears to silently drop ~20% of enqueued detail-page requests once pagination is involved — default run returns 30 jobs though ~40 were listed across 2 result pages; no crash, no quarantine, just fewer jobs than available. | Claude Sonnet (live-validation agent)
2026-07-24 | 0.1.1 | Optional enrichCompany input (default false, output/cost unchanged when off): adds companyDetails (industry, logo, verified badge, rating, review/follower/job counts) sourced from job-page JSON-LD (free) + one cached fetch per distinct company's profile page; no company-size/sector field exists publicly so none is fabricated; 22 new tests on live-captured fixtures | builder-agent
2026-07-23 | 0.1.0 | Initial implementation — Computrabajo scraper (19 countries, SSR HTML), Bumeran stub with parsers and URL builders; unit tests with live HTML fixtures | builder-agent
