Repository navigation
scrape: SiteAdapter has no implementation in the tree; the ten job boards use module-jobs interface #344
Description
Original context (pre-migration snapshot)
Part of #56, originally found by #319. SiteAdapter and the generic runner have no production implementer/caller; job boards implement module-jobs ScraperAdapter (packages/module-jobs/src/types.ts:147) through BaseAdapter and run through packages/module-jobs/src/scrape.ts:180. They share ScrapeContext, HTTP/browser clients and parsers already.
The generic AdapterResult (packages/scrape/src/adapter/types.ts:59) does not encode the source outcomes derived by PageLedger (packages/module-jobs/src/adapters/base.ts:88). Adopting it unchanged would lose confirmed-empty versus unparseable/not-run distinctions. Boards also require cursor/query inputs and detail-fetch metadata.
The original audit's documentation/tag claims have been fixed: docs/extending/README.md:125 now acknowledges the split, and SiteAdapter, AdapterResult and ScrapeContext carry experimental annotations. The architectural choice was still outstanding.
Maintainer decision — 2026-09-28
Option A (original option 1): evolve SiteAdapter for demonstrated job-board requirements and migrate all boards to the shared contract and runner before 1.0. Retain the extension seam, experimental until 1.0. Preserve existing CLI status semantics, positive-empty evidence, cursor/query behavior, browser/proxy handling, polite fetching and detail-host/fetch restrictions. Keep job-domain concerns in module-jobs; do not add speculative extension machinery or retain two competing runners.
Scope
Record the ruling and track its durable decision record/documentation and implementation in #545, attached to #56. That follow-up owns the code, contract suite and migration work.
Out of scope
- Implementing the migration directly under this decision issue.
- Changing per-board status semantics, adding/removing boards or scheduling 1.0.
Acceptance criteria
- A maintainer ruling selecting adoption is recorded on this issue.
- The ruling is recorded in docs/decisions by scrape: migrate job boards to the shared SiteAdapter contract and runner #545.
- Documentation describes the actual adapter implementations and runner after scrape: migrate job boards to the shared SiteAdapter contract and runner #545 lands.
- Implementation/conformance follow-up scrape: migrate job boards to the shared SiteAdapter contract and runner #545 is filed and attached to Epic: 1.0.0 — the stability bar #56.
Verification
After #545, source usage and tests demonstrate the documented boards implement SiteAdapter and use the shared runner. The durable record and seam inventories agree with that implementation.
Contract impact
The ruling itself changes no code. #545 implements the approved pre-1.0 seam changes with contract/breaking labels, CONTRACT: commits, same-commit contract documentation and changesets naming API breaks. Existing jobs CLI behavior remains contractual.
Updated 2026-09-28: selected adoption, corrected stale audit claims and linked implementation #545. No decision remains; awaiting its record/documentation deliverables.
Updated 2026-09-30 readiness review against main 7a7bd9caff1453abaceddc98826b652f2ca955cb: corrected the extension-guide pointer to the SiteAdapter/ScraperAdapter split and the execution pointer to the bind/scrape call. Existing type, bind, PageLedger and detail-host citations still identify the claimed behavior. The 2026-09-28 adoption ruling and scope are unchanged.
Completed 2026-09-30: #545/#706 (3811290, verified on main) delivered the durable ruling and alternatives and actual-implementation documentation. All ten boards and production shared execution have fixture/runtime and mutation proof; package migration notes, integration contract, experimental annotations and API reports agree. The original context citations are the pre-migration snapshot checked on 2026-09-30. All acceptance criteria are complete; the 2026-09-28 ruling is unchanged.
Activity
schlessera commentedon Sep 28, 2026
Decision (maintainer, 2026-09-28): Option A (option 1 in the original issue): evolve SiteAdapter around the real job-board requirements and migrate module-jobs onto the shared adapter contract and runner before 1.0. Retain SiteAdapter as a supported extension seam, experimental until 1.0; do not freeze its unused current shape.
Preserve the existing public scraping behavior, especially the distinction between confirmed empty results, unparseable pages and sources that did not run. Preserve cursor/query handling, browser/proxy requirements, polite fetching and detail-host/fetch restrictions. Keep job-specific metadata and processing in module-jobs; grow the generic interface only for demonstrated requirements, without a speculative plugin system or a second parallel runner.
The follow-up implements the migration, records the durable decision, updates seam inventories and adds meaningful shared-contract coverage using real adapters with deterministic fixtures. The docs already acknowledge the lack of production implementers and the types already carry experimental tags; those original audit claims are stale and are corrected in the body.
Implementation and the durable record: #545, attached to #56 and agent-ready. Remove needs: decision here; #344 remains blocked on that follow-up for its documentation/record acceptance criteria.
schlessera commentedon Sep 30, 2026
Unblocked: #545 is closed, so
scripts/sync-project.tsis removing theblockedlabel.schlessera commentedon Sep 30, 2026
#545 is complete through merged #706 (3811290, verified on main). The durable adoption record and implemented seam documentation satisfy this issue’s remaining criteria. All ten boards execute through the shared contract/runner, with fixture, real Chrome, consumer and ten restored-mutation receipts; all ten CI jobs and the contract gate passed. Marked all criteria complete and closing this decision issue. The adoption ruling is unchanged; no interface freeze or 1.0 schedule is selected.
[-]scrape: SiteAdapter has no implementation in the tree; the eleven job boards use module-jobs' own interface[/-][+]scrape: SiteAdapter has no implementation in the tree; the ten job boards use module-jobs interface[/+]