@oxygen-agent/cli 1.1010.721 → 1.1010.905

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

@@ -26,6 +26,6 @@ export declare const COPILOT_SKILL_SNAPSHOTS_GENERATED: readonly [{
     readonly slug: "signal-based-outbound";
     readonly title: "Playbook: Signal-based outbound";
     readonly sources: readonly ["oxygen-playbooks/playbooks/signal-based-outbound.md"];
-    readonly sha256: "2e7aeef6d3a2eaee0820d273feb60a0fa8a466a4adee4e009a5737534c64bf9b";
-    readonly content: "---\nname: signal-based-outbound\ndescription: \"Installs the general buying-signal engine: arm company-level pulse sources and person-level engagement sources, expand a hit account into named buyers, gate, rank and score them against the ICP, and route only the qualified band into a capped sequence.\"\n---\n\n# Playbook: signal-based outbound\n\n## Motion in one sentence\n\nSources are armed against one segment in two lanes — **pulse** (a company acts: hiring surge, funding, tech install, news) and **engagement** (a person acts: website visit, profile view, post reaction, follow). The pulse lane expands a hit account into named buyers, the engagement lane resolves a person directly, both converge at the warm-lead gate where a CRM person is created, then rank into one daily queue, are scored against the ICP and split — the strongest to the founder's own hand, the qualified band into a capped sequence. The order matters because every step narrows: capture is wide, expansion is account-bound, resolution is identity-bound, ranking is intent-bound, the band gate is fit-bound, and only the last step contacts anyone.\n\nRecipes cover the engagement sources one at a time (`oxygen recipes show website-visitor-outreach --json`, `profile-viewer-outreach`, `linkedin-intent-to-signup`, `daily-warm-lead-queue`, `speed-to-lead`); the pulse lane has none and is stages 1–2. Every command here takes `--json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + registry | Knowledge Graph + Signals | `oxygen context resolve --purpose outbound_copy`; `oxygen knowledge page get icp`; `oxygen signals registry`; `oxygen signals list --since 7` | a filled `icp`; a written segment | — | none | `icp` reads `active`, not a stub; your types read `captureStatus: live` | a stub ICP, or a type you assumed exists that the registry lacks |\n| 1 | **Pulse — company signals** | Signals — signal search | `oxygen signals search plan --prompt \"<goal>\" --family hiring --scope market --last-days 30 --estimate` → `oxygen signals search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap>` | `--family` hiring/tech/funding/acquisition/news/job_change; `--scope market`, or `watch_list --domains` | the plan's own `estimated_credits`; `--max-pages` defaults to 1; a standing harvest adds `--bind-feed --every daily@9 --max-credits-per-cycle <cap>` | `pulse-harvest`: paid, human, per run; `--bind-feed` is a **second**, standing grant | the plan's `routes[]`, `filter_application`, `schedulable`; then `oxygen feeds deliveries --table <signals_table>` | `no_default_provider_chain`; `feed_not_incremental`; `basis` not `provider_count` |\n| 2 | **Accounts → buyers** | Tables | `oxygen people search plan --prompt \"<persona>\" --company-domains <csv> --max-per-company 3 --estimate` → `oxygen people search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap> --table <people_table>` | hit domains from `oxygen tables query <signals_table>`; persona titles and seniorities | `--max-per-company` ≤3; only domains whose event is inside the window | `persona-expansion`: paid, human, per run | the plan's `estimated_match_count.basis`; `oxygen tables query <people_table> --limit 25` | an account with no plausible persona — drop it, never loosen `--titles` |\n| 3 | Engagement capture | Signals — pull feeds + reveal webhook | `oxygen linkedin intent setup --account <sender_id> --post <social_id>`; `oxygen viewers import --account <sender_id>`; `oxygen followers import --account <sender_id>`; a reveal source POSTs the webhook, hand-proved by `oxygen signals record --event website_visit --external-event-id <id>` | a healthy sender; the composite `social_id`, not the URN; a de-anon source | the account's ingest budget; ~15 relations reads/day; ≤20 pages × 100 on `oxygen engagement engagers --post <social_id>` | `arm-capture`: human, once per sender — free, contacts nobody | `oxygen linkedin intent status`; `oxygen feeds list`; `oxygen viewers status --account <sender_id>` (reads both lanes; `stalled` names `oxygen feeds resume <id>`) | feeds `paused`/`error`; `viewers status` `stalled`/`unbound`; sender bad in `oxygen senders health <sender_id>` |\n| 4 | **Warm-lead gate** | Records | `oxygen crm setup --live` once; per engagement type `oxygen blueprints apply crm-post-engager` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>`; pulse buyers via `oxygen crm assert` | `crm-website-visitor`, `crm-profile-viewer`, `crm-post-engager`, `crm-follower` — only where the source delivers | free per event under a positive per-delivery cap | `arm-router`: human per router; re-grant after every reapply | `oxygen workflows runs --workflow <workflow_id> --limit 10`; `oxygen crm activity timeline people <row_id>` | a router armed over a dark source — it only makes capture look live |\n| 5 | Rank | Signals | `oxygen signals leads-today --limit 25 --within-days 7`; narrative via `oxygen blueprints apply daily-gtm-digest --input-json '{...}'` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>` | the CRM people table as `source_tables` | `--within-days` ≤30, `--limit` ≤100; digest cap per cycle | `enable-digest`: human, standing spend | leads carry a type and an occurred-at | an empty queue with armed sources is a capture problem |\n| 6 | Assess | Tables | `oxygen columns add <people_table> --kind ai --key icp_fit --data-type jsonb --definition-json '{...}'` → `oxygen columns run <people_table> icp_fit --limit 10 --dry-run` → same `--all --background --approved --max-credits <cap>` → `oxygen tables auto-run set <people_table> --columns icp_fit --max-credits <cap>` | the `icp` page; identified rows only | pilot ≤10 rows; the auto-run cap is per batch, rows past it skip with `credit_limit_reached` | `run-assessment`: paid, human; the auto-run is scoped standing permission | `oxygen cells inspect <people_table> <row_id> icp_fit`, one per band | generic reasons: fix the ICP page, not the prompt |\n| 7 | Route (band gate) | Sequences | own-network `oxygen linkedin intent autoenroll --account <sender_id> --sequence <slug> --kinds profile_viewers,followers` (previews) → same `--approved --max-enrolls-per-day <n>`; table-backed `oxygen sequences enroll <slug> --leads-file leads.json --exclude-contacted` | only rows past the band gate | at or below the sender's effective daily cap; one attempt per person | `arm-routing`: human — the grant reaches people captured later | the preview's audience split; `oxygen sequences enrollments <slug>` | `--include-existing-network` proposed unasked; most leads `bound_to_other_sender` |\n| 8 | Send | Sequences | `oxygen sequences create --name \"Signal-based outbound\" --slug signal-based-outbound --steps-file steps.json --table <people_table> --url-column linkedin_url --max-new-enrollments-per-day 10 --exclude-contacted` → `oxygen sequences update signal-based-outbound --senders <sender_id>` → `oxygen sequences start signal-based-outbound` → same `--approved --max-live-sends <n>` | copy naming the observable event, never an inferred motive | a new sender is floored at 5 invites and 5 messages a day for its first three days | `create-sequence`: human, every call | `oxygen sequences analytics --sequence signal-based-outbound --range 30d` | sender `restricted` or paused; reply-stop fired |\n| 9 | Replies → CRM | Records | `oxygen crm automation set crm-lead-stage-router --armed --live --approved --max-credits 1` | — | free per event | none beyond arming | `oxygen crm automation rules`; `oxygen crm pipeline` | a reply that moved no stage — a disarmed router never re-arms itself |\n| 10 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id>` → same `--approved`; `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\"` | receipts, delivery ledger, analytics | weekly; one rule | canonical pages route through the proposal queue | `oxygen knowledge lint` | a claim with no receipt behind it |\n\n## Numeric guardrails\n\n- **Weights are product data, not a workspace knob.** `oxygen signals registry --json` returns each type's `sourceWeight` — today `website_visit` 100 > `profile_view` 60 > `post_reaction` 40 > `new_follower` 20, all `engagement` family, all live. Never hardcode one, and never claim one for a type the registry lacks: the pulse families have none.\n- **Pulse:** `--max-pages` defaults to 1; the only honest prices are the plan's `estimated_credits` range and `oxygen tools get <tool_id> --json`. Quote a match count only when `estimated_match_count.basis` is `provider_count`. `--last-days` is the event window: a six-month-old hiring post is history, not intent.\n- **Expansion:** `--max-per-company` ≤3, `--require-email` where the lane sends email, and only accounts whose event is in the window. One account never becomes a list.\n- **Queue:** `signals leads-today` defaults to 7 days (`--within-days`, max 30) and 25 leads (`--limit`, max 100). Work the top 5–10 a morning.\n- **Bands:** strong 80–100 = the founder's own message, never automated; qualified 50–79 = the capped sequence; weak and out ≤49 = keep the evidence, send nothing; unknown = hold. Fit is company/segment fit, size/stage and person/persona fit; strength and recency set *order*, never *fit*.\n- **Ceilings and sending:** a trigger, feed or auto-run armed without an explicit `--max-credits` inherits the plan tier's per-delivery default (the preview prints which). `--max-new-enrollments-per-day` bounds first touches, the grant's `--max-enrolls-per-day` defaults to the sender's warm-up-ramped cap, and the 5-invite / 5-message floor for a new sender's first three days is not bypassable.\n- **Identity before scoring:** a row with neither an email nor a canonical `linkedin.com/in/` URL cannot pass the warm-lead gate and is not worth assessing. Missing evidence is never positive evidence.\n\n## Gate spec\n\n**The warm-lead gate (does a person exist).** A raw signal never creates a CRM person. In the engagement lane the armed `crm-*` router for that exact type does, from a stable identity — email plus domain for `website_visit` and signup, a canonical LinkedIn URL for the rest. Two consequences: the engagement→signal bridge **attaches only to people who already have a CRM record** and never creates one, so a capture armed without its router produces rows nobody can rank (writers before signals); and pulse rows carry no registered type, so no router fires on them. In the pulse lane the gate is stage 2 plus an explicit `oxygen crm assert --json` — a hit account becomes a person only once a named buyer with a verified identity is resolved against it. A company event is never itself a lead, installation is never permission, and a signal is a prioritization input: never consent, never proof of intent.\n\n**The band gate (who gets contacted).** The assessment column returns `{ score, band, segment, persona, confidence, reason, disqualifiers, missing_evidence }`. Enforce it where enrollment happens, never in a display formula — row queries cannot filter on formula columns, so filter on the stored JSON plus a null routing status and re-check in the routing step. A person advances only when the band is `qualified`, the score sits inside it, confidence is high or medium, the segment is recognised, `disqualifiers` is empty, person and employer evidence are complete, the identity is canonical, `do_not_contact` is not true, and no prior routing status exists. Nothing bypasses it: never `oxygen sequences enroll <slug> --from-table --json` against a raw signal or expansion table, and never treat `oxygen signals leads-today --json` as an enrollment source — it ranks by strength then recency and does **not** score fit.\n\n## Approval gates, mapped to who decides\n\n| Gate | What it authorises | Attended Copilot | Unattended run |\n| --- | --- | --- | --- |\n| kit apply (`oxygen recipes apply <slug> --dry-run`, then without it) | 0-credit install; workflows land disabled | auto-approvable write | n/a |\n| `pulse-harvest` | one priced company-signal harvest into a table | human card | its `--max-credits` |\n| `bind-feed` | the recurring harvest — standing, separate from the run | human card; re-asked when `--every` or the cap changes | its `--max-credits-per-cycle` |\n| `persona-expansion` | one priced people search scoped to the hit domains | human card | its `--max-credits` |\n| `arm-capture` | the standing read of the account's own viewers, followers, connections, posts | human card, per sender | never armed unattended |\n| `arm-router` | a `crm-*` router's free internal writes | auto-approvable write | its per-delivery cap |\n| `enable-digest` | the daily digest's recurring synthesis | human card | its per-cycle cap |\n| `run-assessment` | one paid column run, then the standing auto-run | human card; the auto-run is scoped standing permission | its per-batch cap |\n| `arm-routing` | enrolling captured people, including people captured later | human card — it reaches strangers | its `--max-enrolls-per-day` |\n| `create-sequence` | creating, attaching a sender to, and starting the sequence | human card, every call — `external_write` is never waived | its `--max-live-sends` |\n| canonical wiki edits | voice, brand, positioning | a proposal a human approves | never |\n\nReads need no approval: `recipes show`, `signals registry|list|leads-today`, `signals search plan`, `people search plan`, `feeds list|deliveries`, `tables query`, `cells inspect`, `workflows runs`, `senders health`, and every preview or `--dry-run`.\n\n## Failure modes\n\n- **Pulse rows are a table, not the stream.** The registry holds four engagement types and no pulse type, so a hiring / funding / tech / news harvest sourced natively with `oxygen signals search run` lands as table rows that no router subscribes to and that never reach `signals leads-today`; work them from the table (stages 1–2), which is shipped sourcing, not a workaround. Check: harvest, then `oxygen signals list --json` — unchanged. Correction: expand, score and enroll from the table (stages 2–7); never promise a trigger on them.\n- **Treating a company event as a lead.** A funding round is an account fact; nobody there raised a hand. Correction: stage 2 first, one persona at a time, with copy naming the event rather than an invented intent.\n- **`no_default_provider_chain` is an answer.** Market-wide `job_change` refuses by design — use `--scope watch_list --domains <csv>` or name a provider, never a substitute family. Likewise market-wide funding and acquisition are one-shot: read `schedulable` before offering a cadence, or the bind returns `feed_not_incremental`.\n- **Quoting a count nobody published.** Render a number only for `basis: \"provider_count\"` and name the probe tool.\n- **Expansion that fills a quota.** Loosening `--titles` or raising `--max-per-company` until the count looks healthy buys a list, not a signal lane. Drop the account instead.\n- **The bridge attaches; it never creates.** A viewer or engager with no CRM record produces no signal — capture rows accrue while `oxygen signals list --json` stays flat. Correction: arm that type's `crm-*` router first. The mirror failure is a router armed over a dark source: free, silent, and it only makes capture look live — compare `oxygen workflows runs --workflow <workflow_id> --limit 10 --json` with the source's own status read.\n- **Suppression is keyed on LinkedIn provider ids**, so email-only reveals surface unchecked — check do-not-contact, competitors, customers and open deals by hand before the first send on a website or pulse lane.\n- **Double-counted redeliveries.** `oxygen signals record --json` is idempotent on `--external-event-id`; a relay that omits it re-counts every retry.\n- **Revision-bound authority.** Reapplying a blueprint publishes a new **disabled** revision; the standing approval must be granted again.\n- **Ceilings, not bugs.** Named viewers are a fraction of real views and de-anonymization resolves a minority of traffic; re-arming widens neither.\n\n## Data-quality checks (after every cycle)\n\n1. `oxygen signals list --since 7 --limit 100 --json` — events by type. A type at zero whose source is armed is a dark source: inaccessible, never absence.\n2. `oxygen feeds list --json`, then `oxygen feeds deliveries --table <table> --json` — any feed `error` or `exhausted`, any `rejected` delivery.\n3. Pulse table: every row has a `signal_date` inside the window and an openable `source_url`; stale dates are history and must not be expanded.\n4. `oxygen tables query <people_table> --limit 100 --json` — rows with neither an email nor a canonical `linkedin.com/in/` URL are held, never given an invented identity. Dedupe keys are `provider_id` (people), `event_key` (touchpoints) and the plan `upsert_key` (pulse).\n5. `oxygen budget list --json` and `oxygen limits show --json` — the resolved thresholds still match what you armed.\n\n## Learning loop\n\n- **What auto-files:** the table delivery ledger, workflow run receipts, enrollment receipts, sequence analytics, CRM stage changes and reply classifications.\n- **What to synthesise weekly:** positive-reply rate *by signal type and by lane* (a funding hit and a profile view are not one channel), by source and by band; band precision; time from event to first touch. `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id> --json`, read it, then re-run `--approved`.\n- **One rule per loop:** the band threshold, the segment, the pulse `--last-days` window, `--max-per-company`, one source on or off, or one cap — written with `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\" --json`; a canonical change files a proposal.\n- **What you cannot change:** a type's `sourceWeight`. There is no per-workspace weighting surface, and pulse families carry none, so their ordering is yours to define in the queue you work.\n- Define \"good\" before arming: a positive reply, a booked meeting, or a closed deal. A loop with no written definition of good is automation, not a loop.\n\n## Go-live checklist\n\n1. `oxygen signals registry --json` + `oxygen signals list --json` — the live types, weights, baseline; `oxygen knowledge page get icp --json` reads `active`, with the segment written beside it.\n2. `oxygen senders health <sender_id> --json` — one usable sender, its warm-up day and daily caps; `oxygen crm setup --live --json` once.\n3. Pulse: `oxygen signals search plan --json` read in full (routes, dropped filters, `schedulable`), then dry-run, then the approved live run under a cap.\n4. Expansion: `oxygen people search plan --company-domains <csv> --max-per-company 3 --estimate --json`, dry-run, then the approved live run into the people table.\n5. Engagement: arm only what you have (`oxygen linkedin intent setup --account <sender_id> --json`, `oxygen viewers import --account <sender_id> --json`, `oxygen followers import --account <sender_id> --json`, the reveal webhook), each verified by its own status read.\n6. Per armed type: `oxygen blueprints apply crm-profile-viewer --json` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap> --json`, confirmed by `oxygen crm activity timeline people <row_id> --json`.\n7. `oxygen signals leads-today --limit 10 --json` returns people carrying a type; `oxygen columns run <people_table> icp_fit --limit 10 --dry-run --json`, then the approved run, then one assessment read per band.\n8. `oxygen sequences start signal-based-outbound --json` previewed, then `--approved --max-live-sends <n>`; `oxygen linkedin intent autoenroll --account <sender_id> --sequence signal-based-outbound --json` previewed — read the audience split — then `--approved` with explicit caps.\n9. `oxygen crm automation rules --json` shows `crm-lead-stage-router` armed; `oxygen budget list --json` and `oxygen limits show --json` match what you armed; log it with `oxygen knowledge log append --event note --slug campaign-learnings --summary \"...\" --json`.\n\n## Open questions (state them, do not resolve them)\n\n- Pulse and product stream emission is unfinished: the registry carries no hiring / funding / tech / acquisition / news / product-usage type, so those harvests are table data nothing subscribes to. Stages 1–2 source and expand pulse hits natively and work them from the table; the stream/registry half is the unfinished end state.\n- Because pulse families carry no `sourceWeight`, the queue cannot interleave a funding hit with a profile view. Cross-lane ranking is a human judgement today; never present it as one ordered list the product produced.\n- `signals registry` is a read-only snapshot derived from code constants — no registry or subscription objects exist, so \"a workflow triggers on a signal\" means a blueprint bound to one type.\n- The suppression identity gap (LinkedIn provider ids only) leaves email-only reveals unchecked, and no `post_comment` type exists, so a comment ranks as a reaction.\n- No CLI command mints a self-serve inbound URL for a de-anonymization vendor, and no `/signals` web route renders the stream or the queue — both are parity gaps to record, not journeys to describe.\n- \"Arm every source at once\" is not ratified strategy. Start with one lane, one source and one bounded segment with a named downstream owner.\n\n## Resume point\n\n`oxygen signals registry --json` — which types exist, which are live, and where a pulse family's absence from the stream becomes visible. Then `oxygen signals list --json` (arriving), `oxygen feeds list --json` (armed), `oxygen tables list --json` (signal and expansion tables), `oxygen crm automation rules --json` plus `oxygen workflows list --json` (resolving and routing), and `oxygen sequences list --json` (sending). Start there, never from scratch.\n";
+    readonly sha256: "b29bcaf04707f4aee4cb0fdafa6a0ee02cff7f0987ee1e55cf313ebadb76454b";
+    readonly content: "---\nname: signal-based-outbound\ndescription: \"Installs the general buying-signal engine: arm company-level pulse sources and person-level engagement sources, expand a hit account into named buyers, gate, rank and score them against the ICP, and route only the qualified band into a capped sequence.\"\n---\n\n# Playbook: signal-based outbound\n\n## Motion in one sentence\n\nSources are armed against one segment in two lanes — **pulse** (a company acts: hiring surge, funding, tech install, news) and **engagement** (a person acts: website visit, profile view, post reaction, follow). The pulse lane expands a hit account into named buyers, the engagement lane resolves a person directly, both converge at the warm-lead gate where a CRM person is created, then rank into one daily queue, are scored against the ICP and split — the strongest to the founder's own hand, the qualified band into a capped sequence. The order matters because every step narrows: capture is wide, expansion is account-bound, resolution is identity-bound, ranking is intent-bound, the band gate is fit-bound, and only the last step contacts anyone.\n\nRecipes cover the engagement sources one at a time (`oxygen recipes show website-visitor-outreach --json`, `profile-viewer-outreach`, `linkedin-intent-to-signup`, `daily-warm-lead-queue`, `speed-to-lead`); the pulse lane has none and is stages 1–2. Every command here takes `--json`.\n\n## Stage table\n\n| # | Stage | Owner | Install / command | Inputs | Cap | Approval | Verify | Stop |\n| --- | --- | --- | --- | --- | --- | --- | --- | --- |\n| 0 | Context + registry | Knowledge Graph + Signals | `oxygen context resolve --purpose outbound_copy`; `oxygen knowledge page get icp`; `oxygen signals registry`; `oxygen signals list --since 7` | a filled `icp`; a written segment | — | none | `icp` reads `active`, not a stub; your types read `captureStatus: live` | a stub ICP, or a type you assumed exists that the registry lacks |\n| 1 | **Pulse — company signals** | Signals — signal search | `oxygen signals search plan --prompt \"<goal>\" --family hiring --scope market --last-days 30 --estimate` → `oxygen signals search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap>` | `--family` hiring/tech/funding/acquisition/news/job_change; `--scope market`, or `watch_list --domains` | the plan's own `estimated_credits`; `--max-pages` defaults to 1; a standing harvest adds `--bind-feed --every daily@9 --max-credits-per-cycle <cap>` | `pulse-harvest`: paid, human, per run; `--bind-feed` is a **second**, standing grant | the plan's `routes[]`, `filter_application`, `schedulable`; then `oxygen feeds deliveries --table <signals_table>` | `no_default_provider_chain`; `feed_not_incremental`; `basis` not `provider_count` |\n| 2 | **Accounts → buyers** | Tables | `oxygen people search plan --prompt \"<persona>\" --company-domains <csv> --max-per-company 3 --estimate` → `oxygen people search run --plan-json ./plan.json --mode dry_run` → same `--mode live --approved --max-credits <cap> --table <people_table>` | hit domains from `oxygen tables query <signals_table>`; persona titles and seniorities | `--max-per-company` ≤3; only domains whose event is inside the window | `persona-expansion`: paid, human, per run | the plan's `estimated_match_count.basis`; `oxygen tables query <people_table> --limit 25` | an account with no plausible persona — drop it, never loosen `--titles` |\n| 3 | Engagement capture | Signals — pull feeds + reveal webhook | `oxygen linkedin intent setup --account <sender_id> --post <social_id>`; `oxygen viewers import --account <sender_id>`; `oxygen followers import --account <sender_id>`; a reveal source POSTs the webhook, hand-proved by `oxygen signals record --event website_visit --external-event-id <id>` | a healthy sender; the composite `social_id`, not the URN; a de-anon source | the account's ingest budget; ~15 relations reads/day; ≤20 pages × 100 on `oxygen engagement engagers --post <social_id>` | `arm-capture`: human, once per sender — free, contacts nobody | `oxygen linkedin intent status`; `oxygen feeds list`; `oxygen viewers status --account <sender_id>` (reads both lanes; `stalled` names `oxygen feeds resume <id>`) | feeds `paused`/`error`; `viewers status` `stalled`/`unbound`; sender bad in `oxygen senders health <sender_id>` |\n| 4 | **Warm-lead gate** | Records | `oxygen crm setup --live` once; per engagement type `oxygen blueprints apply crm-post-engager` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>`; pulse buyers via `oxygen crm assert` | `crm-website-visitor`, `crm-profile-viewer`, `crm-post-engager`, `crm-follower` — only where the source delivers | free per event under a positive per-delivery cap | `arm-router`: human per router; re-grant after every reapply | `oxygen workflows runs --workflow <workflow_id> --limit 10`; `oxygen crm activity timeline people <row_id>` | a router armed over a dark source — it only makes capture look live |\n| 5 | Rank | Signals | `oxygen signals leads-today --limit 25 --within-days 7`; narrative via `oxygen blueprints apply daily-gtm-digest --input-json '{...}'` → `oxygen workflows enable <workflow_id> --approved --max-credits <cap>` | the CRM people table as `source_tables` | `--within-days` ≤30, `--limit` ≤100; digest cap per cycle | `enable-digest`: human, standing spend | leads carry a type and an occurred-at | an empty queue with armed sources is a capture problem |\n| 6 | Assess | Tables | `oxygen columns add <people_table> --kind ai --key icp_fit --data-type jsonb --definition-json '{...}'` → `oxygen columns run <people_table> icp_fit --limit 10 --dry-run` → same `--all --background --approved --max-credits <cap>` → `oxygen tables auto-run set <people_table> --columns icp_fit --max-credits <cap>` | the `icp` page; identified rows only | pilot ≤10 rows; the auto-run cap is per batch, rows past it skip with `credit_limit_reached` | `run-assessment`: paid, human; the auto-run is scoped standing permission | `oxygen cells inspect <people_table> <row_id> icp_fit`, one per band | generic reasons: fix the ICP page, not the prompt |\n| 7 | Route (band gate) | Sequences | own-network `oxygen linkedin intent autoenroll --account <sender_id> --sequence <slug> --kinds profile_viewers,followers` (previews) → same `--approved --max-enrolls-per-day <n>`; table-backed `oxygen sequences enroll <slug> --leads-file leads.json --exclude-contacted` | only rows past the band gate | at or below the sender's effective daily cap; one attempt per person | `arm-routing`: human — the grant reaches people captured later | the preview's audience split; `oxygen sequences enrollments <slug>` | `--include-existing-network` proposed unasked; most leads `bound_to_other_sender` |\n| 8 | Send | Sequences | `oxygen sequences create --name \"Signal-based outbound\" --slug signal-based-outbound --steps-file steps.json --table <people_table> --url-column linkedin_url --max-new-enrollments-per-day 10 --exclude-contacted` → `oxygen sequences update signal-based-outbound --senders <sender_id>` → `oxygen sequences start signal-based-outbound` → same `--approved --max-live-sends <n>` | copy naming the observable event, never an inferred motive | a new sender is floored at 5 invites and 5 messages a day for its first three days | `create-sequence`: human, every call | `oxygen sequences analytics --sequence signal-based-outbound --range 30d` | sender `restricted` or paused; reply-stop fired |\n| 9 | Replies → CRM | Records | `oxygen crm automation set crm-lead-stage-router --armed --live --approved --max-credits 1` | — | free per event | none beyond arming | `oxygen crm automation rules`; `oxygen crm pipeline` | a reply that moved no stage — a disarmed router never re-arms itself |\n| 10 | Learn | Knowledge Graph | `oxygen knowledge synthesize --kind campaign_learnings --sequence <sequence_id>` → same `--approved`; `oxygen knowledge log append --event decision --slug campaign-learnings --summary \"...\"` | receipts, delivery ledger, analytics | weekly; one rule | canonical pages route through the proposal queue | `oxygen knowledge lint` | a claim with no receipt behind it |\n\n## Numeric guardrails\n\n- **Weights are product data, not a workspace knob.** `oxygen signals registry --json` returns each type's `sourceWeight` — today `website_visit` 100 > `profile_view` 60 > `post_reaction` 40 > `new_follower` 20, all `engagement` family, all live. Never hardcode one, and never claim one for a type the registry lacks: the pulse families have none.\n- **Pulse:** `--max-pages` defaults to 1; the only honest prices are the plan's `estimated_credits` range and `oxygen tools get <tool_id> --json`. Quote a match count only when `estimated_match_count.basis` is `provider_count`. `--last-days` is the event window: a six-month-old hiring post is history, not intent.\n- **Expansion:** `--max-per-company` ≤3, `--require-email` where the lane sends email, and only accounts whose event is in the window. One account never becomes a list.\n- **Queue:** `signals leads-today` defaults to 7 days (`--within-days`, max 30) and 25 leads (`--limit`, max 100). Work the top 5–10 a morning.\n- **Bands:** strong 80–100 = the founder's own message, never automated; qualified 50–79 = the capped sequence; weak and out ≤49 = keep the evidence, send nothing; unknown = hold. Fit is company/segment fit, size/stage and person/persona fit; strength and recency set *order*, never *fit*.\n- **Ceilings and sending:** a trigger, feed or auto-run armed without an explicit `--max-credits` inherits the plan 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/copilot-skills.generated.js

@@ -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;