RFC: gambit mode + the Speculative pipeline state (create-a-role pursuits)

[devty]

RFC: gambit mode + the Speculative pipeline state (create-a-role pursuits)

Type: New mode category + new canonical pipeline state
Reference PR: #824 — feat: create-a-role "gambit" mode + Speculative pipeline state
Process: Filed per RFC Process — Discussion #284
Umbrella: None — this is a standalone new category. It does not fit #272 (Multi-CLI) or #230 (Scanner providers).
Core vs. shared layer: This is core. It is local, human-in-the-loop, and draft-never-send — you hit submit. It is explicitly not the hosted/automation/shared layer from #904: no aggregation, no proxies, no auto-apply, nothing leaves the machine.

This RFC is filed at the maintainer's request: PR #824 was flagged as needing the architect's call because it introduces a new mode category and new pipeline semantics, and categories enter through the RFC process rather than PR review. The PR is already implemented and green (157 JS assertions + Go dashboard tests pass) — but I'm treating it as the reference implementation behind the proposal, not a fait accompli. The point of this RFC is to validate appetite and settle the open questions below before anything merges.

---

1. Problem

Every existing career-ops mode is reactive — it starts from an artifact that already exists:

Mode	Starts from
oferta, pdf	a job description
scan, pipeline	a posting URL
apply	a form on screen
contacto	a known contact / posted req

Intelligence flows inward: given this opening, how do I fit it? That covers the posted job market well.

It leaves a gap. Some of the highest-leverage opportunities are unposted — a developer-facing product with zero DevRel headcount, an API nobody has productized, an AI capability with no one shipping it. The play there is the inverse: pick a company, diagnose the function it is conspicuously missing given its trajectory, and pitch a role that does not exist yet to the person who could create it.

career-ops has no home for that. Today it gets handled with ad-hoc prompting, which is exactly where the system's guardrails don't apply — and a cold, speculative pitch to an executive is the highest annoyance-risk action in the entire system. A bad one wastes a decision-maker's attention and burns a company you actually wanted. So this is precisely the workflow that most needs first-class, ethically-bounded support, not the one that should be left to freehand prompts.

Two things are missing, and they are coupled:

1. A workflow for the proactive/speculative pursuit (research → diagnose the gap → make the case).
2. A pipeline state to track that pursuit honestly — it has no posting behind it, no legitimacy tier to verify, and a different lifecycle than a normal application. Forcing it into Evaluated loses all three distinctions.

---

2. Proposed solution

Two coupled pieces. I'm presenting the state first because it's the concrete, reviewable, cross-cutting artifact — the mode is the use case that motivates it.

2a. The Speculative state — the spine

A new canonical state in templates/states.yml (aliases spec, gambit):

• Lifecycle: Speculative → Responded / Interview / Offer (if the pitch lands) or → Discarded (if it goes nowhere). It marks a pursuit that has no posting behind it yet.

• Why a new state and not Evaluated:

  • A speculative pursuit has no posting to verify → Legitimacy is N/A, not a tier. Evaluated rows carry a real legitimacy tier; conflating them corrupts that signal.
  • It has a distinct lifecycle and dedup identity — the tracker role cell carries the invented title + a (gambit) marker so a speculative pursuit doesn't collide with a future real posting at the same company.
  • The dashboard should surface it distinctly — "I pitched a role that doesn't exist" is a different pipeline reality than "I evaluated a posted job."

• Blast radius (the real reason this needs an RFC, not just a PR). states.yml is the named source of truth, but several consumers hardcode the state list, so a new state fans out to every one of them — and if any consumer is missed, it silently downgrades a Speculative row back to Evaluated:

  Layer	Consumers
  Source of truth	templates/states.yml
  JS pipeline	normalize-statuses.mjs, verify-pipeline.mjs, dedup-tracker.mjs, merge-tracker.mjs
  Go dashboard	dashboard/internal/data/career.go (normalize + sort priority), dashboard/internal/ui/screens/pipeline.go (render, filter tab, color, group order)

  This is genuinely new pipeline semantics across two languages — which is why it deserves the architect's sign-off rather than a quiet merge.

