@agent-native/core 0.118.0 → 0.118.1

package/corpus/templates/crm/.agents/skills/crm/SKILL.md

@@ -1,128 +0,0 @@
----
-name: crm
-description: Work with Native SQL or HubSpot/Salesforce CRM using scoped records, field policies, evidence, proposals, and provider data programs.
----
-
-# CRM Companion
-
-Use actions as the operational source of truth and `shared/crm-contract.ts` as
-the product-model source of truth. This scope supports standalone Native SQL
-and HubSpot/Salesforce Connected/Hybrid behavior.
-
-## Start with the right source
-
-- Use `view-screen` only when the request depends on the current UI view,
-  selection, or saved view. Use `get-crm-overview`, `list-crm-records`, and
-  `get-crm-record` for ordinary CRM reads.
-- Use `sync-crm` for a declared, bounded mirror cohort. It is not an exhaustive
-  provider export.
-- Use `configure-native-crm` to start CRM without an external provider. Native
-  SQL records are local-authoritative and portable across SQLite, Postgres, and
-  D1. Use the normal CRM record, task, view, cadence, and evidence actions;
-  never require a provider connection or call `sync-crm` for Native SQL.
-- After HubSpot or Salesforce is authorized in workspace Connections, use
-  `configure-crm-connection` with the selected provider to register it with
-  CRM. Never pass a token. HubSpot starts with `companies`, `contacts`, and
-  `deals`; Salesforce starts with `Account`, `Contact`, and `Opportunity`.
-- Use `sync-crm` only for the declared recent cohort. HubSpot may be narrowed
-  by deal pipeline ids; Salesforce uses the updated-after boundary for its
-  standard objects. Record detail can perform a scoped read-through refresh;
-  do not treat it as permission for an export-all query.
-- For an endpoint, object, filter, pagination mode, or schema not represented
-  by a CRM action, use `provider-api-catalog`, `provider-api-docs`, then the
-  read-only `provider-api-request` for the selected provider. Before broad work,
-  declare a cohort, selected fields, and a bounded page/row budget. Stage only
-  that result, then use `query-staged-dataset` or a data program to reduce it.
-  Report provider, scope, filters, page/row counts, truncation, and gaps.
-- Always pass the selected workspace `connectionId` for Salesforce provider API
-  reads so its actor-bound OAuth token and instance URL cannot be separated.
-
-## Field, evidence, and credential boundaries
-
-- Credentials exist only in workspace Connections. Never request, paste, log,
-  save, or return a HubSpot or Salesforce token or secret.
-- Treat the upstream CRM as authoritative for remote fields. Only configured
-  allow-listed fields are mirrored. Unknown fields are remote-only; sensitive
-  fields default to redacted and must not be fetched or shown.
-- Salesforce reads must be revalidated against the current connection actor and
-  field permissions. Never infer a user's access from a service-account mirror
-  or from a previously visible local row; fail closed when access is ambiguous.
-- Never save raw provider payloads, media, screenshots, audio, video,
-  transcripts, base64 data, or file bodies in CRM SQL. `attach-call-evidence`
-  stores only a source URL/id, bounded quote, timestamp, speaker, and metadata.
-  For Clips, use only a durable `/share/<id>` or `/r/<id>` page URL with no
-  access token or transcript fragment; never use a `clip.created` event URL.
-- Use `run-crm-signal-trackers` only over evidence already attached to the CRM
-  record. Keyword hits are deterministic. Smart detector and summary requests
-  must go through agent chat, never a direct model call. Persist delegated
-  results with `record-crm-smart-signal` or one atomic
-  `record-crm-call-insight` batch; each quote/timestamp must cite the exact
-  bounded evidence row. Use `review-crm-signal` for human confirmation.
-- Use `create-crm-signal-tracker` to add a keyword or smart tracker, and
-  `manage-crm-signal-tracker` to enable, disable, or delete one tracker with
-  editor access. Tracker management is local configuration only: it never
-  invokes a model or mutates a connected provider. Navigate with
-  `{ view: "settings", settingsSection: "intelligence" }` to open the
-  Intelligence settings tab.
-- Do not identify or merge records by email/domain alone. Provider identity is
-  connection + provider + object type + remote id, and relationships retain
-  direction.
-
-## Safe writes and workflows
-
-- Use `update-crm-record` for a scoped typed edit. Provider writes are
-  prepared as revision-aware, access-checked, idempotent, audited proposals.
-  HubSpot proposals always hand off because HubSpot cannot apply the expected
-  revision atomically. Salesforce conditional-write capability is a
-  prerequisite for a future provider apply, not a reason to claim a write
-  succeeded without a confirmed provider response and the stored approval
-  policy.
-- Agent provider writes default to proposals. For ownership, amount, stage,
-  delete, bulk, or external-side-effect changes, show exact scope and fields,
-  then require approval. Use `list-crm-proposals` and
-  `apply-crm-proposals` to review the change and record the upstream handoff;
-  direct the user to complete it in HubSpot or Salesforce and never claim it
-  was applied without a confirmed adapter result.
-- The only stored delegation pack is `crm-sales-routine-local-v1`. It applies
-  only when a trusted automation trigger supplies that policy id and only to
-  one routine local record update. Do not pass policy ids as action input;
-  provider mutations stay proposal-first and risky, destructive, bulk, or
-  external-effect work stays gated.
-- Native SQL writes are local-authoritative CRM mutations. They remain
-  access-checked, idempotent, and audited, but have no provider handoff or
-  remote revision to claim.
-- Use `list-crm-saved-views` and `save-crm-saved-view` for saved views. Use
-  `list-crm-tasks` and `manage-crm-task` for CRM follow-ups. Use `navigate` to
-  show a requested view instead of merely describing it.
-- Use `install-crm-pipeline-dashboard` to install the owner-scoped Pipeline
-  dashboard. Its stored data program calls the bounded, access-scoped
-  `get-crm-pipeline-data` action through `appAction`; do not reimplement the
-  aggregate with a provider request or put CRM rows in dashboard config. Use
-  `get-crm-dashboard` / `list-crm-dashboards` to inspect dashboards,
-  `save-crm-dashboard` with `expectedUpdatedAt` for safe edits, and
-  `list-crm-dashboard-revisions` / `restore-crm-dashboard-revision` to review
-  or restore prior dashboard configurations.
-- Use `get-crm-automation-recipe` for the default-off Clips call-evidence
-  review recipe after the user explicitly selects a CRM record. The recipe is a
-  configuration aid, not permission to activate an automation. Before enabling
-  it, show the exact Clips-owned `clip.created` trigger, the selected CRM
-  record, and its one bounded local evidence-reference write, then obtain a
-  fresh approval. Use the recipe's exact `call-agent` input and content-bound
-  `approvedActions` grant. The Clips trigger must call
-  `prepare-crm-call-evidence`; never use the event URL or copy media/transcript
-  content. The downstream CRM call may only invoke `attach-call-evidence` for
-  that selected record and cannot create tasks, field updates, proposals, or
-  provider mutations.
-
-## Four-area provider changes
-
-Provider behavior must stay aligned across setup UI, CRM actions, this skill,
-and `application_state`/`view-screen`. Reuse workspace Connections and action
-hooks; do not add a provider-key field, legacy `/api` route, direct browser
-fetch, or provider-specific state outside the shared CRM contract.
-
-## Out of scope
-
-Do not add provider migration, a page builder, or raw provider payload/media in
-CRM SQL. Native SQL supports the canonical CRM objects and generic custom
-records; a separate object-authoring engine is not part of this template.

