job-forge 2.0.2 → 2.1.0

package/.cursor/rules/main.mdc

@@ -14,16 +14,17 @@ The Hard Limits below are non-negotiable numeric rules. If you catch yourself ab
 3. **Always clean Geometra sessions before dispatching.** Before every round of `task` dispatches that will use Geometra, call `geometra_list_sessions` then `geometra_disconnect({closeBrowser: true})`. Every round. The disconnect is a no-op when the pool is empty.
 4. **Orchestrator does NOT fill forms.** This session MUST NOT call `geometra_fill_form`, `geometra_run_actions`, `geometra_pick_listbox_option`, or `geometra_fill_otp` when handling a multi-job request. If you need to, it means you MUST have delegated — `task` out the remaining work instead.
 5. **Re-dispatch only AFTER the previous subagent returns.** Never fire the same company's `task` twice while the first is still in-flight. Wait for the return value, then decide if a retry is warranted.
-6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `node merge-tracker.mjs` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `node merge-tracker.mjs` followed by `node verify-pipeline.mjs` before ending the session.
-7. **URLs passed to downstream subagents must come from a file, not from a prior subagent's prose.** When an orchestrator dispatches a subagent with a URL (for evaluation, apply, verification, etc.), the URL MUST originate from:
-   - `data/pipeline.md`
-   - `data/scan-history.tsv`
-   - `batch/scan-output-*.md` or similar structured output file
-   - A report file (`reports/{num}-*.md`) with an authoritative `**URL:**` header
+6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `npx job-forge merge` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `npx job-forge merge` followed by `npx job-forge verify` before ending the session.
+7. **Load-bearing facts passed to downstream subagents must come from a file, not from a prior subagent's prose.** A URL, score, email ID, confirmation page snippet, JD salary range, exact answer submitted to a form question, or any other specific value that a downstream subagent will act on MUST originate from one of:
+   - `data/pipeline.md` (URL inbox state)
+   - `data/scan-history.tsv` (scan provenance)
+   - `batch/scan-output-*.md` (scan-ranked candidates)
+   - A report file (`reports/{num}-*.md`) with authoritative headers (`**URL:**`, `**Score:**`, etc.)
+   - A TSV in `batch/tracker-additions/` (per-apply outcomes)
 
-   URLs mentioned in a subagent's return message are NOT trustworthy by default — they may be hallucinated or reconstructed. Before passing any URL from a subagent report to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
+   **Not trustworthy by default**: anything quoted from a subagent's return message, any ID or score the orchestrator "remembers" from prose, any page-content snippet reproduced from a subagent's narrative. Subagents can hallucinate plausible-looking IDs, scores, and confirmation text. Before passing any such fact to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
 
