@oxygen-agent/cli 1.1010.650 → 1.1010.905

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

@@ -14,15 +14,15 @@ export const COPILOT_SKILL_SNAPSHOTS_GENERATED = [
         slug: "tam-sourcing",
         title: "Playbook: TAM sourcing",
         sources: ["oxygen-playbooks/playbooks/tam-sourcing.md"],
-        sha256: "697e0092186013444a53b69a52d52cd164c6dc75a3d7fa1aa9026d92078cf11d",
-        content: "---\nname: tam-sourcing\ndescription: \"Turn the workspace ICP into a sourced, scored, deduplicated account map and the buyer personas at those accounts — a bounded sample first, coverage widened only on segments the sample proved — then hand it to outbound. Load it when the whole market map is the ask.\"\n---\n\n# Playbook: TAM sourcing\n\n## Motion in one sentence\n\nThe ICP compiles into a provider-grounded sourcing plan, one bounded sample of accounts is sourced live, deduplicated and filled, every account is scored against that same ICP with its evidence on the row, the sample's band distribution decides which segments deserve coverage, coverage widens one segment at a time through the same gate, buyer personas are sourced only at accounts that passed it, and the accepted map is handed to an outbound motion. The sample before the coverage is the play; the order is companies → fit → people, never people first.\n\nRecipe and kit: `oxygen recipes show icp-to-account-map --json` (its `journey.slug` is `tam-sourcing`); the companion it hands to is `oxygen recipes show outbound-pilot-50 --json`. Read both first — `recipes show` reports which stages this workspace already has.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context | Knowledge Graph | `oxygen knowledge page get icp --json`; `oxygen knowledge page get offers --json` (`oxygen knowledge status` reports the local CLI mirror, not the workspace) | `company`, `offering`, `icp` pages | — | none | pages `active`, not seed stubs; the ICP names segment, geography, size **and who is out** | a stub ICP, or no exclusion clause |\n| 1 | Plan | Tables — company-search planner | `oxygen tools enums get blitzapi industry --query <segment> --json` → `oxygen companies search plan --prompt \"<ICP sentence with EXCLUDE clause>\" --filters-json '<typed filters>' --estimate --json` | one ICP sentence; exact enum strings | `--target-count` ceiling 50,000 per plan | none — no provider call, no spend | `filter_application[].dropped`, `provider_availability`, `estimated_match_count.basis`, `recommended_live_route_id` | a filter you need lands in `dropped_constraints`; a managed primary reads `degraded: true` |\n| 2 | Scaffold | Tables — kit stage `account-sourcing` | `oxygen recipes apply icp-to-account-map --dry-run --json` → the same without `--dry-run` | — | 0 credits, no provider call, no external write | `kit-apply`: human, once for the kit | `oxygen tables describe <accounts> --json` shows `company_name`, `domain`, `company_linkedin_url`, `source`, `fit_notes` | a stage already installed — never re-install it |\n| 3 | Source the sample | Tables — company search | `oxygen companies search run --plan-json <plan> --route-id <route_id> --table <accounts> --upsert-key domain --mode dry_run --json` → `--mode live --max-pages 1 --max-credits <cap> --approved` | the plan you actually read | one page, the recipe's 25-account pilot; `<cap>` from the route estimate | `source-sample`: paid, human, server-enforced | `oxygen table-ingestions wait <ingestion_run_id> --json`; `oxygen tables query <accounts> --limit 25 --json` | `spend_cap_too_low`; near-zero rows; `data_status` still `pending` — the verdict is on the ingestion run, not the queue receipt |\n| 4 | Clean | Tables | `oxygen tables dedupe <accounts> --on domain --normalize domain --json` → `--apply --approved --merge-values fill-empty`; `oxygen tables auto-dedupe set <accounts> --on domain --normalize domain --json`; `oxygen companies enrich preview <accounts> --missing-fields domain,linkedin_url,headcount,industry --json` → `oxygen companies enrich run <accounts> --mode live --max-credits <cap> --approved --json` | `domain`; rows with firmographic gaps | `--scan-limit` 50,000 / 200,000 cap; enrichment scoped by its preview | dedupe apply: free internal delete, losers kept in row history. `fill-firmographics`: paid, human | dedupe preview reruns to 0 groups; `oxygen cells inspect <accounts> <row_id> domain --json` carries provider and cost | groups that are not one company; a provider in the preview reading blocked or benched |\n| 5 | Score | Tables — kit stage `icp-fit-scoring` | `oxygen columns run <accounts> icp_fit_score --limit 10 --dry-run --json` → `--limit 25 --background --approved --max-credits <cap> --json` | the `icp` page (auto-prepended), `company_name`, `domain` | the sample only; `--limit` defaults to 10 | `score-accounts`: paid, human for the cap | `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` — one high, one medium, one low, each `evidence` citing a checkable fact | bands spread evenly, or evidence reads generic: fix the ICP page, not the prompt |\n| 6 | Widen | Tables — company search, again | re-plan the surviving segment, then the stage-3 live command with the new plan and `--max-pages <n>` | segments whose sample cleared the widen bar | one segment per widen; auto-pagination stops at the cap | `widen-coverage`: paid, human, **per segment** | the `auto_paged` block; `oxygen lead-sourcing audit <accounts> --spec ./icp-spec.json --json` | a segment whose sample landed mostly `low` — more pages of a bad filter is more junk |\n| 7 | Personas | Tables — Blueprint `contact-finding` | `oxygen blueprints apply contact-finding --json` → `oxygen people search plan --company-domains <accepted-domains> --titles \"<persona>\" --title-match exact --max-per-company <n> --json` → `oxygen people search run --plan-json <plan> --route-id <route_id> --table <contacts> --upsert-key linkedin_url --mode live --max-credits <cap> --approved --json` | the accepted-domain list from the gate below; one persona title set | `--max-per-company <n>`; upsert dedupes on `linkedin_url` | `source-personas`: paid, human | `oxygen tables query <contacts> --limit 25 --json`; `oxygen tables link <contacts> --to <accounts> --on company_domain --json` → `--approved` | a route whose `tool_access` is not `runnable`; any route that drops `company.domains` |\n| 8 | Hand off and learn | Sequences / Records / Knowledge Graph | `oxygen recipes show outbound-pilot-50 --json`; `oxygen tables promote <accounts> --object companies --dry-run --json` → `--approved`; `oxygen knowledge log append --event decision --slug account-map --summary \"...\" --json` | accepted accounts, their contacts, the run receipts | the receiving motion's caps; one rule changed per loop | `outbound-enrollment` belongs to that motion, never this one; canonical pages route through the proposal queue | `oxygen crm pipeline --json` after the first warm lead; `oxygen knowledge lint --json` | enrolling the contacts table wholesale — sourcing never initiates outreach |\n\n## Numeric guardrails\n\n- **Sample: 25 accounts, one page** — the recipe's `pilot.size`; `--max-pages 1` stops auto-pagination widening a filter nobody has read.\n- **Plan ceiling: 50,000** per company or people plan (`--target-count`); above it the plan returns a clamp warning and segmentation guidance. Segment instead of raising it.\n- **Bands.** `icp_fit_score` returns `band` (high / medium / low), a 0-100 `score` and one `evidence` sentence; borderline accounts land `medium`, never a generous `high`.\n- **Widen bar.** Widen only when a segment's sample clears the bar you wrote down; the recipe's default is high + medium above 50%. Plausible-fit on page 1 runs 60-80% for a sharp ICP, under ~40% means loose filters — both carry `benchmark_basis: estimate`, so they calibrate, they do not measure.\n- **Scope defaults.** Dedupe `--scan-limit` is 50,000 rows (cap 200,000), and standing auto-dedupe runs **before** auto-run so enrichment is never queued for rows about to be deleted. `columns run --limit` defaults to 10, inline deterministic runs cap at 25, `--all` requires `--background`. Personas per account have no default — set `--max-per-company` deliberately. Capacity: 3M rows per Table, 25M per workspace (`oxygen limits show --json`).\n- **Every `--max-credits <cap>` comes from the immediately preceding preview**, route estimate or `recommended_max_credits`. A too-low cap on a waterfall does not stop the run: the expensive lane is refused on its own and the cascade advances, so a cheaper lane still bills while the good one is skipped. Premium managed lanes stay off unless `--allow-premium-lanes` is passed; read a lane's price from `oxygen tools get <tool_id> --json`, never from prose.\n- **`domain` is the account identity, `linkedin_url` the person identity** — both are the upsert keys, neither is overwritten, and provenance accumulates in `source`.\n\n## Accepted-account gate spec\n\nAn account reaches persona sourcing only when `icp_fit_score.band` is `high`, or `medium` **with** an evidence string naming a verifiable fact; `score` is at or above the band floor written into the account-map page; `domain` is present, canonical, and not a directory, aggregator or search URL; the row is not excluded by the ICP spec (competitor, current customer, wrong geography, wrong size); and the row survived dedupe.\n\nEnforcement is a formula column, not prose. Validate it free, attach it, then materialise it — formula values compute when read, so a filter on one is refused by default:\n\n```bash\noxygen formulas validate <accounts> --expression 'if(and(or(path(icp_fit_score, \"band\") == \"high\", path(icp_fit_score, \"band\") == \"medium\"), is_blank(excluded_reason)), \"accepted\", \"held\")' --rows 5 --json\noxygen columns add <accounts> --kind formula --key account_accepted --label \"Accepted\" --definition-json '<validated expression>' --json\noxygen columns run <accounts> account_accepted --force --json\noxygen tables query <accounts> --filter-json '{\"column\":\"account_accepted\",\"op\":\"eq\",\"value\":\"accepted\"}' --formula-values materialized --fields domain --limit 1000 --json\noxygen tables views create <accounts> --name \"Accepted accounts\" --json\n```\n\nNothing bypasses this: never hand the whole accounts table to `oxygen people search run`, never source people at an account whose `icp_fit_score` cell is empty or errored, and never promote a `held` row because the market looks thin. A thin accepted set is a filter or ICP problem, fixed upstream.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Attended Copilot | Unattended run |\n| --- | --- | --- | --- |\n| `kit-apply` | 0-credit install of the accounts table and scoring column | auto-approvable workspace write, one card | installs only; arms nothing |\n| `source-sample` | one live company-search page under a cap | human card — provider spend | its own approved per-delivery ceiling |\n| dedupe `--apply --approved` | deleting duplicates (recoverable from row history) | auto-approvable workspace write | standing auto-dedupe, no per-write approval |\n| `fill-firmographics` | one capped company-enrichment run | human card | its own ceiling |\n| `score-accounts` | one paid AI column run under a cap | human card for the cap | its own ceiling; `tables auto-run set` is scoped standing permission for the listed columns |\n| `widen-coverage` | one more segment, re-granted every time | human card, per segment | never standing — a widen is a new purchase |\n| `source-personas` | one live people-search run scoped to accepted domains | human card | its own ceiling |\n| `tables promote --approved` | writing table columns onto matched CRM records | auto-approvable internal truth write | free, still explicit |\n| `outbound-enrollment` | contacting anyone at all | owned by the outbound motion | never granted here |\n\nReads — `recipes show`, both `search plan` commands, `tables query`, `cells inspect`, `lead-sourcing audit`, `budget list`, `limits show` — need no approval and spend nothing. Canonical wiki edits file a proposal a human approves.\n\n## Failure modes\n\n- **Free-text keyword where the provider wants an enum** → `invalid_provider_enum_value`, or worse a noisy page. Fetch the catalog and pass the exact string; free text only tightens an already enum-grounded segment.\n- **A dropped filter read as applied, or an invented market size.** `filter_application[]` reports applied vs dropped per route with the reason; quote `estimated_match_count` only when its `basis` is `provider_count` — any other basis is derived from your requested target, not from the market.\n- **Scoring the whole table before reading page 1** — the failure this motion exists to prevent: it spends several times over before anyone knows the filters work.\n- **Filtering a formula column.** `tables query` refuses formula filters by default because displayed formulas evaluate live. Run with `--force` (free), then `--formula-values materialized`.\n- **Appending instead of merging.** A source run without `--upsert-key domain` re-adds the same companies every page; collapse them, then arm the standing auto-dedupe. Enriching before deduping pays twice for one company.\n- **A benched or unknown managed provider.** `provider_availability` carries `degraded: true` or `availability: \"unknown\"`, and a live run refuses a benched managed primary before table creation. Read each entry's `next_action` — funding clears neither a staff hold nor a rejected key, and an unknown snapshot is re-previewed, not assumed.\n- **A preview-only people route treated as runnable.** Apollo and ContactOut people search return masked records without the stable `linkedin_url` the Contacts upsert contract needs, so `recommended_live_route_id` can name the right contract without naming a runnable route. Confirm `tool_access` is `runnable`, and never accept a route that drops `company.domains` — that is the gate leaking.\n- **An AI column asked a web question.** AI columns have no web access and answer from the row; web answers belong in a `--kind research` column with a `--research-query`. And a `queued` / `not_started` run has captured nothing yet — `oxygen table-runs cancel <run_id> --json` before pickup leaves spend at 0.\n\n## Data-quality checks (after every sourcing cycle)\n\n1. `oxygen tables query <accounts> --limit 100 --json` — rows with a blank `domain`, or one that is a directory, aggregator or search URL. Clear those cells **and** the row's `icp_fit_score` before re-scoring; poisoned cells are not re-scored on their own.\n2. `oxygen tables dedupe <accounts> --on domain --normalize domain --json` — zero groups once auto-dedupe is armed; anything else means a write path bypassed the key.\n3. `oxygen lead-sourcing audit <accounts> --spec ./icp-spec.json --json` — a reason on every exclusion; an exclusion with no reason is a filter you cannot defend.\n4. `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` on one high, one medium and one low row; evidence citing nothing checkable means a thin ICP page.\n5. `oxygen tables query <contacts> --limit 100 --json` — contacts per accepted account; zero is a persona-filter problem, not a market problem. `oxygen table-runs provider-summary <run_id> --json` says which provider answered and at what cost per row.\n\n## Learning loop\n\n- **What auto-files:** the ingestion run and its item outputs, per-cell provider and cost provenance, the knowledge log line each kit apply writes, `table-runs provider-summary`, and the audit output.\n- **What to synthesise monthly:** high-fit share by segment; contacts per accepted account; credits per *accepted account* (not per sourced row — the denominator that matters is the account someone would work); and, once the outbound companion has run, reply rate by segment joined back to the map.\n- **What to change, one rule per loop:** one filter, one band floor, one excluded segment, or one persona title set. Write the change and its reason into the account-map page; canonical positioning files a proposal instead.\n- **\"Good\", written before the first live run:** an accepted account is one with a reachable buyer persona in a segment where you can name a reason you win. Coverage without that definition is a row count, not a market map.\n\n## Go-live checklist\n\n1. `oxygen knowledge page get icp --json` and `oxygen knowledge page get offers --json` — both `active`, the ICP sentence carrying an explicit EXCLUDE clause. (`oxygen knowledge status --json` describes the local CLI mirror and can report zero pages while the workspace is filled; it is not the readiness check.)\n2. `oxygen integrations list --json` and `oxygen billing balance --json` — a company-search provider reachable, headroom for the sample.\n3. `oxygen tools enums get blitzapi industry --query <segment> --json`, then `oxygen companies search plan --prompt \"<ICP sentence>\" --filters-json '<typed filters>' --estimate --json`; read `filter_application` and `provider_availability`, save the plan to a file.\n4. `oxygen recipes apply icp-to-account-map --dry-run --json`, then apply — table and `icp_fit_score` installed, nothing armed.\n5. `source-sample` granted; `oxygen table-ingestions wait <ingestion_run_id> --json` green; 25 rows readable.\n6. Dedupe applied and `oxygen tables auto-dedupe set <accounts> --on domain --normalize domain --json` armed; `fill-firmographics` and `score-accounts` granted; one high, one medium and one low read by hand.\n7. `account_accepted` validated, attached, materialised; `oxygen tables views create <accounts> --name \"Accepted accounts\" --json`.\n8. Widen bar written down; `widen-coverage` granted for the first segment only.\n9. `oxygen blueprints apply contact-finding --json`; `source-personas` for one persona set at accepted domains; `oxygen tables link <contacts> --to <accounts> --on company_domain --json` previewed, then `--approved`.\n10. `oxygen budget list --json` and `oxygen limits show --json` — org backstop and capacity headroom in place; `oxygen knowledge page upsert --slug account-map --type research_note --json` records segments, filters, band floor and widen decisions.\n\n## Open questions (state them, do not resolve them)\n\n- Company search publishes no `schedulable` field the way signal search does, so a recurring refresh is discovered by attempting `oxygen feeds bind <accounts> --kind company_search --upsert-key domain --every daily@9 --max-credits <cap> --approved --json` and treating a `feed_not_incremental` refusal as the answer. Until then the supported cadence is a monthly re-plan through the same gates.\n- The recipe's fit bands are `benchmark_basis: estimate` with no workspace-measured baseline behind them, and the canonical ICP scorer function is not yet ratifiable — this playbook uses the kit's table AI column, never a callable.\n- Whether accepted accounts should become CRM company records at map time is unratified. This playbook keeps the map in Tables and promotes only accounts a human is working; a CRM *person* is created at the warm-lead gate downstream, never at sourcing time.\n- Cross-table suppression is read-only through `oxygen tables dedupe <accounts> --on domain --against <suppression-table> --against-column domain --json`; no standing suppression policy exists on a source run, so exclusions live in the plan's EXCLUDE clause and the audit spec.\n\n## Resume point\n\n`oxygen recipes show icp-to-account-map --json`. Its `kit` block names each stage's install status; `oxygen tables list --json` says whether an accounts or contacts table already exists, and `oxygen tables auto-dedupe get <accounts> --json` plus `oxygen tables auto-run get <accounts> --json` say what already runs on writes. Start there, never from scratch.\n\n## What the human still has to do\n\nNothing above contacts anyone, and nothing widens on its own. The human writes the ICP sentence and band floor into `oxygen knowledge page upsert --slug account-map --json`; grants `source-sample`, `fill-firmographics` and `score-accounts`, each with a cap read from its own preview; reads one high, one medium and one low row with `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` and decides whether the filters or the ICP page need fixing; grants `widen-coverage` once per segment; grants `source-personas` after choosing the persona titles and `--max-per-company`; and decides whether the accepted map goes to `outbound-pilot-50` now or after another coverage pass. That read is the step routinely skipped, and the one the whole motion is built around.\n",
+        sha256: "f3743642d6b0a1f91d66ea674ea56c3479e34ee840c89f043a2bbfc94dd6efb6",
+        content: "---\nname: tam-sourcing\ndescription: \"Turn the workspace ICP into a sourced, scored, deduplicated account map and the buyer personas at those accounts — a bounded sample first, coverage widened only on segments the sample proved — then hand it to outbound. Load it when the whole market map is the ask.\"\n---\n\n# Playbook: TAM sourcing\n\n## Motion in one sentence\n\nThe ICP compiles into a provider-grounded sourcing plan, one bounded sample of accounts is sourced live, deduplicated and filled, every account is scored against that same ICP with its evidence on the row, the sample's band distribution decides which segments deserve coverage, coverage widens one segment at a time through the same gate, buyer personas are sourced only at accounts that passed it, and the accepted map is handed to an outbound motion. The sample before the coverage is the play; the order is companies → fit → people, never people first.\n\nRecipe and kit: `oxygen recipes show icp-to-account-map --json` (its `journey.slug` is `tam-sourcing`); the companion it hands to is `oxygen recipes show outbound-pilot-50 --json`. Read both first — `recipes show` reports which stages this workspace already has.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context | Knowledge Graph | `oxygen knowledge page get icp --json`; `oxygen knowledge page get offers --json` (`oxygen knowledge status` reports the local CLI mirror, not the workspace) | `company`, `offering`, `icp` pages | — | none | pages `active`, not seed stubs; the ICP names segment, geography, size **and who is out** | a stub ICP, or no exclusion clause |\n| 1 | Plan | Tables — company-search planner | `oxygen tools enums get blitzapi industry --query <segment> --json` → `oxygen companies search plan --prompt \"<ICP sentence with EXCLUDE clause>\" --filters-json '<typed filters>' --estimate --json` | one ICP sentence; exact enum strings | `--target-count` ceiling 50,000 per plan | none — no provider call, no spend | `filter_application[].dropped`, `provider_availability`, `estimated_match_count.basis`, `recommended_live_route_id` | a filter you need lands in `dropped_constraints`; a managed primary reads `degraded: true` |\n| 2 | Scaffold | Tables — kit stage `account-sourcing` | `oxygen recipes apply icp-to-account-map --dry-run --json` → the same without `--dry-run` | — | 0 credits, no provider call, no external write | `kit-apply`: human, once for the kit | `oxygen tables describe <accounts> --json` shows `company_name`, `domain`, `company_linkedin_url`, `source`, `fit_notes` | a stage already installed — never re-install it |\n| 3 | Source the sample | Tables — company search | `oxygen companies search run --plan-json <plan> --route-id <route_id> --table <accounts> --upsert-key domain --mode dry_run --json` → `--mode live --max-pages 1 --max-credits <cap> --approved` | the plan you actually read | one page, the recipe's 25-account pilot; `<cap>` from the route estimate | `source-sample`: paid, human, server-enforced | `oxygen table-ingestions wait <ingestion_run_id> --json`; `oxygen tables query <accounts> --limit 25 --json` | `spend_cap_too_low`; near-zero rows; `data_status` still `pending` — the verdict is on the ingestion run, not the queue receipt |\n| 4 | Clean | Tables | `oxygen tables dedupe <accounts> --on domain --normalize domain --json` → `--apply --approved --merge-values fill-empty`; `oxygen tables auto-dedupe set <accounts> --on domain --normalize domain --json`; `oxygen companies enrich preview <accounts> --missing-fields domain,linkedin_url,headcount,industry --json` → `oxygen companies enrich run <accounts> --mode live --max-credits <cap> --approved --json` | `domain`; rows with firmographic gaps | `--scan-limit` 50,000 / 200,000 cap; enrichment scoped by its preview | dedupe apply: free internal delete, losers kept in row history. `fill-firmographics`: paid, human | dedupe preview reruns to 0 groups; `oxygen cells inspect <accounts> <row_id> domain --json` carries provider and cost | groups that are not one company; a provider in the preview reading blocked or benched |\n| 5 | Score | Tables — kit stage `icp-fit-scoring` | `oxygen columns run <accounts> icp_fit_score --limit 10 --dry-run --json` → `--limit 25 --background --approved --max-credits <cap> --json` | the `icp` page (auto-prepended), `company_name`, `domain` | the sample only; `--limit` defaults to 10 | `score-accounts`: paid, human for the cap | `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` — one high, one medium, one low, each `evidence` citing a checkable fact | bands spread evenly, or evidence reads generic: fix the ICP page, not the prompt |\n| 6 | Widen | Tables — company search, again | re-plan the surviving segment, then the stage-3 live command with the new plan and `--max-pages <n>` | segments whose sample cleared the widen bar | one segment per widen; auto-pagination stops at the cap | `widen-coverage`: paid, human, **per segment** | the `auto_paged` block; `oxygen lead-sourcing audit <accounts> --spec ./icp-spec.json --json` | a segment whose sample landed mostly `low` — more pages of a bad filter is more junk |\n| 7 | Personas | Tables — Blueprint `contact-finding` | `oxygen blueprints apply contact-finding --json` → `oxygen people search plan --company-domains <accepted-domains> --titles \"<persona>\" --title-match exact --max-per-company <n> --json` → `oxygen people search run --plan-json <plan> --route-id <route_id> --table <contacts> --upsert-key linkedin_url --mode live --max-credits <cap> --approved --json` | the accepted-domain list from the gate below; one persona title set | `--max-per-company <n>`; upsert dedupes on `linkedin_url` | `source-personas`: paid, human | `oxygen tables query <contacts> --limit 25 --json`; `oxygen tables link <contacts> --to <accounts> --on company_domain --json` → `--approved` | a route whose `tool_access` is not `runnable`; any route that drops `company.domains` |\n| 8 | Hand off and learn | Sequences / Records / Knowledge Graph | `oxygen recipes show outbound-pilot-50 --json`; `oxygen tables promote <accounts> --object companies --dry-run --json` → `--approved`; `oxygen knowledge log append --event decision --slug account-map --summary \"...\" --json` | accepted accounts, their contacts, the run receipts | the receiving motion's caps; one rule changed per loop | `outbound-enrollment` belongs to that motion, never this one; canonical pages route through the proposal queue | `oxygen crm pipeline --json` after the first warm lead; `oxygen knowledge lint --json` | enrolling the contacts table wholesale — sourcing never initiates outreach |\n\n## Numeric guardrails\n\n- **Sample: 25 accounts, one page** — the recipe's `pilot.size`; `--max-pages 1` stops auto-pagination widening a filter nobody has read.\n- **Plan ceiling: 50,000** per company or people plan (`--target-count`); above it the plan returns a clamp warning and segmentation guidance. Segment instead of raising it.\n- **Bands.** `icp_fit_score` returns `band` (high / medium / low), a 0-100 `score` and one `evidence` sentence; borderline accounts land `medium`, never a generous `high`.\n- **Widen bar.** Widen only when a segment's sample clears the bar you wrote down; the recipe's default is high + medium above 50%. Plausible-fit on page 1 runs 60-80% for a sharp ICP, under ~40% means loose filters — both carry `benchmark_basis: estimate`, so they calibrate, they do not measure.\n- **Scope defaults.** Dedupe `--scan-limit` is 50,000 rows (cap 200,000), and standing auto-dedupe runs **before** auto-run so enrichment is never queued for rows about to be deleted. `columns run --limit` defaults to 10, inline deterministic runs cap at 25, `--all` requires `--background`. Personas per account have no default — set `--max-per-company` deliberately. Capacity follows the plan size: rows per Table and per workspace are in `oxygen limits show --json` (`storage_capacity`); at a limit only new rows are refused.\n- **Every `--max-credits <cap>` comes from the immediately preceding preview**, route estimate or `recommended_max_credits`. A too-low cap on a waterfall does not stop the run: the expensive lane is refused on its own and the cascade advances, so a cheaper lane still bills while the good one is skipped. Premium managed lanes stay off unless `--allow-premium-lanes` is passed; read a lane's price from `oxygen tools get <tool_id> --json`, never from prose.\n- **`domain` is the account identity, `linkedin_url` the person identity** — both are the upsert keys, neither is overwritten, and provenance accumulates in `source`.\n\n## Accepted-account gate spec\n\nAn account reaches persona sourcing only when `icp_fit_score.band` is `high`, or `medium` **with** an evidence string naming a verifiable fact; `score` is at or above the band floor written into the account-map page; `domain` is present, canonical, and not a directory, aggregator or search URL; the row is not excluded by the ICP spec (competitor, current customer, wrong geography, wrong size); and the row survived dedupe.\n\nEnforcement is a formula column, not prose. Validate it free, attach it, then materialise it — formula values compute when read, so a filter on one is refused by default:\n\n```bash\noxygen formulas validate <accounts> --expression 'if(and(or(path(icp_fit_score, \"band\") == \"high\", path(icp_fit_score, \"band\") == \"medium\"), is_blank(excluded_reason)), \"accepted\", \"held\")' --rows 5 --json\noxygen columns add <accounts> --kind formula --key account_accepted --label \"Accepted\" --definition-json '<validated expression>' --json\noxygen columns run <accounts> account_accepted --force --json\noxygen tables query <accounts> --filter-json '{\"column\":\"account_accepted\",\"op\":\"eq\",\"value\":\"accepted\"}' --formula-values materialized --fields domain --limit 1000 --json\noxygen tables views create <accounts> --name \"Accepted accounts\" --json\n```\n\nNothing bypasses this: never hand the whole accounts table to `oxygen people search run`, never source people at an account whose `icp_fit_score` cell is empty or errored, and never promote a `held` row because the market looks thin. A thin accepted set is a filter or ICP problem, fixed upstream.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Attended Copilot | Unattended run |\n| --- | --- | --- | --- |\n| `kit-apply` | 0-credit install of the accounts table and scoring column | auto-approvable workspace write, one card | installs only; arms nothing |\n| `source-sample` | one live company-search page under a cap | human card — provider spend | its own approved per-delivery ceiling |\n| dedupe `--apply --approved` | deleting duplicates (recoverable from row history) | auto-approvable workspace write | standing auto-dedupe, no per-write approval |\n| `fill-firmographics` | one capped company-enrichment run | human card | its own ceiling |\n| `score-accounts` | one paid AI column run under a cap | human card for the cap | its own ceiling; `tables auto-run set` is scoped standing permission for the listed columns |\n| `widen-coverage` | one more segment, re-granted every time | human card, per segment | never standing — a widen is a new purchase |\n| `source-personas` | one live people-search run scoped to accepted domains | human card | its own ceiling |\n| `tables promote --approved` | writing table columns onto matched CRM records | auto-approvable internal truth write | free, still explicit |\n| `outbound-enrollment` | contacting anyone at all | owned by the outbound motion | never granted here |\n\nReads — `recipes show`, both `search plan` commands, `tables query`, `cells inspect`, `lead-sourcing audit`, `budget list`, `limits show` — need no approval and spend nothing. Canonical wiki edits file a proposal a human approves.\n\n## Failure modes\n\n- **Free-text keyword where the provider wants an enum** → `invalid_provider_enum_value`, or worse a noisy page. Fetch the catalog and pass the exact string; free text only tightens an already enum-grounded segment.\n- **A dropped filter read as applied, or an invented market size.** `filter_application[]` reports applied vs dropped per route with the reason; quote `estimated_match_count` only when its `basis` is `provider_count` — any other basis is derived from your requested target, not from the market.\n- **Scoring the whole table before reading page 1** — the failure this motion exists to prevent: it spends several times over before anyone knows the filters work.\n- **Filtering a formula column.** `tables query` refuses formula filters by default because displayed formulas evaluate live. Run with `--force` (free), then `--formula-values materialized`.\n- **Appending instead of merging.** A source run without `--upsert-key domain` re-adds the same companies every page; collapse them, then arm the standing auto-dedupe. Enriching before deduping pays twice for one company.\n- **A benched or unknown managed provider.** `provider_availability` carries `degraded: true` or `availability: \"unknown\"`, and a live run refuses a benched managed primary before table creation. Read each entry's `next_action` — funding clears neither a staff hold nor a rejected key, and an unknown snapshot is re-previewed, not assumed.\n- **A preview-only people route treated as runnable.** Apollo and ContactOut people search return masked records without the stable `linkedin_url` the Contacts upsert contract needs, so `recommended_live_route_id` can name the right contract without naming a runnable route. Confirm `tool_access` is `runnable`, and never accept a route that drops `company.domains` — that is the gate leaking.\n- **An AI column asked a web question.** AI columns have no web access and answer from the row; web answers belong in a `--kind research` column with a `--research-query`. And a `queued` / `not_started` run has captured nothing yet — `oxygen table-runs cancel <run_id> --json` before pickup leaves spend at 0.\n\n## Data-quality checks (after every sourcing cycle)\n\n1. `oxygen tables query <accounts> --limit 100 --json` — rows with a blank `domain`, or one that is a directory, aggregator or search URL. Clear those cells **and** the row's `icp_fit_score` before re-scoring; poisoned cells are not re-scored on their own.\n2. `oxygen tables dedupe <accounts> --on domain --normalize domain --json` — zero groups once auto-dedupe is armed; anything else means a write path bypassed the key.\n3. `oxygen lead-sourcing audit <accounts> --spec ./icp-spec.json --json` — a reason on every exclusion; an exclusion with no reason is a filter you cannot defend.\n4. `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` on one high, one medium and one low row; evidence citing nothing checkable means a thin ICP page.\n5. `oxygen tables query <contacts> --limit 100 --json` — contacts per accepted account; zero is a persona-filter problem, not a market problem. `oxygen table-runs provider-summary <run_id> --json` says which provider answered and at what cost per row.\n\n## Learning loop\n\n- **What auto-files:** the ingestion run and its item outputs, per-cell provider and cost provenance, the knowledge log line each kit apply writes, `table-runs provider-summary`, and the audit output.\n- **What to synthesise monthly:** high-fit share by segment; contacts per accepted account; credits per *accepted account* (not per sourced row — the denominator that matters is the account someone would work); and, once the outbound companion has run, reply rate by segment joined back to the map.\n- **What to change, one rule per loop:** one filter, one band floor, one excluded segment, or one persona title set. Write the change and its reason into the account-map page; canonical positioning files a proposal instead.\n- **\"Good\", written before the first live run:** an accepted account is one with a reachable buyer persona in a segment where you can name a reason you win. Coverage without that definition is a row count, not a market map.\n\n## Go-live checklist\n\n1. `oxygen knowledge page get icp --json` and `oxygen knowledge page get offers --json` — both `active`, the ICP sentence carrying an explicit EXCLUDE clause. (`oxygen knowledge status --json` describes the local CLI mirror and can report zero pages while the workspace is filled; it is not the readiness check.)\n2. `oxygen integrations list --json` and `oxygen billing balance --json` — a company-search provider reachable, headroom for the sample.\n3. `oxygen tools enums get blitzapi industry --query <segment> --json`, then `oxygen companies search plan --prompt \"<ICP sentence>\" --filters-json '<typed filters>' --estimate --json`; read `filter_application` and `provider_availability`, save the plan to a file.\n4. `oxygen recipes apply icp-to-account-map --dry-run --json`, then apply — table and `icp_fit_score` installed, nothing armed.\n5. `source-sample` granted; `oxygen table-ingestions wait <ingestion_run_id> --json` green; 25 rows readable.\n6. Dedupe applied and `oxygen tables auto-dedupe set <accounts> --on domain --normalize domain --json` armed; `fill-firmographics` and `score-accounts` granted; one high, one medium and one low read by hand.\n7. `account_accepted` validated, attached, materialised; `oxygen tables views create <accounts> --name \"Accepted accounts\" --json`.\n8. Widen bar written down; `widen-coverage` granted for the first segment only.\n9. `oxygen blueprints apply contact-finding --json`; `source-personas` for one persona set at accepted domains; `oxygen tables link <contacts> --to <accounts> --on company_domain --json` previewed, then `--approved`.\n10. `oxygen budget list --json` and `oxygen limits show --json` — org backstop and capacity headroom in place; `oxygen knowledge page upsert --slug account-map --type research_note --json` records segments, filters, band floor and widen decisions.\n\n## Open questions (state them, do not resolve them)\n\n- Company search publishes no `schedulable` field the way signal search does, so a recurring refresh is discovered by attempting `oxygen feeds bind <accounts> --kind company_search --upsert-key domain --every daily@9 --max-credits <cap> --approved --json` and treating a `feed_not_incremental` refusal as the answer. Until then the supported cadence is a monthly re-plan through the same gates.\n- The recipe's fit bands are `benchmark_basis: estimate` with no workspace-measured baseline behind them, and the canonical ICP scorer function is not yet ratifiable — this playbook uses the kit's table AI column, never a callable.\n- Whether accepted accounts should become CRM company records at map time is unratified. This playbook keeps the map in Tables and promotes only accounts a human is working; a CRM *person* is created at the warm-lead gate downstream, never at sourcing time.\n- Cross-table suppression is read-only through `oxygen tables dedupe <accounts> --on domain --against <suppression-table> --against-column domain --json`; no standing suppression policy exists on a source run, so exclusions live in the plan's EXCLUDE clause and the audit spec.\n\n## Resume point\n\n`oxygen recipes show icp-to-account-map --json`. Its `kit` block names each stage's install status; `oxygen tables list --json` says whether an accounts or contacts table already exists, and `oxygen tables auto-dedupe get <accounts> --json` plus `oxygen tables auto-run get <accounts> --json` say what already runs on writes. Start there, never from scratch.\n\n## What the human still has to do\n\nNothing above contacts anyone, and nothing widens on its own. The human writes the ICP sentence and band floor into `oxygen knowledge page upsert --slug account-map --json`; grants `source-sample`, `fill-firmographics` and `score-accounts`, each with a cap read from its own preview; reads one high, one medium and one low row with `oxygen cells inspect <accounts> <row_id> icp_fit_score --json` and decides whether the filters or the ICP page need fixing; grants `widen-coverage` once per segment; grants `source-personas` after choosing the persona titles and `--max-per-company`; and decides whether the accepted map goes to `outbound-pilot-50` now or after another coverage pass. That read is the step routinely skipped, and the one the whole motion is built around.\n",
     },
     {
         slug: "linkedin-content-strategy",
         title: "Playbook: LinkedIn content strategy",
         sources: ["oxygen-playbooks/playbooks/linkedin-content-strategy.md"],
-        sha256: "3a0e90ad7451e433473ce09b2db86ea3864eaab1719f19be6333a33fd38be710",
-        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",
+        sha256: "4b182957e72e46be3ff79cf0af68ad073814c3fd88c69289c2d54aa238f1735a",
+        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 | `posts_per_day` (default 10, max 25) | 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 cap `posts_per_day`** per account (default 10, max 25): 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",
     },
     {
         slug: "inbound-led-outbound",
@@ -35,7 +35,7 @@ export const COPILOT_SKILL_SNAPSHOTS_GENERATED = [
         slug: "signal-based-outbound",
         title: "Playbook: Signal-based outbound",
         sources: ["oxygen-playbooks/playbooks/signal-based-outbound.md"],
-        sha256: "2e7aeef6d3a2eaee0820d273feb60a0fa8a466a4adee4e009a5737534c64bf9b",
-        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",
+        sha256: "b29bcaf04707f4aee4cb0fdafa6a0ee02cff7f0987ee1e55cf313ebadb76454b",
+        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 size's per-delivery default (the preview prints which; `oxygen limits show --json` → `spend_safety_defaults`). `--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",
     },
 ];

