@sbains2/lifeos 0.2.2 → 0.3.1

package/src/context.js

@@ -0,0 +1,203 @@
+/**
+ * `lifeos context` — the get_user_context consumer that makes the priority
+ * enum real at convening time (see docs/SCHEMA.md, "How priority is consumed
+ * at runtime").
+ *
+ * Reads lifeos.config.json and produces a compact "convening context" block:
+ * foci / quadrants / council ranked hot → warm → lukewarm → cold, plus the
+ * user profile line and reference paths (writing_style, brain graph). Council
+ * and agent runtimes paste or pipe this at convening start so the council
+ * weights hot items first.
+ *
+ * Pure planning + rendering only — no writes, no network, no env reads
+ * (trust defaults per docs/TRUST.md). Side effects live in
+ * src/commands/context.js.
+ */
+
+import { existsSync, readFileSync } from 'node:fs';
+import { join, isAbsolute } from 'node:path';
+import { loadPersonaTemplate } from './templates-loader.js';
+
+export const PURPOSE = 'Paste or pipe this into a convening so the council weights hot items first.';
+
+// Rank order matches the schema enum. Unknown priorities sink to the bottom
+// rather than throwing — validate.js/doctor own schema enforcement, not us.
+const PRIORITY_RANK = { hot: 0, warm: 1, lukewarm: 2, cold: 3 };
+
+function byPriority(a, b) {
+  return (PRIORITY_RANK[a.priority] ?? 99) - (PRIORITY_RANK[b.priority] ?? 99);
+}
+
+/**
+ * Build the structured convening context for a scaffold.
+ * Returns { ok: true, ...data } or { ok: false, error, fix } — never throws.
+ * options.quadrant scopes output to one quadrant (its council subset + foci).
+ */
+export function planContext(targetDir, options = {}) {
+  const { quadrant = null } = options;
+
+  const configPath = join(targetDir, 'lifeos.config.json');
+  if (!existsSync(configPath)) {
+    return {
+      ok: false,
+      error: `lifeos.config.json not found at ${configPath}`,
+      fix: `Run \`npx @sbains2/lifeos ${targetDir}\` to scaffold a fresh config, or \`npx @sbains2/lifeos doctor ${targetDir}\` to diagnose.`,
+    };
+  }
+  let config;
+  try {
+    config = JSON.parse(readFileSync(configPath, 'utf8'));
+  } catch (err) {
+    return {
+      ok: false,
+      error: `lifeos.config.json parse failed: ${err.message}`,
+      fix: `Open ${configPath} in an editor and fix the JSON syntax, then re-check with \`npx @sbains2/lifeos doctor ${targetDir}\`.`,
+    };
+  }
+
+  // Persona-template voices are the fallback role summaries for council
+  // members whose config entry lacks a `voice`. Lazy + fault-tolerant:
+  // custom/unbundled personas have no template file, and that's fine.
+  let personaVoices = null;
+  const summaryFor = (member) => {
+    if (member.voice) return member.voice;
+    if (personaVoices === null) {
+      try {
+        const template = loadPersonaTemplate(config.user?.persona);
+        personaVoices = new Map((template.council ?? []).map((c) => [c.id, c.voice]));
+      } catch {
+        personaVoices = new Map();
+      }
+    }
+    return personaVoices.get(member.id) ?? member.id;
+  };
+
+  const allQuadrants = config.quadrants ?? [];
+  let scopedQuadrant = null;
+  if (quadrant) {
+    scopedQuadrant = allQuadrants.find((q) => q.id === quadrant) ?? null;
+    if (!scopedQuadrant) {
+      return {
+        ok: false,
+        error: `quadrant '${quadrant}' not found in lifeos.config.json. Available: ${
+          allQuadrants.map((q) => q.id).join(', ') || '(none)'
+        }`,
+        fix: 'Pass one of the ids above to --quadrant, or omit the flag for the full context.',
+      };
+    }
+  }
+
+  const quadrants = (scopedQuadrant ? [scopedQuadrant] : allQuadrants.filter((q) => q.active))
+    .slice()
+    .sort(byPriority)
+    .map((q) => ({
+      id: q.id,
+      name: q.name,
+      description: q.description ?? null,
+      path: q.path,
+      active: q.active,
+      priority: q.priority,
+    }));
+
+  const councilPool = scopedQuadrant
+    ? (config.council ?? []).filter((m) => (scopedQuadrant.council_member_ids ?? []).includes(m.id))
+    : (config.council ?? []);
+  const council = councilPool
+    .slice()
+    .sort(byPriority)
+    .map((m) => ({ id: m.id, name: m.name, priority: m.priority, summary: summaryFor(m) }));
+
+  // Foci are global — a quadrant scope narrows the council, not the user's
+  // direction (see docs/SCHEMA.md: foci set the *direction*).
+  const foci = (config.user?.context?.foci ?? [])
+    .slice()
+    .sort(byPriority)
+    .map((f) => ({ id: f.id, horizon: f.horizon, description: f.description, priority: f.priority }));
+
+  const brainRel = config.brain?.graphify?.output ?? './.lifeos/brain';
+  const brainAbs = isAbsolute(brainRel) ? brainRel : join(targetDir, brainRel);
+
+  return {
+    ok: true,
+    purpose: PURPOSE,
+    scope: { quadrant: scopedQuadrant?.id ?? null },
+    user: {
+      name: config.user?.name ?? null,
+      persona: config.user?.persona ?? null,
+      role: config.user?.context?.role ?? null,
+      affiliations: config.user?.context?.affiliations ?? [],
+    },
+    foci,
+    quadrants,
+    council,
+    writingStylePath: config.writing_style_path ?? null,
+    brainPath: existsSync(brainAbs) ? brainRel : null,
+  };
+}
+
+/**
+ * Render a plan (from planContext) as the markdown convening block.
+ * Plain markdown, no ANSI — it's meant to be piped into a convening.
+ */
+export function renderContextMarkdown(plan) {
+  const lines = [];
+  lines.push('# LifeOS convening context');
+  lines.push('');
+  lines.push(`> ${plan.purpose}`);
+  lines.push('');
+  lines.push(`**User:** ${formatUserLine(plan.user)}`);
+  if (plan.scope.quadrant) {
+    lines.push(`**Scope:** quadrant \`${plan.scope.quadrant}\` only`);
+  }
+
+  lines.push('');
+  lines.push('## Foci (hot → cold)');
+  if (plan.foci.length === 0) {
+    lines.push('_none configured_');
+  }
+  plan.foci.forEach((f, i) => {
+    lines.push(`${i + 1}. [${f.priority} · ${f.horizon}] ${f.description} (\`${f.id}\`)`);
+  });
+
+  lines.push('');
+  lines.push(plan.scope.quadrant ? '## Quadrant' : '## Active quadrants (by priority)');
+  if (plan.quadrants.length === 0) {
+    lines.push('_none active_');
+  }
+  plan.quadrants.forEach((q, i) => {
+    lines.push(`${i + 1}. [${q.priority}] ${q.name} (\`${q.id}\`)${q.description ? ` — ${q.description}` : ''}`);
+  });
+
+  lines.push('');
+  lines.push('## Council (by priority)');
+  if (plan.council.length === 0) {
+    lines.push('_none configured_');
+  }
+  plan.council.forEach((m, i) => {
+    lines.push(`${i + 1}. [${m.priority}] ${m.name} (\`${m.id}\`) — ${m.summary}`);
+  });
+  if (plan.council.some((m) => m.priority === 'cold')) {
+    lines.push('');
+    lines.push('_cold council members are excluded from convenings by default (functionally disabled)._');
+  }
+
+  const refs = [];
+  if (plan.writingStylePath) refs.push(`- writing_style: ${plan.writingStylePath}`);
+  if (plan.brainPath) refs.push(`- brain graph: ${plan.brainPath}`);
+  if (refs.length > 0) {
+    lines.push('');
+    lines.push('## Reference paths');
+    lines.push(...refs);
+  }
+
+  lines.push('');
+  return lines.join('\n');
+}
+
+function formatUserLine(user) {
+  const parts = [user.name || '(unnamed)'];
+  if (user.persona) parts.push(`persona: ${user.persona}`);
+  if (user.role) parts.push(user.role);
+  if (user.affiliations.length > 0) parts.push(user.affiliations.join(', '));
+  return parts.join(' · ');
+}