-   **Why**: a scan subagent once reported 30 plausible-looking Greenhouse IDs in its return message that did not exist in the Greenhouse API. The orchestrator dispatched 30 downstream subagents that all failed verification. Trusting prose-form URLs cost ~2 hours of wasted work and corrupted the tracker.
+   **Why**: on 2026-04-18, a scan subagent returned 30 fabricated Greenhouse IDs in prose (correct role titles, plausible-looking invented IDs that didn't exist in the API). The orchestrator dispatched 30 downstream subagents that all hit 404s. Verification rules downstream (Hard Limit #6, API-first verify) caught the symptom. This rule prevents the *shape* of the bug — hallucinations propagating through prose handoffs — across all quantitative / identifier / specific-fact claims, not just URLs.
 
 Everything below is context and rationale. These seven numbers are the rules.
 
@@ -45,6 +46,8 @@ Whenever the user says any variation of "apply to N jobs", "process the pipeline
 
 **Exception:** evaluation-only or tracker-only work (no Geometra, no repeated tool calls) can proceed in a single session. The rule targets tool-heavy multi-step loops.
 
+**Before any batch-apply dispatch, run the Apply Preflight location filter from `modes/apply.md`** to exclude location-incompatible candidates. Catches the common case where an evaluated role has the right role-shape but a deal-breaking location that profile.yml already rules out.
+
 ---
 
 ## Subagent Routing — which agent for which task
@@ -297,6 +300,8 @@ When a form says "enter the code we sent to your email", you MUST retrieve the c
 | Workday | `from:myworkday newer_than:10m` |
 | Lever | `from:lever newer_than:10m` |
 | Ashby | `from:ashby newer_than:10m` |
+| SmartRecruiters | `from:smartrecruiters newer_than:10m` |
+| Aggregator redirect (WeWorkRemotely / RemoteOK) | Detect the underlying ATS from the post-redirect URL, then use that row's sender query |
 | Unknown | `newer_than:10m subject:(verify OR code OR confirm)` |
 
 **Rules:**
@@ -471,7 +476,7 @@ To check or modify MCP settings, edit `opencode.json` in the project root.
 - JDs in `jds/` (referenced as `local:jds/{file}` in pipeline.md)
 - Batch in `batch/` (gitignored except scripts and prompt)
 - Report numbering: sequential 3-digit zero-padded, max existing + 1
-- **RULE: After each batch of evaluations, run `node merge-tracker.mjs`** to merge tracker additions and avoid duplications.
+- **RULE: After each batch of evaluations, run `npx job-forge merge`** to merge tracker additions and avoid duplications.
 - **RULE: NEVER create new entries in applications.md if company+role already exists.** Update the existing entry.
 - **RULE: NEVER attribute commits to opencode (no `Co-Authored-By: opencode` or similar).** All commits must be attributed solely to the person making the commit (e.g., CharlieGreenman).
 
@@ -498,13 +503,13 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 
 ### Pipeline Integrity
 
-1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `merge-tracker.mjs` handles the merge.
+1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `npx job-forge merge` handles the merge.
 2. **YES you can edit day files in `data/applications/` to UPDATE status/notes of existing entries.**
 3. All reports MUST include `**URL:**` in the header (between Score and PDF).
 4. All statuses MUST be canonical (see `templates/states.yml`).
-5. Health check: `node verify-pipeline.mjs`
-6. Normalize statuses: `node normalize-statuses.mjs`
-7. Dedup: `node dedup-tracker.mjs`
+5. Health check: `npx job-forge verify`
+6. Normalize statuses: `npx job-forge normalize`
+7. Dedup: `npx job-forge dedup`
 
 ### Canonical States (applications day files)
 
@@ -520,6 +525,7 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 | `Offer` | Offer received |
 | `Rejected` | Rejected by company |
 | `Discarded` | Discarded by candidate or offer closed |
+| `Failed` | Submission attempted but blocked by portal (spam-filter, anti-bot, broken form). May be recoverable via manual retry. |
 | `SKIP` | Doesn't fit, don't apply |
 
 **RULES:**

package/.opencode/skills/job-forge.md

@@ -163,8 +163,8 @@ Step 5  — Between rounds: clean sessions again
   - geometra_disconnect({ closeBrowser: true })
 
 Step 6  — After all rounds: reconcile outcomes (Hard Limit #6)
-  - bash: node merge-tracker.mjs      # consumes batch/tracker-additions/*.tsv into the day file
-  - bash: node verify-pipeline.mjs    # validates URL/status consistency
+  - bash: npx job-forge merge      # consumes batch/tracker-additions/*.tsv into the day file
+  - bash: npx job-forge verify     # validates URL/status consistency
   - Review output; if verify-pipeline reports issues, fix them before ending.
 
 Step 7  — Aggregate and report

package/AGENTS.md

@@ -9,16 +9,17 @@ The Hard Limits below are non-negotiable numeric rules. If you catch yourself ab
 3. **Always clean Geometra sessions before dispatching.** Before every round of `task` dispatches that will use Geometra, call `geometra_list_sessions` then `geometra_disconnect({closeBrowser: true})`. Every round. The disconnect is a no-op when the pool is empty.
 4. **Orchestrator does NOT fill forms.** This session MUST NOT call `geometra_fill_form`, `geometra_run_actions`, `geometra_pick_listbox_option`, or `geometra_fill_otp` when handling a multi-job request. If you need to, it means you MUST have delegated — `task` out the remaining work instead.
 5. **Re-dispatch only AFTER the previous subagent returns.** Never fire the same company's `task` twice while the first is still in-flight. Wait for the return value, then decide if a retry is warranted.
-6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `node merge-tracker.mjs` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `node merge-tracker.mjs` followed by `node verify-pipeline.mjs` before ending the session.
-7. **URLs passed to downstream subagents must come from a file, not from a prior subagent's prose.** When an orchestrator dispatches a subagent with a URL (for evaluation, apply, verification, etc.), the URL MUST originate from:
-   - `data/pipeline.md`
-   - `data/scan-history.tsv`
-   - `batch/scan-output-*.md` or similar structured output file
-   - A report file (`reports/{num}-*.md`) with an authoritative `**URL:**` header
+6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `npx job-forge merge` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `npx job-forge merge` followed by `npx job-forge verify` before ending the session.
+7. **Load-bearing facts passed to downstream subagents must come from a file, not from a prior subagent's prose.** A URL, score, email ID, confirmation page snippet, JD salary range, exact answer submitted to a form question, or any other specific value that a downstream subagent will act on MUST originate from one of:
+   - `data/pipeline.md` (URL inbox state)
+   - `data/scan-history.tsv` (scan provenance)
+   - `batch/scan-output-*.md` (scan-ranked candidates)
+   - A report file (`reports/{num}-*.md`) with authoritative headers (`**URL:**`, `**Score:**`, etc.)
+   - A TSV in `batch/tracker-additions/` (per-apply outcomes)
 
-   URLs mentioned in a subagent's return message are NOT trustworthy by default — they may be hallucinated or reconstructed. Before passing any URL from a subagent report to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
+   **Not trustworthy by default**: anything quoted from a subagent's return message, any ID or score the orchestrator "remembers" from prose, any page-content snippet reproduced from a subagent's narrative. Subagents can hallucinate plausible-looking IDs, scores, and confirmation text. Before passing any such fact to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
 
-   **Why**: a scan subagent once reported 30 plausible-looking Greenhouse IDs in its return message that did not exist in the Greenhouse API. The orchestrator dispatched 30 downstream subagents that all failed verification. Trusting prose-form URLs cost ~2 hours of wasted work and corrupted the tracker.
+   **Why**: on 2026-04-18, a scan subagent returned 30 fabricated Greenhouse IDs in prose (correct role titles, plausible-looking invented IDs that didn't exist in the API). The orchestrator dispatched 30 downstream subagents that all hit 404s. Verification rules downstream (Hard Limit #6, API-first verify) caught the symptom. This rule prevents the *shape* of the bug — hallucinations propagating through prose handoffs — across all quantitative / identifier / specific-fact claims, not just URLs.
 
 Everything below is context and rationale. These seven numbers are the rules.
 
@@ -40,6 +41,8 @@ Whenever the user says any variation of "apply to N jobs", "process the pipeline
 
 **Exception:** evaluation-only or tracker-only work (no Geometra, no repeated tool calls) can proceed in a single session. The rule targets tool-heavy multi-step loops.
 
+**Before any batch-apply dispatch, run the Apply Preflight location filter from `modes/apply.md`** to exclude location-incompatible candidates. Catches the common case where an evaluated role has the right role-shape but a deal-breaking location that profile.yml already rules out.
+
 ---
 
 ## Subagent Routing — which agent for which task
@@ -292,6 +295,8 @@ When a form says "enter the code we sent to your email", you MUST retrieve the c
 | Workday | `from:myworkday newer_than:10m` |
 | Lever | `from:lever newer_than:10m` |
 | Ashby | `from:ashby newer_than:10m` |
+| SmartRecruiters | `from:smartrecruiters newer_than:10m` |
+| Aggregator redirect (WeWorkRemotely / RemoteOK) | Detect the underlying ATS from the post-redirect URL, then use that row's sender query |
 | Unknown | `newer_than:10m subject:(verify OR code OR confirm)` |
 
 **Rules:**
@@ -466,7 +471,7 @@ To check or modify MCP settings, edit `opencode.json` in the project root.
 - JDs in `jds/` (referenced as `local:jds/{file}` in pipeline.md)
 - Batch in `batch/` (gitignored except scripts and prompt)
 - Report numbering: sequential 3-digit zero-padded, max existing + 1
-- **RULE: After each batch of evaluations, run `node merge-tracker.mjs`** to merge tracker additions and avoid duplications.
+- **RULE: After each batch of evaluations, run `npx job-forge merge`** to merge tracker additions and avoid duplications.
 - **RULE: NEVER create new entries in applications.md if company+role already exists.** Update the existing entry.
 - **RULE: NEVER attribute commits to opencode (no `Co-Authored-By: opencode` or similar).** All commits must be attributed solely to the person making the commit (e.g., CharlieGreenman).
 
@@ -493,13 +498,13 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 
 ### Pipeline Integrity
 
-1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `merge-tracker.mjs` handles the merge.
+1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `npx job-forge merge` handles the merge.
 2. **YES you can edit day files in `data/applications/` to UPDATE status/notes of existing entries.**
 3. All reports MUST include `**URL:**` in the header (between Score and PDF).
 4. All statuses MUST be canonical (see `templates/states.yml`).
-5. Health check: `node verify-pipeline.mjs`
-6. Normalize statuses: `node normalize-statuses.mjs`
-7. Dedup: `node dedup-tracker.mjs`
+5. Health check: `npx job-forge verify`
+6. Normalize statuses: `npx job-forge normalize`
+7. Dedup: `npx job-forge dedup`
 
 ### Canonical States (applications day files)
 
@@ -515,6 +520,7 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 | `Offer` | Offer received |
 | `Rejected` | Rejected by company |
 | `Discarded` | Discarded by candidate or offer closed |
+| `Failed` | Submission attempted but blocked by portal (spam-filter, anti-bot, broken form). May be recoverable via manual retry. |
 | `SKIP` | Doesn't fit, don't apply |
 
 **RULES:**

package/CLAUDE.md

@@ -9,16 +9,17 @@ The Hard Limits below are non-negotiable numeric rules. If you catch yourself ab
 3. **Always clean Geometra sessions before dispatching.** Before every round of `task` dispatches that will use Geometra, call `geometra_list_sessions` then `geometra_disconnect({closeBrowser: true})`. Every round. The disconnect is a no-op when the pool is empty.
 4. **Orchestrator does NOT fill forms.** This session MUST NOT call `geometra_fill_form`, `geometra_run_actions`, `geometra_pick_listbox_option`, or `geometra_fill_otp` when handling a multi-job request. If you need to, it means you MUST have delegated — `task` out the remaining work instead.
 5. **Re-dispatch only AFTER the previous subagent returns.** Never fire the same company's `task` twice while the first is still in-flight. Wait for the return value, then decide if a retry is warranted.
-6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `node merge-tracker.mjs` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `node merge-tracker.mjs` followed by `node verify-pipeline.mjs` before ending the session.
-7. **URLs passed to downstream subagents must come from a file, not from a prior subagent's prose.** When an orchestrator dispatches a subagent with a URL (for evaluation, apply, verification, etc.), the URL MUST originate from:
-   - `data/pipeline.md`
-   - `data/scan-history.tsv`
-   - `batch/scan-output-*.md` or similar structured output file
-   - A report file (`reports/{num}-*.md`) with an authoritative `**URL:**` header
+6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `npx job-forge merge` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `npx job-forge merge` followed by `npx job-forge verify` before ending the session.
+7. **Load-bearing facts passed to downstream subagents must come from a file, not from a prior subagent's prose.** A URL, score, email ID, confirmation page snippet, JD salary range, exact answer submitted to a form question, or any other specific value that a downstream subagent will act on MUST originate from one of:
+   - `data/pipeline.md` (URL inbox state)
+   - `data/scan-history.tsv` (scan provenance)
+   - `batch/scan-output-*.md` (scan-ranked candidates)
+   - A report file (`reports/{num}-*.md`) with authoritative headers (`**URL:**`, `**Score:**`, etc.)
+   - A TSV in `batch/tracker-additions/` (per-apply outcomes)
 
-   URLs mentioned in a subagent's return message are NOT trustworthy by default — they may be hallucinated or reconstructed. Before passing any URL from a subagent report to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
+   **Not trustworthy by default**: anything quoted from a subagent's return message, any ID or score the orchestrator "remembers" from prose, any page-content snippet reproduced from a subagent's narrative. Subagents can hallucinate plausible-looking IDs, scores, and confirmation text. Before passing any such fact to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
 
-   **Why**: a scan subagent once reported 30 plausible-looking Greenhouse IDs in its return message that did not exist in the Greenhouse API. The orchestrator dispatched 30 downstream subagents that all failed verification. Trusting prose-form URLs cost ~2 hours of wasted work and corrupted the tracker.
+   **Why**: on 2026-04-18, a scan subagent returned 30 fabricated Greenhouse IDs in prose (correct role titles, plausible-looking invented IDs that didn't exist in the API). The orchestrator dispatched 30 downstream subagents that all hit 404s. Verification rules downstream (Hard Limit #6, API-first verify) caught the symptom. This rule prevents the *shape* of the bug — hallucinations propagating through prose handoffs — across all quantitative / identifier / specific-fact claims, not just URLs.
 
 Everything below is context and rationale. These seven numbers are the rules.
 
@@ -40,6 +41,8 @@ Whenever the user says any variation of "apply to N jobs", "process the pipeline
 
 **Exception:** evaluation-only or tracker-only work (no Geometra, no repeated tool calls) can proceed in a single session. The rule targets tool-heavy multi-step loops.
 
+**Before any batch-apply dispatch, run the Apply Preflight location filter from `modes/apply.md`** to exclude location-incompatible candidates. Catches the common case where an evaluated role has the right role-shape but a deal-breaking location that profile.yml already rules out.
+
 ---
 
 ## Subagent Routing — which agent for which task
@@ -292,6 +295,8 @@ When a form says "enter the code we sent to your email", you MUST retrieve the c
 | Workday | `from:myworkday newer_than:10m` |
 | Lever | `from:lever newer_than:10m` |
 | Ashby | `from:ashby newer_than:10m` |
+| SmartRecruiters | `from:smartrecruiters newer_than:10m` |
+| Aggregator redirect (WeWorkRemotely / RemoteOK) | Detect the underlying ATS from the post-redirect URL, then use that row's sender query |
 | Unknown | `newer_than:10m subject:(verify OR code OR confirm)` |
 
 **Rules:**
@@ -466,7 +471,7 @@ To check or modify MCP settings, edit `opencode.json` in the project root.
 - JDs in `jds/` (referenced as `local:jds/{file}` in pipeline.md)
 - Batch in `batch/` (gitignored except scripts and prompt)
 - Report numbering: sequential 3-digit zero-padded, max existing + 1
-- **RULE: After each batch of evaluations, run `node merge-tracker.mjs`** to merge tracker additions and avoid duplications.
+- **RULE: After each batch of evaluations, run `npx job-forge merge`** to merge tracker additions and avoid duplications.
 - **RULE: NEVER create new entries in applications.md if company+role already exists.** Update the existing entry.
 - **RULE: NEVER attribute commits to opencode (no `Co-Authored-By: opencode` or similar).** All commits must be attributed solely to the person making the commit (e.g., CharlieGreenman).
 
@@ -493,13 +498,13 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 
 ### Pipeline Integrity
 
-1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `merge-tracker.mjs` handles the merge.
+1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `npx job-forge merge` handles the merge.
 2. **YES you can edit day files in `data/applications/` to UPDATE status/notes of existing entries.**
 3. All reports MUST include `**URL:**` in the header (between Score and PDF).
 4. All statuses MUST be canonical (see `templates/states.yml`).
-5. Health check: `node verify-pipeline.mjs`
-6. Normalize statuses: `node normalize-statuses.mjs`
-7. Dedup: `node dedup-tracker.mjs`
+5. Health check: `npx job-forge verify`
+6. Normalize statuses: `npx job-forge normalize`
+7. Dedup: `npx job-forge dedup`
 
 ### Canonical States (applications day files)
 
@@ -515,6 +520,7 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 | `Offer` | Offer received |
 | `Rejected` | Rejected by company |
 | `Discarded` | Discarded by candidate or offer closed |
+| `Failed` | Submission attempted but blocked by portal (spam-filter, anti-bot, broken form). May be recoverable via manual retry. |
 | `SKIP` | Doesn't fit, don't apply |
 
 **RULES:**

package/batch/README.md

@@ -51,7 +51,7 @@ npm run merge
 npm run verify   # optional: pipeline health after merge (report links, statuses, pending TSVs)
 ```
 
-(`node merge-tracker.mjs` — same as `npm run merge`; see [CONTRIBUTING.md](../CONTRIBUTING.md#development).)
+(`npx job-forge merge` — same as `npm run merge`; see [CONTRIBUTING.md](../CONTRIBUTING.md#development).)
 
 After a successful merge, each processed file is moved to **`batch/tracker-additions/merged/`** (created on first merge when the directory does not yet exist). `npm run verify` only looks for `*.tsv` files in the **top level** of `batch/tracker-additions/`, so rows already merged and archived under `merged/` do not trigger the “pending TSVs” warning.
 

package/batch/batch-prompt.md

@@ -243,7 +243,7 @@ Where `{company-slug}` is the company name in lowercase, no spaces, with hyphens
 12. Write HTML to `/tmp/cv-candidate-{company-slug}.html`
 13. Run:
 ```bash
-node generate-pdf.mjs \
+npx job-forge pdf \
   /tmp/cv-candidate-{company-slug}.html \
   output/cv-candidate-{company-slug}-{{DATE}}.pdf \
   --format={letter|a4}

package/config/profile.example.yml

@@ -65,3 +65,24 @@ location:
   visa_status: "No sponsorship needed"
   # For remote roles outside your country:
   # onsite_availability: "1 week/month in any city"
+
+# Structured location constraints — consumed by the Apply Preflight location
+# filter in modes/apply.md. The prose fields above (compensation.location_flexibility,
+# location.*) remain for human readability and LLM narrative context; the fields
+# below govern automated, deterministic compatibility checks before dispatching
+# an apply subagent.
+#
+# City names are lowercase, hyphenated (e.g. "san-francisco", "new-york").
+# Country codes are ISO-3166 alpha-2 uppercase (e.g. "US", "CA", "GB").
+location_constraints:
+  remote_us: true                      # open to US-remote roles
+  remote_global: false                 # open to non-US remote (visa / timezone permitting)
+  hybrid_cities:                       # cities where hybrid N-days-in-office is acceptable
+    - san-francisco
+  blocked_cities:                      # cities that are a hard No for relocation (even if hybrid)
+    - new-york
+    - london
+  authorized_countries:                # countries where the candidate has right-to-work
+    - US
+  requires_visa_sponsorship: false     # true → roles in non-authorized countries are blocked unless
+                                       # the JD explicitly mentions visa sponsorship

package/docs/ARCHITECTURE.md

@@ -53,8 +53,8 @@ The skill router (`.opencode/skills/job-forge.md`) loads mode and data files on
 
 ```
                     ┌─────────────────────────────────┐
-                    │         opencode Agent        │
-                    │   (reads OPENCODE.md + modes/*.md) │
+                    │            Agent                │
+                    │   (reads AGENTS.md + modes/*.md) │
                     └──────────┬──────────────────────┘
                                │
             ┌──────────────────┼──────────────────────┐
@@ -85,7 +85,7 @@ The skill router (`.opencode/skills/job-forge.md`) loads mode and data files on
 
 ## Modes (`modes/`)
 
-Markdown mode files in `modes/` define how the opencode workflow behaves together with the root `OPENCODE.md`. **`_shared.md`** is the shared layer (archetypes, scoring dimensions, negotiation scaffolding); the rest align with `/job-forge` command entry points listed in `OPENCODE.md`.
+Markdown mode files in `modes/` define how the workflow behaves together with the root `AGENTS.md`. **`_shared.md`** is the shared layer (archetypes, scoring dimensions, negotiation scaffolding); the rest align with `/job-forge` command entry points listed in `AGENTS.md`.
 
 | File | Focus |
 |------|--------|
@@ -124,7 +124,7 @@ For customization (archetypes, weights, tone), start with `_shared.md` and [CUST
 5. **Score**: Weighted average across 10 dimensions (1-5)
 6. **Report**: Save as `reports/{num}-{company}-{date}.md`
 7. **PDF**: Generate ATS-optimized CV (`generate-pdf.mjs`)
-8. **Track**: Write one TSV per evaluation under `batch/tracker-additions/` (see [OPENCODE.md](../OPENCODE.md) TSV layout); fold rows into `data/applications.md` with `npm run merge` / `merge-tracker.mjs` when you are ready (not automatic in every workflow)
+8. **Track**: Write one TSV per evaluation under `batch/tracker-additions/` (see [AGENTS.md](../AGENTS.md) TSV layout); fold rows into `data/applications.md` with `npm run merge` / `merge-tracker.mjs` when you are ready (not automatic in every workflow)
 
 ## Batch Processing
 

package/iso/commands/job-forge.md

@@ -166,8 +166,8 @@ Step 5  — Between rounds: clean sessions again
   - geometra_disconnect({ closeBrowser: true })
 
 Step 6  — After all rounds: reconcile outcomes (Hard Limit #6)
-  - bash: node merge-tracker.mjs      # consumes batch/tracker-additions/*.tsv into the day file
-  - bash: node verify-pipeline.mjs    # validates URL/status consistency
+  - bash: npx job-forge merge      # consumes batch/tracker-additions/*.tsv into the day file
+  - bash: npx job-forge verify     # validates URL/status consistency
   - Review output; if verify-pipeline reports issues, fix them before ending.
 
 Step 7  — Aggregate and report

package/iso/instructions.md

@@ -9,16 +9,17 @@ The Hard Limits below are non-negotiable numeric rules. If you catch yourself ab
 3. **Always clean Geometra sessions before dispatching.** Before every round of `task` dispatches that will use Geometra, call `geometra_list_sessions` then `geometra_disconnect({closeBrowser: true})`. Every round. The disconnect is a no-op when the pool is empty.
 4. **Orchestrator does NOT fill forms.** This session MUST NOT call `geometra_fill_form`, `geometra_run_actions`, `geometra_pick_listbox_option`, or `geometra_fill_otp` when handling a multi-job request. If you need to, it means you MUST have delegated — `task` out the remaining work instead.
 5. **Re-dispatch only AFTER the previous subagent returns.** Never fire the same company's `task` twice while the first is still in-flight. Wait for the return value, then decide if a retry is warranted.
-6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `node merge-tracker.mjs` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `node merge-tracker.mjs` followed by `node verify-pipeline.mjs` before ending the session.
-7. **URLs passed to downstream subagents must come from a file, not from a prior subagent's prose.** When an orchestrator dispatches a subagent with a URL (for evaluation, apply, verification, etc.), the URL MUST originate from:
-   - `data/pipeline.md`
-   - `data/scan-history.tsv`
-   - `batch/scan-output-*.md` or similar structured output file
-   - A report file (`reports/{num}-*.md`) with an authoritative `**URL:**` header
+6. **Application outcomes flow through TSVs, not `data/pipeline.md`.** When a subagent returns APPLIED / FAILED / SKIP, the outcome goes to `batch/tracker-additions/{num}-{slug}.tsv`. `npx job-forge merge` then consumes the TSVs into the correct `data/applications/YYYY-MM-DD.md` day file. `data/pipeline.md` only tracks URL inbox state (`[ ]` pending → `[x]` processed). **NEVER append APPLIED / FAILED status lines to `pipeline.md`** — that's the day file's job, via the TSV pathway. After any multi-apply run, the orchestrator MUST run `npx job-forge merge` followed by `npx job-forge verify` before ending the session.
+7. **Load-bearing facts passed to downstream subagents must come from a file, not from a prior subagent's prose.** A URL, score, email ID, confirmation page snippet, JD salary range, exact answer submitted to a form question, or any other specific value that a downstream subagent will act on MUST originate from one of:
+   - `data/pipeline.md` (URL inbox state)
+   - `data/scan-history.tsv` (scan provenance)
+   - `batch/scan-output-*.md` (scan-ranked candidates)
+   - A report file (`reports/{num}-*.md`) with authoritative headers (`**URL:**`, `**Score:**`, etc.)
+   - A TSV in `batch/tracker-additions/` (per-apply outcomes)
 
-   URLs mentioned in a subagent's return message are NOT trustworthy by default — they may be hallucinated or reconstructed. Before passing any URL from a subagent report to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
+   **Not trustworthy by default**: anything quoted from a subagent's return message, any ID or score the orchestrator "remembers" from prose, any page-content snippet reproduced from a subagent's narrative. Subagents can hallucinate plausible-looking IDs, scores, and confirmation text. Before passing any such fact to another subagent, cross-check it exists in one of the authoritative files above, OR instruct the dispatching subagent to write its output to a structured file and re-read from that file.
 
-   **Why**: a scan subagent once reported 30 plausible-looking Greenhouse IDs in its return message that did not exist in the Greenhouse API. The orchestrator dispatched 30 downstream subagents that all failed verification. Trusting prose-form URLs cost ~2 hours of wasted work and corrupted the tracker.
+   **Why**: on 2026-04-18, a scan subagent returned 30 fabricated Greenhouse IDs in prose (correct role titles, plausible-looking invented IDs that didn't exist in the API). The orchestrator dispatched 30 downstream subagents that all hit 404s. Verification rules downstream (Hard Limit #6, API-first verify) caught the symptom. This rule prevents the *shape* of the bug — hallucinations propagating through prose handoffs — across all quantitative / identifier / specific-fact claims, not just URLs.
 
 Everything below is context and rationale. These seven numbers are the rules.
 
@@ -40,6 +41,8 @@ Whenever the user says any variation of "apply to N jobs", "process the pipeline
 
 **Exception:** evaluation-only or tracker-only work (no Geometra, no repeated tool calls) can proceed in a single session. The rule targets tool-heavy multi-step loops.
 
+**Before any batch-apply dispatch, run the Apply Preflight location filter from `modes/apply.md`** to exclude location-incompatible candidates. Catches the common case where an evaluated role has the right role-shape but a deal-breaking location that profile.yml already rules out.
+
 ---
 
 ## Subagent Routing — which agent for which task
@@ -292,6 +295,8 @@ When a form says "enter the code we sent to your email", you MUST retrieve the c
 | Workday | `from:myworkday newer_than:10m` |
 | Lever | `from:lever newer_than:10m` |
 | Ashby | `from:ashby newer_than:10m` |
+| SmartRecruiters | `from:smartrecruiters newer_than:10m` |
+| Aggregator redirect (WeWorkRemotely / RemoteOK) | Detect the underlying ATS from the post-redirect URL, then use that row's sender query |
 | Unknown | `newer_than:10m subject:(verify OR code OR confirm)` |
 
 **Rules:**
@@ -466,7 +471,7 @@ To check or modify MCP settings, edit `opencode.json` in the project root.
 - JDs in `jds/` (referenced as `local:jds/{file}` in pipeline.md)
 - Batch in `batch/` (gitignored except scripts and prompt)
 - Report numbering: sequential 3-digit zero-padded, max existing + 1
-- **RULE: After each batch of evaluations, run `node merge-tracker.mjs`** to merge tracker additions and avoid duplications.
+- **RULE: After each batch of evaluations, run `npx job-forge merge`** to merge tracker additions and avoid duplications.
 - **RULE: NEVER create new entries in applications.md if company+role already exists.** Update the existing entry.
 - **RULE: NEVER attribute commits to opencode (no `Co-Authored-By: opencode` or similar).** All commits must be attributed solely to the person making the commit (e.g., CharlieGreenman).
 
@@ -493,13 +498,13 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 
 ### Pipeline Integrity
 
-1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `merge-tracker.mjs` handles the merge.
+1. **NEVER edit day files in `data/applications/` to ADD new entries** -- Write TSV in `batch/tracker-additions/` and `npx job-forge merge` handles the merge.
 2. **YES you can edit day files in `data/applications/` to UPDATE status/notes of existing entries.**
 3. All reports MUST include `**URL:**` in the header (between Score and PDF).
 4. All statuses MUST be canonical (see `templates/states.yml`).
-5. Health check: `node verify-pipeline.mjs`
-6. Normalize statuses: `node normalize-statuses.mjs`
-7. Dedup: `node dedup-tracker.mjs`
+5. Health check: `npx job-forge verify`
+6. Normalize statuses: `npx job-forge normalize`
+7. Dedup: `npx job-forge dedup`
 
 ### Canonical States (applications day files)
 
@@ -515,6 +520,7 @@ Write one TSV file per evaluation to `batch/tracker-additions/{num}-{company-slu
 | `Offer` | Offer received |
 | `Rejected` | Rejected by company |
 | `Discarded` | Discarded by candidate or offer closed |
+| `Failed` | Submission attempted but blocked by portal (spam-filter, anti-bot, broken form). May be recoverable via manual retry. |
 | `SKIP` | Doesn't fit, don't apply |
 
 **RULES:**

package/lib/canonical-states.mjs

@@ -0,0 +1,116 @@
+/**
+ * canonical-states.mjs — single source of truth for JobForge canonical states.
+ *
+ * `templates/states.yml` is the authoritative list. This module reads it
+ * (when available) and provides a hardcoded fallback that MUST stay in sync
+ * with the YAML for the belt-and-suspenders case where the file is missing.
+ *
+ * Consumers:
+ *   - merge-tracker.mjs          — validation + TSV column-swap heuristic
+ *   - normalize-statuses.mjs     — canonical list for direct matching
+ *
+ * The dashboard (Go) currently duplicates this list in
+ *   dashboard/internal/ui/screens/pipeline.go  (statusOptions, statusGroupOrder, statusLabel)
+ *   dashboard/internal/data/career.go          (NormalizeStatus, StatusPriority)
+ * Full codegen from YAML on the Go side is a follow-up; for now those
+ * copies carry KEEP IN SYNC comments.
+ */
+
+import { readFileSync, existsSync } from 'fs';
+import { join } from 'path';
+
+/**
+ * Fallback canonical labels, in display order matching templates/states.yml.
+ * Used when the YAML file can't be read. Keep in sync with the YAML.
+ */
+export const DEFAULT_STATES = [
+  'Evaluated',
+  'Applied',
+  'Responded',
+  'Contacted',
+  'Interview',
+  'Offer',
+  'Rejected',
+  'Discarded',
+  'Failed',
+  'SKIP',
+];
+
+/**
+ * Extra tokens the column-swap heuristic recognises as "this column looks
+ * like a status". Canonical labels plus historical aliases the tracker has
+ * been known to emit (duplicate/repost/hold). Kept here so that both
+ * merge-tracker.mjs and any future consumer see the same alias set.
+ */
+const STATUS_DETECT_EXTRAS = ['duplicate', 'repost', 'hold'];
+
+/**
+ * Parse `templates/states.yml` and return the ordered list of canonical
+ * labels. Returns null when the file is missing or contains no labels,
+ * so callers can fall back to DEFAULT_STATES.
+ *
+ * The parser intentionally uses a line-regex rather than pulling in a
+ * YAML dependency — job-forge has no runtime YAML parser and we don't
+ * want to add one just for this.
+ *
+ * @param {string} repoRoot - repo root where `templates/states.yml` lives.
+ *                            Also checks `states.yml` at the root as a legacy fallback.
+ * @returns {string[] | null}
+ */
+export function loadCanonicalStates(repoRoot) {
+  const candidates = [
+    join(repoRoot, 'templates/states.yml'),
+    join(repoRoot, 'states.yml'),
+  ];
+
+  for (const filePath of candidates) {
+    if (!existsSync(filePath)) continue;
+    let text;
+    try {
+      text = readFileSync(filePath, 'utf-8');
+    } catch {
+      continue;
+    }
+    const labels = [];
+    for (const line of text.split('\n')) {
+      const m = line.match(/^\s+label:\s*(.+)$/);
+      if (!m) continue;
+      const v = m[1].trim().replace(/^['"]|['"]$/g, '');
+      if (v) labels.push(v);
+    }
+    if (labels.length > 0) return labels;
+  }
+  return null;
+}
+
+/**
+ * Build the case-insensitive "does this column look like a status?" regex
+ * used by merge-tracker.mjs to detect swapped status/score columns in
+ * legacy TSVs.
+ *
+ * Matches at the start of the column text, case-insensitive. Includes the
+ * canonical labels plus alias tokens (duplicate/repost/hold) that have
+ * historically appeared in the status column.
+ *
+ * @param {string[]} states - canonical labels (typically the output of
+ *                            loadCanonicalStates, or DEFAULT_STATES).
+ * @returns {RegExp}
+ */
+export function buildStatusDetectionRegex(states) {
+  const tokens = [
+    ...states.map((s) => s.toLowerCase()),
+    ...STATUS_DETECT_EXTRAS,
+  ];
+  // Dedupe while preserving order.
+  const seen = new Set();
+  const unique = [];
+  for (const t of tokens) {
+    if (!seen.has(t)) {
+      seen.add(t);
+      unique.push(t);
+    }
+  }
+  // Escape regex-special chars just in case a label ever contains one.
+  const escaped = unique.map((t) => t.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'));
+  return new RegExp(`^(${escaped.join('|')})`, 'i');
+}

package/merge-tracker.mjs

@@ -26,6 +26,9 @@ import {
   usesDayFiles, ensureDayDir, getHeader, formatAppLine, parseAppLine,
   readAllEntries, writeToDayFiles, listDayFiles, dayFilePath,
 } from './tracker-lib.mjs';
+import {
+  DEFAULT_STATES, loadCanonicalStates, buildStatusDetectionRegex,
+} from './lib/canonical-states.mjs';
 
 const ADDITIONS_DIR = join(PROJECT_DIR, 'batch/tracker-additions');
 const MERGED_DIR = join(ADDITIONS_DIR, 'merged');
@@ -54,26 +57,8 @@ Run from the repository root.`);
   process.exit(0);
 }
 
-const STATES_FILE = existsSync(join(PROJECT_DIR, 'templates/states.yml'))
-  ? join(PROJECT_DIR, 'templates/states.yml')
-  : join(PROJECT_DIR, 'states.yml');
-
-function loadCanonicalLabelsFromStatesYaml(filePath) {
-  if (!existsSync(filePath)) return null;
-  const text = readFileSync(filePath, 'utf-8');
-  const labels = [];
-  for (const line of text.split('\n')) {
-    const m = line.match(/^\s+label:\s*(.+)$/);
-    if (!m) continue;
-    let v = m[1].trim().replace(/^['"]|['"]$/g, '');
-    if (v) labels.push(v);
-  }
-  return labels.length > 0 ? labels : null;
-}
-
-const CANONICAL_STATES = loadCanonicalLabelsFromStatesYaml(STATES_FILE) || [
-  'Evaluated', 'Applied', 'Contacted', 'Responded', 'Interview', 'Offer', 'Rejected', 'Discarded', 'SKIP',
-];
+const CANONICAL_STATES = loadCanonicalStates(PROJECT_DIR) || DEFAULT_STATES;
+const STATUS_DETECT_RE = buildStatusDetectionRegex(CANONICAL_STATES);
 
 function validateStatus(status) {
   const clean = status.replace(/\*\*/g, '').replace(/\s+\d{4}-\d{2}-\d{2}.*$/, '').trim();
@@ -156,8 +141,8 @@ function parseTsvContent(content, filename) {
     const col5 = parts[5].trim();
     const col4LooksLikeScore = /^\d+\.?\d*\/5$/.test(col4) || col4 === 'N/A' || col4 === 'DUP';
     const col5LooksLikeScore = /^\d+\.?\d*\/5$/.test(col5) || col5 === 'N/A' || col5 === 'DUP';
-    const col4LooksLikeStatus = /^(evaluated|applied|contacted|responded|interview|offer|rejected|discarded|skip|duplicate|repost|hold)/i.test(col4);
-    const col5LooksLikeStatus = /^(evaluated|applied|contacted|responded|interview|offer|rejected|discarded|skip|duplicate|repost|hold)/i.test(col5);
+    const col4LooksLikeStatus = STATUS_DETECT_RE.test(col4);
+    const col5LooksLikeStatus = STATUS_DETECT_RE.test(col5);
 
     let statusCol, scoreCol;
     if (col4LooksLikeStatus && !col4LooksLikeScore) {

package/modes/README.md

@@ -1,9 +1,9 @@
 # Modes
 
-Markdown prompts used with opencode together with the root [`OPENCODE.md`](../OPENCODE.md). Each file aligns with a `/job-forge …` entry point or shared behavior described there.
+Markdown prompts used together with the root [`AGENTS.md`](../AGENTS.md). Each file aligns with a `/job-forge …` entry point or shared behavior described there.
 
 - **`_shared.md`** — Archetypes, scoring dimensions, negotiation scaffolding. Edit this first when you change how offers are classified or weighted.
-- **Per-command files** — Each `*.md` here pairs with a `/job-forge …` entry in [`OPENCODE.md`](../OPENCODE.md). How modes connect to batch, tracker, and scripts is spelled out in [**Architecture — Modes**](../docs/ARCHITECTURE.md#modes-modes).
+- **Per-command files** — Each `*.md` here pairs with a `/job-forge …` entry in [`AGENTS.md`](../AGENTS.md). How modes connect to batch, tracker, and scripts is spelled out in [**Architecture — Modes**](../docs/ARCHITECTURE.md#modes-modes).
 
 | File | Role |
 |------|------|

package/modes/_shared.md

@@ -247,7 +247,7 @@ If the candidate has a live demo/dashboard (check profile.yml), offer access in
 
 0. **Cover letter:** If the form has an option to attach or write a cover letter, ALWAYS include one. Generate PDF with the same visual design as the CV. Content: JD quotes mapped to proof points, links to relevant case studies. 1 page max.
 1. Read cv.md and article-digest.md (if exists) before evaluating any offer
-1b. **First evaluation of each session:** Run `node cv-sync-check.mjs` with Bash. If it reports warnings, notify the candidate before continuing
+1b. **First evaluation of each session:** Run `npx job-forge sync-check` with Bash. If it reports warnings, notify the candidate before continuing
 2. Detect the role archetype and adapt framing
 3. Cite exact lines from CV when matching
 4. Use WebSearch for comp and company data
@@ -269,4 +269,4 @@ If the candidate has a live demo/dashboard (check profile.yml), offer access in
 | Read | cv.md, article-digest.md, cv-template.html |
 | Write | Temporary HTML for PDF, day files in `data/applications/YYYY-MM-DD.md`, reports .md |
 | Edit | Update tracker |
-| Bash | `node generate-pdf.mjs` |
+| Bash | `npx job-forge pdf` |

package/modes/apply.md

@@ -10,6 +10,54 @@ Interactive mode for when the candidate is filling out an application form in Ch
 
 For a single application interactively, carry on in the current session — the rule targets multi-job loops.
 
+## Apply Preflight — Location Filter (orchestrator runs before dispatch)
+
+Before dispatching any batch of apply subagents, cross-check each candidate's location against `config/profile.yml`. **Prefer the structured `location_constraints` block** (deterministic match). Fall back to the prose `location.*` / `compensation.location_flexibility` fields only when `location_constraints` is absent (legacy profiles).
+
+### Preferred path — structured `location_constraints` (deterministic)
+
+1. Read `config/profile.yml → location_constraints`. If present, use the structured fields:
+
+   ```yaml
+   location_constraints:
+     remote_us: true | false
+     remote_global: true | false
+     hybrid_cities: [san-francisco, ...]
+     blocked_cities: [new-york, ...]
+     authorized_countries: [US, ...]       # ISO-3166 alpha-2
+     requires_visa_sponsorship: true | false
+   ```
+
+2. For each candidate, open its evaluation report (`reports/{num}-*.md`) and read the Location / Block A content. Extract: `mode ∈ {remote, hybrid, onsite}`, `city` (lowercase hyphenated), `country` (ISO-3166 alpha-2 when derivable).
+
+3. Apply the filter (decision table):
+
+   | Role shape | Rule | Outcome |
+   |---|---|---|
+   | Remote, country ∈ authorized_countries (typically US) | `remote_us == true` → COMPATIBLE | dispatch |
+   | Remote, country ∉ authorized_countries | `remote_global == true` AND (`requires_visa_sponsorship == false` OR JD mentions sponsorship) → COMPATIBLE | dispatch / else skip |
+   | Hybrid, `city ∈ hybrid_cities` | COMPATIBLE | dispatch |
+   | Hybrid or Onsite, `city ∈ blocked_cities` | INCOMPATIBLE | mark `Discarded`, note `location mismatch: blocked_city=X` |
+   | Hybrid or Onsite, `city` not in `hybrid_cities` and not in `blocked_cities` | INCOMPATIBLE by default (hybrid is opt-in per city) | mark `Discarded`, note `location mismatch: city=X not in hybrid_cities` |
+   | Location unclear / ambiguous | dispatch with a prompt flag instructing the apply subagent to verify the JD location first and Discard early if confirmed incompatible | dispatch-with-flag |
+
+4. Country/visa: if `requires_visa_sponsorship == false` AND `country ∉ authorized_countries` AND the JD does NOT explicitly offer sponsorship → INCOMPATIBLE, do NOT dispatch.
+
+### Fallback path — prose fields (legacy profiles with no `location_constraints`)
+
+When `location_constraints` is absent, use the prose fields:
+
+1. Read `config/profile.yml` for `location` (country, city), `compensation.location_flexibility`, and `visa_status`.
+2. For each candidate, open its evaluation report (`reports/{num}-*.md`) and read the Location / Block A content.
+3. Apply the filter:
+   - If the report says "Remote (US)" / "Remote" / "fully remote" — COMPATIBLE, dispatch.
+   - If the report says "Hybrid N days in {city}" AND {city} matches `location.city` OR `location_flexibility` says "open to hybrid in {city}" — COMPATIBLE, dispatch.
+   - If the report says "Hybrid" or "Onsite" at a city NOT in the profile's location set AND `location_flexibility` says Remote-preferred — INCOMPATIBLE, do NOT dispatch. Mark the tracker entry `Discarded` directly with note `location mismatch: profile=X, role=Y`.
+   - If unclear or ambiguous — dispatch with a prompt flag telling the apply subagent to verify the JD location first and Discard early if confirmed incompatible.
+4. Country/visa: if `visa_status: "No sponsorship needed"` and the role is outside the authorized country — INCOMPATIBLE, do NOT dispatch.
+
+**Why**: on 2026-04-18, 5 of 7 candidates dispatched for apply turned out location-incompatible. Each burned an apply-subagent round. The prose-field path reached the right call but cost interpretation cycles per dispatch; the structured path is O(1) field lookup and removes LLM-interpretation risk.
+
 ### Run this multi-job apply runbook literally when N > 1
 
 ```
@@ -24,8 +72,8 @@ Step 4  — For round in ceil(N/2):
             # WAIT for both returns. Do not proceed until both done.
 Step 5  — Between rounds: geometra_list_sessions() + geometra_disconnect({closeBrowser: true})
 Step 6  — Reconcile outcomes (Hard Limit #6):
-            bash: node merge-tracker.mjs       # TSVs → day file
-            bash: node verify-pipeline.mjs     # validate
+            bash: npx job-forge merge       # TSVs → day file
+            bash: npx job-forge verify      # validate
 Step 7  — Summarize outcomes; do NOT auto-retry failures.
 ```
 
@@ -33,7 +81,7 @@ If a subagent fails, report it in the summary and let the user decide whether to
 
 **Outcome routing (Hard Limit #6 in `AGENTS.md`):**
 - Subagents write `batch/tracker-additions/{num}-{slug}.tsv` — one TSV per job.
-- Orchestrator runs `node merge-tracker.mjs` once at the end to consume TSVs into the right day file.
+- Orchestrator runs `npx job-forge merge` once at the end to consume TSVs into the right day file.
 - **Do NOT** append APPLIED / FAILED / SKIP lines to `data/pipeline.md` — that file is the URL inbox only.
 
 ## Verify these requirements
@@ -214,13 +262,30 @@ Specific portals — Workday "parse my resume", iCIMS multi-step, SAP SuccessFac
 Check for an OTP gate after the candidate (or Geometra) submits — the major portals (Greenhouse, Workday, Lever, Ashby) gate submission behind an email verification code. When an OTP step appears, do this.
 
 1. **Do NOT stop and ask the candidate to paste the code manually.** Use the Gmail MCP.
-2. Wait ~5-10 seconds for the email, then `gmail_list_messages` with a sender-scoped recency query (e.g. `from:greenhouse newer_than:10m`).
-3. `gmail_get_message` on the most recent match, extract the code from the body.
-4. `geometra_fill_otp` to enter it, then submit.
+2. **Pick the Gmail sender query from the ATS recorded at scan time.** The scan subagent records the ATS type in `batch/scan-output-{YYYY-MM-DD}.md` (`ats` column) and in `data/pipeline.md` (`| ats={type}` suffix). Read that value first — do NOT re-infer the ATS from the URL host when it's already recorded.
+3. Map the `ats` value to the Gmail sender query (table below). Wait ~5-10 seconds for the email, then call `gmail_list_messages` with the matching query.
+4. `gmail_get_message` on the most recent match, extract the code from the body.
+5. `geometra_fill_otp` to enter it, then submit.
+
+**ATS → Gmail sender query lookup** (use the `ats` value recorded at scan time):
+
+| `ats` value | `q` for `gmail_list_messages` |
+|-------------|-------------------------------|
+| `greenhouse` | `from:greenhouse newer_than:10m` |
+| `workday`    | `from:myworkday newer_than:10m` |
+| `lever`      | `from:lever newer_than:10m` |
+| `ashby`      | `from:ashby newer_than:10m` |
+| `workable`   | `from:workable newer_than:10m` |
+| `smartrecruiters` | `from:smartrecruiters newer_than:10m` |
+| `wwr` / `remoteok` | Follow the apply redirect to the underlying ATS, re-detect the host, then use that row's query. Aggregators do not send OTP emails themselves. |
+| `builtin`    | `from:builtin newer_than:10m` |
+| `custom` / `unknown` / missing | `newer_than:10m subject:(verify OR code OR confirm)` |
+
+**Fallback when `ats` is missing** (legacy pipeline entries with no `| ats=` suffix, or scan-output without an `ats` column): infer from the URL host — `*.greenhouse.io` → `greenhouse`; `jobs.ashbyhq.com` → `ashby`; `jobs.lever.co` → `lever`; `*.myworkdayjobs.com` → `workday`; `apply.workable.com` / `jobs.workable.com` → `workable`; `api.smartrecruiters.com` / `jobs.smartrecruiters.com` → `smartrecruiters`; `weworkremotely.com` → `wwr`; `remoteok.com` → `remoteok`; `builtin.com` → `builtin`; otherwise use the generic `verify OR code OR confirm` subject query.
 
 **Before reporting the submission as failed, always check Gmail.** A "submit did nothing" outcome usually means a silent OTP step — not a real failure.
 
-Full sender-to-query table and fallback patterns: see "OTP Handling via Gmail MCP" in `AGENTS.md`.
+Full OTP recipe and fallback patterns: see "OTP Handling via Gmail MCP" in `AGENTS.md`.
 
 ## Step 7 — Update outcomes after submission
 
@@ -240,7 +305,7 @@ The row exists. You are UPDATING an existing entry, which is allowed (Pipeline I
 The row does NOT exist yet. You MUST go through the TSV pathway (Hard Limit #6 + Pipeline Integrity rule #1):
 
 1. Write `batch/tracker-additions/{num}-{slug}.tsv` with the canonical 9-column format (see "TSV Format for Tracker Additions" in `AGENTS.md`)
-2. At the end of the apply run, the orchestrator calls `node merge-tracker.mjs`, which inserts the row into today's day file
+2. At the end of the apply run, the orchestrator calls `npx job-forge merge`, which inserts the row into today's day file
 3. Do NOT manually add a row to the day file. Do NOT append an `APPLIED` line to `data/pipeline.md`.
 
 ### Apply to both cases

package/modes/pdf.md

@@ -17,7 +17,7 @@
 11. Inject keywords naturally into existing achievements (NEVER fabricate)
 12. Generate complete HTML from template + personalized content
 13. Write HTML to `/tmp/cv-candidate-{company}.html`
-14. Run: `node generate-pdf.mjs /tmp/cv-candidate-{company}.html output/cv-candidate-{company}-{YYYY-MM-DD}.pdf --format={letter|a4}`
+14. Run: `npx job-forge pdf /tmp/cv-candidate-{company}.html output/cv-candidate-{company}-{YYYY-MM-DD}.pdf --format={letter|a4}`
 15. Report: PDF path, page count, keyword coverage %
 
 ## Apply these ATS rules for clean parsing

package/modes/pipeline.md

@@ -53,7 +53,7 @@ Processes accumulated job offer URLs from `data/pipeline.md`. The user adds URLs
 
 Before processing any URL, verify sync:
 ```bash
-node cv-sync-check.mjs
+npx job-forge sync-check
 ```
 If there is a desynchronization, warn the user before continuing.
 
@@ -72,8 +72,8 @@ Step 3  — For round in ceil(N/2):
             # WAIT for both returns before the next round.
 Step 4  — Between rounds: geometra_list_sessions() + geometra_disconnect({closeBrowser: true})
 Step 5  — Reconcile outcomes (Hard Limit #6):
-            bash: node merge-tracker.mjs      # TSVs → correct day file
-            bash: node verify-pipeline.mjs    # validate URL/status consistency
+            bash: npx job-forge merge      # TSVs → correct day file
+            bash: npx job-forge verify     # validate URL/status consistency
 Step 6  — Display summary table; flag any verify-pipeline errors.
 ```
 

package/modes/scan.md

@@ -34,9 +34,88 @@ Read `portals.yml` which contains:
 
 **Every company MUST have a `careers_url` in portals.yml.** If it doesn't, search for it once, save it, and use it in future scans.
 
-### Use Level 2 — Greenhouse API (COMPLEMENTARY)
-
-For companies using Greenhouse, the JSON API (`boards-api.greenhouse.io/v1/boards/{slug}/jobs`) returns clean structured data. Use as a quick complement to Level 1 — it's faster than Geometra but only works with Greenhouse.
+### Use Level 2 — ATS / Aggregator APIs (COMPLEMENTARY)
+
+For companies using an ATS or aggregator that exposes a public JSON/RSS API, fetch structured data directly. APIs are faster than Geometra and harder to hallucinate (the response is load-bearing — record IDs verbatim from the response, never reconstruct them). Use as a complement to Level 1.
+
+Supported API shapes:
+
+#### Greenhouse (JSON, per-company board)
+
+- **Endpoint**: `https://boards-api.greenhouse.io/v1/boards/{slug}/jobs`
+- **Method**: `GET` (plain, no auth)
+- **Shape**: `{ jobs: [{ id, title, absolute_url, updated_at, location: { name } }, ...] }`
+- **Canonical URL to record**: `https://job-boards.greenhouse.io/{slug}/jobs/{id}` — do NOT use `absolute_url` when it points to a customer-skinned front-end (see Verification section below).
+- **ats**: `greenhouse`
+
+#### Ashby (JSON, per-company board)
+
+- **Endpoint**: `https://api.ashbyhq.com/posting-api/job-board/{slug}?includeCompensation=true`
+- **Method**: `GET`
+- **Shape**: `{ jobs: [{ id, title, jobUrl, publishedDate, locationName, employmentType, department, team, compensation }] }`
+- **Canonical URL to record**: use the returned `jobUrl` (format `https://jobs.ashbyhq.com/{slug}/{uuid}`).
+- **ats**: `ashby`
+
+#### Lever (JSON, per-company board)
+
+- **Endpoint**: `https://api.lever.co/v0/postings/{slug}?mode=json`
+- **Method**: `GET`
+- **Shape**: array of postings `[{ id, text, hostedUrl, createdAt, categories: { commitment, department, location, team } }, ...]`
+- **Canonical URL to record**: `hostedUrl` (format `https://jobs.lever.co/{slug}/{uuid}`).
+- **ats**: `lever`
+
+#### Workday (JSON, per-tenant + site — FINICKY)
+
+- **Endpoint**: `https://{subdomain}.{pod}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs`
+  - `subdomain` = the Workday tenant hostname prefix (e.g. `nvidia`, `salesforce`, `adobe`, `shopify`).
+  - `pod` = the Workday data-center pod segment (varies: `wd1`, `wd3`, `wd5`). The hostname in `careers_url` reveals which.
+  - `tenant` = repeats the company slug in the path (usually equal to `subdomain`, but not always).
+  - `site` = the public site name exposed by the tenant (e.g. `NVIDIAExternalCareerSite`, `External`, `ShopifyCareerSite`). Read it from the tenant's HTML landing page if unknown.
+- **Method**: `POST` with JSON body:
+  ```json
+  {"appliedFacets": {}, "limit": 20, "offset": 0, "searchText": ""}
+  ```
+- **Required headers**: `Content-Type: application/json`, `Accept: application/json`. Some tenants reject requests without a realistic `User-Agent` — set one if the response is 403.
+- **Shape**: `{ jobPostings: [{ title, externalPath, postedOn, locationsText, bulletFields }, ...], total }`
+- **Canonical URL to record**: `https://{subdomain}.{pod}.myworkdayjobs.com/{site}{externalPath}` (note: `externalPath` already starts with `/job/...` — do NOT prepend an extra `/`).
+- **Pagination**: increment `offset` by `limit` (20) until `jobPostings.length < limit` or `offset >= total`.
+- **ats**: `workday`
+- **Fallback**: Workday APIs are brittle — tenants occasionally block POST from data-center IPs, change `site` names silently, or return empty `jobPostings` while the HTML page shows listings. If the POST fails or returns 0 jobs on a tenant that Level 1 confirmed has listings, fall back to Level 1 (Geometra scraping the `careers_url`). Treat Workday as Level 2 with a guaranteed Level 1 fallback.
+
+#### SmartRecruiters (JSON, per-company postings)
+
+- **Endpoint**: `https://api.smartrecruiters.com/v1/companies/{company}/postings`
+- **Method**: `GET` (plain, no auth)
+- **Shape**: `{ content: [{ id, name, refNumber, jobAdUrl, releasedDate, location: { city, country, remote }, company: { identifier, name }, department }], totalFound, offset, limit }`
+- **Canonical URL to record**: use `jobAdUrl` when present, otherwise `https://jobs.smartrecruiters.com/{company}/{id}`.
+- **Pagination**: pass `?offset=N&limit=100` (max 100). Loop until `offset + content.length >= totalFound`.
+- **ats**: `smartrecruiters`
+
+#### WeWorkRemotely (RSS, cross-company aggregator)
+
+- **Endpoints** (one per category — enable the ones matching your target roles):
+  - `https://weworkremotely.com/categories/remote-programming-jobs.rss`
+  - `https://weworkremotely.com/categories/remote-devops-sysadmin-jobs.rss`
+  - `https://weworkremotely.com/categories/remote-product-jobs.rss`
+  - `https://weworkremotely.com/categories/remote-design-jobs.rss`
+  - `https://weworkremotely.com/categories/all-other-remote-jobs.rss`
+- **Method**: `GET` — returns RSS 2.0 XML.
+- **Shape**: `<rss><channel><item><title>{company}: {role}</title><link>https://weworkremotely.com/remote-jobs/{slug}</link><pubDate>...</pubDate><region>...</region></item></channel></rss>`
+- **Company/role extraction**: split `<title>` on the first `: ` — left side is company, right side is role. Fallback to the whole title as role if there is no `: `.
+- **Canonical URL to record**: the `<link>` verbatim (format `https://weworkremotely.com/remote-jobs/{slug}`).
+- **Cross-company note**: WeWorkRemotely is NOT per-company — it aggregates postings from hundreds of companies. Scan it via the `cross_company_feeds` section in `portals.yml`, not `tracked_companies`.
+- **ats**: `wwr` (aggregator). The underlying company's ATS is unknown at scan time — downstream evaluators follow the link and re-detect.
+
+#### RemoteOK (JSON, cross-company aggregator)
+
+- **Endpoint**: `https://remoteok.com/api`
+- **Method**: `GET` — returns a JSON array. The **first element is a legal/disclaimer object** (no `id`, has `legal`) — skip it. The remaining 100 entries are postings.
+- **Required headers**: `User-Agent: Mozilla/5.0 ...` — RemoteOK returns 403 without a browser-like UA.
+- **Shape** (per posting after skip): `{ id, slug, company, company_logo, position, description, tags: [string], date, epoch, url, apply_url, location, salary_min, salary_max }`
+- **Canonical URL to record**: `url` (format `https://remoteok.com/remote-jobs/{id}-{slug}`).
+- **Filtering**: RemoteOK feeds are broad — use `tags` for pre-filter (e.g. `tags` contains `"engineer"` or `"ai"`) before passing through `title_filter`.
+- **Cross-company note**: same as WeWorkRemotely — configure via `cross_company_feeds`, not `tracked_companies`.
+- **ats**: `remoteok` (aggregator).
 
 ### Use Level 3 — WebSearch Queries (BROAD DISCOVERY)
 
@@ -44,7 +123,7 @@ The `search_queries` with `site:` filters cover portals broadly (all Ashby board
 
 **Execution priority:**
 1. Level 1: Geometra → all `tracked_companies` with `careers_url`
-2. Level 2: API → all `tracked_companies` with `api:`
+2. Level 2: API → all `tracked_companies` with `api:` (Greenhouse / Ashby / Lever / Workday / SmartRecruiters) AND all `cross_company_feeds` with `enabled: true` (WeWorkRemotely / RemoteOK)
 3. Level 3: WebSearch → all `search_queries` with `enabled: true`
 
 The levels are additive — all are executed, results are merged and deduplicated.
@@ -65,15 +144,26 @@ The levels are additive — all are executed, results are merged and deduplicate
    f. Accumulate in candidates list
    g. If `careers_url` fails (404, redirect), try `scan_query` as fallback and note for URL update
 
-5. **Level 2 — Greenhouse APIs** (WebFetch can batch freely — it's cheap and doesn't use Geometra sessions):
-   For each company in `tracked_companies` with `api:` defined and `enabled: true`:
-   a. WebFetch the API URL → JSON with job list
-   b. For each job extract: `{title, url, company, gh_slug, gh_id, updated_at}`
-      - **`url`**: ALWAYS record the canonical Greenhouse URL: `https://job-boards.greenhouse.io/{gh_slug}/jobs/{gh_id}`. Do **NOT** use `absolute_url` when it points to a customer-skinned front-end (e.g. `pinterestcareers.com/jobs/?gh_jid=N`, `okta.com/company/careers/opportunity/N`, `samsara.com/company/careers/roles/N`, `zoominfo.com/careers?gh_jid=N`, `collibra.com/.../?gh_jid=N`, `careers.toasttab.com/jobs?gh_jid=N`, `careers.airbnb.com/positions/N`, `coinbase.com/careers/positions/N`, `instacart.careers/job/?gh_jid=N`, `pinterestcareers.com/jobs/?gh_jid=N`). These customer front-ends return shells or 403 to bots and cause downstream WebFetch-based verification to wrongly mark the role CLOSED.
-      - **`gh_slug`**: the Greenhouse board slug (from the API URL that was fetched).
-      - **`gh_id`**: `jobs[].id` from the API response.
-      - **`updated_at`**: `jobs[].updated_at` — record for staleness detection (skip if older than 90 days, flag if older than 30).
-   c. Accumulate in candidates list (dedup with Level 1). The pipeline.md entry MUST carry `| gh={gh_slug}/{gh_id}` at the end of the metadata so downstream evaluators can fall back to `https://boards-api.greenhouse.io/v1/boards/{gh_slug}/jobs/{gh_id}` when the canonical URL renders as a shell.
+5. **Level 2 — ATS / Aggregator APIs** (WebFetch can batch freely — it's cheap and doesn't use Geometra sessions):
+
+   **5a. Per-company APIs** — for each company in `tracked_companies` with `api:` defined and `enabled: true`:
+   a. WebFetch (or `fetch` for Workday, which needs POST) the API URL per the endpoint shape documented above.
+   b. Extract per-posting `{title, url, company, updated_at, ats}` plus ATS-specific IDs:
+      - **Greenhouse** → also record `gh_slug`, `gh_id`. URL MUST be canonical `https://job-boards.greenhouse.io/{gh_slug}/jobs/{gh_id}` — do **NOT** use `absolute_url` when it points to a customer-skinned front-end (e.g. `pinterestcareers.com/jobs/?gh_jid=N`, `okta.com/company/careers/opportunity/N`, `samsara.com/company/careers/roles/N`, `zoominfo.com/careers?gh_jid=N`, `collibra.com/.../?gh_jid=N`, `careers.toasttab.com/jobs?gh_jid=N`, `careers.airbnb.com/positions/N`, `coinbase.com/careers/positions/N`, `instacart.careers/job/?gh_jid=N`). These customer front-ends return shells or 403 to bots and cause downstream WebFetch-based verification to wrongly mark the role CLOSED.
+      - **Ashby** → record the returned `jobUrl`.
+      - **Lever** → record the returned `hostedUrl`.
+      - **Workday** → build URL as `https://{subdomain}.{pod}.myworkdayjobs.com/{site}{externalPath}`. If the POST fails, DROP that tenant's API attempt and fall back to Level 1 for that company — do NOT fabricate postings.
+      - **SmartRecruiters** → record `jobAdUrl` (fallback: `https://jobs.smartrecruiters.com/{company}/{id}`).
+      - **`updated_at`**: use `updated_at` (Greenhouse) / `publishedDate` (Ashby) / `createdAt` (Lever) / `postedOn` (Workday) / `releasedDate` (SmartRecruiters) — record for staleness detection (skip if older than 90 days, flag if older than 30).
+   c. Accumulate in candidates list (dedup with Level 1). The pipeline.md entry MUST carry `| ats={type}` at the end, and for Greenhouse ALSO `| gh={gh_slug}/{gh_id}` so downstream evaluators can fall back to `https://boards-api.greenhouse.io/v1/boards/{gh_slug}/jobs/{gh_id}` when the canonical URL renders as a shell.
+
+   **5b. Cross-company aggregator feeds** — for each feed in `cross_company_feeds` with `enabled: true`:
+   a. WebFetch the RSS (WeWorkRemotely) or JSON (RemoteOK) endpoint per the shape documented above.
+   b. Parse each entry to `{title, url, company, ats, updated_at}`:
+      - **WeWorkRemotely** → split `<title>` on the first `: ` to separate company from role; `<link>` → url; `<pubDate>` → updated_at.
+      - **RemoteOK** → skip the first element (legal disclaimer); from each remaining entry take `company`, `position`, `url`, `date`.
+   c. Apply the feed's `tag_filter` / `category_filter` before the global `title_filter` — aggregators have much higher volume than per-company APIs.
+   d. Accumulate in candidates list (dedup with Level 1 + 5a).
 
 6. **Level 3 — WebSearch queries** (WebSearch is parallel-safe; batch freely):
    For each query in `search_queries` with `enabled: true`:
@@ -106,7 +196,14 @@ The levels are additive — all are executed, results are merged and deduplicate
    - When a fuzzy match is found but the URL is new, log it as `skipped_repost` (not `skipped_dup`) with a note referencing the original entry number.
 
 8. **For each new offer that passes filters**:
-   a. Add to `pipeline.md` section "Pending": `- [ ] {url} | {company} | {title}` — append `| gh={gh_slug}/{gh_id}` when the offer came from the Greenhouse API (Level 2) so downstream verification can hit the JSON endpoint.
+   a. Add to `pipeline.md` section "Pending": `- [ ] {url} | {company} | {title} | ats={ats}` — the `| ats={type}` suffix is REQUIRED for every entry (values: `greenhouse`, `ashby`, `workable`, `lever`, `workday`, `smartrecruiters`, `wwr`, `remoteok`, `builtin`, `custom`, `unknown`). When the offer came from the Greenhouse API (Level 2), ALSO append `| gh={gh_slug}/{gh_id}` so downstream verification can hit the JSON endpoint. Example entries:
+      - `- [ ] https://job-boards.greenhouse.io/webflow/jobs/7689676 | Webflow | Lead AI Engineer | ats=greenhouse | gh=webflow/7689676`
+      - `- [ ] https://jobs.ashbyhq.com/everai/abc-123 | EverAI | Senior AI PM | ats=ashby`
+      - `- [ ] https://jobs.lever.co/temporal/xyz | Temporal | Product Manager - AI | ats=lever`
+      - `- [ ] https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite/job/US-CA-Santa-Clara/Senior-AI-Engineer_JR123456 | NVIDIA | Senior AI Engineer | ats=workday`
+      - `- [ ] https://jobs.smartrecruiters.com/Visa1/744000012345678 | Visa | Staff ML Engineer | ats=smartrecruiters`
+      - `- [ ] https://weworkremotely.com/remote-jobs/acme-senior-platform-engineer | Acme | Senior Platform Engineer | ats=wwr`
+      - `- [ ] https://remoteok.com/remote-jobs/12345-senior-ai-engineer-acme | Acme | Senior AI Engineer | ats=remoteok`
    b. Record in `scan-history.tsv`: `{url}\t{date}\t{query_name}\t{title}\t{company}\tadded`
 
 9. **Offers filtered by title**: record in `scan-history.tsv` with status `skipped_title`
@@ -149,21 +246,27 @@ Scan mode MUST write its ranked candidate list to a file, not just return it in
 
 **Format**: one markdown table per scan run, ordered by archetype-fit rank:
 
-| rank | company | role | gh_slug | gh_id | url | updated_at |
-|------|---------|------|---------|-------|-----|------------|
-| 1    | Webflow | Lead AI Engineer | webflow | 7689676 | https://job-boards.greenhouse.io/webflow/jobs/7689676 | 2026-04-14 |
-| ... | ... | ... | ... | ... | ... | ... |
+| rank | company | ats | role | gh_slug | gh_id | url | updated_at |
+|------|---------|-----|------|---------|-------|-----|------------|
+| 1    | Webflow | greenhouse | Lead AI Engineer | webflow | 7689676 | https://job-boards.greenhouse.io/webflow/jobs/7689676 | 2026-04-14 |
+| 2    | EverAI  | ashby      | Senior AI PM     | -       | -       | https://jobs.ashbyhq.com/everai/abc-123 | 2026-04-15 |
+| ... | ... | ... | ... | ... | ... | ... | ... |
+
+**`ats` values** (one of): `greenhouse`, `ashby`, `workable`, `lever`, `workday`, `smartrecruiters`, `wwr`, `remoteok`, `builtin`, `custom`, `unknown`. Every row MUST populate this column — it's what the apply subagent uses to pick the correct Gmail OTP sender query. The `wwr` and `remoteok` values identify aggregator postings whose real underlying ATS is only known after the redirect is followed — downstream evaluators re-detect and may rewrite to the underlying ATS.
 
 Every row MUST have:
-- `gh_slug` and `gh_id` copied verbatim from the Greenhouse API response (not reconstructed)
-- `url` in the canonical form `https://job-boards.greenhouse.io/{gh_slug}/jobs/{gh_id}` (matching the suffix in `data/pipeline.md`)
-- `updated_at` in `YYYY-MM-DD` form (the most recent `updated_at` in the API response)
+- `ats` — the ATS platform hosting the posting. Inferred from the canonical URL host (e.g. `boards-api.greenhouse.io` / `job-boards.greenhouse.io` → `greenhouse`; `jobs.ashbyhq.com` → `ashby`; `jobs.lever.co` → `lever`; `*.myworkdayjobs.com` (any `wd1`/`wd3`/`wd5` pod) → `workday`; `apply.workable.com` / `jobs.workable.com` → `workable`; `api.smartrecruiters.com` / `jobs.smartrecruiters.com` → `smartrecruiters`; `weworkremotely.com` → `wwr`; `remoteok.com` → `remoteok`; `builtin.com/jobs/` → `builtin`; company-own domains → `custom`; anything indeterminate → `unknown`).
+- `url` in canonical form. For Greenhouse use `https://job-boards.greenhouse.io/{gh_slug}/jobs/{gh_id}` (matching the suffix in `data/pipeline.md`). For other ATSes use the platform's native URL (do not rewrite).
+- `updated_at` in `YYYY-MM-DD` form (the most recent `updated_at` in the API response, or scan date when the source has no such field).
+
+Additional columns — REQUIRED when available, `-` (dash) when not applicable:
+- `gh_slug`, `gh_id` — Greenhouse-only. Copied verbatim from the Greenhouse API response (not reconstructed). For non-Greenhouse rows, emit `-` in both columns; `ats` + `url` are sufficient.
 
 The scan subagent's return message MUST:
 - Reference the file path (so orchestrators know where to read)
 - Omit the ranked URL list from prose entirely (summary counts only)
 
-**Rationale**: in a prior run, a scan subagent returned correct IDs in `scan-history.tsv` but hallucinated plausible-looking fake IDs in its prose-form top-30 list. The orchestrator trusted prose and dispatched 30 downstream subagents against fake URLs. File-based handoff prevents this class of error.
+**Rationale**: in a prior run, a scan subagent returned correct IDs in `scan-history.tsv` but hallucinated plausible-looking fake IDs in its prose-form top-30 list. The orchestrator trusted prose and dispatched 30 downstream subagents against fake URLs. File-based handoff prevents this class of error. Recording `ats` at scan time (rather than having the apply subagent infer it from the URL host) saves downstream re-parsing and keeps the OTP sender lookup deterministic.
 
 ## Output Summary
 
@@ -205,6 +308,8 @@ Each company in `tracked_companies` MUST have a `careers_url` — the direct URL
 - **Ashby:** `https://jobs.ashbyhq.com/{slug}`
 - **Greenhouse:** `https://job-boards.greenhouse.io/{slug}` or `https://job-boards.eu.greenhouse.io/{slug}`
 - **Lever:** `https://jobs.lever.co/{slug}`
+- **Workday:** `https://{subdomain}.{pod}.myworkdayjobs.com/{site}` (pod = `wd1`/`wd3`/`wd5`/..., varies by tenant data center; site is tenant-defined, e.g. `External`, `NVIDIAExternalCareerSite`)
+- **SmartRecruiters:** `https://careers.smartrecruiters.com/{company}` (human-facing) / `https://api.smartrecruiters.com/v1/companies/{company}/postings` (API)
 - **Custom:** The company's own URL (e.g., `https://openai.com/careers`)
 
 **If `careers_url` doesn't exist** for a company:

package/normalize-statuses.mjs

@@ -7,7 +7,7 @@
  *   - Single-file: data/applications.md or applications.md (legacy)
  *
  * Maps all non-canonical statuses to canonical ones per templates/states.yml:
- *   Evaluated, Applied, Responded, Contacted, Interview, Offer, Rejected, Discarded, SKIP
+ *   Evaluated, Applied, Responded, Contacted, Interview, Offer, Rejected, Discarded, Failed, SKIP
  *
  * Also strips markdown bold (**) and dates from the status field,
  * moving DUPLICADO info to the notes column.
@@ -23,6 +23,9 @@ import {
   usesDayFiles, ensureDayDir, parseAppLine, formatAppLine,
   readAllEntries, writeToDayFiles, listDayFiles,
 } from './tracker-lib.mjs';
+import { DEFAULT_STATES, loadCanonicalStates } from './lib/canonical-states.mjs';
+
+const CANONICAL_STATES = loadCanonicalStates(PROJECT_DIR) || DEFAULT_STATES;
 
 const DRY_RUN = process.argv.includes('--dry-run');
 
@@ -61,11 +64,7 @@ function normalizeStatus(raw) {
 
   if (s === '—' || s === '-' || s === '') return { status: 'Discarded' };
 
-  const canonical = [
-    'Evaluated', 'Applied', 'Contacted', 'Responded', 'Interview',
-    'Offer', 'Rejected', 'Discarded', 'SKIP',
-  ];
-  for (const c of canonical) {
+  for (const c of CANONICAL_STATES) {
     if (lower === c.toLowerCase()) return { status: c };
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "job-forge",
-  "version": "2.0.2",
+  "version": "2.1.0",
   "description": "AI-powered job search pipeline built on opencode",
   "type": "module",
   "bin": {
@@ -43,6 +43,7 @@
     "batch/batch-runner.sh",
     "batch/README.md",
     "docs/",
+    "lib/",
     "tracker-lib.mjs",
     "merge-tracker.mjs",
     "dedup-tracker.mjs",

package/templates/portals.example.yml

@@ -406,6 +406,36 @@ search_queries:
 # Companies whose career pages are checked directly.
 # scan_method: geometra (default), websearch, greenhouse_api
 # For Greenhouse companies, add api: field for faster structured JSON access.
+#
+# Per-ATS api: field shapes (see modes/scan.md for full endpoint docs):
+#
+#   Greenhouse:     api: https://boards-api.greenhouse.io/v1/boards/{slug}/jobs
+#   Ashby:          api: https://api.ashbyhq.com/posting-api/job-board/{slug}?includeCompensation=true
+#   Lever:          api: https://api.lever.co/v0/postings/{slug}?mode=json
+#   SmartRecruiters: api: https://api.smartrecruiters.com/v1/companies/{company}/postings
+#   Workday:        api_type: workday  (requires workday_subdomain, workday_pod, workday_tenant, workday_site)
+#
+# Workday schema (finicky — POST with JSON body, tenant + site vary per company):
+#   - name: NVIDIA
+#     careers_url: https://nvidia.wd5.myworkdayjobs.com/NVIDIAExternalCareerSite
+#     api_type: workday
+#     workday_subdomain: nvidia                  # hostname prefix
+#     workday_pod: wd5                           # data-center pod (wd1/wd3/wd5/...)
+#     workday_tenant: nvidia                     # usually same as subdomain
+#     workday_site: NVIDIAExternalCareerSite     # public site name — read from careers_url path
+#     tags: ["chips", "ai-lab", "us"]
+#     enabled: true
+#
+#   Built API URL: https://{subdomain}.{pod}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs
+#   POST body:     {"appliedFacets": {}, "limit": 20, "offset": 0, "searchText": ""}
+#
+# SmartRecruiters schema (simple GET):
+#   - name: Visa
+#     careers_url: https://careers.smartrecruiters.com/Visa1
+#     api: https://api.smartrecruiters.com/v1/companies/Visa1/postings
+#     ats: smartrecruiters
+#     tags: ["fintech", "enterprise", "us"]
+#     enabled: true
 
 tracked_companies:
 
@@ -3138,3 +3168,80 @@ tracked_companies:
     notes: "TypeScript ORM. Remote."
     tags: ["developer-tools", "open-source", "remote-first"]
     enabled: true
+
+# -- Cross-company aggregator feeds --
+# Aggregator boards that expose a single feed covering hundreds of companies.
+# Unlike tracked_companies, these are NOT per-company — the scanner pulls the
+# whole feed, applies a pre-filter (category / tags), then runs each posting
+# through the global title_filter above.
+#
+# Types:
+#   - weworkremotely  → RSS 2.0 XML per category
+#   - remoteok        → JSON array, first element is a legal disclaimer (skipped)
+#
+# See modes/scan.md → "Level 2 — ATS / Aggregator APIs" for full shape docs.
+
+cross_company_feeds:
+
+  # -- We Work Remotely (RSS per category) --
+  # Feed IDs map to https://weworkremotely.com/categories/{id}.rss
+  - name: WeWorkRemotely — Programming
+    type: weworkremotely
+    feed: remote-programming-jobs
+    url: https://weworkremotely.com/categories/remote-programming-jobs.rss
+    # Optional pre-filter applied BEFORE title_filter. Drops obviously
+    # off-target entries without cluttering scan-history.
+    category_filter:
+      positive: []   # empty = accept all from this feed
+      negative: ["WordPress", "PHP", "Shopify Theme"]
+    enabled: true
+
+  - name: WeWorkRemotely — DevOps & SysAdmin
+    type: weworkremotely
+    feed: remote-devops-sysadmin-jobs
+    url: https://weworkremotely.com/categories/remote-devops-sysadmin-jobs.rss
+    enabled: true
+
+  - name: WeWorkRemotely — Product
+    type: weworkremotely
+    feed: remote-product-jobs
+    url: https://weworkremotely.com/categories/remote-product-jobs.rss
+    enabled: true
+
+  - name: WeWorkRemotely — All Other
+    type: weworkremotely
+    feed: all-other-remote-jobs
+    url: https://weworkremotely.com/categories/all-other-remote-jobs.rss
+    # This category is very broad — start disabled, enable if signal is good.
+    enabled: false
+
+  # -- RemoteOK (single JSON feed, filter by tags) --
+  # One endpoint, 100 newest postings. Filter by tags BEFORE title_filter,
+  # otherwise you burn the title_filter pass on ~80% irrelevant rows.
+  - name: RemoteOK — AI & Engineering
+    type: remoteok
+    url: https://remoteok.com/api
+    # Required — RemoteOK returns 403 without a browser-like UA.
+    user_agent: "Mozilla/5.0 (compatible; JobForgeScanner/1.0; +https://github.com/razroo/JobForge)"
+    # Pre-filter on entry.tags (case-insensitive substring match against the
+    # array). Row passes if ANY positive matches AND NO negative matches.
+    tag_filter:
+      positive:
+        - "engineer"
+        - "engineering"
+        - "ai"
+        - "ml"
+        - "llm"
+        - "python"
+        - "golang"
+        - "typescript"
+        - "devops"
+        - "platform"
+        - "product manager"
+      negative:
+        - "wordpress"
+        - "php"
+        - "marketing"
+        - "sales"
+        - "customer support"
+    enabled: true

package/templates/states.yml

@@ -55,6 +55,12 @@ states:
     description: Discarded by candidate or offer closed
     dashboard_group: discarded
 
+  - id: failed
+    label: Failed
+    aliases: []
+    description: Submission attempted but blocked by portal (spam-filter, anti-bot, broken form). May be recoverable via manual retry.
+    dashboard_group: failed
+
   - id: skip
     label: SKIP
     aliases: [skip]