package/node_modules/@oxygen/shared/dist/cost-estimate-view.d.ts

@@ -0,0 +1,50 @@
+/**
+ * How `POST /api/cli/billing/estimate` reads to a person. The MCP
+ * `oxygen.cost-estimate` widget and the web Settings → Plan limits → Estimate a
+ * month view both render from here, so a label or a rounding rule cannot differ
+ * between them. Pure and browser-safe: it formats an envelope it is handed.
+ */
+import type { CostEstimateResult } from "./cost-estimate.js";
+export type CostEstimateEnvelope = Partial<CostEstimateResult> & {
+    compared_plan?: string;
+    compared_plan_source?: "workspace" | "requested";
+    sender_billing?: "sending_seats" | "credit_reservations";
+    pricing_schedule?: {
+        effective_at?: string;
+        note?: string;
+    };
+    web_url?: string;
+    deepLink?: string;
+};
+export type CostEstimateViewRow = {
+    key: string;
+    label: string;
+    detail: string;
+    monthly: string;
+    worstCase: string;
+};
+export type CostEstimateViewPlan = {
+    label: string;
+    expected: string;
+    worstCase: string;
+};
+export type CostEstimateViewLimit = {
+    key: string;
+    label: string;
+    usage: string;
+    hit: boolean;
+    note: string;
+};
+export type CostEstimateView = {
+    summary: string;
+    rows: CostEstimateViewRow[];
+    totals: {
+        label: string;
+        expected: string;
+        worstCase: string;
+    }[];
+    plans: CostEstimateViewPlan[];
+    limits: CostEstimateViewLimit[];
+    notes: string[];
+};
+export declare function costEstimateView(envelope: CostEstimateEnvelope): CostEstimateView;

