@agent-native/core 0.123.0 → 0.123.1

package/corpus/templates/crm/changelog/2026-07-26-any-list-or-view-can-be-shown-as-a-board-grouped-by-stage-so.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Any list or view can be shown as a board grouped by stage, so a pipeline can be dragged through its stages instead of edited row by row.

package/corpus/templates/crm/changelog/2026-07-26-crm-now-finds-likely-duplicate-records-and-tells-you-exactly.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+CRM now finds likely duplicate records and tells you exactly why each pair matched, then merges them into the record you choose without losing anything from either side.

package/corpus/templates/crm/changelog/2026-07-26-enrichment-now-shows-what-a-run-will-cost-before-it-starts-g.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Enrichment now shows what a run will cost before it starts, gathers free evidence first, and only spends on the records you approved.

package/corpus/templates/crm/changelog/2026-07-26-lists-turn-any-set-of-records-into-a-pipeline-with-its-own-s.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Lists turn any set of records into a pipeline with its own stage and fields, and they stay yours even when the records come from HubSpot or Salesforce.

package/corpus/templates/crm/changelog/2026-07-26-moving-a-record-or-list-entry-into-a-stage-that-was-retired-.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-07-26
+---
+
+Moving a record or list entry into a stage that was retired or never declared is now refused with the reason and the stages you can pick, and a stage somebody else moved in the meantime is reported instead of being overwritten

package/corpus/templates/crm/changelog/2026-07-26-opening-a-record-now-shows-one-page-with-its-fields-the-list.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Opening a record now shows one page with its fields, the lists it belongs to, its activity and evidence, and the full change history of any single value.

package/corpus/templates/crm/changelog/2026-07-26-press-cmd-k-to-jump-to-any-record-list-view-or-setting-and-u.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Press Cmd+K to jump to any record, list, view or setting, and use keyboard shortcuts to move through the grid without reaching for the mouse.

package/corpus/templates/crm/changelog/2026-07-26-provider-record-edits-now-show-an-exact-before-after-diff-an.md

@@ -0,0 +1,6 @@
+---
+type: improved
+date: 2026-07-26
+---
+
+Provider record edits now show an exact before/after diff and open the record in HubSpot or Salesforce to finish the change, instead of reporting a failure

package/corpus/templates/crm/changelog/2026-07-26-record-page-attribute-labels-now-read-in-full-instead-of-bei.md

@@ -0,0 +1,6 @@
+---
+type: improved
+date: 2026-07-26
+---
+
+Record page attribute labels now read in full instead of being cut off, and the Highlights panel starts from a curated set per record type.

package/corpus/templates/crm/changelog/2026-07-26-records-now-use-typed-fields-currency-dates-ratings-status-s.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Records now use typed fields — currency, dates, ratings, status, select, references and more — and every field remembers who changed it, when, and what it was before.

package/corpus/templates/crm/changelog/2026-07-26-retyping-a-value-on-the-record-page-now-replaces-it-instead-.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-07-26
+---
+
+Retyping a value on the record page now replaces it instead of merging with the old text.

package/corpus/templates/crm/changelog/2026-07-26-settings-now-has-fields-and-lists-tabs-for-adding-fields-edi.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+Settings now has Fields and Lists tabs for adding fields, editing their allowed options and stage targets, and archiving what you no longer use.

package/corpus/templates/crm/changelog/2026-07-26-the-proposal-review-now-shows-the-field-that-actually-change.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-07-26
+---
+
+The proposal review now shows the field that actually changed instead of reading "Empty" on both sides.

package/corpus/templates/crm/changelog/2026-07-26-the-record-grid-is-now-a-real-spreadsheet-filter-sort-and-pa.md

@@ -0,0 +1,6 @@
+---
+type: added
+date: 2026-07-26
+---
+
+The record grid is now a real spreadsheet: filter, sort and page over the full data set, edit in place, and copy or paste ranges straight to a spreadsheet.

package/corpus/templates/crm/components.json

