fullstackgtm 0.40.0 → 0.42.0

package/CHANGELOG.md

@@ -7,6 +7,63 @@ The path to 1.0 is planned in [docs/roadmap-to-1.0.md](./docs/roadmap-to-1.0.md)
 
 ## [Unreleased]
 
+## [0.42.0] — 2026-06-25
+
+### Added
+
+- **Bulk apply for lead creation (HubSpot + Salesforce).** `applyPatchPlan` now
+  routes independent, approved `create_record` **contact** ops through a new
+  optional connector capability, `applyCreateContactsBatch`, instead of two API
+  round-trips per lead (a resolve-first search + a create). HubSpot batches the
+  resolve-first via a `search` `IN` and creates via `batch/create` (100/call);
+  Salesforce batches via a SOQL `IN` and the Composite sObject Collections API
+  (`allOrNone: false`, 200/call). A batch rejection (e.g. a duplicate that the
+  provider 4xxs the whole batch over) falls back to per-record `createRecord`, so
+  one bad row never sinks the rest and resolve-first is preserved. Turns ~2N API
+  calls into ~N/100; ops that aren't safe to batch (grouped, value-overridden,
+  company-associated, conflicted, or non-create) stay on the serial path
+  unchanged. Connectors without the capability are unaffected.
+
+## [0.41.0] — 2026-06-23
+
+### Added
+
+- **Signal-based outbound: `signals`, `icp judge`/`icp eval`, `draft`.** A timing
+  layer on top of CRM hygiene — reach an account the week something changes, not
+  from a rented list. `signals fetch/list/outcome/weights` captures buying
+  triggers into a local, profile-scoped ledger (Detect-side — it writes nothing
+  to the CRM), sorted into five weighted buckets
+  (`demand`/`funding`/`job`/`company`/`social`); public ATS boards (Greenhouse,
+  Lever, Ashby) are the free, no-auth source in the box, while
+  funding/company/social arrive via staged ingest and `demand` is reserved for a
+  privileged source. A reposted role outweighs a first-time post, and recorded
+  outcomes (`signals outcome`) re-weight which buckets earn a touch. `icp judge`
+  scores each account on timing × fit × memory into `send`/`nurture`/`skip` —
+  every *why-now* must quote a real trigger verbatim (the same evidence gate as
+  `call`/`market`), with a deterministic baseline when no LLM key is set.
+  `icp eval` grades the judge against a golden set (and hot-vs-cold outcomes),
+  exiting `2` below the bar — the calibration gate that blocks a miscalibrated
+  judge from a live send. `draft` writes one trigger-grounded opener per hot
+  account as a governed `create_task` plan through the existing approve → apply
+  gate; it has no send capability and adds none. All four are read/plan-side and
+  schedulable; none can auto-apply or send.
+- **LLM base-URL override.** `ANTHROPIC_API_BASE_URL` / `OPENAI_API_BASE_URL` let
+  every LLM feature run against an Anthropic/OpenAI-compatible endpoint (e.g. a
+  GLM/z.ai endpoint or a local Ollama) with no code change; unset preserves the
+  default endpoints.
+
+### Changed
+
+- **pipe0 resolution runs chunks in parallel (bounded) with exponential backoff.**
+  `pipe0ResolveWorkEmails` and `pipe0ResolveCompanyDomains` previously issued one
+  serial HTTP call per chunk — a few hundred leads took tens of minutes. They now
+  run up to `concurrency` chunks at once (default 3) with exponential backoff on
+  transient failures (throttle/5xx/network: 500ms → 4s, up to 5 attempts). Bounded
+  concurrency + real backoff cuts wall-clock several-fold while keeping coverage:
+  an early concurrency-6 + single-retry build throttled pipe0 at scale and dropped
+  the work-email hit-rate from ~79% to ~17%, so the pairing matters. Chunk size
+  stays small (the waterfall's batch failure is all-or-nothing).
+
 ## [0.40.0] — 2026-06-23
 
 ### Added

package/README.md

@@ -206,6 +206,35 @@ LinkedIn is just another discovery source on the same scored → deduped → met
 
 **Leads are never born ownerless.** An `acquire.assign` policy stamps an owner onto every created lead at create time (mapped to HubSpot `hubspot_owner_id`), routed by one of four strategies — `fixed`, `round-robin` (distributed deterministically, no rotation state to drift), `territory` (by geo / industry / size / department / title), or `account-owner` (inherit the matched company's owner). With no policy and a single-owner portal, acquire defaults every lead to that owner (or pass `--assign-owner <id>`); with multiple owners and no policy it warns and leaves them unassigned rather than guess. To clear *existing* ownerless records, `reassign --assign-unowned --to <ownerId>` applies the same intent as a backfill.
 
+## Signal-based outbound: reach accounts the week something changes
+
+Cleaning and filling the CRM tells you *who* to reach; it never tells you *when*. The **signal → judge → draft** loop adds timing — and, like everything else, it stays on the dry-run → approve → apply spine and sends nothing.
+
+```bash
+# 1. Watch for movement. Free, no-auth public job boards in the box; funding/company/social via staged ingest.
+fullstackgtm signals fetch --bucket job --source greenhouse,lever,ashby --keywords "revops,growth" --save
+fullstackgtm signals list --since 7d                         # ranked triggers, each with a verbatim source quote
+
+# 2. Decide who's worth a touch — and who isn't. Scores timing × fit × memory into send/nurture/skip.
+fullstackgtm icp judge --signals-from latest --with-history --save
+fullstackgtm icp eval --golden default                       # gate: prove the judge is calibrated before any send (exits 2 if not)
+
+# 3. Draft the opener from the trigger. A create_task plan — proposed, never transmitted.
+fullstackgtm draft --from-judge latest --min-score 80 --save
+fullstackgtm plans approve <id> --operations all && fullstackgtm apply --plan-id <id> --provider hubspot
+
+# 4. Close the loop. Outcomes re-weight which signals earn a touch.
+fullstackgtm signals outcome --account acme.com --result replied
+```
+
+**`signals`** is Detect-side — it captures triggers into a local, profile-scoped ledger and writes *nothing* to your CRM. The five buckets (`demand`, `funding`, `job`, `company`, `social`) are not equal: a fresh round outweighs a lone social like, and a *reposted* role — the first hire fell through — outweighs a first-time post. Public ATS boards (Greenhouse, Lever, Ashby) are the free, no-auth source shipped in the box; funding/company/social arrive through `--from` staged ingest (an agent or a feed supplies them — the CLI scrapes no one), and `demand` (first-party intent) is reserved for a privileged source.
+
+**`icp judge`** turns raw signals into a short ranked list: it scores each account on **timing × fit × memory** — the signal's weight and recency, your ICP fit, and whether you've touched the account in the last 7 days — and returns `send` / `nurture` / `skip`. Every *why-now* it produces must quote a real trigger **verbatim** (the same evidence gate as `call` and `market`); an ungrounded why-now is never stored. With no LLM key it runs a deterministic baseline. **`icp eval`** is the gate the demos skip: it grades the judge against a labeled golden set (and, once outcomes exist, checks that accounts scored hot actually book more than cold), exiting `2` below the bar so a miscalibrated judge can't reach a live send.
+
+**`draft`** writes one opener per hot account whose first line quotes the trigger in the buyer's own words — no "Hi {{firstName}}", one ask, no manufactured urgency. It emits a `create_task` plan through the normal approval gate; it has **no send capability** and adds none — execution stays in your sender of choice. Without an LLM key it emits a clearly-labeled stub, never wooden copy passed off as a draft.
+
+**Runs on any model.** Every LLM step honors `ANTHROPIC_API_BASE_URL` / `OPENAI_API_BASE_URL`, so the same loop runs on Claude, a GLM/z.ai endpoint, or a local Ollama by pointing one env var — `--model` picks the model id.
+
 ## Schedules: declare a cadence once, keep the governance contract under automation
 
 Everything the CLI produces is accurate the moment it runs and silently stale afterward. The **schedule layer** is the horizontal fix — any read/plan-side command on a cron cadence, one component, every verb (no feature owns its own cron logic):
@@ -220,7 +249,7 @@ fullstackgtm schedule status --runs 5            # last runs, exit codes, artifa
 fullstackgtm schedule uninstall                  # remove the managed block, touch nothing else
 ```
 
-**Scheduling never auto-approves.** Schedulable commands are read/plan-side only — `audit`, `snapshot`, `enrich append|refresh`, `market capture|refresh`, `suggest`, `report`, `doctor` — so unattended runs accumulate *proposals* (plans in the queue, run records, reports), never CRM writes. `apply` is schedulable only as `apply --plan-id <id>`, and every firing re-checks the plan's status is approved: an unapproved plan records a `plan_not_approved` no-op run instead of executing, and no flag relaxes this. Arbitrary shell is not schedulable — an entry's argv must resolve to a known fullstackgtm command (validated at `add` time and re-checked at run time), and the crontab line you audit is always `fullstackgtm schedule run <id>` and nothing else.
+**Scheduling never auto-approves.** Schedulable commands are read/plan-side only — `audit`, `snapshot`, `enrich append|refresh`, `market capture|refresh`, `signals fetch`, `icp judge`, `icp eval`, `draft`, `suggest`, `report`, `doctor` — so unattended runs accumulate *proposals* (plans in the queue, run records, reports), never CRM writes. `apply` is schedulable only as `apply --plan-id <id>`, and every firing re-checks the plan's status is approved: an unapproved plan records a `plan_not_approved` no-op run instead of executing, and no flag relaxes this. Arbitrary shell is not schedulable — an entry's argv must resolve to a known fullstackgtm command (validated at `add` time and re-checked at run time), and the crontab line you audit is always `fullstackgtm schedule run <id>` and nothing else.
 
 `install` renders enabled entries into a sentinel-delimited block (`# >>> fullstackgtm <profile> >>>` … `# <<< fullstackgtm <profile> <<<`) in your user crontab; re-install replaces the block wholesale and never touches lines outside it. Honest limitation: local cron has no catch-up — a laptop asleep at firing time means a missed run. `schedule status` surfaces missed firings by comparing expected-vs-actual run history, so the gap is at least visible. Entries are provider-agnostic; cloud providers (Modal, AWS) arrive as scaffold generators that call the same `schedule run <id>` contract, and are refused as "not yet implemented" until then.