package/node_modules/@oxygen/shared/dist/cost-estimate-view.js

@@ -0,0 +1,90 @@
+function credits(value) {
+    if (value === null || value === undefined)
+        return "—";
+    return `${value.toLocaleString("en-US", { maximumFractionDigits: 2 })} cr`;
+}
+function usd(value) {
+    if (value === null || value === undefined)
+        return "—";
+    return `$${value.toLocaleString("en-US", { minimumFractionDigits: 2, maximumFractionDigits: 2 })}`;
+}
+function lineDetail(line) {
+    const quantity = line.quantity.toLocaleString("en-US");
+    if (line.billed_as === "free")
+        return `${quantity} × 0 cr`;
+    if (line.billed_as === "usd") {
+        const unit = line.quantity > 0 && line.usd_per_month !== null ? line.usd_per_month / line.quantity : null;
+        return `${quantity} × ${usd(unit)} seat`;
+    }
+    if (line.unit_credits === null)
+        return `${quantity} × no price yet`;
+    const worst = line.worst_case_unit_credits !== null && line.worst_case_unit_credits !== line.unit_credits
+        ? ` (up to ${credits(line.worst_case_unit_credits)})`
+        : "";
+    const scheduled = line.scheduled_unit_credits !== undefined && line.scheduled_unit_credits !== null
+        ? `; ${credits(line.scheduled_unit_credits)} from the scheduled date`
+        : "";
+    return `${quantity} × ${credits(line.unit_credits)}${worst}${scheduled}`;
+}
+function lineMonthly(line, worst) {
+    if (line.billed_as === "usd")
+        return usd(line.usd_per_month);
+    return credits(worst ? line.worst_case_credits_per_month : line.credits_per_month);
+}
+function planText(outcome) {
+    const total = outcome.monthly_usd === null ? "" : `${usd(outcome.monthly_usd)} a month all in`;
+    if (outcome.covered)
+        return total ? `Covers it: ${total}` : "Covers it";
+    const topup = `short ${credits(outcome.shortfall_credits)}, top up ${credits(outcome.topup_credits)} (${usd(outcome.topup_usd)})`;
+    return total ? `${total}, ${topup}` : topup;
+}
+export function costEstimateView(envelope) {
+    const plans = [];
+    if (envelope.plan_fit) {
+        const suffix = envelope.compared_plan_source === "requested" ? "" : " (yours)";
+        plans.push({
+            label: `${envelope.plan_fit.expected.label}${suffix}`,
+            expected: planText(envelope.plan_fit.expected),
+            worstCase: planText(envelope.plan_fit.worst_case),
+        });
+    }
+    if (envelope.recommended_plan) {
+        const { expected, worst_case: worstCase } = envelope.recommended_plan;
+        plans.push({
+            label: "Cheapest plan",
+            expected: `${expected.label}: ${planText(expected)}`,
+            worstCase: `${worstCase.label}: ${planText(worstCase)}`,
+        });
+    }
+    const totals = envelope.totals;
+    return {
+        summary: envelope.summary ?? "",
+        rows: (envelope.lines ?? []).map((line) => ({
+            key: line.key,
+            label: line.label,
+            detail: lineDetail(line),
+            monthly: lineMonthly(line, false),
+            worstCase: lineMonthly(line, true),
+        })),
+        totals: totals
+            ? [
+                { label: "Credits a month", expected: credits(totals.credits_per_month), worstCase: credits(totals.worst_case_credits_per_month) },
+                ...(totals.usd_seats_per_month > 0
+                    ? [{ label: "Sending seats (card)", expected: usd(totals.usd_seats_per_month), worstCase: usd(totals.usd_seats_per_month) }]
+                    : []),
+            ]
+            : [],
+        plans,
+        limits: (envelope.limits ?? []).map((row) => ({
+            key: row.key,
+            label: row.label,
+            usage: `${row.needed_per_month.toLocaleString("en-US")} of ${row.capacity_per_month.toLocaleString("en-US")} a month`,
+            hit: row.hit,
+            note: row.note,
+        })),
+        notes: [
+            ...(envelope.warnings ?? []),
+            ...(envelope.pricing_schedule?.note ? [envelope.pricing_schedule.note] : []),
+        ],
+    };
+}

