job-forge 2.0.0

package/modes/_shared.md

@@ -0,0 +1,272 @@
+# Shared Context -- job-forge
+
+<!-- ============================================================
+     HOW TO CUSTOMIZE THIS FILE
+     ============================================================
+     This file contains the shared context for all job-forge modes.
+     Before using job-forge, you MUST:
+     1. Fill in config/profile.yml with your personal data
+     2. Create your cv.md in the project root
+     3. (Optional) Create article-digest.md with your proof points
+     4. Customize the sections below marked with [CUSTOMIZE]
+     ============================================================ -->
+
+## Read these sources of truth
+
+| File | Path | Loaded where? |
+|------|------|----------------|
+| cv.md | `cv.md` (project root) | **Already in context** via `opencode.json:instructions` — do NOT Read again |
+| _shared.md | `modes/_shared.md` (this file) | **Already in context** via `instructions` |
+| AGENTS.harness.md | symlink to `node_modules/job-forge/AGENTS.md` | **Already in context** via `instructions` |
+| article-digest.md | `article-digest.md` (if exists) | **Read on demand** — optional detailed proof points, only when evaluating |
+| profile.yml | `config/profile.yml` | **Read on demand** — for name, contact, targets |
+| templates/states.yml | canonical application states | **Already in context** via `instructions` |
+
+**RULE: Do NOT Read `cv.md` or `modes/_shared.md` from within a mode — they're already in your context.** Re-Reading them pulls the same tokens into conversation history at full input cost; opencode's `instructions` array caches them for you.
+
+**RULE: NEVER hardcode metrics from proof points.** Reference them from the already-loaded cv.md, or Read article-digest.md if you need the richer proof points.
+
+**RULE: For article/project metrics, article-digest.md takes precedence over cv.md** (cv.md may have older numbers).
+
+---
+
+## List the North Star target roles
+
+The skill applies with EQUAL rigor to ALL target roles. None is primary or secondary -- any is a success if comp and growth are right:
+
+| Archetype | Thematic axes | What they buy |
+|-----------|---------------|---------------|
+| **AI Platform / LLMOps Engineer** | Evaluation, observability, reliability, pipelines | Someone who puts AI in production with metrics |
+| **Agentic Workflows / Automation** | HITL, tooling, orchestration, multi-agent | Someone who builds reliable agent systems |
+| **Technical AI Product Manager** | GenAI/Agents, PRDs, discovery, delivery | Someone who translates business to AI product |
+| **AI Solutions Architect** | Hyperautomation, enterprise, integrations | Someone who designs end-to-end AI architectures |
+| **AI Forward Deployed Engineer** | Client-facing, fast delivery, prototyping | Someone who delivers AI solutions to clients fast |
+| **AI Transformation Lead** | Change management, adoption, org enablement | Someone who leads AI transformation in an org |
+
+<!-- [CUSTOMIZE] Edit the archetypes above to match YOUR target roles.
+     For example, if you're a backend engineer, replace with:
+     - Senior Backend Engineer
+     - Staff Platform Engineer
+     - Engineering Manager
+     etc. -->
+
+### Apply framing by archetype
+
+> **Concrete metrics: read from `cv.md` + `article-digest.md` at evaluation time. NEVER hardcode numbers here.**
+
+| If the role is... | Emphasize about the candidate... | Proof point sources |
+|-------------------|----------------------------------|---------------------|
+| Platform / LLMOps | Production systems builder, observability, evals, closed-loop | article-digest.md + cv.md |
+| Agentic / Automation | Multi-agent orchestration, HITL, reliability, cost | article-digest.md + cv.md |
+| Technical AI PM | Product discovery, PRDs, metrics, stakeholder mgmt | cv.md + article-digest.md |
+| Solutions Architect | System design, integrations, enterprise-ready | article-digest.md + cv.md |
+| Forward Deployed Engineer | Fast delivery, client-facing, prototype to prod | cv.md + article-digest.md |
+| AI Transformation Lead | Change management, team enablement, adoption | cv.md + article-digest.md |
+
+<!-- [CUSTOMIZE] Map YOUR specific projects/articles to each archetype above -->
+
+### Use this exit narrative in ALL framings
+
+<!-- [CUSTOMIZE] Replace with YOUR narrative. Examples:
+     - "Built and sold my SaaS after 5 years. Now focused on applied AI at scale."
+     - "Led engineering at a Series B startup through 10x growth. Now seeking my next challenge."
+     - "Transitioned from consulting to building product. Looking for high-ownership roles."
+     Read from config/profile.yml → narrative.exit_story -->
+
+Use the candidate's exit story from `config/profile.yml` to frame ALL content:
+- **In PDF Summaries:** Bridge from past to future -- "Now applying the same [skill] to [JD domain]."
+- **In STAR stories:** Reference proof points from article-digest.md
+- **In Draft Answers (Section G):** Place the transition narrative in the first response.
+- **When the JD asks for "entrepreneurial", "ownership", "builder", "end-to-end":** This is the #1 differentiator. Increase match weight.
+
+### Use the cross-cutting advantage frame
+
+Frame the candidate as a **"Technical builder with real-world proof"**. Adapt the phrasing per archetype.
+
+- For PM: "builder who reduces uncertainty with prototypes then productionizes with discipline."
+- For FDE: "builder who delivers fast with observability and metrics from day 1."
+- For SA: "builder who designs end-to-end systems with real integration experience."
+- For LLMOps: "builder who puts AI in production with closed-loop quality systems."
+
+Convert "builder" into a professional signal, not a "hobby maker". Real proof points make this credible.
+
+### Use the portfolio as a proof point in high-value applications
+
+<!-- [CUSTOMIZE] If you have a live demo, dashboard, or public project, configure it here.
+     Example:
+     dashboard:
+       url: "https://yoursite.dev/demo"
+       password: "demo-2026"
+       when_to_share: "LLMOps, AI Platform, observability roles"
+     Read from config/profile.yml → narrative.proof_points and narrative.dashboard -->
+
+If the candidate has a live demo/dashboard (check profile.yml), offer access in applications for relevant roles.
+
+### Comp Intelligence
+
+<!-- [CUSTOMIZE] Research comp ranges for YOUR target roles and update these ranges -->
+
+**Follow this general guidance.**
+
+- Use WebSearch for current market data (Glassdoor, Levels.fyi, Blind).
+- Frame by role title, not by skills — titles determine comp bands.
+- Contractor rates are typically 30-50% higher than employee base to account for benefits.
+- Geographic arbitrage works for remote roles: lower CoL = better net.
+
+### Negotiation Scripts
+
+<!-- [CUSTOMIZE] Adapt these to your situation -->
+
+**Salary expectations (general framework):**
+> "Based on market data for this role, I'm targeting [RANGE from profile.yml]. I'm flexible on structure -- what matters is the total package and the opportunity."
+
+**Geographic discount pushback:**
+> "The roles I'm competitive for are output-based, not location-based. My track record doesn't change based on postal code."
+
+**When offered below target:**
+> "I'm comparing with opportunities in the [higher range]. I'm drawn to [company] because of [reason]. Can we explore [target]?"
+
+### Location Policy
+
+<!-- [CUSTOMIZE] Adapt to your situation. Read from config/profile.yml → location -->
+
+**In forms:**
+- Binary "can you be on-site?" questions: follow your actual availability from profile.yml
+- In free-text fields: specify your timezone overlap and availability
+
+**In evaluations (scoring):**
+- Remote dimension for hybrid outside your country: score **3.0** (not 1.0)
+- Only score 1.0 if JD explicitly says "must be on-site 4-5 days/week, no exceptions"
+
+### Use time-to-offer as the priority
+- Working demo + metrics > perfection
+- Apply sooner > learn more
+- 80/20 approach, timebox everything
+
+---
+
+## Use this canonical scoring model (SINGLE SOURCE OF TRUTH)
+
+**ALL evaluation modes MUST use this exact model.** Whether the offer is evaluated via `offer`, `auto-pipeline`, `batch`, or compared via `compare`, the score is computed the same way. This ensures scores are comparable across the entire pipeline.
+
+| # | Dimension | Weight | 1 | 3 | 5 |
+|---|-----------|--------|---|---|---|
+| 1 | North Star alignment | 25% | Unrelated to any target archetype | Adjacent — transferable skills apply | Exact target archetype match |
+| 2 | CV match | 15% | <40% requirements covered | 60-75% covered, gaps are soft | 90%+ covered with proof points |
+| 3 | Seniority fit | 15% | Junior / 2+ levels below | Mid-senior, manageable positioning | Staff+ or exact level match |
+| 4 | Comp estimate | 10% | Well below market / no data | Median for role+location | Top quartile or above target |
+| 5 | Growth trajectory | 10% | Dead end, no progression path | 1-2 yr path forward, timeline unclear | Clear path to next level |
+| 6 | Remote quality | 5% | On-site only, no flexibility | Hybrid 2-3 days in office | Full remote, async-friendly |
+| 7 | Company reputation | 5% | Red flags, poor reviews | Average employer, neutral signals | Top employer, strong brand |
+| 8 | Tech stack modernity | 5% | Legacy, no AI/ML relevance | Mix of modern and legacy tooling | Frontier AI/ML stack (LLMs, agents, evals) |
+| 9 | Speed to offer | 5% | 6+ month process, bureaucratic | Standard 4-6 week process | Fast-track, <4 weeks typical |
+| 10 | Cultural signals | 5% | Bureaucratic, risk-averse | Mixed signals | Builder culture, high ownership |
+
+**Final score** = weighted sum, rounded to 1 decimal (e.g., 4.2/5).
+
+### Score Emission — EMIT-ONCE JSON (REQUIRED)
+
+**Before writing any report prose**, emit the score as a single JSON block. Then derive the narrative from the JSON — do NOT re-enumerate the 10 dimensions in thinking or prose. This rule exists because repeated scoring monologues are a major token-burn source: a typical eval session otherwise spends ~1,500 tokens narrating the same 10 scores two or three times.
+
+**Shape** (emit exactly one block, nothing else in the block):
+
+```json
+{
+  "report_num": "520",
+  "company": "Anthropic",
+  "role": "Manager, Forward Deployed Engineering",
+  "archetype": "AI Forward Deployed Engineer",
+  "url": "https://job-boards.greenhouse.io/anthropic/jobs/5099753008",
+  "date": "2026-04-15",
+  "scores": {
+    "north_star":    { "score": 5, "rationale": "Exact FDE archetype match" },
+    "cv_match":      { "score": 3, "rationale": "60% coverage; mgmt gap" },
+    "seniority_fit": { "score": 3, "rationale": "Senior IC, no formal mgmt" },
+    "comp":          { "score": 5, "rationale": "$320-400K vs target $135-200K" },
+    "growth":        { "score": 5, "rationale": "Founding team" },
+    "remote":        { "score": 3, "rationale": "Hybrid, 25% in-office" },
+    "company":       { "score": 5, "rationale": "Top AI brand" },
+    "stack":         { "score": 5, "rationale": "Cutting-edge AI" },
+    "speed":         { "score": 3, "rationale": "Standard process" },
+    "culture":       { "score": 5, "rationale": "Builder culture" }
+  },
+  "weighted_total": 4.2,
+  "recommendation": "apply",
+  "pdf_threshold_met": true,
+  "draft_answers_threshold_met": true
+}
+```
+
+**Rules:**
+
+- `score` per dimension is 1-5 (integer or 0.5 step).
+- `rationale` is ≤ 80 characters, no markdown.
+- `weighted_total` = round(Σ weight × score, 1). The 10 weights sum to 100% exactly.
+- `recommendation` ∈ {`"apply"` (≥3.5), `"apply_with_caveats"` (3.0-3.4), `"skip"` (<3.0)}.
+- `pdf_threshold_met` ⇔ `weighted_total ≥ 3.0`.
+- `draft_answers_threshold_met` ⇔ `weighted_total ≥ 3.5`.
+
+**After emitting the JSON:**
+
+1. Embed the same JSON block verbatim in the report `.md` under a `## Score` section (fenced as ` ```json `).
+2. Write Blocks A-F **referencing** the scores by key (e.g., "Seniority fit: 3/5 — Senior IC, no formal management"). Do NOT re-list all 10 dimensions in prose. Do NOT repeat the rationales verbatim.
+3. Do NOT narrate the scoring process in thinking before emitting the JSON. Decide, emit, move on.
+
+**Score interpretation (use consistently everywhere):**
+- **4.5-5.0** — Strong match. Generate PDF + draft answers. Apply promptly.
+- **3.5-4.4** — Apply with tailored CV. Generate PDF + draft answers.
+- **3.0-3.4** — Moderate match. Generate PDF. Flag gaps to candidate before applying.
+- **< 3.0** — Weak match. Report only. Explicitly discourage applying unless candidate has a specific reason.
+
+**PDF generation threshold:** >= 3.0 (consistent across all modes).
+**Draft answer threshold:** >= 3.5 (consistent across all modes).
+
+## Scoring Calibration Anchors
+
+**Moved:** the score anchors table now lives in `modes/_shared-calibration.md` — Read on-demand during evaluation, NOT loaded into the global `instructions` prefix. This split matters because the anchors churn as you accumulate reports; keeping them out of the cached prefix means each update doesn't bust cache for every unrelated session.
+
+**Rule:** right before assigning a final score, Read `modes/_shared-calibration.md` once (per evaluation, not per dimension) and sanity-check your score against the anchors. Do not Read it more than once per evaluation.
+
+---
+
+## Global Rules
+
+### Skip these actions
+
+1. Invent experience or metrics
+2. Modify cv.md or portfolio files
+3. Submit applications on behalf of the candidate
+4. Share phone number in generated messages
+5. Recommend comp below market rate
+6. Generate a PDF without reading the JD first
+7. Use corporate-speak
+8. Ignore the tracker (every evaluated offer gets registered)
+9. Use AI-hallmark words: "leveraged", "utilized", "spearheaded", "orchestrated" (as metaphor), "cutting-edge", "passionate about", "drive innovation", "synergy", "holistic approach", "navigate complex", "foster collaboration". ATS platforms flag these. Use plain, specific verbs instead.
+
+### Do these always
+
+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
+2. Detect the role archetype and adapt framing
+3. Cite exact lines from CV when matching
+4. Use WebSearch for comp and company data
+5. Register in tracker after evaluating
+6. Generate content in the language of the JD (EN default)
+7. Be direct and actionable -- no fluff
+8. When generating English text (PDF summaries, bullets, LinkedIn messages, STAR stories): native tech English, not translated. Short sentences, action verbs, no unnecessary passive voice.
+8b. **Case study URLs in PDF Professional Summary:** If the PDF mentions case studies or demos, URLs MUST appear in the first paragraph (Professional Summary). The recruiter may only read the summary. All URLs with `white-space: nowrap` in HTML.
+9. **Tracker additions as TSV** -- NEVER add new entries directly to day files in `data/applications/`. Write TSV in `batch/tracker-additions/` and `merge-tracker.mjs` handles the merge.
+10. **Include `**URL:**` in every report header** -- between Score and PDF.
+
+### Use these tools
+
+| Tool | Use |
+|------|-----|
+| WebSearch | Comp research, trends, company culture, LinkedIn contacts, fallback for JDs |
+| WebFetch | Fallback for extracting JDs from static pages |
+| Geometra MCP | Verify offers (`geometra_page_model`), extract JDs (`geometra_connect` + `geometra_snapshot`), fill forms (`geometra_fill_form`), generate PDFs (`geometra_generate_pdf`). **The MCP server accepts up to 5 concurrent sessions, but orchestrator subagent parallelism is capped at 2** (Hard Limit #1 in `AGENTS.md`) — do not interpret the 5-session ceiling as permission to dispatch 5 subagents. Each `geometra_connect` returns a `sessionId` — pass it to all subsequent tool calls to target the right session. Omitting `sessionId` targets the most recently connected session. Use `geometra_list_sessions` to inspect active sessions. |
+| 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` |

package/modes/apply.md

@@ -0,0 +1,257 @@
+# Mode: apply — Live Application Assistant
+
+Interactive mode for when the candidate is filling out an application form in Chrome. Reads what's on screen, loads prior context from the offer evaluation, and generates personalized answers for each form question.
+
+## Apply the session-length rule — REQUIRED
+
+**If the candidate wants to apply to more than one job**, this mode MUST delegate each application to its own subagent with **max 2 in parallel** (Hard Limit #1 in `AGENTS.md`). For N jobs, run `ceil(N/2)` sequential rounds of 2. Never drive multi-job applications from a single interactive session: the accumulating Geometra tool results invalidate prompt caching and each message ends up re-processing 100K+ tokens of fresh history — see "Session Hygiene" in `.opencode/skills/job-forge.md`.
+
+**DO NOT dispatch 3+ `task` calls in one message.** Two is the absolute ceiling. This is non-negotiable, even when the user asks for "apply to 10 jobs" — that becomes 5 rounds of 2, not one message with 10 dispatches.
+
+For a single application interactively, carry on in the current session — the rule targets multi-job loops.
+
+### Run this multi-job apply runbook literally when N > 1
+
+```
+Step 1  — Build the job list (N items)
+Step 2  — Dedup: Grep data/pipeline.md + today's day file for each company+role. Drop any already APPLIED.
+Step 3  — geometra_list_sessions() + geometra_disconnect({closeBrowser: true})  [once, before loop]
+Step 4  — For round in ceil(N/2):
+            pair = jobs[round*2 : round*2 + 2]
+            # ONE message, 1 or 2 task() calls. Never 3.
+            task(apply to pair[0])
+            task(apply to pair[1])  # only if pair has 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
+Step 7  — Summarize outcomes; do NOT auto-retry failures.
+```
+
+If a subagent fails, report it in the summary and let the user decide whether to retry. Never auto-retry — re-running a submit step risks duplicate applications.
+
+**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.
+- **Do NOT** append APPLIED / FAILED / SKIP lines to `data/pipeline.md` — that file is the URL inbox only.
+
+## Verify these requirements
+
+- **Best with Geometra MCP**: In visible proxy mode, the candidate sees the browser and opencode can interact with the page via `geometra_connect`, `geometra_form_schema`, and `geometra_fill_form`.
+- **Without Geometra**: the candidate shares a screenshot or pastes the questions manually.
+
+## Run this workflow
+
+```
+1. DETECT     → Read active Chrome tab (screenshot/URL/title)
+2. IDENTIFY   → Extract company + role from the page
+3. SEARCH     → Match against existing reports in reports/
+4. LOAD       → Read full report + Section G (if it exists)
+5. COMPARE    → Does the role on screen match the evaluated one? If changed → warn
+6. ANALYZE    → Identify ALL visible form questions
+7. GENERATE   → For each question, generate a personalized answer
+8. PRESENT    → Show formatted answers for copy-paste
+```
+
+## Step 1 — Detect the offer
+
+Run `geometra_connect` against the active page (with Geometra MCP), then `geometra_page_model` to read the title, URL, and visible content. **Do NOT also WebFetch the same URL** — Geometra's page model already contains the JD text. Each additional fetch re-pulls the same content into conversation history at full input cost.
+
+**Without Geometra:** Ask the candidate to do one of these:
+
+- Share a screenshot of the form (Read tool reads images).
+- Paste the form questions as text.
+- Provide company + role so we can look it up.
+
+## Step 2 — Extract context and search reports
+
+- Extract the company name and role title from the page.
+- Search in `reports/` by company name (Grep case-insensitive).
+- If there's a match → load the full report.
+- If there's a Section G → load the previous draft answers as a base.
+- If there's NO match → notify and offer to run a quick auto-pipeline.
+
+## Step 3 — Detect role changes
+
+Compare the role on screen against the evaluated one. When they differ, do the following.
+
+- **Warn the candidate**: "The role has changed from [X] to [Y]. Do you want me to re-evaluate or adapt the answers to the new title?"
+- **If adapt**: Adjust the answers to the new role without re-evaluating.
+- **If re-evaluate**: Run a full A-F evaluation, update the report, regenerate Section G.
+- **Update tracker**: Change the role title in the day file under `data/applications/` when the row already exists.
+
+## Step 4 — Scan form questions
+
+Extract ALL visible questions across these field types.
+
+- Free text fields (cover letter, why this role, additional info).
+- Dropdowns (how did you hear, work authorization, source).
+- Yes/No (relocation, visa sponsorship, current employment).
+- Salary fields (range, expectation).
+- Upload fields (resume, cover letter PDF).
+
+Classify each question:
+- **Already answered in Section G** → adapt the existing answer
+- **New question** → generate an answer from the report + cv.md
+
+## Step 5 — Generate answers
+
+Generate the answer for each question using these inputs in order.
+
+<!-- isolint-disable-next-line undefined-step-reference -->
+1. **Report context**: Use proof points from Block B, STAR stories from Block F.
+2. **Previous Section G**: If a draft answer exists, use it as a base and refine
+3. **"I'm choosing you" tone**: Same framework as the auto-pipeline
+4. **Specificity**: Reference something concrete from the JD visible on screen
+5. **job-forge proof point**: Include in "Additional info" if there's a field for it
+
+**Output format:**
+
+```
+## Answers for [Company] — [Role]
+
+Based on: Report #NNN | Score: X.X/5 | Archetype: [type]
+
+---
+
+### 1. [Exact form question]
+> [Answer ready for copy-paste]
+
+### 2. [Next question]
+> [Answer]
+
+...
+
+---
+
+Notes:
+- [Any observations about the role, changes, etc.]
+- [Personalization suggestions the candidate should review]
+```
+
+## Dispatch the form atomically (Step 5.5 — REQUIRED)
+
+When the candidate asks you to actually submit (or when running in auto-pipeline mode at score ≥ 3.0), follow these rules **strictly**. Greenhouse-style forms regenerate internal field IDs after any DOM-mutating action, especially file uploads. That breaks multi-call fill sequences and forces the model into a retry loop that burns tens of thousands of tokens.
+
+### Use one `run_actions` call (Rule A — never split)
+
+Do the entire submission in a **single** `geometra_run_actions` call that chains all steps. Never split upload / fill / submit across multiple tool calls.
+
+```
+geometra_run_actions({
+  sessionId: "...",
+  actions: [
+    { type: "upload_files",  fieldLabel: "Resume/CV", paths: ["/abs/path/cv.pdf"] },
+    { type: "fill_fields",   valuesByLabel: { "First Name": "...", "Last Name": "...", ... } },
+    { type: "pick_listbox_option", fieldLabel: "Country", value: "United States" },
+    ... (one entry per choice/listbox) ...
+    { type: "click",         labelOrText: "Submit application" }
+  ]
+})
+```
+
+### Use `fieldLabel` over `fieldId` (Rule B)
+
+Labels are stable across DOM refreshes; IDs are not. If `fieldLabel` works, use it everywhere. Only fall back to `fieldId` when two fields share the same label (rare — add a qualifier via sibling text instead).
+
+### Run recovery ONCE on ANY session error (Rule C)
+
+**Trigger:** you see ANY of these error strings from a Geometra call:
+- `Not connected`
+- `session expired`
+- `unknown session`
+- `Failed to connect`
+- `WebSocket` + `closed` / `error`
+
+**Recovery sequence — run these FOUR calls in this EXACT order:**
+
+```
+Call 1:  geometra_list_sessions()
+Call 2:  geometra_disconnect({ closeBrowser: true })
+Call 3:  geometra_connect({
+           pageUrl: "<the same URL as before>",
+           isolated: true,
+           headless: true,
+           slowMo: 350
+         })
+Call 4:  geometra_run_actions({
+           sessionId: "<new sessionId from Call 3>",
+           actions: [... the EXACT same actions array you used before ...]
+         })
+```
+
+### Apply these recovery rules
+
+1. **Always run all 4 calls.** Do not skip Call 1 or Call 2 even if Call 1 shows an empty pool.
+2. **Do not re-fetch the form schema.** Do not call `geometra_form_schema` between Call 3 and Call 4. Your labels haven't changed, so the same `actions` array still works.
+3. **Do not edit the actions array.** Copy it verbatim from your first attempt. Do not re-pick fieldIds. Do not add or remove actions. Same array in, same array out.
+4. **Only ONE retry.** If Call 4 ALSO fails, STOP. Return this exact message to the orchestrator:
+
+   ```
+   APPLY FAILED AFTER RECOVERY: <URL>
+   Error 1: <first error message>
+   Error 2: <error after recovery>
+   Recommend: re-dispatch on @general-paid
+   ```
+
+   Do NOT try a third time. Do NOT try a different approach. The orchestrator will decide whether to re-dispatch on a bigger model.
+
+### Skip schema re-fetches mid-flow (Rule D)
+
+`geometra_form_schema` returns hundreds of nested field IDs and pollutes context. Fetch it **at most once** per application, right after the initial `geometra_connect`, to discover the list of labels. After that, operate on labels only. Do not call `geometra_form_schema` again "to verify" — you're just paying for the same payload twice.
+
+### Skip mixed upload + separate fill (Rule E)
+
+If you've uploaded a file with a dedicated `geometra_run_actions` call (e.g., the resume), and THEN try a separate `geometra_fill_form` or `geometra_fill_fields` call, the field IDs from the pre-upload schema are already stale. This was the primary failure mode on the Anthropic FDE apply trace — 4 retries, ~10K wasted tokens. The fix is Rule A: do everything in one shot.
+
+### Use two phases when the form has a post-upload conditional section (Exception)
+
+Specific portals — Workday "parse my resume", iCIMS multi-step, SAP SuccessFactors — reveal additional fields ONLY after a file upload. In that case, use exactly two `run_actions` calls: (1) upload + wait_for, (2) fill+submit. After the first call, call `geometra_form_schema` **once** to discover the newly-revealed labels, then run the second call using labels. Never more than two phases.
+
+## Step 6 — Resolve OTP verification (if prompted)
+
+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.
+
+**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`.
+
+## Step 7 — Update outcomes after submission
+
+Select the matching case below — two cases, two different flows. Do NOT mix them.
+
+### Update the existing row (Case A — prior `Evaluated` status)
+
+The row exists. You are UPDATING an existing entry, which is allowed (Pipeline Integrity rule #2 in `AGENTS.md`):
+
+1. Find the existing row in `data/applications/YYYY-MM-DD.md` (or an older day file — use `rg` to locate it)
+2. Edit the `Status` column from `Evaluated` to `Applied` (or `FAILED` / `SKIP`)
+3. Append a confirmation note to the `Notes` column (e.g. OTP code, confirmation URL)
+4. Do NOT write a TSV. The row is already there.
+
+### Write a TSV addition (Case B — no prior evaluation row)
+
+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
+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
+
+- Update Section G of the report with the final answers
+<!-- isolint-disable-next-line undefined-step-reference -->
+- Suggest next step: `/job-forge contact` for LinkedIn outreach — contact will automatically load this evaluation report and use the top proof points from Block B to craft targeted messages
+
+## Resolve long forms by scrolling
+
+If the form has more questions than are visible:
+- Ask the candidate to scroll and share another screenshot
+- Or paste the remaining questions
+- Process in iterations until the entire form is covered

package/modes/auto-pipeline.md

@@ -0,0 +1,70 @@
+# Mode: auto-pipeline — Full Automatic Pipeline
+
+When the user pastes a JD (text or URL) without an explicit sub-command, execute the ENTIRE pipeline in sequence:
+
+## Step 0 — Extract JD
+
+Fetch the JD content once. If the input is a **URL** (not pasted JD text), fetch the content **once** using exactly ONE of the methods below. **Do NOT chain methods as redundant fallbacks** — each method re-pulls the same 3-5K tokens into context.
+
+**Pick exactly one method, in this priority order:**
+
+1. **Geometra MCP (preferred):** Most job portals (Lever, Ashby, Greenhouse, Workday) are SPAs. Use `geometra_connect` + `geometra_page_model` to render and read the JD. **If this returns non-empty JD text, STOP — do not WebFetch the same URL.**
+2. **WebFetch (only if Geometra is unavailable OR returned only a shell with no JD text):** For static pages (ZipRecruiter, WeLoveProduct, company career pages).
+3. **WebSearch (only if methods 1 AND 2 both failed):** Search for the role title + company on secondary portals that index the JD in static HTML.
+
+**Rule:** Each URL gets fetched at most once per session. If you already have the JD text in context — from Geometra, a previous WebFetch, or pasted by the candidate — do not fetch again.
+
+**If no method works:** Ask the candidate to paste the JD manually or share a screenshot.
+
+**If the input is JD text** (not a URL): use it directly, no fetching needed.
+
+## Step 1 — Run Evaluation A-F
+Execute exactly as in the `offer` mode (read `modes/offer.md` for all blocks A-F).
+
+## Step 2 — Save Report .md
+Save the complete evaluation to `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` (see format in `modes/offer.md`).
+
+## Step 3 — Generate PDF
+Execute the full `pdf` pipeline (read `modes/pdf.md`).
+
+## Step 4 — Generate Application Answers When Score >= 3.5
+
+Generate draft answers for the application form when the final score is >= 3.5. If the final score is >= 3.5 (per Canonical Scoring Model thresholds in `_shared.md`), generate draft answers for the application form:
+
+1. **Extract form questions**: Use Geometra MCP (`geometra_connect` + `geometra_form_schema`) to discover all form fields. If questions cannot be extracted, use the generic questions.
+2. **Generate answers** following the tone guidelines (see below).
+3. **Save in the report** as a `## G) Draft Application Answers` section.
+
+### Use Generic Questions When Form Extraction Fails
+
+- Why are you interested in this role?
+- Why do you want to work at [Company]?
+- Tell us about a relevant project or achievement.
+- What makes you a strong fit for this position?
+- How did you hear about this role?
+
+### Apply This Tone For Form Answers
+
+**Position: "I'm choosing you."** The candidate has options and is choosing this company for concrete reasons.
+
+**Tone rules:**
+
+- **Confident without arrogance**: "I've spent the past year building production AI agent systems — your role is where I want to apply that experience next".
+- **Selective without overstatement**: "I've been intentional about finding a team where I can contribute meaningfully from day one".
+- **Specific and concrete**: Always reference something REAL from the JD or the company, and something REAL from the candidate's experience.
+- **Direct, no fluff**: 2-4 sentences per answer. No "I'm passionate about..." or "I would love the opportunity to...".
+- **The hook is the proof, not the claim**: Instead of "I'm great at X", say "I built X that does Y".
+
+**Framework per question:**
+- **Why this role?** → "Your [specific thing] maps directly to [specific thing I built]."
+- **Why this company?** → Mention something concrete about the company. "I've been using [product] for [time/purpose]."
+- **Relevant experience?** → A quantified proof point. "Built [X] that [metric]. Sold the company in 2025."
+- **Strong fit?** → "I sit at the intersection of [A] and [B], which is exactly where this role lives."
+- **How did you hear?** → Honest: "Found through [portal/scan], evaluated against my criteria, and it scored highest."
+
+**Language**: Always in the language of the JD (EN default). Apply `/tech-translate`.
+
+## Step 5 — Update Tracker
+Update the current day file `data/applications/YYYY-MM-DD.md` with all columns including Report and PDF marked as ✅.
+
+**If any step fails**, continue with the remaining steps and mark the failed step as pending in the tracker.