# Salesforce CRM Install Seed Policy

This pack currently declares no install-time seed hook.

Install seed behavior is L1 intent. If the Salesforce-compatible CRM pack needs
standard seed or repair work, the fact must live in this repository as app-pack
payload: object metadata, field mappings, validation rules, standard flows, or
other source-backed component kinds owned by the pack. NexusCRM L0 should only
interpret generic metadata and lifecycle substrates; it should not know which
CRM flow should run during install.

The install boundary is:

- pack activation is the last install step that may fail the install;
- any post-activation seed execution must be idempotent and fail-forward;
- a failed post-activation seed must leave the pack active and retryable through
  the same L1-owned identity;
- scheduler windows must not be used as synthetic install transactions.

Do not encode install seed intent with host-only shortcut fields such as
`runImmediatelyOnInstall`, pack-level `installLifecycleHooks`, or prepared
scheduler-window reservation tokens. Those fields make a control-plane
one-time seed action look like a scheduler occurrence and recreate the split
between activation, reservation, runtime identity, and retry ownership.

For the current platform substrate, scheduled CRM seed work should be modeled as
ordinary scheduled Flow metadata and run on its natural scheduler tick. If the
product later needs "run right after activation" semantics, introduce it as a
generic post-activation, fail-forward app-pack lifecycle job only after the L0
contract has a real multi-consumer shape.

Standard Flow identity must remain single-source:

- the manifest `standard_flow.businessKey` is the Flow developer name;
- the Flow payload filename stem is the same developer name;
- future seed policy must reference that same identity instead of mixing
  business keys, filenames, active FlowDefinition rows, or scheduler tokens.