@@ -0,0 +1,20 @@
+{
+  "$schema": "https://ui.shadcn.com/schema.json",
+  "style": "default",
+  "rsc": false,
+  "tsx": true,
+  "tailwind": {
+    "config": "",
+    "css": "app/global.css",
+    "baseColor": "slate",
+    "cssVariables": true,
+    "prefix": ""
+  },
+  "aliases": {
+    "components": "@/components",
+    "utils": "@/lib/utils",
+    "ui": "@/components/ui",
+    "lib": "@/lib",
+    "hooks": "@/hooks"
+  }
+}

package/corpus/templates/crm/docs/architecture/crm-contract.md

@@ -0,0 +1,214 @@
+# CRM kernel contract
+
+This contract is the boundary for the Native SQL CRM and the HubSpot and
+Salesforce companion implementations. It prevents either connected provider's
+object model or permission semantics from becoming the product model.
+
+It is the _design_ record: identity, field policy, access scope, the write
+matrix, and the provider-model validation behind them. The operating rules an
+agent follows every turn live in [`AGENTS.md`](../../AGENTS.md), and the
+workflows behind them in the [`crm` skill](../../.agents/skills/crm/SKILL.md).
+Those two are the single source; this document explains _why_ they say what they
+say and must not restate them differently.
+
+## Canonical vocabulary
+
+- **Connection**: an authorized workspace integration grant and provider
+  account. Tokens remain in workspace connections; CRM stores only the
+  connection id and non-secret account metadata. Native SQL uses a CRM-owned
+  native connection identity and never has an integration token.
+- **Object definition**: a provider or CRM-owned schema for one object type,
+  including field types and effective capabilities for its authority.
+- **Attribute**: one typed field definition on an object type or a list. Its
+  type comes from the registry in `shared/crm-attributes.ts`; its `apiSlug` and
+  type are immutable once assigned, because every stored value row is keyed and
+  typed by them. Authority is `provider`, `derived-local`, or
+  `local-authoritative` per attribute — this, not the connection mode, is what
+  decides who may write a field.
+- **Attribute option**: a managed allowed value for a `status` or `select`
+  attribute, optionally carrying a stage SLA (`targetDays`). Options are never
+  auto-created by a value write; an unknown value is a typed 422.
+- **Field value**: bitemporal. A change closes the current row (`activeUntil`)
+  and opens a new one (`activeFrom`) with its actor and provenance, so value
+  history and stage history are the same thing. An equal write is suppressed
+  entirely. `historyTracked = false` opts a churny mirror field out of history
+  by updating in place; that is not the same as "never changed".
+- **Record**: one provider or native object instance. Canonical kinds are
+  `account`, `person`, `opportunity`, `activity`, `task`, and `custom`.
+- **List**: a workflow overlay over exactly one object type, with its own entry
+  attributes. **List entry**: one record's membership in a list, holding that
+  list's attribute values. Lists and entries are local-authoritative on every
+  backend including HubSpot and Salesforce, so a pipeline never requires a
+  provider write. There is deliberately no unique constraint on
+  `(list_id, record_id)`: two open deals for one company are two entries.
+- **Saved view**: stored filter, ordered sort, columns, audience, and a `table`
+  or `board` presentation (a board groups by a status attribute). A filter
+  condition value may be the literal `"@currentUser"`, resolved server-side
+  against the calling actor.
+- **Relationship**: a directed edge between records. It preserves a provider
+  relationship id or source reference field and optional directional labels.
+- **Interaction**: a bounded relationship event such as a meeting, call,
+  email, or note. Rich media remains in its source app/provider.
+- **Evidence**: a URL/id plus bounded quote, timestamp, speaker, and source
+  metadata supporting a CRM claim. Evidence is not a transcript or media blob.
+- **Signal**: a first-class, reviewable moment, call summary, or next step with
+  a bounded quote/summary, timestamp, confidence, detector/model metadata, and
+  an evidence reference. Signals never contain transcript bodies.
+- **Cadence**: desired contact interval, last meaningful interaction, and next
+  contact date for an account or person.
+- **Mirror**: a scoped local projection for fast lists, monitoring, joins, and
+  agent context. It is not a second ungoverned copy of the upstream CRM.
+- **Local field**: a derived or user-authored field whose authority is CRM.
+- **Mutation**: a typed create/update/delete/association request with an
+  idempotency key and optional expected remote revision.
+- **Proposal**: a mutation awaiting review or an agent-generated preview.
+
+The TypeScript source of truth is
+[`shared/crm-contract.ts`](../../shared/crm-contract.ts).
+
+## Identity and provenance
+
+Connected-provider identity is the tuple:
+
+`connection_id + provider + object_type + remote_id`
+
+Native SQL record ids are opaque CRM-local identifiers with `provider: native`;
+they are never sent upstream. Email and domain are matching
+signals, not identity keys. Every mirrored field keeps field-level provenance:
+provider, connection, object type, remote id, optional field name, observed
+revision/time, and optional evidence reference.
+
+Relationships preserve direction because HubSpot association type ids and
+Salesforce reference fields are directional. Identity resolution may link two
+records, but never merges provider identities or silently overwrites one
+provider with another.
+
+## Thin mirror and authority
+
+The mirror contains only configured cohorts: selected pipelines, active
+accounts, their linked people, explicitly linked records, recent interaction
+metadata, and local-owned objects. List and monitoring views read from it;
+record detail performs a read-through refresh; long-tail or exhaustive work
+uses provider API requests and staged data programs.
+
+Every mirrored record stores the remote revision, sync cursor/time, tombstone,
+connection identity, and access-scope key. Upstream is authoritative for every
+attribute whose authority is `provider`; CRM is authoritative for
+`derived-local` and `local-authoritative` attributes, and for all lists, list
+entries, and entry values regardless of backend. In Native SQL mode CRM is
+authoritative for the record and all its fields; no remote revision, provider
+token, or sync cursor is invented.
+
+Authority is per attribute, which is what the `hybrid` connection mode was for.
+That mode is deprecated: the enum value stays for rows already carrying it
+(schema changes are additive), it is no longer offered or documented, and it
+must be read as `mirrored`.
+
+No raw provider response, audio, video, transcript, screenshot, base64 body, or
+file payload is stored in CRM SQL.
+
+## Call intelligence boundary
+
+CRM may link one Clips artifact to several CRM records through separate scoped
+evidence rows. Deterministic keyword detectors operate only on the bounded
+stored excerpts. Smart detectors and summaries are delegated to agent chat;
+server actions do not call a model. Delegated results are accepted only when
+the run, record, tracker, and evidence scopes agree and every quote/timestamp
+is grounded to the stored evidence excerpt. Clips retains recording,
+transcript, consent, recovery, and media ownership.
+
+The default-off Clips review recipe is scoped to one explicitly selected CRM
+record, and its trigger is installed in Clips because that is where
+`clip.created` is registered. The contract's requirement is only that CRM
+receives an opaque id and a durable page reference — never media, a transcript,
+a temporary grant, an inferred record, or a provider write — so both CRM record
+ACLs and Clips page access hold without duplicating source media. The exact
+activation sequence is in the `crm` skill.
+
+## Field storage policy
+
+Unknown fields are **not mirrored**. A field value enters the mirror only when
+it is on the configured allow-list.
+
+| Policy                | Stored locally                            | Read behavior                     | Write authority                |
+| --------------------- | ----------------------------------------- | --------------------------------- | ------------------------------ |
+| `mirrored`            | Bounded typed value                       | Mirror, then read-through refresh | Provider                       |
+| `remote-only`         | Metadata, never the value                 | Fetch ephemerally from provider   | Provider                       |
+| `redacted`            | Neither metadata value nor value          | Do not fetch or expose            | None                           |
+| `derived-local`       | Typed value plus provenance/evidence refs | Local                             | CRM computation                |
+| `local-authoritative` | Typed value                               | Local                             | Human or approved CRM workflow |
+
+Sensitive fields default to `redacted`; other newly discovered fields default
+to `remote-only`. An admin must explicitly allow-list a field as `mirrored`.
+
+## Access-scope semantics
+
+`ownableColumns()` and framework access checks provide the local privacy
+boundary. Provider access remains a second, non-substitutable boundary.
+
+Connected records and field projections carry the connection actor, grant id,
+record-visibility mode, object CRUD capabilities, and hashes/fingerprints for
+effective field and sharing access. A service-account mirror must not be shown
+as though it inherited a human user's Salesforce sharing or field-level
+permissions. Reads fail closed when the current access scope cannot be proven
+compatible. Scope changes invalidate or quarantine affected mirror rows until
+they are refreshed. Native SQL uses its CRM ownership/share scope and does not
+claim or emulate an upstream provider permission.
+
+## Write policy matrix
+
+| Initiator and operation                                             | Default decision      | Required behavior                                         |
+| ------------------------------------------------------------------- | --------------------- | --------------------------------------------------------- |
+| Human, direct scoped edit                                           | Execute               | Optimistic UI, conflict check, undo where possible, audit |
+| Agent, local and reversible                                         | Execute               | Must pass access and stored policy; audit                 |
+| Agent, provider and reversible                                      | Propose               | Preview first; execute only with delegated authority      |
+| Agent, bulk/destructive/ownership/amount/stage/external side effect | Require approval      | Preview exact scope and changed fields; fail closed       |
+| Automation with stored policy                                       | Execute inside policy | No per-run prompt; stop and propose/deny outside policy   |
+
+Named high-risk classes remain approval-gated even when routine provider writes
+have delegated authority. A later policy version may add field-specific
+delegation without weakening the destructive/bulk boundary. A human `execute`
+decision assumes the initiating UI has already collected any required
+destructive confirmation; the policy layer does not add a second prompt.
+
+All mutations are idempotent, access-checked, audited, and record the actor,
+policy decision, before/after field summary, provider response status, and
+remote revision. Provider conflicts never overwrite silently.
+
+`applyMutation` represents one logical record mutation, not one HTTP request.
+Adapters may use provider batch endpoints internally. A future bulk action can
+add an `applyMutations` adapter method without changing the single-mutation
+contract.
+
+## Provider-model validation
+
+| Contract concern              | Native SQL                                      | HubSpot                                       | Salesforce                                                  | Contract consequence                                          |
+| ----------------------------- | ----------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- |
+| Object names                  | Canonical CRM and generic custom object names   | Built-ins plus numeric/custom object type ids | Standard and `__c` API names                                | `objectType` is an opaque case-preserving string              |
+| Record ids                    | CRM-local opaque id                             | String ids                                    | 15/18-character string ids                                  | Record refs preserve provider and opaque identity             |
+| Schema discovery              | CRM-owned canonical schema                      | Properties and CRM schemas APIs               | sObject/Object Info describe                                | Adapter returns object and field capabilities                 |
+| Accounts/people/opportunities | Account/person/opportunity                      | Companies/contacts/deals                      | Account/Contact/Opportunity                                 | Canonical kind is separate from provider object type          |
+| Relationships                 | CRM-directed edge                               | Directional association type ids and labels   | Reference fields and child relationships                    | Directed edge preserves type, label, and source field         |
+| Custom objects                | Generic display/link/write, no object authoring | Schema-discovered                             | `__c` and describe-discovered                               | V1 generic discover/search/display/link/write support         |
+| Remote revision               | Local mutation version                          | `updatedAt`                                   | `LastModifiedDate` or `SystemModstamp`                      | Revision is opaque; Native never claims a remote revision     |
+| Deletion                      | CRM tombstone/archive policy                    | Archived records                              | Deleted records/query-all semantics                         | Tombstone is first-class and sync-capability gated            |
+| Permissions                   | CRM ownership and sharing scope                 | OAuth scopes, object/property sensitivity     | CRUD, FLS, record sharing                                   | Access scope is stored and checked independently of local ACL |
+| Conditional write             | Local version check                             | Provider-specific conflict strategy           | `If-Unmodified-Since`/revision-aware update where available | Adapter reports capability and never invents success          |
+
+Reference checks used for this validation:
+
+- [HubSpot CRM objects and associations](https://developers.hubspot.com/docs/api-reference/latest/crm/understanding-the-crm)
+- [HubSpot association definitions and labels](https://developers.hubspot.com/docs/api-reference/latest/crm/associations/associations-schema/guide)
+- [Salesforce object metadata](https://developer.salesforce.com/docs/platform/graphql/guide/query-objectinfo.html)
+- [Salesforce record queries and effective permissions](https://developer.salesforce.com/docs/platform/graphql/guide/query-record-objects.html)
+- [Salesforce revision-aware record updates](https://developer.salesforce.com/docs/platform/lwc/guide/reference-update-record.html)
+
+## Initial-scope boundary
+
+This scope is Native SQL plus a HubSpot and Salesforce companion. Native SQL is
+the portable, local-authoritative replacement path; it does not depend on or
+synchronize to HubSpot or Salesforce. Provider migration, a full
+object-authoring engine, and a page builder remain out of scope. Provider writes
+stay proposal-first until an adapter can prove the required revision,
+access-scope, and approval guarantees — a proposal handed off for completion
+upstream is the finished state of that flow, not a degraded one.

package/corpus/templates/crm/docs/features/README.md

@@ -0,0 +1,55 @@
+# CRM — Features
+
+This folder explains what CRM is for and what users can do in the product. It
+describes the shipped user experience; the [CRM contract](../architecture/crm-contract.md)
+and the [agent guide](../../AGENTS.md) cover implementation and operating rules.
+
+## Shipped core
+
+CRM gives teams one place to work with customer records, pipeline context, and
+follow-up work:
+
+- **Records and fields (F1)** — spreadsheet-style records with typed
+  attributes, filtering, sorting, pagination, keyboard navigation, and value
+  history.
+- **Lists, pipelines, and views (F2)** — local workflow lists with entry
+  fields, saved table views, and status-based boards.
+- **Work and record quality (F3)** — follow-up tasks, pipeline dashboards,
+  duplicate detection and merge, and approval-gated enrichment.
+- **Evidence and chat (F4)** — bounded call evidence, reviewable signals, and
+  agent actions that use the same product rules as the UI.
+
+## Modes
+
+CRM can start as a standalone system of record or as a scoped companion to a
+connected CRM:
+
+- **Native SQL** — CRM owns accounts, people, opportunities, lists, views,
+  tasks, and local fields. No provider account is required.
+- **HubSpot or Salesforce** — the connected provider remains authoritative for
+  its own fields. CRM adds scoped record work, local lists and pipelines,
+  saved views, tasks, evidence, and analysis.
+
+In either mode, lists and their entry values remain local to CRM. Provider edits
+are prepared as reviewable proposals with an exact before/after diff; the final
+change is completed in the provider.
+
+## Features
+
+| Feature                                                                | Status | What it covers                                            |
+| ---------------------------------------------------------------------- | ------ | --------------------------------------------------------- |
+| [F1 — Records and fields](./f1-records-and-fields.mdx)                 | done   | Records, typed attributes, grid, record page, and history |
+| [F2 — Lists, pipelines, and views](./f2-lists-pipelines-and-views.mdx) | done   | Workflow lists, boards, saved views, and stage history    |
+| [F3 — Work and record quality](./f3-work-and-record-quality.mdx)       | done   | Tasks, dashboards, dedupe, merge, and enrichment          |
+| [F4 — Evidence and chat](./f4-evidence-and-chat.mdx)                   | done   | Call evidence, signals, agent parity, and useful prompts  |
+
+## First steps
+
+1. Open **Set up CRM** and choose **Start with Native SQL**, or authorize and
+   grant a HubSpot or Salesforce connection from shared Settings.
+2. Add records or sync a small, recent provider cohort.
+3. Create a list for the workflow you want to manage, then add records to it.
+4. Save a table or board view for the way you want to return to that work.
+
+The command menu (**⌘K**) can open records, lists, views, settings, and work
+without requiring a particular navigation path.

package/corpus/templates/crm/docs/features/f1-records-and-fields.mdx

@@ -0,0 +1,52 @@
+---
+id: F1
+title: Records and fields
+status: done
+order: 1
+---
+
+# F1 — Records and fields
+
+## What it is
+
+A **record** is a customer, company, opportunity, activity, task, or custom
+object that CRM can find and work with. Records are displayed in a spreadsheet-
+style grid and can be opened in a detail page without losing the surrounding
+list context.
+
+## What users can do
+
+<!-- status: done -->
+
+- Add native records for accounts, people, opportunities, activities, tasks,
+  and custom objects.
+- Search, filter, sort by multiple columns, and move through paginated results.
+- Move through cells with the keyboard and copy or paste tab-separated values.
+- Open a record to see its fields, lists, interactions, evidence, and history.
+- Create and manage typed attributes from **Settings → Fields**.
+- Find likely duplicates, inspect the matching reasons, and merge records with
+  an explicit survivor choice.
+
+## Typed fields
+
+Fields can be text, numbers, checkboxes, currency, dates, timestamps, ratings,
+statuses, selects, record or actor references, locations, domains, email
+addresses, and phone numbers. Status and select fields use managed options, so
+an accidental value cannot create an untracked stage.
+
+## History and authority
+
+Each meaningful field change records who changed it and when. A record's stage
+history is therefore part of its value history. Repeating the same value does
+not create another history entry.
+
+In Native SQL mode, CRM owns the record and its local fields. In connected mode,
+the provider owns provider fields while CRM owns local fields and workflow
+data. CRM does not silently overwrite provider data.
+
+## Connected records
+
+Connect HubSpot or Salesforce from shared Settings and grant the connection to
+CRM. Start with a small, recent cohort and an explicit object scope. CRM keeps
+the configured mirror bounded; unknown or sensitive provider fields are not
+automatically copied into CRM.

package/corpus/templates/crm/docs/features/f2-lists-pipelines-and-views.mdx

@@ -0,0 +1,48 @@
+---
+id: F2
+title: Lists, pipelines, and views
+status: done
+order: 2
+---
+
+# F2 — Lists, pipelines, and views
+
+## What it is
+
+A **list** is a local workflow overlay for one record type. It can represent a
+sales pipeline, account segment, onboarding queue, or any other process without
+requiring a write to HubSpot or Salesforce. A record's membership is a list
+entry, and each entry can have its own fields.
+
+## What users can do
+
+<!-- status: done -->
+
+- Create a list for accounts, people, opportunities, or another object type.
+- Add and remove records from a list.
+- Add list-specific fields such as stage, owner, priority, or next step.
+- Move an entry between stages and review the time spent in each stage.
+- Save filters, ordered sorts, columns, and audience settings as a view.
+- Open a saved view as a table or as a board grouped by a status field.
+
+## How it behaves
+
+- Lists, entries, and entry values are local-authoritative in Native SQL and
+  connected modes.
+- One record may have multiple entries when the workflow needs them, such as
+  two opportunities for the same company.
+- A board groups by a managed status attribute; it is another presentation of
+  the same saved view, not a separate copy of the pipeline.
+- A view using `@currentUser` resolves that filter for the person viewing it,
+  so one shared view can show each teammate their own work.
+
+## A typical pipeline
+
+1. Create an **Opportunities** list.
+2. Add a status field with stages such as New, Qualified, Proposal, and Won.
+3. Add records to the list and fill in entry-specific amount, owner, and next
+   step fields.
+4. Save a table view for detailed work and a board view for stage review.
+
+The same workflow works over native records or records mirrored from a
+connected provider.

package/corpus/templates/crm/docs/features/f3-work-and-record-quality.mdx

@@ -0,0 +1,40 @@
+---
+id: F3
+title: Work and record quality
+status: done
+order: 3
+---
+
+# F3 — Work and record quality
+
+## What it is
+
+CRM keeps follow-up work beside the record context that explains it. Tasks,
+pipeline dashboards, duplicate review, and enrichment are separate workflows
+so a cleanup or spend decision does not get hidden inside a record edit.
+
+## What users can do
+
+<!-- status: done -->
+
+- Create and manage local follow-up tasks from a record or the Work view.
+- Review pipeline value and stage distribution in the dashboard.
+- Ask CRM to find likely duplicates and show the email, domain, or name signal
+  behind each match.
+- Choose the surviving record before merging. CRM promotes values the survivor
+  lacks, moves related workflow data, and keeps the losing record linked as a
+  tombstone rather than silently deleting it.
+- Run a free enrichment verification pass, review the evidence and estimated
+  line-item cost, then approve the exact records for the paid pass.
+
+## Spend and approval gates
+
+The enrichment flow has two phases:
+
+1. **Verify** gathers evidence and estimates what the paid run would cost.
+2. **Approve** selects the exact records and fields that may be enriched.
+3. **Run** performs the paid work only for the approved input set.
+
+A failed provider slot is reported as a failure, not as an empty result. Bulk,
+destructive, ownership, amount, stage, and external-effect changes require an
+exact preview and approval.

package/corpus/templates/crm/docs/features/f4-evidence-and-chat.mdx

@@ -0,0 +1,47 @@
+---
+id: F4
+title: Evidence and chat
+status: done
+order: 4
+---
+
+# F4 — Evidence and chat
+
+## What it is
+
+CRM can connect a bounded piece of call evidence to a record and turn it into a
+reviewable signal. The agent is the conversational interface to the same CRM
+actions the UI uses, so work stays visible, permission-scoped, and reversible
+where possible.
+
+## Call evidence and signals
+
+<!-- status: done -->
+
+- Attach a source URL or id, a bounded quote, speaker, timestamp, and summary
+  to a CRM record.
+- Run deterministic keyword trackers over the stored excerpt.
+- Delegate smart moments and summaries through agent chat.
+- Review each signal and confirm or dismiss it before it becomes part of the
+  record's working context.
+
+CRM stores references and bounded excerpts, not recordings, transcripts, or
+other raw media. The source app keeps ownership of the original call artifact.
+
+## Chat parity
+
+The agent can use the same actions as the UI: list records, create a list, save
+a view, add a task, inspect a record, prepare a provider proposal, and navigate
+to the relevant screen. It reads the current CRM screen when that context
+matters and keeps the UI synchronized after a change.
+
+Useful prompts include:
+
+- “Show me open opportunities in the Proposal stage.”
+- “Create a board view for this list grouped by stage.”
+- “Add a follow-up task for this account next Tuesday.”
+- “Find likely duplicates for this company and explain each match.”
+- “Prepare the provider change, but do not apply it.”
+
+Provider changes remain proposal-first: CRM shows the exact diff and hands the
+final upstream action back to HubSpot or Salesforce.

package/corpus/templates/crm/learnings.defaults.md

@@ -0,0 +1,5 @@
+# Learnings
+
+<!-- This file is your app's memory. The AI reads it at the start of every conversation and updates it when it learns something new. -->
+<!-- Your personal learnings.md is gitignored so preferences and private info stay local. -->
+<!-- This defaults file is what new checkouts start with. -->

package/corpus/templates/crm/netlify.toml

@@ -0,0 +1,11 @@
+[build]
+ignore = "node ./scripts/netlify-ignore-build.mjs crm"
+command = "export DATABASE_URL=${NETLIFY_DATABASE_URL:-$DATABASE_URL} && pnpm install && NITRO_PRESET=netlify pnpm --filter crm build"
+publish = "templates/crm/dist"
+functions = "templates/crm/.netlify/functions-internal"
+
+[build.environment]
+GA_MEASUREMENT_ID = "G-ESF7FYXGN9"
+GTM_CONTAINER_ID = "GTM-N3WSTXZ"
+NITRO_PRESET = "netlify"
+NPM_CONFIG_PRODUCTION = "false"