OpenHire · 哨兵

Record an authorized, employer-direct application. REFUSES résumés. (Formerly `apply` — renamed to make explicit that this only records the user's authorization to apply as themselves; it never submits anything on their behalf.) This tool never accepts a résumé, file, cover letter, name, email or phone — a résumé never transits the server. It only takes a job_id, an anonymous fingerprint, and an explicit per-job authorization. On success it returns the apply_channel (the employer's own application URL) for the user to submit as themselves, plus resume_transmitted=false. Do NOT paste résumé content into any argument. Args: job_id: the job to apply to (from search_jobs / check_watches). fingerprint: the user's anonymous fingerprint. authorized: must be true — explicit per-job consent.

Pull matches that are new since this fingerprint's last check. stdio has no server push, so clients pull: call this at the start of a session. Returns the new matches per watch and advances each watch's last-notified marker. The FIRST pull on a watch returns everything matching it, not an increment: nothing has been reported for that watch before, so the whole standing set is new to the user. Each result says which it is via `is_first_pull`; do not present a first pull to the user as "postings that appeared since last time".

Aggregate, anonymous trust signals for one employer. Returns ghost_score_avg, active_jobs, and index_built_at (when the index was last built). NEVER returns any individual candidate data — the server holds none. `claimed` is true only when the employer has claimed this tenant and we verified them by corporate identity — never by payment, and it never affects ranking. It is the only signal here that comes from the employer rather than from their public ATS data, and it is what makes `response_sla_days` non-null on their postings.

Re-crawl ONE employer's public ATS now. Takes about a minute. Throttled to 6h. The index is refreshed weekly, so `search_jobs` can be up to seven days behind and `check_watches` has nothing new to report until it moves. This is the manual nudge for the case that matters: the user is about to act on one employer and wants today's truth. Rules worth knowing before you call it: * ONE employer per call. A full crawl is 20+ minutes and no client will wait; a vague word like "robot" is refused with the list of candidates rather than fanned out into eleven live crawls. * At most one crawl per employer per 6 hours. A throttled call returns immediately with `refreshed: false`, `reason: "throttled"` and `last_refreshed_at` — no network request is made. That is not an error: it means the data you already hold is that fresh. * Do NOT call this speculatively or in a loop. Every call hits somebody else's public endpoint. Search first; refresh only when the user needs today's state of one employer. Args: company: one employer — an id ("unitree") or any part of the name in either language ("宇树", "XPeng"). Ambiguous input is refused, not guessed. Returns: `refreshed` plus `last_refreshed_at` / `next_allowed_at`; when it did run, also jobs_new / jobs_updated / jobs_delisted / jobs_unchanged.

Search the live job index by hard filters; returns ranked JobPosting[]. The server does ONLY a hard filter plus a fixed ranking of match-quality × freshness — precise re-ranking is left to you, the client, which holds the user's context. Every result includes the five protocol fields (verified_at, source, ghost_score, response_sla_days, apply_channel) plus datePosted, days_open, remote_scope, eligible_regions, role_group and ghost_reason. `verified_at` and `ghost_score` answer DIFFERENT questions and routinely disagree: a posting confirmed live today can score 1.0. Live means the employer's ATS still returns it; the score means it has been returned for a long time, or keeps being relisted. `ghost_reason` says which input drove the score ("age only: open 367d, never relisted") so you can tell the user that instead of a bare number. Neither field measures intent — a long-open role can equally mean hard-to-fill. `response_sla_days` is null on almost every row, and that is a meaningful null: it is the employer's OWN committed reply window, set only when they claim their tenant. We never infer or estimate it — the application deep-links to the employer and never touches this server, so we cannot observe a reply even in principle. Read null as "no employer has claimed this tenant", never as "missing data" or "slow". `employer_correction` appears only when the employer has claimed this tenant and said something about this specific role. It is the employer's own account, verified by corporate identity, and it sits BESIDE ghost_score, never on it: `status: "evergreen"` explains a high score (they hire continuously, so there is no single opening to fill), it does not lower it. `status: "closed"` means they say they are no longer hiring even though their ATS still returns the row, so stop sending people there. `date_semantics: "requisition_created"` means their ATS reports the day the req was opened internally rather than the day it went live, so days_open overstates for…

Register a standing intent so new matches can be pulled later. The caller supplies its OWN anonymous fingerprint (e.g. "#a3f9") — the client generates and owns it; the server stores but can never recover it, so persist it client-side and pass the identical one to check_watches. Only the fingerprint and non-PII filter keys are stored — never a name, email, phone or résumé. Accepted filter keys mirror search_jobs: `skills` (ANY-overlap), `required_skills` (ALL/AND — use this to keep sales / solutions-architect roles out), `remote` (bool), `role_family` (e.g. "engineering"), `min_salary` (int). Returns { watch_id, status, fingerprint, fingerprint_notice }.