package/corpus/templates/crm/.agents/skills/customizing-agent-native/SKILL.md

@@ -1,220 +0,0 @@
----
-name: customizing-agent-native
-description: >-
-  How to configure, compose, or eject Agent Native features into app-owned
-  code. Use when overriding shared components or integrations, customizing a
-  template, adding UI to chat or headless apps, or inspecting package source.
-scope: dev
-metadata:
-  internal: true
----
-
-# Customizing Agent Native
-
-## Rule
-
-Start with the app's registered design system and local UI adapters, then use
-the public feature's props, semantic components, controller, product slots,
-and callbacks. If those seams are not enough, use the eject CLI to transfer
-the smallest supported feature into the app and make that copy app-owned.
-Never edit `node_modules`, deep-import a private source file at runtime, or
-patch an `@agent-native/*` package.
-
-Use this order:
-
-1. Set brand tokens with the build-time theme configuration when tokens are
-   enough.
-2. Register company components in `app/design-system.ts` with
-   `defineDesignSystem`, then pass that definition to `ToolkitProvider`.
-3. Configure a public feature through its semantic components, headless
-   controller, and product-level render slots.
-4. Compose app primitives behind the app's local UI adapter layer.
-5. Eject the smallest feature into app-owned source.
-6. Propose a new Toolkit seam when the same override is useful in two apps.
-
-Ejection is for intentional product customization, not for hiding an upgrade
-failure or replacing Core runtime behavior.
-
-## Use A Company Design System
-
-Keep the explicit, typed registration seam in `app/design-system.ts`:
-
-```tsx
-import { defineDesignSystem } from "@agent-native/toolkit/design-system";
-import {
-  AcmeActionButtonAdapter,
-  AcmeDialogAdapter,
-} from "./design-system/acme-adapter";
-
-export const designSystem = defineDesignSystem({
-  name: "Acme",
-  components: {
-    ActionButton: AcmeActionButtonAdapter,
-    Dialog: AcmeDialogAdapter,
-  },
-});
-```
-
-Adapters translate the semantic Toolkit contract into company component props.
-They are ordinary React components and may use MUI-style providers, React Aria,
-CSS modules, CSS-in-JS, or another styling runtime. `className` and `style` are
-optional interoperability hooks, not Tailwind or CVA requirements.
-
-The contract has nine leaf components (`ActionButton`, `IconButton`,
-`TextField`, `TextArea`, `Spinner`, `Skeleton`, `Status`, `Surface`, `Avatar`)
-and eight behavior components (`Tooltip`, `Menu`, `Popover`, `Dialog`,
-`Picker`, `Checkbox`, `Switch`, `Tabs`). `Picker` covers select and combobox
-behavior, not date picking. Behavior adapters own their portal, focus,
-keyboard, dismissal, and stacking implementation while honoring the semantic
-props and `portalContainer` interop contract.
-
-App product code imports standard controls from its local adapter path, usually
-`@/components/ui/*`. Do not import `@agent-native/toolkit/ui/*` directly from
-pages, routes, or domain components. That bypasses the app seam and makes a
-future design-system replacement incomplete. Toolkit feature packages remain
-valid imports; configure their presentation through the registered semantic
-components, controller, and product slots.
-
-Run the published conformance kit against a complete adapter in its own CI:
-
-```tsx
-import { assertDesignSystemConformance } from "@agent-native/toolkit/conformance";
-import { DESIGN_SYSTEM_CONTRACT_VERSION } from "@agent-native/toolkit/design-system";
-
-await assertDesignSystemConformance({
-  adapterName: "Acme",
-  components,
-  contractVersion: DESIGN_SYSTEM_CONTRACT_VERSION,
-});
-```
-
-New components and optional props are minor contract changes. Required props,
-removed APIs, or behavioral changes require a new contract major.
-
-## Customize A Shared Feature
-
-Prefer feature-level headless controllers over rebuilding individual widgets.
-One controller must power both the Toolkit default view and every custom render
-path so behavior, actions, analytics, accessibility state, and error handling
-cannot drift. Use a product-level render slot to replace the view while keeping
-that controller. Eject only when the controller and slots cannot express the
-required product behavior.
-
-## Eject A Feature
-
-Discover and inspect the ejection units published by installed first-party
-packages before changing source:
-
-```bash
-agent-native eject --list
-agent-native eject inspect <unit>
-agent-native eject <unit> --app <app>
-agent-native eject <unit> --app <app> --apply
-```
-
-The command is dry-run by default. It prints the file closure, consumer import
-rewrites, protected package contracts, and verification commands before
-writing. `--apply` copies the package-version-matched source into the app and
-rewrites only imports covered by the unit manifest.
-
-Every first-party public ejection unit must have a complete manifest. If one is
-missing, treat that as a framework coverage bug instead of inventing a copy
-recipe. For an unknown third-party package, use the emitted add-style blueprint
-as a starting point. Protected runtime behavior is never copied; follow the
-reported configuration, adapter, or extension seam instead.
-
-Applied ejections are recorded in the committed
-`agent-native.ejections.json`, including package version, manifest digest,
-target hashes, and import rewrites. Use the recorded state to review drift or
-undo an unchanged ejection:
-
-```bash
-agent-native eject diff <unit> --app <app>
-agent-native eject restore <unit> --app <app>
-agent-native eject restore <unit> --app <app> --apply
-```
-
-Restore is hash-gated. It refuses to remove locally edited files or reverse
-changed imports and prints their diff instead. Keep an edited ejection as
-app-owned code, or reconcile those edits before restoring it.
-
-## Find The Installed Implementation
-
-Use the source that matches the installed package version:
-
-```bash
-pnpm action docs-search --query "<component or feature>"
-pnpm action source-search --query "<component or symbol>"
-rg -n "<component or symbol>" node_modules/@agent-native/toolkit/src
-rg -n "<component or symbol>" node_modules/@agent-native/core/corpus
-```
-
-- Toolkit publishes readable TypeScript under
-  `node_modules/@agent-native/toolkit/src/` for selective UI adoption.
-- Core and first-party template source lives under
-  `node_modules/@agent-native/core/corpus/core/` and
-  `node_modules/@agent-native/core/corpus/templates/`.
-- Treat those trees as read-only references. Prefer `agent-native eject` so the
-  package manifest selects the complete source closure and rewrites imports.
-  Manual inspection is still useful for deciding whether to configure,
-  compose, eject, or propose a shared seam.
-
-Do not manually guess at sibling dependencies. The ejection manifest owns the
-required file closure and keeps protected contracts on public package imports.
-
-## Preserve The Agent-Native Contract
-
-UI ownership may change; product contracts should not:
-
-- Keep app operations in `defineAction` actions and call them through
-  `useActionQuery`, `useActionMutation`, or another named client helper.
-- Keep navigation, selection, and focused-object state visible through the
-  existing application-state keys.
-- Keep AI work in the shared agent chat instead of adding direct LLM calls.
-- Keep auth, access checks, persistence, chat transport, and agent execution in
-  Core. Do not copy those runtimes into the app.
-- Keep local adapters narrow so package upgrades still improve every surface
-  the app has not intentionally taken ownership of.
-- Keep page, route, and domain code on local UI adapter imports. Never reach
-  around the registered design system with direct Toolkit UI primitive imports.
-
-## App Shapes
-
-- **Template app:** begin with `app/design-system.ts`, its local UI adapters,
-  and domain UI. Use Toolkit features for repeated workspace behavior; eject
-  only the unit being customized.
-- **Chat app:** keep `AgentChatSurface`, thread state, and chat transport in
-  Core. Compose or eject Toolkit presentation such as chat-history UI around it.
-- **Headless app:** stay action-first while no UI is needed. When adding a UI,
-  use the Chat template as the on-ramp or add Toolkit components without
-  replacing the existing actions.
-- **Workspace:** put one-app overrides in that app. Promote a local component
-  to `packages/shared` only when multiple workspace apps use it.
-
-## After Ejecting
-
-- Commit `agent-native.ejections.json` with the app-owned files and rewrites.
-- Remove unused dependencies and imports from the ejected files.
-- Keep visible text in the app's localization catalogs.
-- Run the manifest verification commands plus the app's formatter, typecheck,
-  and focused tests.
-- Re-check the installed source during future package upgrades; the app-owned
-  ejection does not receive upstream fixes automatically. Use `eject diff` to
-  distinguish recorded output from subsequent local edits.
-
-## Don't
-
-- Don't edit or import from `node_modules/@agent-native/*/src` at runtime.
-- Don't add `pnpm.overrides`, patches, or resolutions for Agent Native packages.
-- Don't copy Core auth, DB, action, agent-loop, or transport internals.
-- Don't manually copy a first-party unit with a missing recipe; fix its manifest.
-- Don't eject a full package when a prop, slot, wrapper, or smaller unit works.
-- Don't fork feature state into a custom view; consume the feature's controller.
-
-## Related Skills
-
-- `agent-native-docs` — version-matched docs and source lookup
-- `agent-native-toolkit` — shared-vs-app-owned architecture boundary
-- `self-modifying-code` — safe app source edits
-- `upgrade-agent-native` — supported package upgrade path
-- `adding-a-feature` — UI/action/instructions/application-state parity

