@sbains2/lifeos 0.2.2 → 0.3.1

package/templates/packs/job-search/council_playbook.md

@@ -0,0 +1,117 @@
+# Council playbook — job-search pack (two tracks)
+
+This is the operating spec the council follows when convened on the Job Search quadrant. It assumes a filled `SCOPE.md` (from [SCOPE.template.md](SCOPE.template.md)) sits next to it. The playbook is generic on purpose: everything candidate-specific lives in the scope file, so targeting changes never require editing this file.
+
+> Two tracks, scored on **separate rubrics with separate maxima** — never cross denominators.
+> A printed score above its stated max is a hard bug; recompute.
+
+---
+
+## Standing orders (before EVERY convening)
+
+1. **Load `SCOPE.md` in full.** It is the source of truth for identity, gates, the proof bank, claim boundaries, and scoring maxima. If it conflicts with anything below, the scope file wins. If it cannot be loaded, **STOP** — do not proceed from memory.
+2. **Prove the load:** restate in one line each — the level-lane rule (§A2), the four relationship gates G1–G4, and the claim boundaries (§E). An agent that cannot restate them did not read them.
+3. **Check the calendar** (if a calendar MCP is wired): flag any interview, coffee chat, or application deadline within 72 hours as URGENT before doing anything else.
+4. **Draft only.** Compile, rank, and draft. Never submit an application, never send a message or connection request.
+
+## Member roles
+
+<!-- Map these to whichever MCPs you wired; the roles are stable, the tools are swappable. -->
+
+| Member | Role | Primary tools |
+|---|---|---|
+| **The Archivist** | Retrieves past applications, outreach history, and resume materials | filesystem / drive MCP |
+| **The Analyst** | Gates and scores postings (APPLY track) | job-search MCP, web fetch |
+| **The Connector** | Finds and gates network contacts; scores bridge value (RELATIONSHIP track) | people-search MCP |
+| **The Scribe** | Drafts outreach and follow-ups inside the claim boundaries | text output only — no send tools |
+
+---
+
+## APPLY protocol (jobs to apply to now — fit /5, velocity /15)
+
+### 1. Search
+
+Run searches across every §B archetype in the target geos. Prioritize roles matching the SIGNATURE archetype — it is the tie-breaker up. Deprioritize stale / ghost / evergreen reposts on sight.
+
+### 2. Hard-gate, THEN score
+
+For each posting:
+
+- **Level lane FIRST (§A2)** — read the Minimum-Qualifications years line before anything else and route: cold-apply / warm-referral / kill. Warm-referral-lane roles are handed to the RELATIONSHIP track (company → referral queue), never cold-applied — but run the variant hunt first.
+- **Hard disqualifiers (§C)** — name the exact firing string for each rejection and label it **KILL** vs **FLAG**. A keyword match never survives a fired gate.
+- **Classify into exactly ONE archetype** (read the responsibilities, not the title), then **score fit /5** by mapping the JD to that archetype's lead-with proof point (§D). If no lead-with proof point maps cleanly, the role is not tailored — say so. **Show the arithmetic**: each component named, summed, clamped to 5. There is **no company-tier bonus in either direction**.
+- **Velocity /15 is a separate line** — posting age, active-hiring signals, freshness integrity. It sets ordering and apply-urgency, never the fit score. Suggested bands: 12–15 HOT (apply same day) · 8–11 FRESH (24–48 h) · 4–7 AGING (apply only if fit ≥ 4.5) · 0–3 STALE/GHOST (deprioritize → hand the company to the RELATIONSHIP track).
+- **Queue rule:** the active apply queue requires cold-apply lane AND fit ≥ 4.0 AND velocity ≥ 4 (high fit may pull in an AGING role). If freshness is *unverifiable* but not disproven on a high-fit role, route it to a "verify-then-apply" list rather than dropping it — hard-drop only on a positive ghost/evergreen/closed tell.
+
+### 3. Output
+
+A ranked apply queue (HOT/FRESH first). Per row: company · role · URL · lane + **the years line verbatim** · fit /5 · velocity /15 · the one proof point to lead with · the single best reason to apply.
+
+Then a **REJECTED list**: title + the one-line firing reason each. **No fixed top-N quota** — a quota forces padding; show only what passes the gates, and make the cuts auditable.
+
+---
+
+## RELATIONSHIP protocol (warm referrals — bridge value /100)
+
+You are scoring a contact's **bridge value to the candidate**, not the contact's prestige. Company fame is at most a tie-breaker.
+
+### Gates first (G1–G4) — ANY fail ⇒ print `DQ: <reason with the firing string>`, never a number, never a ranked position
+
+- **G1 — Verified network membership.** For alumni networks: a **degree** at a §A school shown in the profile's **Education** section (with class/grad years). **FAIL** if the school appears only in *Experience* — professor, lecturer, adjunct, instructor, postdoc, staff, advisor, guest speaker, or a student-researcher/RA role. An academic title is employment, not attendance. When in doubt → FAIL.
+- **G2 — Current employment at the target company.** Present-tense full-time (a converted intern with a few months of FTE tenure counts). **FAIL** on "ex-/former" or a past end date; a past internship is labeled "intel only, not a bridge".
+- **G3 — Referral-capable.** IC or first-line/early manager with peer-referral standing. **FAIL** a pure recruiter/sourcer with no team membership; a current student/intern; or **too-senior** Director/VP/Head-of/C-suite — detached senior leaders do not file peer referrals.
+- **G4 — Role-domain relevance.** The contact's team plausibly hires one of the §B archetypes. **FAIL** a wholly unrelated function, and mirror the scope's specialty boundaries (e.g. if the scope excludes infra work, an infra engineer at the right company still fails G4).
+
+### Base factors — select exactly **ONE tier per factor** (never additive within a factor); sum, then cap
+
+| Factor | Max | What it measures |
+|--------|-----|------------------|
+| **F1 — Referral power** | **30** | 30 = IC/first-line manager with clear standing · 18 = senior IC (still peer-referral-capable) · 8 = borderline case who directly staffs the archetype |
+| **F2 — Team hires the candidate** | **28** | 28 = own team does archetype work AND has an open early-career req now · 18 = own team does the work, no confirmed req · 10 = company hires the archetype, not this team · 0 = no line of sight |
+| **F3 — Shared-context depth** | **18** | 18 = same program + overlapping years, or a named shared tie (advisor, org, prior employer) · 10 = same school, overlapping era · 4 = same school only, distant era |
+| **F4 — Groundable personalization** | **14** | 14 = a specific proof point maps **1:1** to the contact's specific work · 7 = archetype-level match · 0 = only a generic hook (also fails the swap-invariance test below) |
+| **F5 — Reachability / freshness** | **10** | 10 = active < 90 days AND easy contact path · 5 = active < 90 days · 2 = active < 12 months · 0 = dormant |
+
+Max attainable = 30 + 28 + 18 + 14 + 10 = **100**. `BASE = min(100, F1+F2+F3+F4+F5)` — the cap is a safety net; under single-tier selection it never binds, and mutually exclusive tiers make double-counting impossible.
+
+**Floors (don't under-score a confirmed but terse profile):** a contact who passes all four gates and is confirmed in-archetype gets **F2 ≥ 10 and F4 ≥ 7** even on a sparse headline. DQ only on an actual gate failure, never on missing profile detail.
+
+### Mutual-connection multiplier M — multiply, then clamp
+
+- **M = 1.30** — a close broker who has actually agreed to make the intro.
+- **M = 1.15** — a credible mutual **verified** in the platform's mutual-connections panel.
+- **M = 1.00** — no mutual, or unverified/assumed (**default**).
+
+**`FINAL = min(100, round(BASE × M))`.** Always report **both** BASE and FINAL so broker inflation is auditable. **Anti-leapfrog:** require BASE ≥ 60 before any multiplier may push a contact into TOP (≥ 80) — a thin contact cannot leapfrog a higher-BASE peer on a multiplier alone.
+
+> Multiply-then-clamp + single-tier selection is what makes a score like `105/90` structurally impossible: the denominator is fixed at 100, BASE is pre-capped, and FINAL is clamped.
+
+### Bands & alarms
+
+≥ 80 **TOP** (reach out first, personalized) · 65–79 **SOLID** · 50–64 **WATCH** · < 50 **DO NOT PRIORITIZE** · any gate fail = `DQ: <reason>`.
+
+**Score-collapse alarm:** if > 40% of contacts share one total, the scoring is non-differentiating — re-score before publishing the digest.
+
+### Personalization rules (where precision lives)
+
+Every outreach draft (≤ 300 characters) must:
+
+1. Classify the contact into the archetype their team hires, then **lead with that archetype's lead-with proof point** from §D — verbatim claims only.
+2. Reference their **specific** title/team plus one concrete detail (a recent post, a named product area) and ask one sharp question about their team's actual work.
+3. Match the shared school to where they **actually earned a degree**.
+4. Stay inside the §E claim boundaries.
+5. **Pass the swap-invariance test: if the message still works with another name swapped in, it is not personalized enough — rewrite it.** Banned openers: "I came across your profile", "I hope this finds you well", or leading with your degree program as the hook.
+
+---
+
+## Keep it honest (why these lines exist)
+
+Each maps to an observed failure mode — keep them even as you customize:
+
+1. **"Prove you loaded the file"** — forces the scope read instead of guessing from training data; the root cause of generic output.
+2. **"Name the firing string" + the REJECTED list** — inflation hides in what a model silently keeps; making it justify cuts surfaces the gating.
+3. **"Years line verbatim, lane first"** — decides the lane before optimism creeps in.
+4. **"Show the arithmetic, clamped to max"** — kills the score-above-its-own-max class of error.
+5. **"No fixed top-N quota"** — a quota forces padding; gate-only output is the opposite.
+
+**If the model is fast but loose, split into two passes:** pass 1 = gate + route + the REJECTED list only (cheap, no scoring); pass 2 = score and draft only the survivors. It stops the model polishing blurbs for roles that should have been cut.

package/templates/packs/job-search/scout_prompt.template.md

@@ -0,0 +1,111 @@
+# Scheduled scout — agent prompt (RELATIONSHIP track)
+
+> Register this prompt as a recurring task with `lifeos schedule` (daily is the dogfooded cadence).
+> It assumes a people-search MCP (e.g. `linkedin` from the registry — read its risk advisory first)
+> and optionally a web-fetch MCP. This is the **RELATIONSHIP track**: you score a *contact's bridge
+> value to the candidate*, not their prestige.
+> You COMPILE, RANK, and DRAFT only — you do **not** send any message or connection request.
+
+<!-- Fill every {{PLACEHOLDER}}, then copy to <your-lifeos>/JobSearch/scout_prompt.md.
+     The scoring model below is the same one as council_playbook.md — if you tune tiers or
+     maxima in SCOPE.md §F, keep this file in sync. -->
+
+---
+
+## Step 0 — Load the scope (MANDATORY, before any search)
+
+1. **Read `{{SCOPE_PATH}}` in full** (e.g. `./JobSearch/SCOPE.md`). It is the source of truth for who the candidate is, the bridge-value model, the proof bank, and the claim boundaries. If anything below conflicts with it, the scope file wins.
+2. **Prove you read it — restate in one line each, before searching:**
+   - the level-lane rule (§A2),
+   - the four gates G1–G4,
+   - the claim boundaries (§E).
+3. If you cannot load the scope file, **STOP and report the failure.** Do not proceed from memory.
+
+## Step 1 — Build the target-company list
+
+Union of:
+- the referral queue at `.lifeos/job-search/referral_queue.txt` (fed by the bridge — see [bridge.md](bridge.md)); skip silently if missing or empty, and
+- the standing tracked companies: {{TRACKED_COMPANIES}}. <!-- e.g. "the 10–20 companies you most want a warm path into" -->
+
+## Step 2 — Search the network
+
+Run **multiple** `search_people` calls covering every §B archetype at the target companies, across **every** network listed in SCOPE §A:
+
+- "{{SCHOOL_1}} {{ARCHETYPE_1}} {company}" / "{{SCHOOL_1}} {{ARCHETYPE_2}} {company}" / ...
+- "{{SCHOOL_2}} {{ARCHETYPE_1}} {company}" / "{{SCHOOL_2}} {{ARCHETYPE_2}} {company}" / ...
+
+Collect up to {{MAX_PROFILES}} unique candidate profiles. <!-- 40 is the dogfooded ceiling. --> Prioritize people whose work touches the SIGNATURE archetype — that is the candidate's edge.
+
+## Step 3 — Capture gate evidence (per profile)
+
+Call `get_person_profile` and record exactly what the gates need:
+
+- Full name, current title, company, location, tenure.
+- **Education section verbatim** — degree(s), school(s), class/grad years. *This is the G1 evidence; an academic title in the Experience section is NOT attendance.*
+- Whether the current role is present-tense FTE vs "former" / an internship (G2 evidence).
+- IC vs manager vs recruiter vs senior leader (G3 evidence); team/department if listed (G4 evidence).
+- Recent activity (F5 evidence); any mutual connection and whether it is **verified in the mutual-connections panel** (the multiplier M).
+
+## Step 4 — Gate, then score (SCOPE §F model — max = 100)
+
+**Numerators can never exceed 100. Show every line item. Never reuse a remembered score.**
+
+**GATES first — ANY fail ⇒ print `DQ: <reason with the firing string>`, no number, no rank:**
+- **G1** verified network membership (a degree in Education at a §A school; faculty / lecturer / advisor / student-researcher-in-Experience = DQ).
+- **G2** current FTE at the target company (former / ex / past-intern = DQ, label "intel only").
+- **G3** referral-capable IC or early manager (recruiter/sourcer, current student, or Director/VP/Head/C-suite = DQ).
+- **G4** team plausibly hires a §B archetype (unrelated function, or a specialty the scope excludes, = DQ).
+
+**Then BASE factors — exactly ONE tier per factor (never additive within a factor):**
+F1 referral power (max 30) · F2 team-hires-the-candidate (max 28) · F3 shared-context depth (max 18) · F4 groundable personalization (max 14) · F5 reachability (max 10).
+
+`BASE = min(100, F1+F2+F3+F4+F5)` (max attainable = 30+28+18+14+10 = 100).
+**Mutual = MULTIPLIER M** (1.30 broker who agreed · 1.15 verified mutual · 1.00 default), never an additive bonus.
+**`FINAL = min(100, round(BASE × M))`** — print **both** BASE and FINAL; require BASE ≥ 60 before M lifts anyone into TOP (≥ 80).
+
+Rank the qualified contacts by FINAL. **If fewer than {{TOP_N}} pass the gates, output fewer — never pad.** If > 40% share one total, you mis-scored — re-score.
+
+## Step 5 — Draft personalized outreach (never send)
+
+For each qualified contact, draft a connection note (≤ 300 characters) for the candidate to review and send manually:
+
+- Classify the contact's archetype, then **lead with that archetype's lead-with proof point** from SCOPE §D — verbatim claims only, nothing outside the proof bank.
+- Reference their **specific** title/team + one concrete detail (recent post, named product area); ask one sharp question about their team's actual work.
+- Match the shared school to where they **actually earned a degree**.
+- Stay inside the §E claim boundaries; never imply a level or specialty the scope forbids.
+- **Swap-invariance test:** if the message still works with another name swapped in, it is not personalized enough — rewrite it. Banned openers: "I came across your profile", "I hope this finds you well", leading with your degree program.
+
+**Right shape (grounded, breaks under a name swap):**
+> "Hey Priya — saw your team owns experimentation for {{PRODUCT}}. I just shipped {{PROOF_POINT_1_SHORT}} and am curious how you balance metric sensitivity vs guardrails at {{COMPANY}}'s scale. {{SCHOOL_1}} grad here — 20 mins to compare notes?"
+
+**Wrong shape (generic, swap-invariant — regenerate):**
+> "Hi [Name], I came across your profile and was impressed by your experience at [Company]. I'm a student interested in data science and would love to connect."
+
+## Step 6 — Write the digest
+
+Write one ranked digest to **`.lifeos/schedule/out/job-search-scout-<YYYY-MM-DD>.md`**. It opens with:
+
+> _Drafts only — nothing has been sent. Review and send manually._
+
+**Per-contact block:**
+
+```
+#[rank] — [Name] | FINAL: [X]/100  (BASE [Y] × M [1.00/1.15/1.30])
+[Title] at [Company] | [Location] | Archetype their team hires: [archetype]
+Network (degree): [school + degree + years]   [Verified mutual: [name]] (only if verified)
+Profile: [URL]
+
+Gates: G1 ✓ (degree in Education) | G2 ✓ (current FTE) | G3 ✓ ([level]) | G4 ✓ ([team hires archetype])
+Score: F1 [n] + F2 [n] + F3 [n] + F4 [n] + F5 [n] = BASE [Y]; FINAL = min(100, round([Y]×[M])) = [X]
+
+── DRAFT OUTREACH (for you to send manually) ──
+[the ≤300-char message]
+```
+
+Close the digest with: `[N] qualified bridges from [P] profiles reviewed; [R] disqualified (gates, reasons listed above).` Do **not** include any line implying messages were sent — they were not.
+
+If a `gmail` MCP is wired, you may additionally **draft** (never send) an email carrying the digest body.
+
+## Step 7 — No auto-send. No exceptions.
+
+Do **not** call `connect_with_person`, `send_message`, or any outreach tool. This pipeline compiles, ranks, and drafts; the candidate reviews the digest each morning and sends manually. This is a LifeOS trust default ([docs/TRUST.md](../../../../docs/TRUST.md)), not a suggestion.

package/templates/prompts/weekly_digest.md

@@ -0,0 +1,47 @@
+# Cross-quadrant digest
+
+You are running as a scheduled LifeOS agent inside the user's repo. Your job is
+to produce a short digest the user reads on their own time — not to take action
+on their behalf.
+
+## Ground rules (trust defaults — non-negotiable)
+
+- **Draft-only.** Never send email, messages, or anything else. If outreach
+  would help, write the draft into the digest for the user to review and send
+  themselves.
+- **Local-only.** Read and write files inside this repo only. No uploads.
+- **Secrets stay secret.** Refer to env vars by name only, never by value.
+
+## Steps
+
+1. Run `npx @sbains2/lifeos context` to load the current config context (foci,
+   quadrants, council, priorities). If that command is unavailable, read
+   `lifeos.config.json` directly.
+2. Read each **active** quadrant folder (paths come from the config). Look for
+   what changed recently: new files, updated notes, checked-off items.
+3. If `.lifeos/brain/` exists, read its graph report for cross-quadrant
+   connections you'd otherwise miss.
+4. Write the digest to `.lifeos/schedule/out/` and also print it to stdout —
+   the scheduler captures stdout into `<schedule-name>-latest.md`.
+
+## Digest format
+
+Write in the second person, addressed to the user by their config name (sample
+data style: "Alex Rivera"). Sections, in order:
+
+- **What moved** — per active quadrant, concrete progress since the last
+  digest. Hot and warm quadrants first.
+- **What's stalled** — items with no recent movement, and your best one-line
+  guess why.
+- **Top 3 decisions needed** — the highest-leverage calls the user should make
+  this week, each with a one-sentence recommendation.
+- **Drafted next actions per hot focus** — for each focus with
+  `priority: hot`, 2-3 concrete next actions written as drafts for the user to
+  approve, edit, or discard. If an action involves contacting someone, include
+  the draft text itself — never send it.
+
+Keep the whole digest under one screen. Ruthlessly cut anything the user
+already knows.
+
+---
+Schedule it: `lifeos schedule add digest --prompt templates/prompts/weekly_digest.md --every 1d`