Click element #n → returns the FRESH snapshot (popups become the active tab automatically).

Close the browser (the login profile persists on disk).

Evaluate JS on the page (extract hidden JSON, scroll, dismiss cookie banners).

The dominant form with human labels per field (n, tag, type, label, required, options) + likely submit buttons. Use once per application page, then browser_set fields by number.

Ensure we're signed in on a job board before applying. Opens the site; if signed out, walks 'Continue with Google' and picks the pre-approved account (active profile auth.google_account — the user allows this WITHOUT asking). Returns logged_in; needs_user=true on 2FA/ captcha/consent — then stop and ask the user to finish in the window.

Open a URL in the persistent application browser; returns the first snapshot. Logins survive between runs. Headed by default so the user can handle 2FA/captcha.

Press a page-level key (Enter, Tab, Escape) → fresh snapshot.

Save a PNG to data/screenshots — pass the path as evidence to record_application.

Set element #n to a value — one verb for every control: inputs → fill; selects → pick option value; checkboxes/radios → true/false → returns fresh snapshot.

Look at the page: numbered interactive elements + text. focus: 'inputs'|'buttons'|'links'; filter_text narrows by name (find 'Apply'); text_chars=0 → elements only, 6000 → reading mode. modal_only=true → ONLY the active dialog/wizard (question text + controls, hidden templates excluded) — use for apply wizards, then browser_set/click by number.

Tabs: list / select / close. Click-opened popups become active automatically — use this to switch back.

Type into #n key-by-key (fires JS handlers); submit=true presses Enter → fresh snapshot. Use for search boxes and chat fields.

Click upload control #n and send a local file (the CV path from start_application) → fresh snapshot.

Wait for time / text to appear ('Application submitted') / text to disappear (spinners) → returns a snapshot.

'Have we already applied here?' — by job_id, exact URL, or fuzzy title+company (catches the same vacancy re-found on another board). ALWAYS call before a manual browser application.

Fetch FULL job descriptions by opening pages in the browser. Accepts 1-10 job_ids (BATCH - prefer batching to save round-trips). Use for jobs where the parser returned null/short descriptions (common on Totaljobs/Reed). Stores descriptions back and re-runs the requirements check against your CVs. Also detects closed vacancies ("no longer accepting applications").

Details for selected jobs with adaptive batch sizing. Pass the same context_window/response_profile used for search_jobs. Compact returns up to 5 summaries or 2 full descriptions; balanced 12/5; wide 30/12. Request full descriptions only for plausible finalists. No job is deleted when a supplied job_ids list is truncated; request the remainder later.

Health/config snapshot: active candidate, local CV directory, DB stats, providers, API keys and saved searches. Call first in a session.

Application history (job, company, status, dates) — the long-term memory of everything already applied to.

CVs indexed from the active profile's local folder. Pass job_id to get per-CV recommendation scores for that job.

Search the LOCAL job database by criteria (no board calls). Use INSTEAD of Bash/sqlite: find all jobs from a company, filter by title keyword, location, source board, or freshness. Returns job_ids + titles + requirements status - then get_job / fetch_job_description for detail.

Write a cover letter as a DOCX file into CV_collection and return its path — ready for browser_upload as a supporting file. Boards like Totaljobs reject files smaller than 8KB, so the document is padded through metadata if the text alone is too short. Prefer DOCX over PDF here (PDFs from minimal text are usually under the limit).

Employer/recruiter exclusion memory. When the user says 'never apply to ' → action=add, kind=company, value=, reason=. kind=keyword blocks any vacancy whose title/description contains it. action: add | remove | list. Blocked jobs are hidden from search results and start_application refuses them until removed.

List candidate profiles or switch the active candidate.

    ``switch`` persists [general].active_profile in config.toml and takes
    effect immediately. It closes the old candidate's browser first, then
    changes the isolated CV folder, database/application history and
    browser-login folder. Always list/verify profiles before a
    search or application task for a named person.
    

Update an application: status planned|applying|submitted|interview| offer|rejected|withdrawn|failed; notes; evidence {screenshot: path,…}; cover_letter text.

Run a UK job search OR page an earlier one. Fresh search: pass query ('Data Analyst'…) or profile ('data_analytics'/'field_geologist'). Paging: pass search_id (+offset from next_offset), preferably by copying the returned next_page object. Response sizing: pass context_window and auto selects compact (<=80k), balanced (80k-300k), or wide (>=300k). Local Qwen 3.8 27B uses context_window=78000. You may instead pass response_profile explicitly. Optional limit requests a page size within that profile's safety cap (8/20/50). With no sizing signal the default is balanced (12). All remaining results stay stored. Results are ranked, cross-board duplicates merged (sources[]), with memory flags (already_applied, application_status) and location intelligence (work_mode, distance_miles from the active profile's home, location_status ok|mismatch|caution|unknown). PAID TRAINING/COURSE ADS (where you pay them, e.g. Netcom-style 'trainee' course marketing) are excluded automatically — training_offers_skipped shows how many; set include_training=true only if the user explicitly wants courses. location_policy: 'auto' (default), 'uk_wide', 'commute_only'. work_from_home=true restricts to remote.

Begin applying to a job. Returns the full plan: URL, apply method + site playbook, chosen CV (+alternatives), applicant profile values, step list, cautions (location mismatch, LinkedIn ToS…). REFUSES to create a second application for a job that already has one — that is the anti-double-apply memory (works across boards via dedup).

Feed jobs found via the harness's own browser (Indeed, CV-Library, LinkedIn, Glassdoor) into the same dedup + ranking store. Each observation: {source, url, title, company, location_text, salary_raw, description, posted_at?}. Returns stored count + duplicates merged.

Index CV files manually copied into the active profile's cv_dir. Unchanged files are skipped unless force=true. There is no cloud sync.