package/corpus/templates/crm/.agents/skills/feature-flags/SKILL.md

@@ -1,169 +0,0 @@
----
-name: feature-flags
-description: >-
-  Declare, evaluate, manage, and remove framework feature flags. Use when
-  shipping a capability gradually, targeting users or organizations, or
-  replacing a compile-time rollout switch with a production-safe runtime flag.
-scope: dev
-metadata:
-  internal: true
----
-
-# Feature Flags
-
-A feature flag is a boolean declared in app code, evaluated locally by Core,
-and managed from the Analytics fleet control plane. Code owns whether a flag
-exists. Runtime settings own only its rollout state.
-
-Flags let an app deploy dormant code and turn it on in the real environment
-without another deployment. They are not experiments: do not add variants,
-hypotheses, conversion metrics, exposure tracking, or lifecycle states.
-
-## When to use one
-
-Use a flag for a reversible rollout of a user-facing capability whose dormant
-code is safe to deploy. Flags are useful for production dogfooding, exact-user
-or organization pilots, and deterministic percentage rollouts.
-
-Do not use a flag for authentication, authorization, secrets, audit enablement,
-SSR cache behavior, or another security boundary. Client hiding is presentation
-only; every guarded server action must evaluate the same registered flag.
-
-## Agent workflow
-
-### 1. Declare
-
-Keep definitions in a shared TypeScript module so server and client code use the
-same stable key. Flags are boolean and default-off.
-
-```ts
-import { defineFeatureFlag } from "@agent-native/core/feature-flags/registry";
-
-export const FULL_APP_BUILDING = defineFeatureFlag({
-  key: "full-app-building",
-  displayName: "Full app building",
-  description: "Create and edit Fusion-backed applications.",
-});
-```
-
-Keys are immutable, never reused, and contain only letters, numbers, dots,
-underscores, or hyphens. Prefer a concise app-owned name. Do not create flag
-definitions or rollout rows from Analytics.
-
-### 2. Register
-
-Register app definitions from a Nitro plugin before actions are discovered.
-Do not add app-specific flags to a Core registry.
-
-```ts
-import { createFeatureFlagsPlugin } from "@agent-native/core/server";
-
-import { FULL_APP_BUILDING } from "../../shared/feature-flags.js";
-
-export default createFeatureFlagsPlugin({ flags: [FULL_APP_BUILDING] });
-```
-
-### 3. Guard server and client
-
-The server action is the enforcement boundary:
-
-```ts
-import { isFeatureFlagEnabled } from "@agent-native/core/feature-flags";
-
-run: async (args, ctx) => {
-  if (!(await isFeatureFlagEnabled(FULL_APP_BUILDING, ctx))) {
-    throw new Error("Full app building is not enabled for this account.");
-  }
-  // guarded operation
-}
-```
-
-Use the client hook only to hide or reveal hydrated UI:
-
-```tsx
-import { useFeatureFlag } from "@agent-native/core/client/feature-flags";
-
-const enabled = useFeatureFlag(FULL_APP_BUILDING.key);
-return enabled ? <FullAppOption /> : null;
-```
-
-The client hook intentionally returns false while loading or for an unknown
-flag. Never replace that fail-closed behavior with app-local bucketing or a
-compile-time fallback. Never evaluate personalized flags in the public SSR
-shell; it is shared and cached for every visitor.
-
-### 4. Verify and roll out
-
-1. Verify the off path before changing rollout state.
-2. Confirm the registered flag appears in **Analytics → Feature flags** for the
-   app and is Off by default.
-3. Use **Enable for me** for initial production dogfood.
-4. Expand to exact emails, organization IDs, or a percentage only from
-   Analytics.
-5. Confirm the client presentation and authoritative server action agree.
-
-## Management contract
-
-Core mounts three actions in registered apps:
-
-| Action | Purpose |
-| --- | --- |
-| `get-feature-flags` | Return the current caller's evaluated boolean values. |
-| `list-feature-flags` | Return definitions and rollout metadata to an authorized operator. |
-| `set-feature-flag` | Atomically turn a flag off, enable it for the operator, or replace targeting rules. |
-
-Analytics calls the app-local operator actions through narrowly scoped A2A
-delegation. Tokens require an exact audience, organization, scope, operator
-role, and audit correlation id. Management is permission-checked and audited
-by the target app. Never manage flags through generic settings routes, raw SQL,
-or per-app toggle UIs.
-
-## Rollout semantics
-
-The operator modes are **Off**, **Targeted**, and **Everyone**. Core stores them
-as `off`, `rules`, and `on`.
-
-Targeted rules combine exact normalized emails, exact organization IDs, and a
-percentage with OR semantics. Exact matches are checked first. Percentage
-buckets use Core's stable hash of the flag key and authenticated user identity;
-anonymous callers fail closed. Raising a percentage preserves the users already
-included at a lower percentage. Do not implement bucketing in app code.
-
-Unknown definitions, missing state, malformed state, storage errors, and
-evaluation errors all return the code default (`false` in v1). Explicit Off
-wins over every target; Everyone enables every authenticated caller.
-
-## Remove a flag
-
-After a rollout is permanent:
-
-1. Replace guarded branches with the chosen behavior.
-2. Delete the server and client gates.
-3. Delete the definition and registration entry.
-4. Verify the flag disappears from the Analytics fleet.
-5. Remove stale tests and rollout instructions.
-
-A permanent flag is just an if statement with a pension plan.
-
-## Verification checklist
-
-- Unknown and unregistered keys evaluate false.
-- UI hiding and server enforcement use the same registered key.
-- Exact-user, organization, deterministic percentage, Everyone, and Off paths
-  have focused tests.
-- Increasing a percentage is monotonic; anonymous percentage evaluation is off.
-- Unauthorized callers cannot list targeting details or mutate flags.
-- Mutations are atomic, read back stored state, emit refresh, and appear in the
-  audit log with the flag key.
-- Analytics represents ready, no-definition, unsupported, forbidden, legacy,
-  and unreachable directory apps honestly.
-- Future agents can find this skill from root `AGENTS.md`, and
-  `pnpm guard:workspace-skills` passes after syncing generated copies.
-
-## Related skills
-
-- **adding-a-feature** — preserve UI/action/instruction/application-state parity
-- **actions** — define and call guarded app operations
-- **audit-log** — inspect automatic action mutation history
-- **reliable-mutations** — make rollout changes atomic and provable
-- **security** — keep security controls out of feature flags