package/node_modules/@oxygen/shared/dist/cost-estimate.d.ts

@@ -0,0 +1,167 @@
+/**
+ * The scenario cost estimator behind `POST /api/cli/billing/estimate`
+ * (`oxygen billing estimate`, MCP `oxygen_billing_estimate`, Settings → Plan
+ * limits → Estimate a month). OXP-43.33.
+ *
+ * A founder asks "2,000 leads a month, work email on each, a 3-step email and
+ * LinkedIn sequence from 2 mailboxes and 1 LinkedIn account: what does that
+ * cost, and does anything run out?". Before this, an agent answered it by
+ * stitching six reads together by hand (blind baseline 2026-09-26, finding 9).
+ *
+ * Pure: the route resolves every price from the live pricing book, the
+ * enrichment catalog and the sending limits the send path enforces, and hands
+ * them in as a price sheet. Nothing here knows a price, so the estimate can
+ * never quote a number the product does not charge.
+ *
+ * Three things are kept apart on purpose, because they are paid differently:
+ *   - credits that recur every month (sender reservations, enrichment), which
+ *     size the plan;
+ *   - dollars that recur on a card (sending seats while seats are sold), which a
+ *     plan's credits never pay for;
+ *   - sending itself, which is free and is bounded by per-account limits, not by
+ *     money.
+ */
+export declare const COST_ESTIMATE_BOUNDS: {
+    readonly maxLeadsPerMonth: 10000000;
+    readonly maxStepsPerChannel: 20;
+    readonly maxSendersPerKind: 1000;
+    readonly maxEnrichments: 12;
+};
+export type CostEstimateScenario = {
+    leadsPerMonth: number;
+    /** Enrichment catalog ids, each run once on every lead. */
+    enrichmentIds: readonly string[];
+    emailSteps: number;
+    /** The first LinkedIn step is a connection invite; later ones are messages. */
+    linkedinSteps: number;
+    /** Mailboxes you connect yourself (Google, Microsoft, SMTP). */
+    mailboxes: number;
+    /** Mailboxes OXYGEN sells you (managed inboxes). */
+    managedMailboxes: number;
+    linkedinAccounts: number;
+};
+export type CostEstimateEnrichmentPrice = {
+    id: string;
+    label: string;
+    kind: "fixed" | "estimated" | "unavailable";
+    expectedCreditsPerRow: number | null;
+    worstCaseCreditsPerRow: number | null;
+    hitRatesAssumed: boolean;
+};
+export type CostEstimateSenderPrice = {
+    billedAs: "credits";
+    /** null: no price in force, so nothing is reserved yet. */
+    creditsPerMonth: number | null;
+    /** The reservation from the scheduled repricing date, when that differs. */
+    scheduledCreditsPerMonth?: number | null;
+} | {
+    billedAs: "usd";
+    usdCentsPerMonth: number;
+};
+export type CostEstimatePlanRung = {
+    planKey: string;
+    label: string;
+    monthlyPriceCents: number | null;
+    monthlyCredits: number;
+};
+export type CostEstimatePriceSheet = {
+    /** One entry per selected enrichment id, in the scenario's order. */
+    enrichments: readonly CostEstimateEnrichmentPrice[];
+    senders: {
+        mailbox: CostEstimateSenderPrice;
+        managedMailbox: CostEstimateSenderPrice;
+        linkedinAccount: CostEstimateSenderPrice;
+    };
+    /** The plans a customer can buy, cheapest first. */
+    rungs: readonly CostEstimatePlanRung[];
+    /** The plan the estimate is checked against (the workspace's own by default). */
+    comparePlan: CostEstimatePlanRung | null;
+    creditsPerUsd: number;
+    topupUsdCentsPer100: number;
+    topupMinCredits: number;
+    topupStepCredits: number;
+    sending: {
+        emailPerMailboxPerDay: number;
+        emailRamp: readonly {
+            throughDay: number;
+            perDay: number;
+        }[];
+        linkedinInvitesPerDay: number;
+        linkedinInvitesPerWeek: number;
+        linkedinMessagesPerDay: number;
+        sendingDaysPerMonth: number;
+    };
+};
+export type CostEstimateLine = {
+    key: string;
+    group: "enrichment" | "senders" | "sending";
+    label: string;
+    quantity: number;
+    unit: string;
+    /** `credits` draws on the plan, `usd` bills a card, `free` costs nothing. */
+    billed_as: "credits" | "usd" | "free";
+    unit_credits: number | null;
+    worst_case_unit_credits: number | null;
+    credits_per_month: number | null;
+    worst_case_credits_per_month: number | null;
+    /** A `usd` line's card charge; a credit line's credits at face value. */
+    usd_per_month: number | null;
+    scheduled_unit_credits?: number | null;
+    note?: string;
+};
+export type CostEstimatePlanOutcome = {
+    plan_key: string;
+    label: string;
+    monthly_price_usd: number | null;
+    monthly_credits: number;
+    covered: boolean;
+    /** Credits the plan does not cover, before rounding to a purchasable top-up. */
+    shortfall_credits: number;
+    topup_credits: number;
+    topup_usd: number;
+    /** Plan price + top-ups + seats billed in dollars. */
+    monthly_usd: number | null;
+};
+export type CostEstimateLimit = {
+    key: "email_per_mailbox" | "linkedin_invites_per_account" | "linkedin_messages_per_account";
+    label: string;
+    needed_per_month: number;
+    senders: number;
+    /** What one sender manages a month, and the limit that sets it. */
+    per_sender_per_month: number;
+    binding_limit: string;
+    capacity_per_month: number;
+    /** What a newly connected sender manages in its first month (email ramp). */
+    first_month_capacity: number | null;
+    senders_needed: number;
+    hit: boolean;
+    note: string;
+};
+export type CostEstimateResult = {
+    lines: CostEstimateLine[];
+    totals: {
+        fixed_credits_per_month: number;
+        flexible_credits_per_month: number;
+        flexible_worst_case_credits_per_month: number;
+        credits_per_month: number;
+        worst_case_credits_per_month: number;
+        usd_seats_per_month: number;
+        unpriced_lines: string[];
+    };
+    plan_fit: {
+        expected: CostEstimatePlanOutcome;
+        worst_case: CostEstimatePlanOutcome;
+    } | null;
+    recommended_plan: {
+        expected: CostEstimatePlanOutcome;
+        worst_case: CostEstimatePlanOutcome;
+    } | null;
+    limits: CostEstimateLimit[];
+    limits_hit: CostEstimateLimit["key"][];
+    assumptions: string[];
+    warnings: string[];
+    summary: string;
+};
+/** Clamp a scenario into the accepted bounds: whole, non-negative numbers. */
+export declare function normalizeCostEstimateScenario(scenario: CostEstimateScenario): CostEstimateScenario;
+export declare function estimateScenarioCost(rawScenario: CostEstimateScenario, sheet: CostEstimatePriceSheet): CostEstimateResult;