2b. The gambit mode — the use case

/career-ops gambit {company} runs the create-a-role play. High-level flow (full spec in PR #824 / modes/gambit.md):

research → negative-space gap analysis → ranked role theses
  → CHECKPOINT (user picks the bet)
  → synthetic JD → reuse the reactive engine → contact discovery
  → pitch package → conviction gate → report + tracker row

The keystone is a synthetic-JD bridge. The mode writes the invented role as the posting the company should publish — and from that point on, the entire reactive engine works unchanged: pdf.md keyword-extracts and tailors the CV, the _shared.md cover-letter rule fires, report blocks A–F apply almost verbatim. The system is inverted exactly once, at the thesis; everything after it is trusted, already-tested machinery. That's what keeps the mode small instead of a parallel pipeline.

Three design points worth flagging to reviewers:

• Entity disambiguation (Step 0.5). Company names collide (a recipe app, a blockchain firm, and an HR-tech startup can all be "Crouton"). Before spending any research budget, the mode resolves the entity and STOPs if ambiguous. (Added after the first live run hit exactly this failure.)
• Negative-space analysis. What a company is hiring reveals its priorities and org shape; the gap is what's conspicuously absent given that trajectory.
• The right human. Contact discovery targets the founder/CEO at seed–Series A, the owning exec at Series B+ — never a recruiter, because recruiters fill posted reqs, they don't invent them.

2c. Ethics — the conviction gate (a feature, not a footnote)

This is the part I'd most want the community and the architect to pressure-test, because it's where the repo's stated soul — "quality over quantity, respect the recruiter's time" — is most load-bearing. A speculative cold pitch is the highest-annoyance-risk action the system can take, so the mode holds itself to the strictest bar in career-ops:

• Evidenced, not invented. Every claimed company gap must cite a real signal (a careers page, a funding note, an exec hire). Fabricating a need is forbidden under the same rule as "never invent metrics."
• The synthetic JD is always labeled candidate-authored — in the report and in the forwardable memo. It is never presented as the company's posting.
• High conviction only. A go/no-go gate recommends SEND only when all three legs hold: (a) the unmet need is evidenced, (b) CV-fit is strong (≈≥4.0), and (c) a specific decision-maker who could create the role is reachable. Any weak leg → it recommends against sending, explicitly, and names which leg failed.
• Human-in-the-loop, always. The mode produces drafts and leads with an honest recommendation; the user decides. Nothing is ever sent automatically.

This is the "respect their time" ethos turned up a notch for the one action where it matters most — and it's why this belongs in the core, governed by these guardrails, rather than left to freehand prompting.

---

3. Files affected

All changed files are system-layer (auto-updatable). No user data is touched; the personalization hook is via template placeholders only (see §4).

Area	Files
Source of truth	templates/states.yml
JS pipeline	normalize-statuses.mjs, verify-pipeline.mjs, dedup-tracker.mjs, merge-tracker.mjs
Go dashboard	dashboard/internal/data/career.go (+ career_test.go), dashboard/internal/ui/screens/pipeline.go (+ pipeline_test.go)
Mode	modes/gambit.md (new)
Routing & docs	.agents/skills/career-ops/SKILL.md, CLAUDE.md, AGENTS.md
User-layer scaffold	modes/_profile.template.md (adds two fill-in-yourself sections)
CI	test-all.mjs (mode-integrity + Speculative-state assertions)

---

4. Data Contract impact

• No new files in the contract. modes/gambit.md is a new system-layer mode (auto-updatable), exactly like oferta.md.
• Personalization stays in the user layer. gambit.md reads two sections from the user's modes/_profile.md — ## Your Natural Level & Company-Stage Calibration and ## Gambit Playbook — the same way oferta reads _profile.md for archetype framing. The PR seeds these as bio-free, fill-in-yourself scaffolds in modes/_profile.template.md (system-layer template), so a fresh install resolves them to a prompt rather than to nothing. The user's actual _profile.md is never overwritten by updates.
• The Speculative state is system-layer in templates/states.yml. Reports and the tracker remain user-layer as today.
• Parser compatibility is preserved. The gambit report's ## Machine Summary keeps every existing key, sets legitimacy: "N/A (speculative)" as a safe sentinel, and only adds keys (mode: gambit, decision_maker). Existing parsers (merge-tracker.mjs, analyze-patterns.mjs) are unaffected.

Net: this is a clean system-layer addition with a user-layer hook via the established template mechanism — no change to how user vs. system data is classified.

---

5. Phases

The reference PR (#824) currently bundles both pieces. For merge, I'd split it into two independently-shippable phases (this mirrors the build sequence in the design spec — land the riskiest cross-cutting change first, alone, where it's independently verifiable):

• Phase 1 — the Speculative state contract. states.yml + the 4 JS consumers + the 2 Go dashboard files + tests. This is the riskiest change (cross-language, hardcoded-list blast radius) and is verifiable on its own: a sample Speculative tracker row survives normalize-statuses, verify-pipeline, dedup-tracker, merge-tracker, and renders/sorts correctly in the dashboard. Mergeable without the mode.
• Phase 2 — the gambit mode. modes/gambit.md + the _profile.template.md scaffolds + routing/docs (SKILL.md, CLAUDE.md, AGENTS.md) + the CI mode-integrity check. Depends on Phase 1.

I'm happy to split #824 into two PRs along this line if the RFC is approved — or leave it as one if the architect prefers to review the category whole. Either way, Phase 1 is the natural first merge.

---

6. Open questions (community + architect input wanted)

These are genuinely open — the RFC is here to settle them, not to ratify a finished answer.

1. Naming. Is gambit the right public-facing name? Alternatives: create-a-role, speculative, pitch. gambit is memorable but jargon-y; a plainer name might be more discoverable. (The state could keep a neutral name even if the mode is renamed.)

2. State generality. Should Speculative be a generic state for any unposted pursuit — referral-chasing, talent-network intros, "they'll open a req next quarter" — rather than gambit-specific? Making it generic now (gambit being the first consumer) may be the more durable design and is the question most likely to matter long-term. The counter-argument is YAGNI: keep it gambit-scoped until a second use case actually appears.

3. Dashboard grouping. Should Speculative get its own dashboard group, or fold into the existing evaluated band? The PR gives it its own filter tab and color but sorts it at the same priority as evaluated (with a tie-breaker to keep the two contiguous). Open to the maintainers' preference on visual treatment.

4. Conviction-gate configurability. Should the ≥4.0 send threshold and the three-leg go/no-go test be configurable in config/profile.yml, or hardcoded in the mode? Hardcoding keeps the ethical floor non-negotiable (arguably the point); configuring respects that different users calibrate "high conviction" differently. There's a real values trade-off here, not just a knob.

Known follow-up (not a question): CLI-skill routing was wired into .agents/skills/career-ops/SKILL.md only; the .claude/ and .qwen/ variants are structurally different and were intentionally left to the maintainers' conventions. Easy to extend in-phase or as a follow-up.

---

Closing

PR #824 can wait on this RFC — link it here and I'll hold. If the community sees appetite, Phase 1 (the state contract) is a small, well-tested first merge and the mode follows. If the architect would rather this not enter the core at all, I'd genuinely like to hear why on the record, because the "no posting behind it" pursuit feels like a real and growing slice of how people actually job-hunt — and I'd rather it be governed by career-ops's guardrails than left to ad-hoc prompts.

Thanks for the process, and for the kind words on the PR.

[santifer]

Acknowledged, @devty — and thank you for turning this around within hours, filed exactly per the process (#284), with the core-vs-shared-layer self-classification done right. That makes evaluating it much easier.

What happens next: I'll give this a proper architectural read (the new pipeline state is the part with the widest blast radius — every tool that parses pipeline.md/states.yml needs to understand it), and I'd genuinely like community input here too: if you'd use create-a-role pursuits, say so in this thread — appetite is a real input to whether a new category earns its complexity. No timeline promises, but it's on the list and PR #824 stays open waiting on this.