package/corpus/templates/crm/.agents/skills/upgrade-agent-native/SKILL.md

@@ -1,100 +0,0 @@
----
-name: upgrade-agent-native
-description: >-
-  Bring an older Agent Native app or workspace current. Use when updating
-  @agent-native/core, fixing a broken upgrade, or when tempted to patch or
-  override core/dispatch packages to make an old branch run.
-scope: dev
-metadata:
-  internal: true
----
-
-# Upgrade Agent Native
-
-## Rule
-
-When an older Agent Native app/branch needs to run on current packages, use
-`agent-native upgrade`. Never "fix" upgrade breakage with
-`pnpm.overrides`, `patchedDependencies`, `resolutions`, local patches, or
-edits under `node_modules/@agent-native/*` — especially not against
-`@agent-native/core` or `@agent-native/dispatch`.
-
-## Why
-
-Agents often respond to a failed core bump by inventing framework patches and
-dispatch behavior overrides. That hides the real app-level break, drifts from
-upstream, and makes the next upgrade worse. The supported path is bump →
-install → refresh scaffold skills → verify, then fix **app** code only.
-
-## How
-
-1. **Preview migration codemods first**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods
-   ```
-
-   Codemods are preview-by-default: read the diff before applying it. Do not
-   manually edit imports before running this command; the migration manifest is
-   the source of truth for renamed specifiers and symbols.
-
-2. **Apply the reviewed codemods, then run the upgrade**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods --yes
-   npx @agent-native/core@latest upgrade
-   ```
-
-   Or from an already-installed CLI: `pnpm exec agent-native upgrade` /
-   `agent-native upgrade`.
-
-   What it does:
-
-   - Blocks (unless `--force`) when `@agent-native/*` overrides/patches exist
-   - Rewrites non-local `@agent-native/*` dependency pins to `latest`
-   - Runs the package manager install
-   - Runs `skills update scaffold --project`
-   - Runs `typecheck` when the project has that script
-
-3. **If upgrade or typecheck fails**
-
-   - Read the concrete error
-   - Fix **app** source, actions, config, or env — not framework packages
-   - Re-run `agent-native upgrade` or `pnpm typecheck`
-   - Stop and ask the user if you cannot fix the app-level error
-
-   Intentional app-level UI customization is a separate workflow. Read
-   `customizing-agent-native` when the product needs to own a selectively
-   copied component; do not use that path to reproduce framework runtime
-   behavior or hide version skew.
-
-4. **Dry-run / partial runs**
-
-   ```bash
-   agent-native upgrade --dry-run
-   agent-native upgrade --skip-verify
-   agent-native upgrade --skip-install   # package.json bumps only
-   agent-native doctor --only migration-manifest
-   ```
-
-   `migration-manifest` has no opt-out. Run it in CI before upgrading to find
-   imports that will break, then use `npx @agent-native/core@latest upgrade --codemods`
-   to preview the supported rewrite.
-
-## Don't
-
-- Don't add `pnpm.overrides`, `overrides`, `resolutions`, or
-  `patchedDependencies` for any `@agent-native/*` package
-- Don't edit `node_modules/@agent-native/core` or
-  `node_modules/@agent-native/dispatch`
-- Don't invent local "dispatch behavior" shims to paper over version skew
-- Don't keep iterating with more framework patches after a failed install
-- Don't skip `skills update scaffold --project` after a core bump (the
-  upgrade command does this for you)
-
-## Related Skills
-
-- **self-modifying-code** — Tier 4: framework packages are off limits
-- **agent-native-docs** — version-matched docs after the bump
-- **customizing-agent-native** — intentional app-owned UI copies, not upgrade patches
-- **portability** — keep app code provider-agnostic across upgrades

package/corpus/templates/crm/.env.example

@@ -1,5 +0,0 @@
-# Persistent SQL is required outside local development.
-DATABASE_URL=file:./data/app.db
-
-# Local development or preview only.
-# AUTH_DISABLED=true