Files
raulgupta 89ca9ad647 Initial commit: matchmaking-v2 on-demand multi-board job-search agent
On-demand Scout service (replaces the nightly aggregator):
- FastAPI agent-mesh service; card name "matchmaking-service" (HTTP /a2a/tasks
  + Redis-stream worker matching the sibling-service pattern)
- run_search: parallel multi-board sweep (Naukri/blackfalcondata + Foundit +
  LinkedIn), city-filtered at the board, cheapest-per-result first
- per-board adapters + normalizers -> ScoutJob with rich read-only details and
  offsite apply links; recall mode + MVQ guard
- result cache for dev replay ($0); per-board cost knobs; retry-on-5xx
- research/: engine design, board cost economics, India-actor shortlist, POC
2026-06-18 19:22:03 +05:30

21 lines
748 B
Python

"""
Adapter contract. An adapter is a THIN layer of board-specific knowledge — it does NOT
re-implement the apply loop. The generic engine does all the work; an adapter only:
- matches(url): claims a URL by its domain/ATS, and
- hints(): returns extra prompt text about that board's known quirks (controls, field names).
The GenericAdapter returns no hints — pure vision. Specialized adapters (Ashby, later Greenhouse/
Lever/Workday) add hints that raise accuracy on that board.
"""
from __future__ import annotations
class Adapter:
name = "base"
tier = "unknown" # tier1-autonomous | account-gated | generic
def matches(self, url: str) -> bool:
return False
def hints(self) -> str:
return ""