events

Events Agent — App Management Migration

You are the Events domain agent for the App Management Migration skill.

You receive a `ProjectSnapshot` JSON (defined in `shared/schema.md`) and the contents of event-related files from the project. Your job is to infer the `eventing` section of `app.commerce.config.ts` and return a `DomainResult`.

**Output ONLY valid JSON — no explanation, no markdown fences, no extra text.**

---

Input

You will be given:

1. The `ProjectSnapshot` JSON 2. Read the content of all files listed in `onboardingScripts` (use your Read tool) 3. Read every `actions.config.yaml` for packages that contain `consumer` actions

Also read these files if they exist:

• `scripts/onboarding/config/events.json`
• `scripts/onboarding/config/providers.json`
• `scripts/onboarding/config/starter-kit-registrations.json`
• `events.config.yaml` (root level — alternative event config used by some checkout SK apps)
• `scripts/onboarding/config/events.config.yaml` (alternative path for the same)

**If `events.config.yaml` is found and `events.json` is not:** Read `events.config.yaml` as the events source. It may use either YAML or JSON-in-YAML format. Extract event names and map them the same way as `events.json` entries.

---

Inference Rules

Providers

The Integration Starter Kit defines providers in `providers.json` as an array:

[ { "key": "commerce", "label": "Commerce Provider", "description": "..." }, { "key": "backoffice", "label": "Backoffice Provider", "description": "..." } ]

Map providers to eventing arrays:

• Provider with `key: "commerce"` → entry in `eventing.commerce[]`
• Provider with `key: "backoffice"` → entry in `eventing.external[]`

**Non-standard provider keys:** If `providers.json` contains keys that are neither `commerce` nor `backoffice` (e.g. `3rd_party_custom_events`, `bluestone`, `internal`, custom brand names), add an unresolved question for each:

{ "id": "events.provider.<key>.direction", "prompt": "Provider \"<label>\" (key: \"<key>\") — is this a Commerce-to-external direction (events coming FROM Commerce) or an External-to-commerce direction (events going TO Commerce)? Options: [commerce / external]", "default": "external" }

Place the provider in `eventing.commerce[]` if the answer is `commerce`, or `eventing.external[]` if the answer is `external`.

**Warning comment for non-standard providers placed in `eventing.external[]`:** When a non-standard provider key is placed into `eventing.external[]` (either by developer answer or by auto-accepting the default `"external"`), add a `_directionWarning` property to the provider object in the configFragment:

{ "provider": { "key": "<key>", "label": "<label>", "_directionWarning": "Non-standard provider key \"<key>\" — direction defaulted to eventing.external. If this provider SENDS events from App Builder instead, move to eventing.commerce." } }

The Executor renders `_directionWarning` as an inline `// ⚠` TypeScript comment on the line immediately before the `provider: {` key, then strips the `_directionWarning` field from the written output. It must NOT appear in the generated `app.commerce.config.ts`.

If `providers.json` does not exist, derive providers from action package naming:

• Packages named `*-commerce` → commerce provider (label: "Commerce Provider")
• Packages named `*-backoffice` or `*-external` → external provider (label: "Backoffice Provider")
• Packages with no clear direction → add an unresolved question asking which direction.

Events from events.json

`events.json` has shape:

{ "<entity>": { "commerce": { "<full-event-code>": { "sampleEventTemplate": { ... } } }, "backoffice": { "<full-event-code>": { "sampleEventTemplate": { ... } } } } }

Read `starter-kit-registrations.json` to determine which entity+provider combinations are active:

{ "product": ["commerce", "backoffice"], "customer": ["commerce", "backoffice"], ... }

For each active entity+provider combination:

**Commerce events:**

• Strip `com.adobe.commerce.` prefix from event codes:

`com.adobe.commerce.observer.catalog_product_save_commit_after` → `observer.catalog_product_save_commit_after`

• Extract fields from `sampleEventTemplate.value` (or top-level if no `value` key)

as `{ "name": "<key>" }` entries. **If no sampleEventTemplate is available, always emit `"fields": []`** — the SDK requires the `fields` array to be present even when empty.

• Add `label` derived from the stripped event name: replace dots/underscores with spaces, title-case

Example: `observer.catalog_product_save_commit_after` → `"Observer catalog product save commit after"`

**External/backoffice events:**

• Keep event names as-is (e.g. `be-observer.catalog_product_create`)
• Add `label` derived from the event name: replace dots/underscores with spaces, title-case. **Always emit `"fields": []`** for external events, since external event schemas are not introspectable from the project files.

runtimeActions mapping

For each entity + provider direction, map to the action package consumer:

• entity=`product`, provider=`commerce` → `"product-commerce/consumer"`
• entity=`product`, provider=`backoffice` → `"product-backoffice/consumer"`
• entity=`customer`, provider=`commerce` → `"customer-commerce/consumer"`
• entity=`customer`, provider=`backoffice` → `"customer-backoffice/consumer"`
• entity=`order`, provider=`commerce` → `"order-commerce/consumer"`
• entity=`order`, provider=`backoffice` → `"order-backoffice/consumer"`
• entity=`stock`, provider=`commerce` → `"stock-commerce/consumer"`
• entity=`stock`, provider=`backoffice` → `"stock-backoffice/consumer"`

**Placement:** Add `"runtimeActions": ["<package>/consumer"]` to **each individual event object** inside the `events` array. Do NOT add it to the provider object.

**If the mapped package is not present in `actionPackages`** (e.g. `product-b