@oxygen-agent/cli 1.1003.12 → 1.1010.644

package/node_modules/@oxygen/shared/dist/column-autofill.js

@@ -1,22 +1,4 @@
-/**
- * "Did I type this, or did Oxygen?" — the single rule behind the bolt.
- *
- * A CRM record mixes two kinds of field in one list: the handful a founder
- * types (name, stage, owner, a phone they were given) and the majority Oxygen
- * fills from one paid LinkedIn scrape and the free extractors over its payload.
- * Reading a record without that distinction, every cell looks equally
- * authoritative — which is exactly backwards, because a scraped headline and a
- * hand-corrected job title deserve different trust.
- *
- * The grid already marks derived columns in its header (`ColumnDefinitionBadge`)
- * and the record page did not, so the same field read as enriched in one place
- * and hand-entered in the other. This is the shared answer both surfaces call.
- *
- * The rule is TOTAL over column kinds and deliberately coarse: a bolt means
- * "you did not type this", and the label says what did. Splitting hairs between
- * an AI column and a formula over an AI column's payload is an implementation
- * detail a customer has no reason to hold.
- */
+import { PROFESSIONAL_NETWORK_DATA_LABEL } from "./data-suppliers.js";
 function readString(definition, key) {
     const value = definition?.[key];
     return typeof value === "string" && value.trim() !== "" ? value : null;
@@ -34,11 +16,11 @@ function isExtractedFromPayload(column) {
 /** Name the provider lane when the column declares one, so the tooltip is specific. */
 function enrichmentLabel(column) {
     const toolId = readString(column.definition, "toolId") ?? readString(column.definition, "tool_id");
-    // Vendor names never reach a customer surface — the managed scraper is a
-    // deliberately vendor-neutral rail (`packages/providers/src/descriptors/scraper.ts`),
-    // and tests fail if the vendor behind it leaks. Speak in terms of the SOURCE.
+    // Name the source and its supplier (Philipp, 2026-09-25: suppliers are named;
+    // data-extraction labels say "Professional Network"). The label comes from
+    // one owner so it cannot drift from the picker and the Connections card.
     if (toolId?.startsWith("scraper.linkedin"))
-        return "Enriched from LinkedIn";
+        return `Enriched from ${PROFESSIONAL_NETWORK_DATA_LABEL}`;
     if (toolId)
         return "Enriched by a data provider";
     return "Enriched automatically";

package/node_modules/@oxygen/shared/dist/column-decision.d.ts

@@ -0,0 +1,50 @@
+export declare const COLUMN_DECISION_ENGINE = "system_one";
+export declare const COLUMN_DECISION_MODES: readonly ["labels", "yes_no", "score"];
+export type ColumnDecisionMode = (typeof COLUMN_DECISION_MODES)[number];
+export declare const COLUMN_DECISION_GROUNDINGS: readonly ["workspace", "none"];
+export type ColumnDecisionGrounding = (typeof COLUMN_DECISION_GROUNDINGS)[number];
+export declare const COLUMN_DECISION_MIN_LABELS = 2;
+export declare const COLUMN_DECISION_MAX_LABELS = 20;
+export declare const COLUMN_DECISION_MIN_LEVELS = 2;
+export declare const COLUMN_DECISION_MAX_LEVELS = 10;
+export declare const COLUMN_DECISION_MAX_OPTION_CHARS = 80;
+/** Floors the ADR shipped with: 0.85 for a choice or score, a 70/30 band for yes/no. */
+export declare const COLUMN_DECISION_DEFAULT_MIN_CONFIDENCE: Readonly<Record<ColumnDecisionMode, number>>;
+export declare const COLUMN_DECISION_DEFAULT_FIELD: Readonly<Record<ColumnDecisionMode, string>>;
+/** Keys the cell writes next to the answer field; a field may not reuse one. */
+export declare const COLUMN_DECISION_RESERVED_FIELDS: ReadonlySet<string>;
+export type ColumnDecisionDefinition = {
+    engine: typeof COLUMN_DECISION_ENGINE;
+    mode: ColumnDecisionMode;
+    /** The cell key the answer lands under. */
+    field: string;
+    /** `labels` mode: the options, in the customer's own words. */
+    labels?: string[];
+    /** `score` mode: ordered levels, lowest first. */
+    levels?: string[];
+    /** Below this the answer is kept as a best guess marked uncertain. */
+    minConfidence: number;
+    /** `workspace` sends the column's workspace knowledge slice in the state; `none` (the default) judges the row alone. */
+    grounding: ColumnDecisionGrounding;
+};
+/** A validation failure naming the field, for the normalizer to wrap in its own error type. */
+export declare class ColumnDecisionError extends Error {
+    readonly field: string;
+    readonly value: unknown;
+    constructor(message: string, field: string, value?: unknown);
+}
+/** True for any definition that carries a `decision` object, valid or not. */
+export declare function hasColumnDecision(definition: unknown): boolean;
+/** The stored decision, or null. Assumes the normalizer already validated it. */
+export declare function readColumnDecision(definition: unknown): ColumnDecisionDefinition | null;
+/**
+ * Validate and fill a caller-supplied decision. Throws {@link ColumnDecisionError}
+ * naming the bad field; the caller maps it to its own error envelope.
+ */
+export declare function normalizeColumnDecision(value: unknown): ColumnDecisionDefinition;
+/**
+ * The cell's JSON Schema, derived from the decision so filters, sorts, sub-columns
+ * and `{{column.field}}` references see a typed answer: an enum for labels, a
+ * boolean for yes/no, a number for a score.
+ */
+export declare function columnDecisionOutputSchema(decision: ColumnDecisionDefinition): Record<string, unknown>;

package/node_modules/@oxygen/shared/dist/column-decision.js

@@ -0,0 +1,228 @@
+/**
+ * The classification column contract: an AI column whose `definition.decision`
+ * asks System One (TypeSafe Jev, ADR 0027) a closed question per row instead of
+ * asking a generative model for prose.
+ *
+ * Three modes, one per System One question type:
+ *
+ * - `labels` — pick one of 2–20 customer labels (a `choice`).
+ * - `yes_no` — a yes/no probability (a `noul`). Its confidence is how far the
+ *   probability sits from 50%, so a 0.7 floor means "yes at 70% or more, no at
+ *   30% or less".
+ * - `score`  — rate against 2–10 ordered levels, lowest first (a `score`). The
+ *   value is the vendor's 0-based position, so it sorts and filters as a number.
+ *
+ * The column's own `prompt` is the question. Row values never enter it: the
+ * runner rewrites `{{tokens}}` to bracketed names and sends the values in the
+ * state (ADR 0027 §5). Below the floor the cell keeps the best guess, marked
+ * `uncertain` with its confidence; there is no generative fallback on this
+ * surface (ADR 0027 amendment 2026-09-25).
+ *
+ * Pure and client-safe: the tenant-db normalizer, the runner, the web editor,
+ * the CLI and the MCP server all read the same shape from here.
+ */
+import { isRecord } from "./type-guards.js";
+export const COLUMN_DECISION_ENGINE = "system_one";
+export const COLUMN_DECISION_MODES = ["labels", "yes_no", "score"];
+export const COLUMN_DECISION_GROUNDINGS = ["workspace", "none"];
+export const COLUMN_DECISION_MIN_LABELS = 2;
+export const COLUMN_DECISION_MAX_LABELS = 20;
+export const COLUMN_DECISION_MIN_LEVELS = 2;
+export const COLUMN_DECISION_MAX_LEVELS = 10;
+export const COLUMN_DECISION_MAX_OPTION_CHARS = 80;
+/** Floors the ADR shipped with: 0.85 for a choice or score, a 70/30 band for yes/no. */
+export const COLUMN_DECISION_DEFAULT_MIN_CONFIDENCE = {
+    labels: 0.85,
+    yes_no: 0.7,
+    score: 0.85,
+};
+export const COLUMN_DECISION_DEFAULT_FIELD = {
+    labels: "label",
+    yes_no: "answer",
+    score: "score",
+};
+/** Keys the cell writes next to the answer field; a field may not reuse one. */
+export const COLUMN_DECISION_RESERVED_FIELDS = new Set([
+    "confidence",
+    "uncertain",
+    "reason",
+    "probabilities",
+    "level",
+]);
+const FIELD_SHAPE = /^[a-z][a-z0-9_]{0,39}$/;
+/** A validation failure naming the field, for the normalizer to wrap in its own error type. */
+export class ColumnDecisionError extends Error {
+    field;
+    value;
+    constructor(message, field, value) {
+        super(message);
+        this.name = "ColumnDecisionError";
+        this.field = field;
+        this.value = value;
+    }
+}
+/** True for any definition that carries a `decision` object, valid or not. */
+export function hasColumnDecision(definition) {
+    return isRecord(definition) && isRecord(definition.decision);
+}
+/** The stored decision, or null. Assumes the normalizer already validated it. */
+export function readColumnDecision(definition) {
+    if (!isRecord(definition) || !isRecord(definition.decision))
+        return null;
+    const decision = definition.decision;
+    if (decision.engine !== COLUMN_DECISION_ENGINE)
+        return null;
+    if (!COLUMN_DECISION_MODES.includes(decision.mode))
+        return null;
+    const mode = decision.mode;
+    const field = typeof decision.field === "string" && FIELD_SHAPE.test(decision.field)
+        ? decision.field
+        : COLUMN_DECISION_DEFAULT_FIELD[mode];
+    const minConfidence = typeof decision.minConfidence === "number" && Number.isFinite(decision.minConfidence)
+        ? decision.minConfidence
+        : COLUMN_DECISION_DEFAULT_MIN_CONFIDENCE[mode];
+    const grounding = decision.grounding === "workspace" ? "workspace" : "none";
+    const strings = (value) => Array.isArray(value) ? value.filter((entry) => typeof entry === "string") : [];
+    return {
+        engine: COLUMN_DECISION_ENGINE,
+        mode,
+        field,
+        ...(mode === "labels" ? { labels: strings(decision.labels) } : {}),
+        ...(mode === "score" ? { levels: strings(decision.levels) } : {}),
+        minConfidence,
+        grounding,
+    };
+}
+function readOptionList(value, field, bounds) {
+    const raw = typeof value === "string" ? value.split(",") : value;
+    if (!Array.isArray(raw)) {
+        throw new ColumnDecisionError(`decision.${field} must be a list of strings.`, `decision.${field}`, value);
+    }
+    const options = [];
+    const seen = new Set();
+    for (const entry of raw) {
+        if (typeof entry !== "string") {
+            throw new ColumnDecisionError(`decision.${field} must contain only strings.`, `decision.${field}`, entry);
+        }
+        const option = entry.trim();
+        if (!option)
+            continue;
+        if (option.length > COLUMN_DECISION_MAX_OPTION_CHARS) {
+            throw new ColumnDecisionError(`Each of decision.${field} must be at most ${COLUMN_DECISION_MAX_OPTION_CHARS} characters.`, `decision.${field}`, option);
+        }
+        const folded = option.toLowerCase();
+        if (seen.has(folded)) {
+            throw new ColumnDecisionError(`decision.${field} lists "${option}" twice.`, `decision.${field}`, option);
+        }
+        seen.add(folded);
+        options.push(option);
+    }
+    if (options.length < bounds.min || options.length > bounds.max) {
+        throw new ColumnDecisionError(`decision.${field} needs ${bounds.min}–${bounds.max} entries (got ${options.length}).`, `decision.${field}`, options);
+    }
+    return options;
+}
+/**
+ * Validate and fill a caller-supplied decision. Throws {@link ColumnDecisionError}
+ * naming the bad field; the caller maps it to its own error envelope.
+ */
+export function normalizeColumnDecision(value) {
+    if (!isRecord(value)) {
+        throw new ColumnDecisionError("decision must be an object.", "decision", value);
+    }
+    const engine = value.engine ?? COLUMN_DECISION_ENGINE;
+    if (engine !== COLUMN_DECISION_ENGINE) {
+        throw new ColumnDecisionError(`decision.engine must be "${COLUMN_DECISION_ENGINE}".`, "decision.engine", engine);
+    }
+    const mode = value.mode;
+    if (!COLUMN_DECISION_MODES.includes(mode)) {
+        throw new ColumnDecisionError(`decision.mode must be one of ${COLUMN_DECISION_MODES.join(", ")}.`, "decision.mode", mode);
+    }
+    const decisionMode = mode;
+    const rawField = value.field;
+    let field = COLUMN_DECISION_DEFAULT_FIELD[decisionMode];
+    if (rawField !== undefined && rawField !== null) {
+        if (typeof rawField !== "string" || !FIELD_SHAPE.test(rawField.trim())) {
+            throw new ColumnDecisionError("decision.field must be a lowercase key (letters, digits, underscores; starts with a letter; at most 40 characters).", "decision.field", rawField);
+        }
+        field = rawField.trim();
+    }
+    if (COLUMN_DECISION_RESERVED_FIELDS.has(field)) {
+        throw new ColumnDecisionError(`decision.field cannot be "${field}": the cell already writes that key.`, "decision.field", field);
+    }
+    const floorMin = decisionMode === "yes_no" ? 0.5 : 0.05;
+    let minConfidence = COLUMN_DECISION_DEFAULT_MIN_CONFIDENCE[decisionMode];
+    if (value.minConfidence !== undefined && value.minConfidence !== null) {
+        const raw = value.minConfidence;
+        if (typeof raw !== "number" || !Number.isFinite(raw) || raw < floorMin || raw > 1) {
+            throw new ColumnDecisionError(`decision.minConfidence must be a number from ${floorMin} to 1${decisionMode === "yes_no" ? " for yes/no (0.7 means yes at 70% or more, no at 30% or less)" : ""}.`, "decision.minConfidence", raw);
+        }
+        minConfidence = raw;
+    }
+    // Default `none` (2026-09-25): a classification judges the row against the
+    // column's own question. Workspace knowledge is opt-in, because the ICP slice
+    // turned "is this SaaS?" into "is this our ICP?" in the blind acceptance run
+    // (Stripe came back "other: not a B2B SaaS targeting seed founders").
+    const grounding = value.grounding ?? "none";
+    if (!COLUMN_DECISION_GROUNDINGS.includes(grounding)) {
+        throw new ColumnDecisionError(`decision.grounding must be one of ${COLUMN_DECISION_GROUNDINGS.join(", ")}.`, "decision.grounding", grounding);
+    }
+    if (decisionMode === "labels") {
+        if (value.levels !== undefined) {
+            throw new ColumnDecisionError("decision.levels belongs to score mode; labels mode takes decision.labels.", "decision.levels");
+        }
+        const labels = readOptionList(value.labels, "labels", {
+            min: COLUMN_DECISION_MIN_LABELS,
+            max: COLUMN_DECISION_MAX_LABELS,
+        });
+        return { engine: COLUMN_DECISION_ENGINE, mode: decisionMode, field, labels, minConfidence, grounding: grounding };
+    }
+    if (decisionMode === "score") {
+        if (value.labels !== undefined) {
+            throw new ColumnDecisionError("decision.labels belongs to labels mode; score mode takes decision.levels, lowest first.", "decision.labels");
+        }
+        const levels = readOptionList(value.levels, "levels", {
+            min: COLUMN_DECISION_MIN_LEVELS,
+            max: COLUMN_DECISION_MAX_LEVELS,
+        });
+        return { engine: COLUMN_DECISION_ENGINE, mode: decisionMode, field, levels, minConfidence, grounding: grounding };
+    }
+    if (value.labels !== undefined || value.levels !== undefined) {
+        throw new ColumnDecisionError("yes_no mode takes no labels or levels.", value.labels !== undefined ? "decision.labels" : "decision.levels");
+    }
+    return { engine: COLUMN_DECISION_ENGINE, mode: decisionMode, field, minConfidence, grounding: grounding };
+}
+/**
+ * The cell's JSON Schema, derived from the decision so filters, sorts, sub-columns
+ * and `{{column.field}}` references see a typed answer: an enum for labels, a
+ * boolean for yes/no, a number for a score.
+ */
+export function columnDecisionOutputSchema(decision) {
+    const answer = decision.mode === "labels"
+        ? {
+            type: ["string", "null"],
+            enum: [...(decision.labels ?? []), null],
+            description: "The chosen label (the best guess when uncertain).",
+        }
+        : decision.mode === "yes_no"
+            ? { type: ["boolean", "null"], description: "Yes or no (the best guess when uncertain)." }
+            : {
+                type: ["number", "null"],
+                description: `Position on the scale, 0 (${decision.levels?.[0] ?? "lowest"}) to ${Math.max(0, (decision.levels?.length ?? 1) - 1)} (${decision.levels?.at(-1) ?? "highest"}).`,
+            };
+    const properties = {
+        [decision.field]: answer,
+        ...(decision.mode === "score"
+            ? { level: { type: ["string", "null"], enum: [...(decision.levels ?? []), null], description: "The nearest level." } }
+            : {}),
+        confidence: { type: "number", description: "How sure the classifier is, 0 to 1." },
+        uncertain: { type: "boolean", description: "True when confidence is below the column's floor." },
+        reason: { type: "string", description: "The answer and its confidence in words." },
+    };
+    return {
+        type: "object",
+        additionalProperties: true,
+        properties,
+        required: [decision.field, "confidence", "uncertain", "reason"],
+    };
+}

package/node_modules/@oxygen/shared/dist/company-enrichment-fields.d.ts

@@ -55,10 +55,15 @@ export declare function isDerivedCompanyEnrichmentField(field: CompanyEnrichment
 export declare const DEFAULT_COMPANY_FIND_FIELDS: readonly CompanyEnrichmentFieldKey[];
 /**
  * What `columns add --preset company_enrich` creates when the caller names no
- * fields: the identity/firmographic set plus the full profile and the funding
- * facts LinkedIn publishes for free off that same profile. Every lane-priced
- * relationship, signal, technology and web-presence field is opt-in through
- * `--fields`, so the default bundle's per-row ceiling stays the profile chain's.
+ * fields: the identity/firmographic set plus the full profile and what it says
+ * about the company. Every lane-priced relationship, funding, signal,
+ * technology and web-presence field is opt-in through `--fields`, so the
+ * default bundle's per-row ceiling stays the profile chain's.
+ *
+ * Funding stage and latest round left the default on 2026-09-24 (founder, D55):
+ * the profile lane is Blitz first now, and Blitz's company profile carries no
+ * funding, so on the rows Blitz answers those two columns would sit empty. They
+ * live in the Funding details group instead.
  */
 export declare const DEFAULT_COMPANY_PRESET_FIELDS: readonly CompanyEnrichmentFieldKey[];
 export type CompanyEnrichmentFieldGroupId = "profile_details" | "funding_details" | "job_openings" | "tech_stack" | "technology_check";

package/node_modules/@oxygen/shared/dist/company-enrichment-fields.js

@@ -441,10 +441,15 @@ export const DEFAULT_COMPANY_FIND_FIELDS = [
 ];
 /**
  * What `columns add --preset company_enrich` creates when the caller names no
- * fields: the identity/firmographic set plus the full profile and the funding
- * facts LinkedIn publishes for free off that same profile. Every lane-priced
- * relationship, signal, technology and web-presence field is opt-in through
- * `--fields`, so the default bundle's per-row ceiling stays the profile chain's.
+ * fields: the identity/firmographic set plus the full profile and what it says
+ * about the company. Every lane-priced relationship, funding, signal,
+ * technology and web-presence field is opt-in through `--fields`, so the
+ * default bundle's per-row ceiling stays the profile chain's.
+ *
+ * Funding stage and latest round left the default on 2026-09-24 (founder, D55):
+ * the profile lane is Blitz first now, and Blitz's company profile carries no
+ * funding, so on the rows Blitz answers those two columns would sit empty. They
+ * live in the Funding details group instead.
  */
 export const DEFAULT_COMPANY_PRESET_FIELDS = [
     "domain",
@@ -455,8 +460,6 @@ export const DEFAULT_COMPANY_PRESET_FIELDS = [
     "description",
     "founded_year",
     "hq_country",
-    "funding_stage",
-    "latest_funding_round",
 ];
 /**
  * The opt-in company fields, grouped the way a customer asks for them ("add
@@ -478,8 +481,8 @@ export const COMPANY_ENRICHMENT_FIELD_GROUPS = [
     {
         id: "funding_details",
         label: "Funding details",
-        description: "Total raised, number of rounds and investors, with the full funding history kept alongside.",
-        fields: ["funding", "revenue", "total_funding", "funding_rounds_count", "investors"],
+        description: "Funding stage, latest round, total raised, number of rounds and investors, with the full funding history kept alongside.",
+        fields: ["funding", "revenue", "funding_stage", "latest_funding_round", "total_funding", "funding_rounds_count", "investors"],
         cost: "extra",
     },
     {

package/node_modules/@oxygen/shared/dist/copilot-skills.generated.d.ts

@@ -14,8 +14,8 @@ export declare const COPILOT_SKILL_SNAPSHOTS_GENERATED: readonly [{
     readonly slug: "linkedin-content-strategy";
     readonly title: "Playbook: LinkedIn content strategy";
     readonly sources: readonly ["oxygen-playbooks/playbooks/linkedin-content-strategy.md"];
-    readonly sha256: "8c548c7d76f037f096462cabee4d8463ba707274ec4f31445cd526d67f6499d6";
-    readonly content: "---\nname: linkedin-content-strategy\ndescription: \"Install and run the founder LinkedIn content engine: a wiki-grounded strategy page, an idea backlog, a week of drafts approved post by post, scheduled publishing, answered comments, weekly engagement read-back, outlier mining, and the hand-off of engagers to inbound-led outbound.\"\n---\n\n# Playbook: LinkedIn content strategy\n\n## Motion in one sentence\n\nA strategy page written from the wiki fixes the pillars, cadence and voice; ideas accumulate in a backlog; a week of drafts is generated from that wiki and approved one post at a time; the scheduler publishes each from the founder's own account; comments are answered through a previewed reply; engagement is read back weekly; outlier mining says which structures travelled; the lessons file back into the wiki; and the engagers become the inbound signal. Each stage reads the page the last one wrote — a posting habit without the strategy page is a treadmill, and an outlier bank without the habit is a swipe file nobody drains.\n\nRead first: `oxygen recipes show founder-posting-system --json`, `oxygen recipes show weekly-content-calendar --json`, `oxygen recipes show content-outlier-mining --json` (the stage 7 kit). Mechanics: `oxygen skills get oxygen-linkedin-marketing --json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + strategy | Knowledge Graph | `oxygen knowledge resolve --purpose outbound_copy --require-ready --json` → `oxygen knowledge page upsert --slug content-strategy --type strategy --title \"Content strategy\" --status active --body \"<pillars / cadence / voice>\" --json` | `positioning`, `icp`, `offers`, `voice`, all `active` | 3–5 pillars, each naming one ICP problem | none — a `strategy` page is working knowledge, logged as a revision | `oxygen knowledge page get content-strategy --json` | a stub ICP page, or a pillar with no buyer problem |\n| 1 | Sender | Publishing | `oxygen senders list --status active --json`; `oxygen senders health <sender_id> --json` (`oxygen senders limits get` for the budgets) | one connected LinkedIn account | own-feed ceiling 25 posts / 24h | none — reads | `active`, no open checkpoint | `restricted` / `credentials_required`: reconnect, never route around it |\n| 2 | Backlog | Publishing | `oxygen publishing ideas add --text \"<angle>\" --topic <pillar> --json`; `oxygen publishing ideas list --json` | angles as they occur; structures from stage 7 | two weeks of slots ahead | none (internal write) | `oxygen publishing ideas list --limit 50 --json` | an empty backlog on drafting day: mine outliers, don't draft from taste |\n| 3 | Draft + queue | Publishing | `oxygen publishing posts draft --template personal_story --topic \"<angle>\" --max-credits <cap> --json` → `oxygen publishing drafts edit <draft_id> --text-file mon.txt --json` → `oxygen publishing drafts accept <draft_id> --publish-at <iso+offset> --sender <sender_id> --json` | a pillar + a backlog angle per slot | 3–5 posts/week; 1–5 variants (default 3) | `draft-week`: paid, cap from the preview; queueing needs none — it never sends | `oxygen publishing posts list --approval-status needs_approval --json` | a bare `--publish-at`: with no offset it is stored as UTC |\n| 4 | Review + publish | Publishing | `oxygen publishing posts review <post_id> --max-credits <cap> --json`; `oxygen publishing mentions resolve --text-file mon.txt --json` → `oxygen publishing posts approve <post_id> --json` | the exact final text, read by the founder | ≤15% promotion posts; ≤1 lead-magnet CTA/week | `review-post`: paid, advisory. `post-publish`: human, every post, never batched | `oxygen publishing posts get <post_id> --json` — attempts, provider id, deep-link | an unresolved `@<public-identifier>`; `linkedin_rate_limited` |\n| 5 | Comments | Publishing | `oxygen publishing comments list --view unanswered --json` → `oxygen publishing comments reply <comment_id> --text-file reply.txt --json` → `oxygen publishing comments approve <action_id> --content-hash <sha256> --approved --json` → `oxygen publishing comments resolve <comment_id> --json` | the unanswered queue (30-day scope) | one reply per comment, inside 48h | `comment-reply`: human approves that exact previewed text and its hash | the queue drains; handled items read `resolved` | a comment older than 48h with no reply |\n| 6 | Read back | Publishing + Posts | `oxygen publishing analytics summary --channel linkedin --range 30d --json`; `oxygen publishing analytics post <post_id> --json`; `oxygen posts get --post <post_url> --json` | published posts | metrics refresh ~30 days after publish | none — reads | reactions, comments, reshares present; impressions honestly null | every metric zero after two days: confirm `published`, not `deferred` |\n| 7 | Mine outliers | Workflows — kit stage `linkedin-keyword-outliers` | `oxygen recipes apply content-outlier-mining --dry-run --json` → without `--dry-run`; then `oxygen blueprints apply linkedin-creator-outliers --table-ref content_outliers=<bank_table_id> --json` | 3–4 buyer-language keywords; ≤25 public `/in/` URLs | 7-day lookback; 1 page/keyword on the pilot; ceiling from preflight | `pilot-live` then `sweep-arm`: human, re-granted on reapply | `oxygen workflows tail <run_id> --json`; `oxygen tables query <bank_table_id> --json` | everything near par, or top rows are hiring posts |\n| 8 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind voice --json` → `--approved`; `oxygen knowledge log append --event decision --slug content-strategy --json` | analytics, comments, the bank, draft edits | one rule per loop | canonical voice / positioning file a proposal: `oxygen knowledge proposals approve <id> --json` | `oxygen knowledge page get content-strategy --json` | a change with no receipt behind it |\n| 9 | Hand off | Signals → inbound-led outbound | `oxygen engagement harvest --post <social_id> --source unipile --recurring --json`; `oxygen engagement status --post <social_id> --json` | the composite `social_id` from `oxygen posts get` | free; drips against the ingest budget | none — it contacts nobody | `oxygen engagement engagers --post <social_id> --json` previews the table | outreach begins here: run the inbound-led-outbound playbook |\n\n## Numeric guardrails\n\n- **Cadence and mix:** 3–5 posts/week planned; 2–3/week for four consecutive weeks is the floor before any signal is readable. At most 15% promotion posts and one lead-magnet CTA post per week. Consistency leads, reach lags.\n- **Own-feed ceiling 25 posts / 24h** per account, a platform default: own-feed publishing sits outside the outreach send quotas because it is not aimed at another member, but still refuses a sender that is not `active`. Own-post reads draw the other-API-read budget (200/day default, 1,000 max); `engagement harvest` draws the separate ingest budget (20/day, 200 max), so a big post drips over days. `oxygen engagement engagers` walks both sources up to `--max-pages` (default 5, max 20) × 100.\n- **Paid calls:** 1–5 variants per draft call (default 3), one AI call per draft and per review. Take every ceiling from the preview and `oxygen tools get <tool_id> --json`, never from prose; sweep ceilings from `oxygen blueprints preflight`.\n- **Comment SLA 48 hours**, over a rolling 30-day owned-post scope: an older thread is absent from the queue, not silent. Analytics refresh for ~30 days; reactions, comments and reshares are real, impressions and saves are never exposed for a member's own posts.\n- **Outlier scoring:** `rank_score = 100 × √(outlier_multiple × audience_index)`, **100 is par**; a healthy sweep puts ~5–15% above 200. Defaults: `lookback_days` 7, `min_post_age_hours` 24, `min_author_followers` 1000, weights 1 / 3 / 5; 3–4 keywords (max 8), 10–25 creators (max 25).\n\n## Angle gate spec\n\nThe gate is not who gets contacted — nobody is contacted here — it is **which idea becomes a public post in the founder's name**. An item advances to draft only when all of these hold: it maps to a named pillar on `[[content-strategy]]`; it carries one concrete claim, story or artifact traceable to a wiki page, a shipped thing or a real customer outcome; it names the audience in plain words; if promotional, the week's share is still under 15%; and its voice matches the pinned voice page. The first three are enforced at drafting, because the draft call grounds on the wiki by default; voice by the free channel lint plus the paid `publishing posts review` check.\n\nNothing bypasses it, because **approval is per post and is not batchable server-side**: a draft accepted from the AI queue, a post created directly, and a row loaded by `oxygen publishing import` all land needs-approval. Borrowing from the bank has its own rule — lift the **structure**, never the text, and only from a row that cleared `rank_score` 200 with a `baseline_kind` you trust; `author_unresolved` and `maturing` rows are unscored and are not evidence.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Copilot posture |\n| --- | --- | --- |\n| kit apply (`oxygen recipes apply content-outlier-mining`) | 0-credit install of the sweep, workflow disabled | human card, once |\n| `draft-week` / `review-post` | one paid AI drafting or voice/claims call | human sets each cap from the preview |\n| `post-publish` | one public post in the founder's name, on this exact text | human, every post, never batched |\n| `comment-reply` | one public reply bound to the preview's `action_id` and `content_hash` | human approves that exact text |\n| `pilot-live` then `sweep-arm` | one live outlier cycle, then the recurring sweep | human for each; re-grant on reapply (revision-bound) |\n| amplification (`oxygen publishing amplification create`, then `enable`) | real public engagement from teammates' accounts, spending credits | human twice: grant, then arm |\n| canonical wiki edits | voice / brand / positioning / pinned playbooks | a proposal a human approves |\n\nInstallation is never permission: the kit applies at 0 credits with its workflow disabled, and every paid run, publish, reply and armed sweep is its own gate above.\n\nReads need no approval (`oxygen publishing posts list`, `oxygen publishing analytics summary`, `oxygen senders health`, `oxygen tables query`); working wiki pages write as logged revisions.\n\n## Failure modes\n\n- **The two axes.** `--status` is pipeline position (`draft` → `scheduled` → `queued` → `published`); `--approval-status` is whether a human said yes. A queued post is both `scheduled` and `needs_approval`. Filter on the approval axis or you will report an empty queue you just filled.\n- **A bare local `--publish-at`.** With no offset it is stored as UTC; `--timezone` only changes the display. Pass an offset or `Z`.\n- **The activity URN is not the `social_id`.** `posts reactions`, `posts comments`, `engagement engagers` and `engagement harvest` all need the composite `social_id` from `oxygen posts get`. Nothing lists your own feed, so record the id when the post goes out.\n- **Mentions and content.** A verified `@<public-identifier>` goes in the post text — a structured `mentions` array is ignored and `content.mentions` rejected; approve blocks anything unresolved. `--content-json` replaces the whole content object, so a media update drops an existing `first_comment` unless you resend it.\n- **A post on a dead sender never dispatches**; fix the account instead of re-queueing. A rate limit **defers** rather than drops and names `resets_at`, so retrying in a loop only burns quota. Company-page posting is a tested-negative anti-pattern — post from the personal profile.\n- **Generic drafts are a thin wiki, not a thin prompt**; a bank where everything scores near par is a keyword naming a category. Fix the page or the phrase, never the prompt length or the weights.\n- **Outreach leaking in.** The moment the plan is to message an engager, this motion is over — hand off at stage 9. Sequences own initiation; a CRM person is created at a warm-lead gate, never because someone reacted.\n\n## Data-quality checks (after every week)\n\n1. `oxygen publishing posts list --status published --json` — every planned slot published, or one sat `needs_approval` all week? A missed slot is the failure this motion exists to prevent.\n2. `oxygen publishing comments list --view unanswered --json` — nothing older than 48h, and never `resolved` on a thread still owed an answer.\n3. `oxygen publishing analytics summary --channel linkedin --range 30d --json` — all-zero after two days means `deferred`. Then read the comments, not the counts: ICP titles, or peers and recruiters?\n4. `oxygen tables query <bank_table_id> --limit 25 --json` — mostly `author_unresolved` or `maturing` is a cold cache or short lookback; a backlog under two weeks deep means next week starts from taste.\n\n## Learning loop\n\n- **What auto-files:** a draft edit snapshots the AI's original copy, so an accepted edit records what the founder changed; `oxygen publishing drafts reject <draft_id> --reason \"...\" --json` files the reason; revisions, review findings, the metric series and the comment queue are durable.\n- **What to synthesise weekly:** which pillar produced ICP-fit comments rather than peer likes; which post *shape* travelled (a number in line one, a named enemy, a before/after); and `oxygen knowledge synthesize --kind voice --json`, a voice guide distilled from real sent copy.\n- **What to change, one rule per loop:** the pillar mix, a slot's time, a keyword on the source table (pause it, never delete it), the CTA, or the voice page. Write the change and its reason into the wiki; a voice or positioning change files a proposal.\n- **Define \"good\" first:** an inbound conversation from an ICP-fit person — a DM, a comment thread that becomes a call, a reply naming their own version of the problem. Not reach, not reactions, not a bank with more rows.\n\n## Go-live checklist\n\n1. `oxygen senders list --status active --json`, then `oxygen senders health <sender_id> --json` — one healthy account, no open checkpoint.\n2. `oxygen knowledge resolve --purpose outbound_copy --require-ready --json`, then `oxygen knowledge page upsert --slug content-strategy --type strategy --status active --body \"...\" --json`.\n3. `oxygen publishing ideas add --text \"...\" --topic <pillar> --json` until two weeks of slots exist, then draft and queue each slot (stage 3).\n4. `oxygen publishing posts list --approval-status needs_approval --json`, present the week, then `oxygen publishing posts approve <post_id> --json` one post at a time.\n5. `oxygen publishing comments list --view unanswered --json` — the 48h loop runs and a named person owns it.\n6. `oxygen recipes apply content-outlier-mining --dry-run --json`, apply, one `oxygen workflows call <workflow_id> --mode dry-run --json`, one `pilot-live` cycle, then `oxygen workflows enable <workflow_id> --approved --max-credits <cap> --json`.\n7. `oxygen budget list --json` for the org backstop, then `oxygen knowledge log append --event note --slug content-strategy --json`.\n\n## Open questions (state them, do not resolve them)\n\n- LinkedIn does not expose impressions, saves or sends for a member's own posts, so reach is unmeasurable and earned-media value stays null. Never substitute a proxy and call it reach.\n- The cadence and mix numbers are operator estimates, not measured benchmarks. Replace them with four weeks of your own evidence.\n- The outlier kit is `beta`, and `oxygen recipes apply content-outlier-mining` installs only the keyword sweep; the creator watch applies separately against the same tables with `--table-ref`, and omitting those flags reports a table collision — the guard working.\n- Whether engagers flow automatically into outreach is not this playbook's call; stage 9 hands them over deliberately. Amplification from teammates' accounts is likewise a founder decision about the company's public name.\n\n## Resume point\n\n`oxygen recipes show founder-posting-system --json` and `oxygen knowledge page get content-strategy --json`, then `oxygen publishing posts list --json`, `oxygen publishing comments list --json` and `oxygen workflows list --json`. Start from what exists, never from scratch.\n";
+    readonly sha256: "3a0e90ad7451e433473ce09b2db86ea3864eaab1719f19be6333a33fd38be710";
+    readonly content: "---\nname: linkedin-content-strategy\ndescription: \"Install and run the founder LinkedIn content engine: a wiki-grounded strategy page, an idea backlog, a week of drafts approved post by post, scheduled publishing, answered comments, weekly engagement read-back, outlier mining, and the hand-off of engagers to inbound-led outbound.\"\n---\n\n# Playbook: LinkedIn content strategy\n\n## Motion in one sentence\n\nA strategy page written from the wiki fixes the pillars, cadence and voice; ideas accumulate in a backlog; a week of drafts is generated from that wiki and approved one post at a time; the scheduler publishes each from the founder's own account; comments are answered through a previewed reply; engagement is read back weekly; outlier mining says which structures travelled; the lessons file back into the wiki; and the engagers become the inbound signal. Each stage reads the page the last one wrote — a posting habit without the strategy page is a treadmill, and an outlier bank without the habit is a swipe file nobody drains.\n\nRead first: `oxygen recipes show founder-posting-system --json`, `oxygen recipes show weekly-content-calendar --json`, `oxygen recipes show content-outlier-mining --json` (the stage 7 kit). Mechanics: `oxygen skills get oxygen-linkedin-marketing --json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + strategy | Knowledge Graph | `oxygen knowledge resolve --purpose outbound_copy --require-ready --json` → `oxygen knowledge page upsert --slug content-strategy --type strategy --title \"Content strategy\" --status active --body \"<pillars / cadence / voice>\" --json` | `positioning`, `icp`, `offers`, `voice`, all `active` | 3–5 pillars, each naming one ICP problem | none — a `strategy` page is working knowledge, logged as a revision | `oxygen knowledge page get content-strategy --json` | a stub ICP page, or a pillar with no buyer problem |\n| 1 | Sender | Publishing | `oxygen senders list --status active --json`; `oxygen senders health <sender_id> --json` (`oxygen senders limits get` for the budgets) | one connected LinkedIn account | own-feed ceiling 25 posts / 24h | none — reads | `active`, no open checkpoint | `restricted` / `credentials_required`: reconnect, never route around it |\n| 2 | Backlog | Publishing | `oxygen publishing ideas add --text \"<angle>\" --topic <pillar> --json`; `oxygen publishing ideas list --json` | angles as they occur; structures from stage 7 | two weeks of slots ahead | none (internal write) | `oxygen publishing ideas list --limit 50 --json` | an empty backlog on drafting day: mine outliers, don't draft from taste |\n| 3 | Draft + queue | Publishing | `oxygen publishing posts draft --template personal_story --topic \"<angle>\" --max-credits <cap> --json` → `oxygen publishing drafts edit <draft_id> --text-file mon.txt --json` → `oxygen publishing drafts accept <draft_id> --publish-at <iso+offset> --sender <sender_id> --json` | a pillar + a backlog angle per slot | 3–5 posts/week; 1–5 variants (default 3) | `draft-week`: paid, cap from the preview; queueing needs none — it never sends | `oxygen publishing posts list --approval-status needs_approval --json` | a bare `--publish-at`: with no offset it is stored as UTC |\n| 4 | Review + publish | Publishing | `oxygen publishing posts review <post_id> --max-credits <cap> --json`; `oxygen publishing mentions resolve --text-file mon.txt --json` → `oxygen publishing posts approve <post_id> --json` | the exact final text, read by the founder | ≤15% promotion posts; ≤1 lead-magnet CTA/week | `review-post`: paid, advisory. `post-publish`: human, every post, never batched | `oxygen publishing posts get <post_id> --json` — attempts, provider id, deep-link | an unresolved `@<public-identifier>`; `linkedin_rate_limited` |\n| 5 | Comments | Publishing | `oxygen publishing comments list --view unanswered --json` → `oxygen publishing comments reply <comment_id> --text-file reply.txt --json` → `oxygen publishing comments approve <action_id> --content-hash <sha256> --approved --json` → `oxygen publishing comments resolve <comment_id> --json` | the unanswered queue (30-day scope) | one reply per comment, inside 48h | `comment-reply`: human approves that exact previewed text and its hash | the queue drains; handled items read `resolved` | a comment older than 48h with no reply |\n| 6 | Read back | Publishing + Posts | `oxygen publishing analytics summary --channel linkedin --range 30d --json` (winners, `leader` lead, `null_reasons`); `oxygen publishing analytics timeseries --channel linkedin --range 30d --json` (earned per day, growing or shrinking vs the previous period, follower change); `oxygen publishing analytics post <post_id> --json`; `oxygen posts get --post <post_url> --json` | published posts | metrics refresh ~30 days after publish | none — reads | reactions, comments, reshares and — on your own original posts — impressions present; reposts counted in `reposts_excluded`, not in totals | every metric zero after two days: confirm `published`, not `deferred` |\n| 7 | Mine outliers | Workflows — kit stage `linkedin-keyword-outliers` | `oxygen recipes apply content-outlier-mining --dry-run --json` → without `--dry-run`; then `oxygen blueprints apply linkedin-creator-outliers --table-ref content_outliers=<bank_table_id> --json` | 3–4 buyer-language keywords; ≤25 public `/in/` URLs | 7-day lookback; 1 page/keyword on the pilot; ceiling from preflight | `pilot-live` then `sweep-arm`: human, re-granted on reapply | `oxygen workflows tail <run_id> --json`; `oxygen tables query <bank_table_id> --json` | everything near par, or top rows are hiring posts |\n| 8 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind voice --json` → `--approved`; `oxygen knowledge log append --event decision --slug content-strategy --json` | analytics, comments, the bank, draft edits | one rule per loop | canonical voice / positioning file a proposal: `oxygen knowledge proposals approve <id> --json` | `oxygen knowledge page get content-strategy --json` | a change with no receipt behind it |\n| 9 | Hand off | Signals → inbound-led outbound | `oxygen engagement harvest --post <social_id> --source unipile --recurring --json`; `oxygen engagement status --post <social_id> --json` | the composite `social_id` from `oxygen posts get` | free; drips against the ingest budget | none — it contacts nobody | `oxygen engagement engagers --post <social_id> --json` previews the table | outreach begins here: run the inbound-led-outbound playbook |\n\n## Numeric guardrails\n\n- **Cadence and mix:** 3–5 posts/week planned; 2–3/week for four consecutive weeks is the floor before any signal is readable. At most 15% promotion posts and one lead-magnet CTA post per week. Consistency leads, reach lags.\n- **Own-feed ceiling 25 posts / 24h** per account, a platform default: own-feed publishing sits outside the outreach send quotas because it is not aimed at another member, but still refuses a sender that is not `active`. Own-post reads draw the other-API-read budget (200/day default, 1,000 max); `engagement harvest` draws the separate ingest budget (20/day, 200 max), so a big post drips over days. `oxygen engagement engagers` walks both sources up to `--max-pages` (default 5, max 20) × 100.\n- **Paid calls:** 1–5 variants per draft call (default 3), one AI call per draft and per review. Take every ceiling from the preview and `oxygen tools get <tool_id> --json`, never from prose; sweep ceilings from `oxygen blueprints preflight`.\n- **Comment SLA 48 hours**, over a rolling 30-day owned-post scope: an older thread is absent from the queue, not silent. Analytics refresh for ~30 days; reactions, comments and reshares are real; impressions come from LinkedIn's own post analytics, which it shows only to the author, so they are real for the connected member's original posts; saves and sends are not exposed.\n- **Outlier scoring:** `rank_score = 100 × √(outlier_multiple × audience_index)`, **100 is par**; a healthy sweep puts ~5–15% above 200. Defaults: `lookback_days` 7, `min_post_age_hours` 24, `min_author_followers` 1000, weights 1 / 3 / 5; 3–4 keywords (max 8), 10–25 creators (max 25).\n\n## Angle gate spec\n\nThe gate is not who gets contacted — nobody is contacted here — it is **which idea becomes a public post in the founder's name**. An item advances to draft only when all of these hold: it maps to a named pillar on `[[content-strategy]]`; it carries one concrete claim, story or artifact traceable to a wiki page, a shipped thing or a real customer outcome; it names the audience in plain words; if promotional, the week's share is still under 15%; and its voice matches the pinned voice page. The first three are enforced at drafting, because the draft call grounds on the wiki by default; voice by the free channel lint plus the paid `publishing posts review` check.\n\nNothing bypasses it, because **approval is per post and is not batchable server-side**: a draft accepted from the AI queue, a post created directly, and a row loaded by `oxygen publishing import` all land needs-approval. Borrowing from the bank has its own rule — lift the **structure**, never the text, and only from a row that cleared `rank_score` 200 with a `baseline_kind` you trust; `author_unresolved` and `maturing` rows are unscored and are not evidence.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Copilot posture |\n| --- | --- | --- |\n| kit apply (`oxygen recipes apply content-outlier-mining`) | 0-credit install of the sweep, workflow disabled | human card, once |\n| `draft-week` / `review-post` | one paid AI drafting or voice/claims call | human sets each cap from the preview |\n| `post-publish` | one public post in the founder's name, on this exact text | human, every post, never batched |\n| `comment-reply` | one public reply bound to the preview's `action_id` and `content_hash` | human approves that exact text |\n| `pilot-live` then `sweep-arm` | one live outlier cycle, then the recurring sweep | human for each; re-grant on reapply (revision-bound) |\n| amplification (`oxygen publishing amplification create`, then `enable`) | real public engagement from teammates' accounts, spending credits; LinkedIn may restrict those accounts | human twice: grant, then arm, each with `--acknowledge-risk` |\n| canonical wiki edits | voice / brand / positioning / pinned playbooks | a proposal a human approves |\n\nInstallation is never permission: the kit applies at 0 credits with its workflow disabled, and every paid run, publish, reply and armed sweep is its own gate above.\n\nReads need no approval (`oxygen publishing posts list`, `oxygen publishing analytics summary`, `oxygen senders health`, `oxygen tables query`); working wiki pages write as logged revisions.\n\n## Failure modes\n\n- **The two axes.** `--status` is pipeline position (`draft` → `scheduled` → `queued` → `published`); `--approval-status` is whether a human said yes. A queued post is both `scheduled` and `needs_approval`. Filter on the approval axis or you will report an empty queue you just filled.\n- **A bare local `--publish-at`.** With no offset it is stored as UTC; `--timezone` only changes the display. Pass an offset or `Z`.\n- **The activity URN is not the `social_id`.** `posts reactions`, `posts comments`, `engagement engagers` and `engagement harvest` all need the composite `social_id` from `oxygen posts get`. Nothing lists your own feed, so record the id when the post goes out.\n- **Mentions and content.** A verified `@<public-identifier>` goes in the post text — a structured `mentions` array is ignored and `content.mentions` rejected; approve blocks anything unresolved. `--content-json` replaces the whole content object, so a media update drops an existing `first_comment` unless you resend it.\n- **A post on a dead sender never dispatches**; fix the account instead of re-queueing. A rate limit **defers** rather than drops and names `resets_at`, so retrying in a loop only burns quota. Company-page posting is a tested-negative anti-pattern — post from the personal profile.\n- **Generic drafts are a thin wiki, not a thin prompt**; a bank where everything scores near par is a keyword naming a category. Fix the page or the phrase, never the prompt length or the weights.\n- **Outreach leaking in.** The moment the plan is to message an engager, this motion is over — hand off at stage 9. Sequences own initiation; a CRM person is created at a warm-lead gate, never because someone reacted.\n\n## Data-quality checks (after every week)\n\n1. `oxygen publishing posts list --status published --json` — every planned slot published, or one sat `needs_approval` all week? A missed slot is the failure this motion exists to prevent.\n2. `oxygen publishing comments list --view unanswered --json` — nothing older than 48h, and never `resolved` on a thread still owed an answer.\n3. `oxygen publishing analytics summary --channel linkedin --range 30d --json` — all-zero after two days means `deferred`. Then read the comments, not the counts: ICP titles, or peers and recruiters?\n4. `oxygen tables query <bank_table_id> --limit 25 --json` — mostly `author_unresolved` or `maturing` is a cold cache or short lookback; a backlog under two weeks deep means next week starts from taste.\n\n## Learning loop\n\n- **What auto-files:** a draft edit snapshots the AI's original copy, so an accepted edit records what the founder changed; `oxygen publishing drafts reject <draft_id> --reason \"...\" --json` files the reason; revisions, review findings, the metric series and the comment queue are durable.\n- **What to synthesise weekly:** which pillar produced ICP-fit comments rather than peer likes; which post *shape* travelled (a number in line one, a named enemy, a before/after); and `oxygen knowledge synthesize --kind voice --json`, a voice guide distilled from real sent copy.\n- **What to change, one rule per loop:** the pillar mix, a slot's time, a keyword on the source table (pause it, never delete it), the CTA, or the voice page. Write the change and its reason into the wiki; a voice or positioning change files a proposal.\n- **Define \"good\" first:** an inbound conversation from an ICP-fit person — a DM, a comment thread that becomes a call, a reply naming their own version of the problem. Not reach, not reactions, not a bank with more rows.\n\n## Go-live checklist\n\n1. `oxygen senders list --status active --json`, then `oxygen senders health <sender_id> --json` — one healthy account, no open checkpoint.\n2. `oxygen knowledge resolve --purpose outbound_copy --require-ready --json`, then `oxygen knowledge page upsert --slug content-strategy --type strategy --status active --body \"...\" --json`.\n3. `oxygen publishing ideas add --text \"...\" --topic <pillar> --json` until two weeks of slots exist, then draft and queue each slot (stage 3).\n4. `oxygen publishing posts list --approval-status needs_approval --json`, present the week, then `oxygen publishing posts approve <post_id> --json` one post at a time.\n5. `oxygen publishing comments list --view unanswered --json` — the 48h loop runs and a named person owns it.\n6. `oxygen recipes apply content-outlier-mining --dry-run --json`, apply, one `oxygen workflows call <workflow_id> --mode dry-run --json`, one `pilot-live` cycle, then `oxygen workflows enable <workflow_id> --approved --max-credits <cap> --json`.\n7. `oxygen budget list --json` for the org backstop, then `oxygen knowledge log append --event note --slug content-strategy --json`.\n\n## Open questions (state them, do not resolve them)\n\n- LinkedIn shows impressions only to a post's author and never exposes saves or sends. Reach is measurable for the connected member's original posts (and earned-media value once a CPM is set with `oxygen publishing analytics emv`); for anything else it stays empty. Never substitute a proxy and call it reach.\n- The cadence and mix numbers are operator estimates, not measured benchmarks. Replace them with four weeks of your own evidence.\n- The outlier kit is `beta`, and `oxygen recipes apply content-outlier-mining` installs only the keyword sweep; the creator watch applies separately against the same tables with `--table-ref`, and omitting those flags reports a table collision — the guard working.\n- Whether engagers flow automatically into outreach is not this playbook's call; stage 9 hands them over deliberately. Amplification from teammates' accounts is likewise a founder decision about the company's public name.\n\n## Resume point\n\n`oxygen recipes show founder-posting-system --json` and `oxygen knowledge page get content-strategy --json`, then `oxygen publishing posts list --json`, `oxygen publishing comments list --json` and `oxygen workflows list --json`. Start from what exists, never from scratch.\n";
 }, {
     readonly slug: "inbound-led-outbound";
     readonly title: "Playbook: Inbound-led outbound";
@@ -26,6 +26,6 @@ export declare const COPILOT_SKILL_SNAPSHOTS_GENERATED: readonly [{
     readonly slug: "signal-based-outbound";
     readonly title: "Playbook: Signal-based outbound";
     readonly sources: readonly ["oxygen-playbooks/playbooks/signal-based-outbound.md"];
-    readonly sha256: "20ac0c73c7c62c278962b32cc66cc7acdac689c3bb835c614f46d5c85f1e82a9";
-    readonly content: "---\nname: signal-based-outbound\ndescription: \"Installs the general buying-signal engine: arm company-level pulse sources and person-level engagement sources, expand a hit account into named buyers, gate, rank and score them against the ICP, and route only the qualified band into a capped sequence.\"\n---\n\n# Playbook: signal-based outbound\n\n## Motion in one sentence\n\nSources are armed against one segment in two lanes — **pulse** (a company acts: hiring surge, funding, tech install, news) and **engagement** (a person acts: website visit, profile view, post reaction, follow). The pulse lane expands a hit account into named buyers, the engagement lane resolves a person directly, both converge at the warm-lead gate where a CRM person is created, then rank into one daily queue, are scored against the ICP and split — the strongest to the founder's own hand, the qualified band into a capped sequence. The order matters because every step narrows: capture is wide, expansion is account-bound, resolution is identity-bound, ranking is intent-bound, the band gate is fit-bound, and only the last step contacts anyone.\n\nRecipes cover the engagement sources one at a time (`oxygen recipes show website-visitor-outreach --json`, `profile-viewer-outreach`, `linkedin-intent-to-signup`, `daily-warm-lead-queue`, `speed-to-lead`); the pulse lane has none and is stages 1–2. Every command here takes `--json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + registry | Knowledge Graph + Signals | `oxygen context resolve --purpose outbound_copy`; `oxygen knowledge page get icp`; `oxygen signals registry`; `oxygen signals list --since 7` | a filled `icp`; a written segment | — | none | `icp` reads `active`, not a stub; your types read `captureStatus: live` | a stub ICP, or a type you assumed exists that the registry lacks |\n| 1 | **Pulse — company signals** | Signals — signal search | `oxygen signals search plan --prompt \"<goal>\" --family hiring --scope market --last-days 30 --estimate` → `oxygen signals search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap>` | `--family` hiring/tech/funding/acquisition/news/job_change; `--scope market`, or `watch_list --domains` | the plan's own `estimated_credits`; `--max-pages` defaults to 1; a standing harvest adds `--bind-feed --every daily@9 --max-credits-per-cycle <cap>` | `pulse-harvest`: paid, human, per run; `--bind-feed` is a **second**, standing grant | the plan's `routes[]`, `filter_application`, `schedulable`; then `oxygen feeds deliveries --table <signals_table>` | `no_default_provider_chain`; `feed_not_incremental`; `basis` not `provider_count` |\n| 2 | **Accounts → buyers** | Tables | `oxygen people search plan --prompt \"<persona>\" --company-domains <csv> --max-per-company 3 --estimate` → `oxygen people search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap> --table <people_table>` | hit domains from `oxygen tables query <signals_table>`; persona titles and seniorities | `--max-per-company` ≤3; only domains whose event is inside the window | `persona-expansion`: paid, human, per run | the plan's `estimated_match_count.basis`; `oxygen tables query <people_table> --limit 25` | an account with no plausible persona — drop it, never loosen `--titles` |\n| 3 | Engagement capture | Signals — pull feeds + reveal webhook | `oxygen linkedin intent setup --account <sender_id> --post <social_id>`; `oxygen viewers import --account <sender_id>`; `oxygen followers import --account <sender_id>`; a reveal source POSTs the webhook, hand-proved by `oxygen signals record --event website_visit --external-event-id <id>` | a healthy sender; the composite `social_id`, not the URN; a de-anon source | the account's ingest budget; ~15 relations reads/day; ≤20 pages × 100 on `oxygen engagement engagers --post <social_id>` | `arm-capture`: human, once per sender — free, contacts nobody | `oxygen linkedin intent status`; `oxygen feeds list`; `oxygen viewers status --account <sender_id>` | feeds `paused`/`error`; sender bad in `oxygen senders health <sender_id>` |\n| 4 | **Warm-lead gate** | Records | `oxygen crm setup --live` once; per engagement type `oxygen blueprints apply crm-post-engager` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>`; pulse buyers via `oxygen crm assert` | `crm-website-visitor`, `crm-profile-viewer`, `crm-post-engager`, `crm-follower` — only where the source delivers | free per event under a positive per-delivery cap | `arm-router`: human per router; re-grant after every reapply | `oxygen workflows runs --workflow <workflow_id> --limit 10`; `oxygen crm activity timeline people <row_id>` | a router armed over a dark source — it only makes capture look live |\n| 5 | Rank | Signals | `oxygen signals leads-today --limit 25 --within-days 7`; narrative via `oxygen blueprints apply daily-gtm-digest --input-json '{...}'` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>` | the CRM people table as `source_tables` | `--within-days` ≤30, `--limit` ≤100; digest cap per cycle | `enable-digest`: human, standing spend | leads carry a type and an occurred-at | an empty queue with armed sources is a capture problem |\n| 6 | Assess | Tables | `oxygen columns add <people_table> --kind ai --key icp_fit --data-type jsonb --definition-json '{...}'` → `oxygen columns run <people_table> icp_fit --limit 10 --dry-run` → same `--all --background --approved --max-credits <cap>` → `oxygen tables auto-run set <people_table> --columns icp_fit --max-credits <cap>` | the `icp` page; identified rows only | pilot ≤10 rows; the auto-run cap is per batch, rows past it skip with `credit_limit_reached` | `run-assessment`: paid, human; the auto-run is scoped standing permission | `oxygen cells inspect <people_table> <row_id> icp_fit`, one per band | generic reasons: fix the ICP page, not the prompt |\n| 7 | Route (band gate) | Sequences | own-network `oxygen linkedin intent autoenroll --account <sender_id> --sequence <slug> --kinds profile_viewers,followers` (previews) → same `--approved --max-enrolls-per-day <n>`; table-backed `oxygen sequences enroll <slug> --leads-file leads.json --exclude-contacted` | only rows past the band gate | at or below the sender's effective daily cap; one attempt per person | `arm-routing`: human — the grant reaches people captured later | the preview's audience split; `oxygen sequences enrollments <slug>` | `--include-existing-network` proposed unasked; most leads `bound_to_other_sender` |\n| 8 | Send | Sequences | `oxygen sequences create --name \"Signal-based outbound\" --slug signal-based-outbound --steps-file steps.json --table <people_table> --url-column linkedin_url --max-new-enrollments-per-day 10 --exclude-contacted` → `oxygen sequences update signal-based-outbound --senders <sender_id>` → `oxygen sequences start signal-based-outbound` → same `--approved --max-live-sends <n>` | copy naming the observable event, never an inferred motive | a new sender is floored at 5 invites and 5 messages a day for its first three days | `create-sequence`: human, every call | `oxygen sequences analytics --sequence signal-based-outbound --range 30d` | sender `restricted` or paused; reply-stop fired |\n| 9 | Replies → CRM | Records | `oxygen crm automation set crm-lead-stage-router --armed --live --approved --max-credits 1` | — | free per event | none beyond arming | `oxygen crm automation rules`; `oxygen crm pipeline` | a reply that moved no stage — a disarmed router never re-arms itself |\n| 10 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id>` → same `--approved`; `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\"` | receipts, delivery ledger, analytics | weekly; one rule | canonical pages route through the proposal queue | `oxygen knowledge lint` | a claim with no receipt behind it |\n\n## Numeric guardrails\n\n- **Weights are product data, not a workspace knob.** `oxygen signals registry --json` returns each type's `sourceWeight` — today `website_visit` 100 > `profile_view` 60 > `post_reaction` 40 > `new_follower` 20, all `engagement` family, all live. Never hardcode one, and never claim one for a type the registry lacks: the pulse families have none.\n- **Pulse:** `--max-pages` defaults to 1; the only honest prices are the plan's `estimated_credits` range and `oxygen tools get <tool_id> --json`. Quote a match count only when `estimated_match_count.basis` is `provider_count`. `--last-days` is the event window: a six-month-old hiring post is history, not intent.\n- **Expansion:** `--max-per-company` ≤3, `--require-email` where the lane sends email, and only accounts whose event is in the window. One account never becomes a list.\n- **Queue:** `signals leads-today` defaults to 7 days (`--within-days`, max 30) and 25 leads (`--limit`, max 100). Work the top 5–10 a morning.\n- **Bands:** strong 80–100 = the founder's own message, never automated; qualified 50–79 = the capped sequence; weak and out ≤49 = keep the evidence, send nothing; unknown = hold. Fit is company/segment fit, size/stage and person/persona fit; strength and recency set *order*, never *fit*.\n- **Ceilings and sending:** a trigger, feed or auto-run armed without an explicit `--max-credits` inherits the plan tier's per-delivery default (the preview prints which). `--max-new-enrollments-per-day` bounds first touches, the grant's `--max-enrolls-per-day` defaults to the sender's warm-up-ramped cap, and the 5-invite / 5-message floor for a new sender's first three days is not bypassable.\n- **Identity before scoring:** a row with neither an email nor a canonical `linkedin.com/in/` URL cannot pass the warm-lead gate and is not worth assessing. Missing evidence is never positive evidence.\n\n## Gate spec\n\n**The warm-lead gate (does a person exist).** A raw signal never creates a CRM person. In the engagement lane the armed `crm-*` router for that exact type does, from a stable identity — email plus domain for `website_visit` and signup, a canonical LinkedIn URL for the rest. Two consequences: the engagement→signal bridge **attaches only to people who already have a CRM record** and never creates one, so a capture armed without its router produces rows nobody can rank (writers before signals); and pulse rows carry no registered type, so no router fires on them. In the pulse lane the gate is stage 2 plus an explicit `oxygen crm assert --json` — a hit account becomes a person only once a named buyer with a verified identity is resolved against it. A company event is never itself a lead, installation is never permission, and a signal is a prioritization input: never consent, never proof of intent.\n\n**The band gate (who gets contacted).** The assessment column returns `{ score, band, segment, persona, confidence, reason, disqualifiers, missing_evidence }`. Enforce it where enrollment happens, never in a display formula — row queries cannot filter on formula columns, so filter on the stored JSON plus a null routing status and re-check in the routing step. A person advances only when the band is `qualified`, the score sits inside it, confidence is high or medium, the segment is recognised, `disqualifiers` is empty, person and employer evidence are complete, the identity is canonical, `do_not_contact` is not true, and no prior routing status exists. Nothing bypasses it: never `oxygen sequences enroll <slug> --from-table --json` against a raw signal or expansion table, and never treat `oxygen signals leads-today --json` as an enrollment source — it ranks by strength then recency and does **not** score fit.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Attended Copilot | Unattended run |\n| --- | --- | --- | --- |\n| kit apply (`oxygen recipes apply <slug> --dry-run`, then without it) | 0-credit install; workflows land disabled | auto-approvable write | n/a |\n| `pulse-harvest` | one priced company-signal harvest into a table | human card | its `--max-credits` |\n| `bind-feed` | the recurring harvest — standing, separate from the run | human card; re-asked when `--every` or the cap changes | its `--max-credits-per-cycle` |\n| `persona-expansion` | one priced people search scoped to the hit domains | human card | its `--max-credits` |\n| `arm-capture` | the standing read of the account's own viewers, followers, connections, posts | human card, per sender | never armed unattended |\n| `arm-router` | a `crm-*` router's free internal writes | auto-approvable write | its per-delivery cap |\n| `enable-digest` | the daily digest's recurring synthesis | human card | its per-cycle cap |\n| `run-assessment` | one paid column run, then the standing auto-run | human card; the auto-run is scoped standing permission | its per-batch cap |\n| `arm-routing` | enrolling captured people, including people captured later | human card — it reaches strangers | its `--max-enrolls-per-day` |\n| `create-sequence` | creating, attaching a sender to, and starting the sequence | human card, every call — `external_write` is never waived | its `--max-live-sends` |\n| canonical wiki edits | voice, brand, positioning | a proposal a human approves | never |\n\nReads need no approval: `recipes show`, `signals registry|list|leads-today`, `signals search plan`, `people search plan`, `feeds list|deliveries`, `tables query`, `cells inspect`, `workflows runs`, `senders health`, and every preview or `--dry-run`.\n\n## Failure modes\n\n- **Pulse rows are a table, not the stream.** The registry holds four engagement types and no pulse type, so a hiring / funding / tech / news harvest sourced natively with `oxygen signals search run` lands as table rows that no router subscribes to and that never reach `signals leads-today`; work them from the table (stages 1–2), which is shipped sourcing, not a workaround. Check: harvest, then `oxygen signals list --json` — unchanged. Correction: expand, score and enroll from the table (stages 2–7); never promise a trigger on them.\n- **Treating a company event as a lead.** A funding round is an account fact; nobody there raised a hand. Correction: stage 2 first, one persona at a time, with copy naming the event rather than an invented intent.\n- **`no_default_provider_chain` is an answer.** Market-wide `job_change` refuses by design — use `--scope watch_list --domains <csv>` or name a provider, never a substitute family. Likewise market-wide funding and acquisition are one-shot: read `schedulable` before offering a cadence, or the bind returns `feed_not_incremental`.\n- **Quoting a count nobody published.** Render a number only for `basis: \"provider_count\"` and name the probe tool.\n- **Expansion that fills a quota.** Loosening `--titles` or raising `--max-per-company` until the count looks healthy buys a list, not a signal lane. Drop the account instead.\n- **The bridge attaches; it never creates.** A viewer or engager with no CRM record produces no signal — capture rows accrue while `oxygen signals list --json` stays flat. Correction: arm that type's `crm-*` router first. The mirror failure is a router armed over a dark source: free, silent, and it only makes capture look live — compare `oxygen workflows runs --workflow <workflow_id> --limit 10 --json` with the source's own status read.\n- **Suppression is keyed on LinkedIn provider ids**, so email-only reveals surface unchecked — check do-not-contact, competitors, customers and open deals by hand before the first send on a website or pulse lane.\n- **Double-counted redeliveries.** `oxygen signals record --json` is idempotent on `--external-event-id`; a relay that omits it re-counts every retry.\n- **Revision-bound authority.** Reapplying a blueprint publishes a new **disabled** revision; the standing approval must be granted again.\n- **Ceilings, not bugs.** Named viewers are a fraction of real views and de-anonymization resolves a minority of traffic; re-arming widens neither.\n\n## Data-quality checks (after every cycle)\n\n1. `oxygen signals list --since 7 --limit 100 --json` — events by type. A type at zero whose source is armed is a dark source: inaccessible, never absence.\n2. `oxygen feeds list --json`, then `oxygen feeds deliveries --table <table> --json` — any feed `error` or `exhausted`, any `rejected` delivery.\n3. Pulse table: every row has a `signal_date` inside the window and an openable `source_url`; stale dates are history and must not be expanded.\n4. `oxygen tables query <people_table> --limit 100 --json` — rows with neither an email nor a canonical `linkedin.com/in/` URL are held, never given an invented identity. Dedupe keys are `provider_id` (people), `event_key` (touchpoints) and the plan `upsert_key` (pulse).\n5. `oxygen budget list --json` and `oxygen limits show --json` — the resolved thresholds still match what you armed.\n\n## Learning loop\n\n- **What auto-files:** the table delivery ledger, workflow run receipts, enrollment receipts, sequence analytics, CRM stage changes and reply classifications.\n- **What to synthesise weekly:** positive-reply rate *by signal type and by lane* (a funding hit and a profile view are not one channel), by source and by band; band precision; time from event to first touch. `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id> --json`, read it, then re-run `--approved`.\n- **One rule per loop:** the band threshold, the segment, the pulse `--last-days` window, `--max-per-company`, one source on or off, or one cap — written with `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\" --json`; a canonical change files a proposal.\n- **What you cannot change:** a type's `sourceWeight`. There is no per-workspace weighting surface, and pulse families carry none, so their ordering is yours to define in the queue you work.\n- Define \"good\" before arming: a positive reply, a booked meeting, or a closed deal. A loop with no written definition of good is automation, not a loop.\n\n## Go-live checklist\n\n1. `oxygen signals registry --json` + `oxygen signals list --json` — the live types, weights, baseline; `oxygen knowledge page get icp --json` reads `active`, with the segment written beside it.\n2. `oxygen senders health <sender_id> --json` — one usable sender, its warm-up day and daily caps; `oxygen crm setup --live --json` once.\n3. Pulse: `oxygen signals search plan --json` read in full (routes, dropped filters, `schedulable`), then dry-run, then the approved live run under a cap.\n4. Expansion: `oxygen people search plan --company-domains <csv> --max-per-company 3 --estimate --json`, dry-run, then the approved live run into the people table.\n5. Engagement: arm only what you have (`oxygen linkedin intent setup --account <sender_id> --json`, `oxygen viewers import --account <sender_id> --json`, `oxygen followers import --account <sender_id> --json`, the reveal webhook), each verified by its own status read.\n6. Per armed type: `oxygen blueprints apply crm-profile-viewer --json` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap> --json`, confirmed by `oxygen crm activity timeline people <row_id> --json`.\n7. `oxygen signals leads-today --limit 10 --json` returns people carrying a type; `oxygen columns run <people_table> icp_fit --limit 10 --dry-run --json`, then the approved run, then one assessment read per band.\n8. `oxygen sequences start signal-based-outbound --json` previewed, then `--approved --max-live-sends <n>`; `oxygen linkedin intent autoenroll --account <sender_id> --sequence signal-based-outbound --json` previewed — read the audience split — then `--approved` with explicit caps.\n9. `oxygen crm automation rules --json` shows `crm-lead-stage-router` armed; `oxygen budget list --json` and `oxygen limits show --json` match what you armed; log it with `oxygen knowledge log append --event note --slug campaign-learnings --summary \"...\" --json`.\n\n## Open questions (state them, do not resolve them)\n\n- Pulse and product stream emission is unfinished: the registry carries no hiring / funding / tech / acquisition / news / product-usage type, so those harvests are table data nothing subscribes to. Stages 1–2 source and expand pulse hits natively and work them from the table; the stream/registry half is the unfinished end state.\n- Because pulse families carry no `sourceWeight`, the queue cannot interleave a funding hit with a profile view. Cross-lane ranking is a human judgement today; never present it as one ordered list the product produced.\n- `signals registry` is a read-only snapshot derived from code constants — no registry or subscription objects exist, so \"a workflow triggers on a signal\" means a blueprint bound to one type.\n- The suppression identity gap (LinkedIn provider ids only) leaves email-only reveals unchecked, and no `post_comment` type exists, so a comment ranks as a reaction.\n- No CLI command mints a self-serve inbound URL for a de-anonymization vendor, and no `/signals` web route renders the stream or the queue — both are parity gaps to record, not journeys to describe.\n- \"Arm every source at once\" is not ratified strategy. Start with one lane, one source and one bounded segment with a named downstream owner.\n\n## Resume point\n\n`oxygen signals registry --json` — which types exist, which are live, and where a pulse family's absence from the stream becomes visible. Then `oxygen signals list --json` (arriving), `oxygen feeds list --json` (armed), `oxygen tables list --json` (signal and expansion tables), `oxygen crm automation rules --json` plus `oxygen workflows list --json` (resolving and routing), and `oxygen sequences list --json` (sending). Start there, never from scratch.\n";
+    readonly sha256: "2e7aeef6d3a2eaee0820d273feb60a0fa8a466a4adee4e009a5737534c64bf9b";
+    readonly content: "---\nname: signal-based-outbound\ndescription: \"Installs the general buying-signal engine: arm company-level pulse sources and person-level engagement sources, expand a hit account into named buyers, gate, rank and score them against the ICP, and route only the qualified band into a capped sequence.\"\n---\n\n# Playbook: signal-based outbound\n\n## Motion in one sentence\n\nSources are armed against one segment in two lanes — **pulse** (a company acts: hiring surge, funding, tech install, news) and **engagement** (a person acts: website visit, profile view, post reaction, follow). The pulse lane expands a hit account into named buyers, the engagement lane resolves a person directly, both converge at the warm-lead gate where a CRM person is created, then rank into one daily queue, are scored against the ICP and split — the strongest to the founder's own hand, the qualified band into a capped sequence. The order matters because every step narrows: capture is wide, expansion is account-bound, resolution is identity-bound, ranking is intent-bound, the band gate is fit-bound, and only the last step contacts anyone.\n\nRecipes cover the engagement sources one at a time (`oxygen recipes show website-visitor-outreach --json`, `profile-viewer-outreach`, `linkedin-intent-to-signup`, `daily-warm-lead-queue`, `speed-to-lead`); the pulse lane has none and is stages 1–2. Every command here takes `--json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + registry | Knowledge Graph + Signals | `oxygen context resolve --purpose outbound_copy`; `oxygen knowledge page get icp`; `oxygen signals registry`; `oxygen signals list --since 7` | a filled `icp`; a written segment | — | none | `icp` reads `active`, not a stub; your types read `captureStatus: live` | a stub ICP, or a type you assumed exists that the registry lacks |\n| 1 | **Pulse — company signals** | Signals — signal search | `oxygen signals search plan --prompt \"<goal>\" --family hiring --scope market --last-days 30 --estimate` → `oxygen signals search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap>` | `--family` hiring/tech/funding/acquisition/news/job_change; `--scope market`, or `watch_list --domains` | the plan's own `estimated_credits`; `--max-pages` defaults to 1; a standing harvest adds `--bind-feed --every daily@9 --max-credits-per-cycle <cap>` | `pulse-harvest`: paid, human, per run; `--bind-feed` is a **second**, standing grant | the plan's `routes[]`, `filter_application`, `schedulable`; then `oxygen feeds deliveries --table <signals_table>` | `no_default_provider_chain`; `feed_not_incremental`; `basis` not `provider_count` |\n| 2 | **Accounts → buyers** | Tables | `oxygen people search plan --prompt \"<persona>\" --company-domains <csv> --max-per-company 3 --estimate` → `oxygen people search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap> --table <people_table>` | hit domains from `oxygen tables query <signals_table>`; persona titles and seniorities | `--max-per-company` ≤3; only domains whose event is inside the window | `persona-expansion`: paid, human, per run | the plan's `estimated_match_count.basis`; `oxygen tables query <people_table> --limit 25` | an account with no plausible persona — drop it, never loosen `--titles` |\n| 3 | Engagement capture | Signals — pull feeds + reveal webhook | `oxygen linkedin intent setup --account <sender_id> --post <social_id>`; `oxygen viewers import --account <sender_id>`; `oxygen followers import --account <sender_id>`; a reveal source POSTs the webhook, hand-proved by `oxygen signals record --event website_visit --external-event-id <id>` | a healthy sender; the composite `social_id`, not the URN; a de-anon source | the account's ingest budget; ~15 relations reads/day; ≤20 pages × 100 on `oxygen engagement engagers --post <social_id>` | `arm-capture`: human, once per sender — free, contacts nobody | `oxygen linkedin intent status`; `oxygen feeds list`; `oxygen viewers status --account <sender_id>` (reads both lanes; `stalled` names `oxygen feeds resume <id>`) | feeds `paused`/`error`; `viewers status` `stalled`/`unbound`; sender bad in `oxygen senders health <sender_id>` |\n| 4 | **Warm-lead gate** | Records | `oxygen crm setup --live` once; per engagement type `oxygen blueprints apply crm-post-engager` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>`; pulse buyers via `oxygen crm assert` | `crm-website-visitor`, `crm-profile-viewer`, `crm-post-engager`, `crm-follower` — only where the source delivers | free per event under a positive per-delivery cap | `arm-router`: human per router; re-grant after every reapply | `oxygen workflows runs --workflow <workflow_id> --limit 10`; `oxygen crm activity timeline people <row_id>` | a router armed over a dark source — it only makes capture look live |\n| 5 | Rank | Signals | `oxygen signals leads-today --limit 25 --within-days 7`; narrative via `oxygen blueprints apply daily-gtm-digest --input-json '{...}'` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>` | the CRM people table as `source_tables` | `--within-days` ≤30, `--limit` ≤100; digest cap per cycle | `enable-digest`: human, standing spend | leads carry a type and an occurred-at | an empty queue with armed sources is a capture problem |\n| 6 | Assess | Tables | `oxygen columns add <people_table> --kind ai --key icp_fit --data-type jsonb --definition-json '{...}'` → `oxygen columns run <people_table> icp_fit --limit 10 --dry-run` → same `--all --background --approved --max-credits <cap>` → `oxygen tables auto-run set <people_table> --columns icp_fit --max-credits <cap>` | the `icp` page; identified rows only | pilot ≤10 rows; the auto-run cap is per batch, rows past it skip with `credit_limit_reached` | `run-assessment`: paid, human; the auto-run is scoped standing permission | `oxygen cells inspect <people_table> <row_id> icp_fit`, one per band | generic reasons: fix the ICP page, not the prompt |\n| 7 | Route (band gate) | Sequences | own-network `oxygen linkedin intent autoenroll --account <sender_id> --sequence <slug> --kinds profile_viewers,followers` (previews) → same `--approved --max-enrolls-per-day <n>`; table-backed `oxygen sequences enroll <slug> --leads-file leads.json --exclude-contacted` | only rows past the band gate | at or below the sender's effective daily cap; one attempt per person | `arm-routing`: human — the grant reaches people captured later | the preview's audience split; `oxygen sequences enrollments <slug>` | `--include-existing-network` proposed unasked; most leads `bound_to_other_sender` |\n| 8 | Send | Sequences | `oxygen sequences create --name \"Signal-based outbound\" --slug signal-based-outbound --steps-file steps.json --table <people_table> --url-column linkedin_url --max-new-enrollments-per-day 10 --exclude-contacted` → `oxygen sequences update signal-based-outbound --senders <sender_id>` → `oxygen sequences start signal-based-outbound` → same `--approved --max-live-sends <n>` | copy naming the observable event, never an inferred motive | a new sender is floored at 5 invites and 5 messages a day for its first three days | `create-sequence`: human, every call | `oxygen sequences analytics --sequence signal-based-outbound --range 30d` | sender `restricted` or paused; reply-stop fired |\n| 9 | Replies → CRM | Records | `oxygen crm automation set crm-lead-stage-router --armed --live --approved --max-credits 1` | — | free per event | none beyond arming | `oxygen crm automation rules`; `oxygen crm pipeline` | a reply that moved no stage — a disarmed router never re-arms itself |\n| 10 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id>` → same `--approved`; `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\"` | receipts, delivery ledger, analytics | weekly; one rule | canonical pages route through the proposal queue | `oxygen knowledge lint` | a claim with no receipt behind it |\n\n## Numeric guardrails\n\n- **Weights are product data, not a workspace knob.** `oxygen signals registry --json` returns each type's `sourceWeight` — today `website_visit` 100 > `profile_view` 60 > `post_reaction` 40 > `new_follower` 20, all `engagement` family, all live. Never hardcode one, and never claim one for a type the registry lacks: the pulse families have none.\n- **Pulse:** `--max-pages` defaults to 1; the only honest prices are the plan's `estimated_credits` range and `oxygen tools get <tool_id> --json`. Quote a match count only when `estimated_match_count.basis` is `provider_count`. `--last-days` is the event window: a six-month-old hiring post is history, not intent.\n- **Expansion:** `--max-per-company` ≤3, `--require-email` where the lane sends email, and only accounts whose event is in the window. One account never becomes a list.\n- **Queue:** `signals leads-today` defaults to 7 days (`--within-days`, max 30) and 25 leads (`--limit`, max 100). Work the top 5–10 a morning.\n- **Bands:** strong 80–100 = the founder's own message, never automated; qualified 50–79 = the capped sequence; weak and out ≤49 = keep the evidence, send nothing; unknown = hold. Fit is company/segment fit, size/stage and person/persona fit; strength and recency set *order*, never *fit*.\n- **Ceilings and sending:** a trigger, feed or auto-run armed without an explicit `--max-credits` inherits the plan tier's per-delivery default (the preview prints which). `--max-new-enrollments-per-day` bounds first touches, the grant's `--max-enrolls-per-day` defaults to the sender's warm-up-ramped cap, and the 5-invite / 5-message floor for a new sender's first three days is not bypassable.\n- **Identity before scoring:** a row with neither an email nor a canonical `linkedin.com/in/` URL cannot pass the warm-lead gate and is not worth assessing. Missing evidence is never positive evidence.\n\n## Gate spec\n\n**The warm-lead gate (does a person exist).** A raw signal never creates a CRM person. In the engagement lane the armed `crm-*` router for that exact type does, from a stable identity — email plus domain for `website_visit` and signup, a canonical LinkedIn URL for the rest. Two consequences: the engagement→signal bridge **attaches only to people who already have a CRM record** and never creates one, so a capture armed without its router produces rows nobody can rank (writers before signals); and pulse rows carry no registered type, so no router fires on them. In the pulse lane the gate is stage 2 plus an explicit `oxygen crm assert --json` — a hit account becomes a person only once a named buyer with a verified identity is resolved against it. A company event is never itself a lead, installation is never permission, and a signal is a prioritization input: never consent, never proof of intent.\n\n**The band gate (who gets contacted).** The assessment column returns `{ score, band, segment, persona, confidence, reason, disqualifiers, missing_evidence }`. Enforce it where enrollment happens, never in a display formula — row queries cannot filter on formula columns, so filter on the stored JSON plus a null routing status and re-check in the routing step. A person advances only when the band is `qualified`, the score sits inside it, confidence is high or medium, the segment is recognised, `disqualifiers` is empty, person and employer evidence are complete, the identity is canonical, `do_not_contact` is not true, and no prior routing status exists. Nothing bypasses it: never `oxygen sequences enroll <slug> --from-table --json` against a raw signal or expansion table, and never treat `oxygen signals leads-today --json` as an enrollment source — it ranks by strength then recency and does **not** score fit.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Attended Copilot | Unattended run |\n| --- | --- | --- | --- |\n| kit apply (`oxygen recipes apply <slug> --dry-run`, then without it) | 0-credit install; workflows land disabled | auto-approvable write | n/a |\n| `pulse-harvest` | one priced company-signal harvest into a table | human card | its `--max-credits` |\n| `bind-feed` | the recurring harvest — standing, separate from the run | human card; re-asked when `--every` or the cap changes | its `--max-credits-per-cycle` |\n| `persona-expansion` | one priced people search scoped to the hit domains | human card | its `--max-credits` |\n| `arm-capture` | the standing read of the account's own viewers, followers, connections, posts | human card, per sender | never armed unattended |\n| `arm-router` | a `crm-*` router's free internal writes | auto-approvable write | its per-delivery cap |\n| `enable-digest` | the daily digest's recurring synthesis | human card | its per-cycle cap |\n| `run-assessment` | one paid column run, then the standing auto-run | human card; the auto-run is scoped standing permission | its per-batch cap |\n| `arm-routing` | enrolling captured people, including people captured later | human card — it reaches strangers | its `--max-enrolls-per-day` |\n| `create-sequence` | creating, attaching a sender to, and starting the sequence | human card, every call — `external_write` is never waived | its `--max-live-sends` |\n| canonical wiki edits | voice, brand, positioning | a proposal a human approves | never |\n\nReads need no approval: `recipes show`, `signals registry|list|leads-today`, `signals search plan`, `people search plan`, `feeds list|deliveries`, `tables query`, `cells inspect`, `workflows runs`, `senders health`, and every preview or `--dry-run`.\n\n## Failure modes\n\n- **Pulse rows are a table, not the stream.** The registry holds four engagement types and no pulse type, so a hiring / funding / tech / news harvest sourced natively with `oxygen signals search run` lands as table rows that no router subscribes to and that never reach `signals leads-today`; work them from the table (stages 1–2), which is shipped sourcing, not a workaround. Check: harvest, then `oxygen signals list --json` — unchanged. Correction: expand, score and enroll from the table (stages 2–7); never promise a trigger on them.\n- **Treating a company event as a lead.** A funding round is an account fact; nobody there raised a hand. Correction: stage 2 first, one persona at a time, with copy naming the event rather than an invented intent.\n- **`no_default_provider_chain` is an answer.** Market-wide `job_change` refuses by design — use `--scope watch_list --domains <csv>` or name a provider, never a substitute family. Likewise market-wide funding and acquisition are one-shot: read `schedulable` before offering a cadence, or the bind returns `feed_not_incremental`.\n- **Quoting a count nobody published.** Render a number only for `basis: \"provider_count\"` and name the probe tool.\n- **Expansion that fills a quota.** Loosening `--titles` or raising `--max-per-company` until the count looks healthy buys a list, not a signal lane. Drop the account instead.\n- **The bridge attaches; it never creates.** A viewer or engager with no CRM record produces no signal — capture rows accrue while `oxygen signals list --json` stays flat. Correction: arm that type's `crm-*` router first. The mirror failure is a router armed over a dark source: free, silent, and it only makes capture look live — compare `oxygen workflows runs --workflow <workflow_id> --limit 10 --json` with the source's own status read.\n- **Suppression is keyed on LinkedIn provider ids**, so email-only reveals surface unchecked — check do-not-contact, competitors, customers and open deals by hand before the first send on a website or pulse lane.\n- **Double-counted redeliveries.** `oxygen signals record --json` is idempotent on `--external-event-id`; a relay that omits it re-counts every retry.\n- **Revision-bound authority.** Reapplying a blueprint publishes a new **disabled** revision; the standing approval must be granted again.\n- **Ceilings, not bugs.** Named viewers are a fraction of real views and de-anonymization resolves a minority of traffic; re-arming widens neither.\n\n## Data-quality checks (after every cycle)\n\n1. `oxygen signals list --since 7 --limit 100 --json` — events by type. A type at zero whose source is armed is a dark source: inaccessible, never absence.\n2. `oxygen feeds list --json`, then `oxygen feeds deliveries --table <table> --json` — any feed `error` or `exhausted`, any `rejected` delivery.\n3. Pulse table: every row has a `signal_date` inside the window and an openable `source_url`; stale dates are history and must not be expanded.\n4. `oxygen tables query <people_table> --limit 100 --json` — rows with neither an email nor a canonical `linkedin.com/in/` URL are held, never given an invented identity. Dedupe keys are `provider_id` (people), `event_key` (touchpoints) and the plan `upsert_key` (pulse).\n5. `oxygen budget list --json` and `oxygen limits show --json` — the resolved thresholds still match what you armed.\n\n## Learning loop\n\n- **What auto-files:** the table delivery ledger, workflow run receipts, enrollment receipts, sequence analytics, CRM stage changes and reply classifications.\n- **What to synthesise weekly:** positive-reply rate *by signal type and by lane* (a funding hit and a profile view are not one channel), by source and by band; band precision; time from event to first touch. `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id> --json`, read it, then re-run `--approved`.\n- **One rule per loop:** the band threshold, the segment, the pulse `--last-days` window, `--max-per-company`, one source on or off, or one cap — written with `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\" --json`; a canonical change files a proposal.\n- **What you cannot change:** a type's `sourceWeight`. There is no per-workspace weighting surface, and pulse families carry none, so their ordering is yours to define in the queue you work.\n- Define \"good\" before arming: a positive reply, a booked meeting, or a closed deal. A loop with no written definition of good is automation, not a loop.\n\n## Go-live checklist\n\n1. `oxygen signals registry --json` + `oxygen signals list --json` — the live types, weights, baseline; `oxygen knowledge page get icp --json` reads `active`, with the segment written beside it.\n2. `oxygen senders health <sender_id> --json` — one usable sender, its warm-up day and daily caps; `oxygen crm setup --live --json` once.\n3. Pulse: `oxygen signals search plan --json` read in full (routes, dropped filters, `schedulable`), then dry-run, then the approved live run under a cap.\n4. Expansion: `oxygen people search plan --company-domains <csv> --max-per-company 3 --estimate --json`, dry-run, then the approved live run into the people table.\n5. Engagement: arm only what you have (`oxygen linkedin intent setup --account <sender_id> --json`, `oxygen viewers import --account <sender_id> --json`, `oxygen followers import --account <sender_id> --json`, the reveal webhook), each verified by its own status read.\n6. Per armed type: `oxygen blueprints apply crm-profile-viewer --json` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap> --json`, confirmed by `oxygen crm activity timeline people <row_id> --json`.\n7. `oxygen signals leads-today --limit 10 --json` returns people carrying a type; `oxygen columns run <people_table> icp_fit --limit 10 --dry-run --json`, then the approved run, then one assessment read per band.\n8. `oxygen sequences start signal-based-outbound --json` previewed, then `--approved --max-live-sends <n>`; `oxygen linkedin intent autoenroll --account <sender_id> --sequence signal-based-outbound --json` previewed — read the audience split — then `--approved` with explicit caps.\n9. `oxygen crm automation rules --json` shows `crm-lead-stage-router` armed; `oxygen budget list --json` and `oxygen limits show --json` match what you armed; log it with `oxygen knowledge log append --event note --slug campaign-learnings --summary \"...\" --json`.\n\n## Open questions (state them, do not resolve them)\n\n- Pulse and product stream emission is unfinished: the registry carries no hiring / funding / tech / acquisition / news / product-usage type, so those harvests are table data nothing subscribes to. Stages 1–2 source and expand pulse hits natively and work them from the table; the stream/registry half is the unfinished end state.\n- Because pulse families carry no `sourceWeight`, the queue cannot interleave a funding hit with a profile view. Cross-lane ranking is a human judgement today; never present it as one ordered list the product produced.\n- `signals registry` is a read-only snapshot derived from code constants — no registry or subscription objects exist, so \"a workflow triggers on a signal\" means a blueprint bound to one type.\n- The suppression identity gap (LinkedIn provider ids only) leaves email-only reveals unchecked, and no `post_comment` type exists, so a comment ranks as a reaction.\n- No CLI command mints a self-serve inbound URL for a de-anonymization vendor, and no `/signals` web route renders the stream or the queue — both are parity gaps to record, not journeys to describe.\n- \"Arm every source at once\" is not ratified strategy. Start with one lane, one source and one bounded segment with a named downstream owner.\n\n## Resume point\n\n`oxygen signals registry --json` — which types exist, which are live, and where a pulse family's absence from the stream becomes visible. Then `oxygen signals list --json` (arriving), `oxygen feeds list --json` (armed), `oxygen tables list --json` (signal and expansion tables), `oxygen crm automation rules --json` plus `oxygen workflows list --json` (resolving and routing), and `oxygen sequences list --json` (sending). Start there, never from scratch.\n";
 }];