package/src/doctor.js

@@ -201,7 +201,7 @@ export function runDoctor(targetDir) {
         .join('; '),
       fix: `Set the missing env vars in your shell rc (~/.zshrc or ~/.bashrc), e.g.:\n     ${missingEnv
         .map((m) => `export ${m.env_var}=...`)
-        .join('\n     ')}\n   Then reload your shell + restart Claude.`,
+        .join('\n     ')}\n   Then reload your shell, and reopen the project in your IDE (or restart Claude Desktop if you use it).`,
     });
   }
 

package/src/index.js

@@ -26,7 +26,7 @@ export async function run(targetDir, options = {}) {
   const { minimal = false } = options;
 
   console.log('');
-  console.log(c.bold('lifeos') + c.dim(' v0.2.2 — scaffold a personal LifeOS'));
+  console.log(c.bold('lifeos') + c.dim(' v0.2.3 — scaffold a personal LifeOS'));
   console.log(c.dim(`Target directory: ${targetDir}`));
   if (minimal) {
     console.log(c.dim('Mode: --minimal (speed-optimized; using template defaults for quadrants, council, MCPs)'));
@@ -248,10 +248,10 @@ export async function run(targetDir, options = {}) {
   if (groups.needs_env.length > 0) {
     console.log(`  ${c.arrow} Set the env vars listed above (in your shell rc — ~/.zshrc or ~/.bashrc), then reload your shell`);
   }
-  if (desktopMergeResult || groups.ready.length > 0 || groups.needs_oauth.length > 0) {
-    console.log(`  ${c.arrow} Restart Claude Desktop (Cmd+Q, then reopen) so the new MCPs load`);
+  console.log(`  ${c.arrow} Open ${targetDir} in your IDE (Claude Code / Cursor) — it reads the generated .mcp.json — and try convening the council on a real artifact`);
+  if (desktopMergeResult) {
+    console.log(`  ${c.arrow} Using the Claude Desktop app instead? Restart it (Cmd+Q, then reopen) so the merged MCPs load`);
   }
-  console.log(`  ${c.arrow} Open ${targetDir} in Claude Code and try convening the council on a real artifact`);
   console.log(`  ${c.arrow} Edit lifeos.config.json to tune council priorities, add quadrants, or change foci`);
   if (groups.manual.length > 0 || groups.risk.length > 0) {
     console.log(`  ${c.arrow} For manual / risky MCPs: see .lifeos/INSTALL_MCPS.md for the full hint per server`);

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

@@ -0,0 +1,82 @@
+# Job-search pack — v0.2
+
+This pack is a generalized version of a job-search loop that has been dogfooded end-to-end by a real early-career candidate. The personal data has been stripped out; the *structure* — which is what actually made it precise — is preserved as fill-in templates. You supply your own facts.
+
+The loop exists to kill four failure modes observed in agent-run job searches:
+
+1. **Score incoherence** — an agent printing a score above its own stated maximum.
+2. **Fake network matches** — e.g. a professor counted as an "alum" because the school's name appeared somewhere on their profile.
+3. **Prestige-only score collapse** — every contact landing on the same number because the model scored fame instead of usefulness-to-you.
+4. **Generic personalization** — outreach that would read the same with anyone else's name swapped in.
+
+Every template below carries a structural fix for each of these. Don't remove the fixes when you fill in your data — they are the pack.
+
+## The loop
+
+```
+SCOPE.md ──────────────── who you are; single source of truth; every agent reads it FIRST
+   │
+   ├─► APPLY track          gate roles hard, THEN score fit /5 ──► ranked apply queue (YOU apply)
+   │        │
+   │        │  fit ≥ threshold
+   │        ▼
+   ├─► bridge                high-scoring APPLY companies feed the referral queue (bridge.md)
+   │        │
+   │        ▼
+   └─► RELATIONSHIP track   gate contacts G1–G4, THEN score bridge value /100 ──► outreach DRAFTS (YOU send)
+            ▲
+            │  runs on a schedule (lifeos schedule); digest lands in .lifeos/schedule/out/
+            │
+      you review the digest each morning
+```
+
+Two tracks, two rubrics, two maxima — never crossed:
+
+| Track | Question it answers | Score | Gate first |
+|---|---|---|---|
+| **APPLY** | Which postings should I apply to *this week*? | fit **/5** (+ a separate velocity /15 for urgency) | Level lane, hard disqualifiers |
+| **RELATIONSHIP** | Which people can give me a *warm referral*? | bridge value **/100** | G1–G4 (real network member, current employee, referral-capable, relevant team) |
+
+The bridge is the one arrow between them: when an APPLY-track evaluation scores at or above your threshold, that company is appended to the relationship-track queue, and the next scheduled scout hunts for warm contacts there. See [bridge.md](bridge.md).
+
+## Trust defaults (non-negotiable, same as the rest of LifeOS)
+
+- **Drafts only. You send.** The scout compiles, ranks, and *drafts* outreach. It never sends a message or connection request, and nothing auto-applies to any job. The digest exists so a human reviews before anything leaves the machine.
+- **Local-first.** The scope file, queues, evaluations, and digests are all local files in your scaffold. Nothing is uploaded.
+- **Env vars by name only.** MCP auth follows the schema rule — token names in config, values in your shell.
+
+Full commitments: [docs/TRUST.md](../../../../docs/TRUST.md). If anything in this pack violates them, file an issue — that's a bug, not a feature.
+
+## What's in the pack
+
+```
+packs/job-search/
+  README.md                  # this file
+  SCOPE.template.md          # the candidate-scope contract — copy, fill in ~20 minutes
+  council_playbook.md        # the two-track council spec (gates, rubrics, personalization rules)
+  scout_prompt.template.md   # the scheduled scout prompt — fill placeholders, then schedule it
+  bridge.md                  # the APPLY → RELATIONSHIP bridge pattern + a copy-pasteable watcher sketch
+```
+
+## Quickstart (5 steps)
+
+1. **Copy the templates** into your Job Search quadrant:
+   ```bash
+   cp SCOPE.template.md        <your-lifeos>/JobSearch/SCOPE.md
+   cp council_playbook.md      <your-lifeos>/JobSearch/council_playbook.md
+   cp scout_prompt.template.md <your-lifeos>/JobSearch/scout_prompt.md
+   ```
+2. **Fill `SCOPE.md`** (~20 minutes). Every `{{PLACEHOLDER}}` has an inline guidance comment. Be honest in the proof bank and ruthless in the never-say list — the whole loop inherits its precision from this one file.
+3. **Wire the MCPs** the scout needs from the registry ([templates/mcps/registry.json](../../mcps/registry.json)): `linkedin` (read its `risk_advisory` first), `fetch` for web lookups, and optionally `gmail` for digest delivery — which ships draft-only (`send_permission: false`) and stays that way unless you explicitly change it.
+4. **Schedule the scout.** Register `scout_prompt.md` as a recurring task with `lifeos schedule` (or any cron-style scheduled task your agent runtime provides, pointed at the same prompt). Daily is the dogfooded cadence. Digests are written to `.lifeos/schedule/out/`.
+5. **Review the digest each morning.** Apply to the queue yourself; send the drafts you like, rewrite the ones you don't. Run the bridge watcher (see [bridge.md](bridge.md)) so high-fit APPLY companies flow into the next scout run.
+
+## Why gate-then-score
+
+A keyword match is *necessary, not sufficient*. Scoring before gating is how agents end up polishing blurbs for roles that should have been cut — so both tracks gate first (hard disqualifiers with the exact firing string named), and only survivors get a score. Every score is a re-derivable sum with the arithmetic shown, clamped to its stated max. A numerator above its denominator is a bug, not an opinion: recompute.
+
+## What's NOT here yet
+
+- A declarative bridge config (`bridges[]` in `lifeos.config.json`) — the watcher in bridge.md is the manual version; see that file for the forward spec.
+- An ATS/portal scanner. The APPLY track assumes you find postings via the council playbook's search step (LinkedIn MCP + web fetch); a dedicated scanner integration is a future pack revision.
+- Automated application submission. Deliberately absent — that's a trust default, not a missing feature.

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

@@ -0,0 +1,156 @@
+# CANDIDATE SCOPE — {{CANDIDATE_NAME}} (canonical targeting spec)
+
+> **This file is the single source of truth for *who you are* and *what counts as a tailored opportunity*.**
+> Every job-search agent — the scout, the council, any workflow — **MUST read this file first**
+> before searching, scoring, or drafting anything. If an agent cannot load it, it must STOP,
+> not proceed from memory.
+>
+> **Posture: ruthless precision.** A keyword match is *necessary, not sufficient*. Read the
+> responsibilities, not the title. Name the exact string that fires every gate. Default to
+> **skeptical**: when a fit signal is ambiguous, downgrade and flag — do not pad the score.
+
+<!-- Fill time budget: ~20 minutes. Every {{PLACEHOLDER}} has a guidance comment next to it.
+     Sample values throughout use a fictional candidate ("Alex Rivera", an MSc Business
+     Analytics candidate) — replace all of them. Delete these comments as you fill. -->
+
+---
+
+## How agents must use this file (Step 0 contract)
+
+1. **Read this file in full** before any search, scoring, or message drafting.
+2. Apply the **two-track split** — every output belongs to exactly one track:
+   - **APPLY track** = *jobs to apply to now*. Optimize for ruthless fit + right level + target geo + freshness.
+   - **RELATIONSHIP track** = *contacts for warm referrals*. Optimize for **bridge value to the candidate**, not the contact's prestige.
+3. Never invent a fact, metric, or claim beyond the **§D Proof Bank**. Honor every **§E Claim Boundary**.
+4. Every score must be a **re-derivable sum** with each line item shown, **clamped to its stated max** (§F). A printed numerator that exceeds its denominator is a hard bug — recompute.
+5. Distinguish **HARD KILL** (auto-reject, no scoring) from **SOFT FLAG** (downgrade, still scored). Always name the firing string and label it KILL vs FLAG. A borderline good-fit role is never *silently* auto-rejected.
+
+---
+
+## §A — Identity & non-negotiables
+
+<!-- One line each. These are gates, not preferences — an agent treats every item here as binding. -->
+
+- **Candidate:** {{CANDIDATE_NAME}}. Based in {{BASE_LOCATION}}. <!-- e.g. "Alex Rivera. Based in Chicago, IL / CST." -->
+- **Work authorization:** {{WORK_AUTH}} <!-- e.g. "US work-authorized; no visa sponsorship needed." State it exactly as a recruiter would need to know it. -->
+- **Networks valid for referrals:** <!-- List every school (or program/community) where you hold real member status. The relationship track gates on verifiable membership — a degree shown in the Education section, not a mention anywhere on a profile. -->
+  - **{{SCHOOL_1}}** — {{DEGREE_1}}, {{GRAD_YEAR_1}}. <!-- e.g. "Lakeside University — MSc Business Analytics, 2026." -->
+  - **{{SCHOOL_2}}** — {{DEGREE_2}}, {{GRAD_YEAR_2}}. <!-- Optional. Delete if you have one network. Add more if you have them. -->
+- **Level:** {{LEVEL_BAND}}. <!-- e.g. "early-career / new-grad / 0–3 yrs / Associate / Analyst I–II." Then state what you are NOT: "NOT senior IC, staff, principal, manager, director, VP, or head-of." The NOT list is what the gates fire on. -->
+- **Comp:** target {{COMP_TARGET}}, **floor {{COMP_FLOOR}} base**. <!-- e.g. "target $95–115K, floor $85K USD base." The floor is a structural wall only against a posted band whose MAXIMUM is clearly below it — a straddling band passes. -->
+- **Geo:** {{METRO_1}}, {{METRO_2}}, {{METRO_3}}, Remote-{{COUNTRY}}. <!-- Gate on WORK ARRANGEMENT, not the HQ field — a non-target HQ that is remote/hybrid-eligible is in scope. Hard kill only: wrong country, wrong work auth, or mandatory on-site 4–5 days/week in a non-target metro with no remote/relocation. -->
+
+---
+
+## §A2 — Level lane: cold-apply vs warm-referral vs kill (the decisive APPLY filter)
+
+**The biggest predictor of an early-career application converting is the req's *level*, not the content match.** Read the **Minimum Qualifications / years-of-experience line FIRST**, before scoring anything, and route the posting into a lane:
+
+- **COLD-APPLY lane (score & apply normally):** the posting is explicitly {{EARLY_CAREER_TAGS}} <!-- e.g. "new-grad / university grad / early-career program / Associate / Analyst I–II" -->, **OR** its *required* minimum is **≤ {{COLD_APPLY_MAX_YOE}} years** (or unstated).
+- **WARM-REFERRAL lane (route to the RELATIONSHIP track — do NOT cold-apply):** the req requires **{{REFERRAL_LANE_YOE}}+ years** and carries no early-career framing. Content fit may still be high, but a cold app is ~noise against experienced-hire competition; the realistic path in is a warm referral. This is *especially* true at high-applicant-volume brands.
+- **KILL:** required **≥ {{KILL_YOE}} years**, or a Senior/Staff/Principal/Manager+ title (§C).
+
+**Variant hunt (do this BEFORE discarding or referral-routing a desirable role):** if a company you fit on substance is running an *experienced* req, search that same company for an early-career variant of the role and target *that* instead. Large companies often run dedicated early-career pipelines that are genuinely reachable; the experienced req for the same work is not.
+
+**This is track-routing, NOT a fit-score gate.** No company-tier or company-size gate exists in the fit score, and none may be added — in either direction. An in-archetype role at a 12-person startup and one at a famous lab are both cold-apply targets; an experienced role at either defaults to the referral lane. (This is the structural fix for prestige-only scoring.)
+
+---
+
+## §B — Target role archetypes (3–6; read responsibilities, not just the title)
+
+<!-- 3–6 rows. Tier one of them SIGNATURE — the rare intersection that is distinctly yours; agents
+     treat it as a tie-breaker UP. "Substance signals" = strings an agent can actually find in a JD.
+     Sample row (delete): | 1 | Product Data Scientist | PRIMARY | experimentation / A-B testing,
+     product metrics, behavioral segmentation; Python + SQL; deliverable = a decision or metric | -->
+
+| # | Archetype | Tier | True-positive substance signals |
+|---|-----------|------|---------------------------------|
+| 1 | {{ARCHETYPE_1}} | PRIMARY | {{ARCHETYPE_1_SIGNALS}} |
+| 2 | {{ARCHETYPE_2}} | PRIMARY | {{ARCHETYPE_2_SIGNALS}} |
+| 3 | {{ARCHETYPE_3}} | PRIMARY | {{ARCHETYPE_3_SIGNALS}} |
+| 4 | {{ARCHETYPE_4}} | **SIGNATURE** | {{ARCHETYPE_4_SIGNALS}} |
+| 5 | {{ARCHETYPE_5}} | ADJACENT | {{ARCHETYPE_5_SIGNALS}} |
+
+**Off-list titles that PASS on substance (read harder — never auto-reject):** {{ADJACENT_TITLES}} <!-- e.g. "Decision Scientist, Insights Analyst, Quantitative UX Researcher" — titles that don't match your list but often ARE your work. -->
+
+---
+
+## §C — Hard job disqualifiers (APPLY track)
+
+Run these **after** a title/keyword match — they **override** it. Each entry names the JD-detectable string. Label each firing as **KILL** (auto-reject) or **FLAG** (downgrade, keep scoring). *The years number is load-bearing; the title adjective is secondary.*
+
+<!-- Keep the categories; edit the specifics. Each line should name strings an agent can grep a JD for. -->
+
+1. **Seniority token in title — KILL:** {{SENIORITY_KILL_TOKENS}}. <!-- e.g. "Senior / Sr. / Staff / Principal / Manager / Director / Head of / VP / Chief". Add a caveat for any borderline title you'd still consider (FLAG, not KILL). -->
+2. **People-management — KILL:** "manage a team of N", "direct reports", "hire and grow the team".
+3. **Hard experience floor — KILL at ≥ {{KILL_YOE}} yrs *required*.** Distinguish **required/minimum** from **preferred/bonus**: a big number in a *preferred* bullet does not fire; route the middle band per §A2. **Never reject for an unstated minimum.**
+4. **Wrong specialty — KILL:** {{WRONG_SPECIALTY_KILLS}}. <!-- The roles that pattern-match your keywords but are a different job. e.g. for a product-analytics candidate: "foundation-model research, low-level ML systems, production distributed-systems/backend/platform SWE". -->
+5. **Credential wall — KILL only when hard-required:** {{CREDENTIAL_KILLS}}. <!-- e.g. "PhD hard-required; regulated credentials (actuarial exams, clinical biostatistics, licensure)". A standalone "advanced degree preferred" is a FLAG, not a KILL, if your degree satisfies it. -->
+6. **Security clearance — KILL** if the posting requires one you don't hold.
+7. **Geo — KILL:** wrong country / wrong work auth / mandatory full on-site in a non-target metro with no remote or relocation. Ambiguous remote policy = **FLAG**.
+8. **Comp — KILL** only when the posted band **maximum** is clearly below {{COMP_FLOOR}} base, full-time. A straddling band passes. A borderline band on a high-fit role is a surfaced **FLAG**, not a silent kill.
+9. **Wrong function wearing your keywords — KILL:** {{WRONG_FUNCTION_TRAPS}}. <!-- e.g. "pre-sales 'data scientist', reporting-clerk 'analyst', functional-consultant 'business analyst'". Name the tells. -->
+10. **Employment type — KILL (default):** {{EMPLOYMENT_TYPE_KILLS}}. <!-- e.g. "contract / 1099 / staffing / commission-only / unpaid; internships if you're graduating into full-time". -->
+
+**No company-tier or company-size gate exists, and none may be added — in either direction.**
+
+---
+
+## §D — Proof Bank (cite verbatim; never invent)
+
+**Exact figures — never round or invent:** {{EXACT_FIGURES_LIST}}. *If a number is not on this list, the agent does not have it.*
+<!-- List every number an agent may ever cite about you, e.g.: "2.1M users · 5-segment taxonomy · 0.81 out-of-sample AUC · $2.3M renewals isolated · 40% triage-time reduction". This one line kills invented metrics. -->
+
+<!-- 3–7 rows. Each claim must be checkable against real evidence (a deck, a repo, a report).
+     The Boundary column is as load-bearing as the claim — it is what stops an agent overselling you.
+     Sample row (delete): | P1 — {{INTERNSHIP_1}} | Built the first behavioral segmentation of a
+     2.1M-user base; 5-segment taxonomy; top segment converts 2–4× on paid plans | Product DS,
+     Analytics outreach | Applied ML on product data — intern scope, NOT senior ownership | -->
+
+| ID | Claim (with metrics, verbatim) | Where it may be used | Boundary |
+|----|--------------------------------|----------------------|----------|
+| **P1 — {{PROOF_POINT_1_TITLE}}** | {{PROOF_POINT_1}} | {{PROOF_POINT_1_USE}} | {{PROOF_POINT_1_BOUNDARY}} |
+| **P2 — {{PROOF_POINT_2_TITLE}}** | {{PROOF_POINT_2}} | {{PROOF_POINT_2_USE}} | {{PROOF_POINT_2_BOUNDARY}} |
+| **P3 — {{PROOF_POINT_3_TITLE}}** | {{PROOF_POINT_3}} | {{PROOF_POINT_3_USE}} | {{PROOF_POINT_3_BOUNDARY}} |
+| **P4 — {{PROOF_POINT_4_TITLE}}** | {{PROOF_POINT_4}} | {{PROOF_POINT_4_USE}} | {{PROOF_POINT_4_BOUNDARY}} |
+
+**Per-archetype "lead-with":** <!-- For each §B archetype, name the ONE proof point outreach and applications lead with. If no lead-with proof point maps cleanly to a JD, the role is NOT tailored. -->
+
+| Archetype | LEAD with |
+|-----------|-----------|
+| {{ARCHETYPE_1}} | {{ARCHETYPE_1_LEAD}} |
+| {{ARCHETYPE_2}} | {{ARCHETYPE_2_LEAD}} |
+| {{ARCHETYPE_3}} | {{ARCHETYPE_3_LEAD}} |
+| {{ARCHETYPE_4}} | {{ARCHETYPE_4_LEAD}} |
+| {{ARCHETYPE_5}} | {{ARCHETYPE_5_LEAD}} |
+
+---
+
+## §E — Claim boundaries / never-say list
+
+<!-- The inverse of the proof bank: framings that are technically adjacent to your experience but
+     false or oversold. Agents may NEVER use these. Common shapes: (a) a brand-name employer implying
+     a different specialty than the work you did there; (b) in-progress work described as finished;
+     (c) "isolated/identified $X" inflated to "drove/generated $X"; (d) your level inflated. -->
+
+**Never** sell the candidate as / imply:
+
+- {{NEVER_SAY_1}} <!-- e.g. "a backend/platform/infra engineer — the work was product analytics" -->
+- {{NEVER_SAY_2}} <!-- e.g. "the manuscript is published — it is IN PREP" -->
+- {{NEVER_SAY_3}} <!-- e.g. "causal-credit verbs on the $2.3M ('drove/generated/saved') — it was ISOLATED for targeting" -->
+- {{NEVER_SAY_4}} <!-- e.g. "senior / 5+ years / people-management experience" -->
+- {{NEVER_SAY_5}} <!-- e.g. "project metrics framed as business outcomes" -->
+
+---
+
+## §F — Scoring maxima per track
+
+**Denominators never cross tracks.** A job is scored on the APPLY rubric; a person on the RELATIONSHIP rubric. Full protocols live in [council_playbook.md](council_playbook.md) — this section only fixes the maxima so no agent can drift them.
+
+| Track | Rubric | Max | Rule |
+|---|---|---|---|
+| APPLY | fit score | **/5** | gate first (§A2 lane + §C), then score by mapping the JD to the §D lead-with; arithmetic shown |
+| APPLY | velocity (freshness/urgency) | **/15** | a separate line — never folded into the /5 fit score |
+| RELATIONSHIP | bridge value | **/100** | gates G1–G4 first; one tier per factor; multiplier applied then clamped: `FINAL = min(100, round(BASE × M))` |
+
+Any printed score above its max is a hard bug. Recompute — never publish it.

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

@@ -0,0 +1,89 @@
+# The bridge — high-scoring APPLY hits feed the RELATIONSHIP queue
+
+The two tracks stay deliberately decoupled — a job is scored /5, a person /100, and neither rubric leaks into the other. The **bridge** is the one sanctioned arrow between them:
+
+```
+APPLY track                          bridge                       RELATIONSHIP track
+evaluations (one row per role) ──► fit ≥ threshold? ──► append company to referral_queue.txt
+                                                                   │
+                                                    next scheduled scout run reads the queue
+```
+
+**Why this works:** the postings where you score highest on *substance* are exactly the companies where a warm referral pays off most — whether you cold-applied (a referral multiplies a live application) or the role was routed to the warm-referral lane (a referral is the only realistic path in). So instead of maintaining a target-company list by hand, the APPLY track's own output feeds the RELATIONSHIP track automatically.
+
+## The concrete pattern
+
+1. Your APPLY-track evaluations land as tab-separated rows, one file per scan batch, in `.lifeos/job-search/evaluations/`:
+
+   ```
+   num<TAB>date<TAB>company<TAB>role<TAB>status<TAB>score/5<TAB>notes
+   ```
+
+2. A small watcher reads each new file, promotes every company whose fit score is **≥ threshold** (4.25/5 dogfooded — high enough that only genuinely tailored roles trigger a scout run) into `.lifeos/job-search/referral_queue.txt`, then archives the file to `processed/` so no row is ever double-queued.
+
+3. The next scheduled scout run ([scout_prompt.template.md](scout_prompt.template.md), Step 1) picks the queue up and hunts for warm contacts at those companies.
+
+The queue is a plain newline-delimited text file on purpose: you can inspect it, hand-edit it, or append a company yourself — the scout can't tell the difference.
+
+## Watcher sketch (copy-pasteable)
+
+Pure local file ops — no network, no dependencies beyond node builtins, in keeping with the trust defaults. Save as `bridge-watcher.mjs` and run it after each APPLY scan (or on the same schedule as the scout, just before it):
+
+```js
+#!/usr/bin/env node
+// bridge-watcher.mjs — promote high-fit APPLY evaluations into the relationship queue.
+import { readFileSync, appendFileSync, readdirSync, renameSync, mkdirSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+
+const EVAL_DIR = '.lifeos/job-search/evaluations';   // one .tsv per APPLY scan batch
+const PROCESSED_DIR = join(EVAL_DIR, 'processed');
+const QUEUE_FILE = '.lifeos/job-search/referral_queue.txt';
+const THRESHOLD = 4.25;                              // fit /5 that earns a referral hunt
+
+mkdirSync(PROCESSED_DIR, { recursive: true });
+// De-dupe against companies already queued (the scout clears the queue after each run).
+const queued = new Set(
+  existsSync(QUEUE_FILE) ? readFileSync(QUEUE_FILE, 'utf8').split('\n').filter(Boolean) : [],
+);
+
+for (const name of readdirSync(EVAL_DIR).filter((f) => f.endsWith('.tsv'))) {
+  const file = join(EVAL_DIR, name);
+  for (const row of readFileSync(file, 'utf8').split('\n').filter(Boolean)) {
+    // Row: num  date  company  role  status  score/5  notes
+    const cols = row.split('\t');
+    const company = (cols[2] ?? '').trim();
+    const score = Number.parseFloat((cols[5] ?? '').replace('/5', ''));
+    if (company && Number.isFinite(score) && score >= THRESHOLD && !queued.has(company)) {
+      appendFileSync(QUEUE_FILE, `${company}\n`);
+      queued.add(company);
+      console.log(`queued ${company} (fit ${score}/5)`);
+    }
+  }
+  renameSync(file, join(PROCESSED_DIR, name)); // archive so a row is never double-queued
+}
+```
+
+Run: `node bridge-watcher.mjs` from your scaffold root.
+
+## Rules the bridge must honor
+
+- **Never promote on raw score alone across a fired gate.** The watcher trusts that upstream evaluations were already gated (§C of your scope). If a row somehow carries a high score on a role that should have been killed, fix the evaluator — don't lower the threshold.
+- **The queue holds companies, not people and not roles.** Which *contacts* to pursue at each company is entirely the scout's job, gated G1–G4.
+- **Clearing the queue is the scout's last step, not its first** — only after the digest exists, so a failed run never silently drops companies.
+
+## Where this is going
+
+In a future schema version this whole file becomes declarative config instead of a hand-run script — something like:
+
+```jsonc
+// forward spec — NOT implemented; do not add to lifeos.config.json yet
+"bridges": [
+  {
+    "from": { "quadrant": "job_search", "artifact": "evaluations", "field": "fit", "gte": 4.25 },
+    "to": { "quadrant": "job_search", "queue": "referral_queue" },
+    "carry": ["company"]
+  }
+]
+```
+
+with a runtime executor watching the `from` artifact. Until then, the ~30-line watcher above is the whole mechanism — inspectable, local, and yours.