service-digital-engagement-messaging-site-integrate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Embed Messaging Widget on an Experience Cloud Site

在Experience Cloud站点中嵌入消息组件

Wires an existing Embedded Messaging (MIAW) deployment onto an Experience Cloud site by retrieving the site's bundle (LWR

DigitalExperienceBundle

or Aura

ExperienceBundle

), patching the home page JSON to place the

experience_messaging:embeddedMessaging

component, staging the bundle into the local project, deploying it, publishing the site, and verifying guest access.

The operation is idempotent: if the component is already present it is updated in place (its

id

is preserved), so re-running with different ESD coordinates cleanly updates.

通过检索站点包（LWR

DigitalExperienceBundle

或 Aura

ExperienceBundle

）、修补主页JSON以添加

experience_messaging:embeddedMessaging

组件、将包暂存到本地项目、部署、发布站点并验证访客访问权限，将现有的嵌入式消息（MIAW）部署关联到Experience Cloud站点。

该操作具有幂等性：如果组件已存在，则会就地更新（保留其

id

），因此使用不同ESD坐标重新运行可干净完成更新。

Scope

范围

In scope: Detecting LWR vs Aura bundle type; scaffolding missing LWR template routes required by the site template (e.g.
```
too-many-requests
```
); patching the home-page JSON to insert or update the Embedded Messaging component; staging the bundle into
```
force-app
```
; async deploy with polling; resolving the
```
Network.Name
```
and publishing the site; guest-URL smoke test; manual Experience Builder fallback with a deep link.
Out of scope: Creating the
```
EmbeddedServiceConfig
```
(Embedded Service Deployment) itself — use
```
service-digital-engagement-deployment-configure
```
; creating the
```
MessagingChannel
```
— use
```
service-digital-engagement-channel-configure
```
; creating the Experience Cloud site itself — use
```
experience-lwr-site-generate
```
; generating a standalone JS snippet for a non-Experience website.

包含范围：检测LWR与Aura包类型；搭建站点模板所需的缺失LWR模板路由（如
```
too-many-requests
```
）；修补主页JSON以插入或更新嵌入式消息组件；将包暂存到
```
force-app
```
；异步部署并轮询；解析
```
Network.Name
```
并发布站点；访客URL冒烟测试；提供带深度链接的Experience Builder手动回退方案。
排除范围：创建
```
EmbeddedServiceConfig
```
（嵌入式服务部署）本身——请使用
```
service-digital-engagement-deployment-configure
```
；创建
```
MessagingChannel
```
——请使用
```
service-digital-engagement-channel-configure
```
；创建Experience Cloud站点本身——请使用
```
experience-lwr-site-generate
```
；为非Experience网站生成独立JS代码片段。

Clarifying Questions

澄清问题

Before executing, ask the user if not already clear:

Site name? The
```
DeveloperName
```
of the Experience Cloud site (the metadata folder name under
```
digitalExperiences/site/<siteName>/
```
or
```
experiences/<siteName>/
```
).
Deployment coordinates? The
```
deploymentName
```
(Embedded Service Deployment
```
DeveloperName
```
), the
```
scrtUrl
```
, and the
```
siteEndpoint
```
(Experience site base URL). All three come from the published
```
EmbeddedServiceConfig
```
— obtain from
```
service-digital-engagement-deployment-configure
```
output if not provided.
Target org alias? For the
```
sf
```
commands.
URL path prefix? The site's
```
UrlPathPrefix
```
(needed to resolve
```
Network.Name
```
for publish and to hit the guest URL for verification).

执行前，若以下信息不明确，请询问用户：

站点名称？ Experience Cloud站点的
```
DeveloperName
```
（
```
digitalExperiences/site/<siteName>/
```
或
```
experiences/<siteName>/
```
下的元数据文件夹名称）。
部署坐标？
```
deploymentName
```
（嵌入式服务部署的
```
DeveloperName
```
）、
```
scrtUrl
```
和
```
siteEndpoint
```
（Experience站点基础URL）。这三项均来自已发布的
```
EmbeddedServiceConfig
```
——若未提供，可从
```
service-digital-engagement-deployment-configure
```
的输出中获取。
目标组织别名？ 用于
```
sf
```
命令。
URL路径前缀？ 站点的
```
UrlPathPrefix
```
（解析
```
Network.Name
```
以完成发布，以及访问访客URL进行验证时需要）。

Required Inputs

必填输入

Gather or infer before proceeding:

Site name —
```
DeveloperName
```
of the site
Deployment name —
```
DeveloperName
```
of the
```
EmbeddedServiceConfig
```
scrtUrl — SCRT2 endpoint URL from the deployment
siteEndpoint — Base URL of the Experience site
Target org alias
URL path prefix — Site's public URL path segment (e.g.
```
esw-site
```
)

Defaults applied to the component's attributes when writing:

```
isExpSiteAuthMode
```
:
```
false
```
```
hideChatButtonOnLoad
```
:
```
"Default"
```
```
clientVersion
```
:
```
"WebV1"
```

执行前需收集或推断以下信息：

站点名称 —— 站点的
```
DeveloperName
```
部署名称 ——
```
EmbeddedServiceConfig
```
的
```
DeveloperName
```
scrtUrl —— 部署中的SCRT2端点URL
siteEndpoint —— Experience站点的基础URL
目标组织别名
URL路径前缀 —— 站点的公共URL路径段（如
```
esw-site
```
）

写入组件属性时应用以下默认值：

```
isExpSiteAuthMode
```
:
```
false
```
```
hideChatButtonOnLoad
```
:
```
"Default"
```
```
clientVersion
```
:
```
"WebV1"
```

Workflow

工作流程

Steps are sequential. If any automated step fails, proceed to the manual fallback (Phase 6) and do not claim the widget is "live" until either the guest-URL smoke test returns

or the user confirms manual publish.

步骤按顺序执行。若任何自动化步骤失败，进入手动回退阶段（第6阶段），且仅当访客URL冒烟测试返回

或用户确认手动发布后，才可声称组件已“上线”。

Phase 1 — Detect Bundle Type

阶段1 —— 检测包类型

Retrieve both candidate bundles into

<retrieve-dir>

. The script only performs a deterministic path check, so the retrieve calls must run first:

bash

sf project retrieve start --metadata "DigitalExperienceBundle:site/<siteName>" \
  --target-org <org-alias> --target-metadata-dir <retrieve-dir>
sf project retrieve start --metadata "ExperienceBundle:<siteName>" \
  --target-org <org-alias> --target-metadata-dir <retrieve-dir>

Either call may return "no metadata found" — that is expected; the missing bundle simply means the site is the other type.

Run
scripts/detect_bundle_type.sh <retrieve-dir> <siteName>
. It emits exactly one token to stdout:
- ```
LWR
```
  → the LWR marker file exists (
```
digitalExperiences/site/<siteName>/sfdc_cms__view/home/content.json
```
  ). Go to Phase 2.
- ```
AURA
```
  → the Aura marker file exists (
```
experiences/<siteName>/views/homeGuestLayout.json
```
  ). Go to Phase 3.
- ```
UNKNOWN
```
  (exit code 1) → neither marker exists. Skip to the manual fallback in Phase 6.

Read

references/bundle_detection.md

for retrieval command shapes and troubleshooting.

将两个候选包检索到
<retrieve-dir>
中。脚本仅执行确定性路径检查，因此必须先运行检索命令：

bash

sf project retrieve start --metadata "DigitalExperienceBundle:site/<siteName>" \
  --target-org <org-alias> --target-metadata-dir <retrieve-dir>
sf project retrieve start --metadata "ExperienceBundle:<siteName>" \
  --target-org <org-alias> --target-metadata-dir <retrieve-dir>

任一命令可能返回“未找到元数据”——这是预期情况；缺失的包仅表示站点为另一种类型。

运行
scripts/detect_bundle_type.sh <retrieve-dir> <siteName>
。它会向标准输出输出恰好一个标记：
- ```
LWR
```
  → 存在LWR标记文件（
```
digitalExperiences/site/<siteName>/sfdc_cms__view/home/content.json
```
  ）。进入阶段2。
- ```
AURA
```
  → 存在Aura标记文件（
```
experiences/<siteName>/views/homeGuestLayout.json
```
  ）。进入阶段3。
- ```
UNKNOWN
```
  （退出代码1） → 两个标记文件均不存在。跳至阶段6的手动回退。

有关检索命令格式和故障排除，请阅读

references/bundle_detection.md

。

Phase 2 — Patch the LWR Bundle

阶段2 —— 修补LWR包

Scaffold any missing LWR template routes (commonly
```
too-many-requests
```
) before patching — missing routes fail the deploy. Route+view scaffolding is owned by
```
experience-lwr-site-generate
```
(see its
```
configure-content-route.md
```
,
```
configure-content-view.md
```
, and
```
handle-component-and-region-ids.md
```
). Delegate to that skill for the actual scaffold; this skill only supplies the messaging-specific context (which route the deploy is complaining about, and confirmation that the scaffolded pair resolves that specific deploy error). See
```
references/lwr_route_scaffolding.md
```
for the delegation pointer.

Patch the home page by running:

bash

scripts/patch_lwr_bundle.sh \
  <retrieve-dir>/digitalExperiences/site/<siteName>/sfdc_cms__view/home/content.json \
  <deploymentName> <scrtUrl> <siteEndpoint>

The script deterministically walks

.contentBody.component.children[]

, targets the region with

.type == "region"

and

.name == "content"

, and either updates the existing

.definition == "experience_messaging:embeddedMessaging"

component in place (preserving its

id

) or appends a fresh

community_layout:section

wrapper with a JSON-string

sectionConfig

. See

references/lwr_patch.md

for the JSON shapes it emits and how to verify.

Proceed to Phase 4.

搭建任何缺失的LWR模板路由（通常为
```
too-many-requests
```
）后再进行修补——缺失路由会导致部署失败。路由+视图搭建由
```
experience-lwr-site-generate
```
负责（请参阅其
```
configure-content-route.md
```
、
```
configure-content-view.md
```
和
```
handle-component-and-region-ids.md
```
）。将实际搭建工作委托给该技能，本技能仅提供消息相关上下文（部署报错的路由，以及确认搭建的路由对可解决该特定部署错误）。有关委托指引，请参阅
```
references/lwr_route_scaffolding.md
```
。

通过运行以下命令修补主页：

bash

scripts/patch_lwr_bundle.sh \
  <retrieve-dir>/digitalExperiences/site/<siteName>/sfdc_cms__view/home/content.json \
  <deploymentName> <scrtUrl> <siteEndpoint>

脚本会确定性遍历

.contentBody.component.children[]

，定位

.type == "region"

且

.name == "content"

的区域，要么就地更新现有的

.definition == "experience_messaging:embeddedMessaging"

组件（保留其

id

），要么附加一个新的

community_layout:section

包装器及JSON字符串格式的

sectionConfig

。有关其输出的JSON格式及验证方法，请参阅

references/lwr_patch.md

。

进入阶段4。

Phase 3 — Patch the Aura Bundle

阶段3 —— 修补Aura包

Patch the home guest layout by running:

bash

scripts/patch_aura_bundle.sh \
  <retrieve-dir>/experiences/<siteName>/views/homeGuestLayout.json \
  <deploymentName> <scrtUrl> <siteEndpoint>

The script iterates

.regions[]

, picks the first region whose

.components[]

is non-empty, recurses through any

forceCommunity:section

wrappers, and either updates the existing

.componentName == "experience_messaging:embeddedMessaging"

component in place (preserving

id

) or appends a fresh

forceCommunity:section

wrapper. Aura uses

componentName

componentAttributes

(not

definition

attributes

) and has no

dxpStyle

. See

references/aura_patch.md

for JSON shapes and verification steps.

Proceed to Phase 4.

通过运行以下命令修补主页访客布局：

bash

scripts/patch_aura_bundle.sh \
  <retrieve-dir>/experiences/<siteName>/views/homeGuestLayout.json \
  <deploymentName> <scrtUrl> <siteEndpoint>

脚本会遍历

.regions[]

，选择第一个

.components[]

非空的区域，递归遍历所有

forceCommunity:section

包装器，要么就地更新现有的

.componentName == "experience_messaging:embeddedMessaging"

组件（保留

id

），要么附加一个新的

forceCommunity:section

包装器。Aura使用

componentName

componentAttributes

（而非

definition

attributes

），且无

dxpStyle

。有关JSON格式及验证步骤，请参阅

references/aura_patch.md

。

进入阶段4。

Phase 4 — Stage and Deploy

阶段4 —— 暂存与部署

Copy the modified bundle into the project's default package. Use
```
cp -R
```
so unchanged files travel with the modified one:
- LWR:
```
cp -R <retrieve-dir>/digitalExperiences force-app/main/default/
```
- Aura:
```
cp -R <retrieve-dir>/experiences force-app/main/default/
```
  and also copy the sibling
```
<siteName>.site-meta.xml
```
  file — Aura deploys are rejected without it.

Async deploy and poll:

bash

sf project deploy start --source-dir force-app/main/default \
  --target-org <org-alias> --async

Poll every 15 seconds up to 10 minutes:

bash

sf project deploy report --job-id <job-id> --target-org <org-alias>

Stop when status is

Succeeded

Failed

SucceededPartial

, or

Canceled

. On failure, surface the deploy report and do not proceed to publish. See

references/deploy_and_publish.md

for the full polling loop and common failure modes.

将修改后的包复制到项目的默认包中。使用
```
cp -R
```
命令，确保未修改的文件与修改后的文件一同复制：
- LWR：
```
cp -R <retrieve-dir>/digitalExperiences force-app/main/default/
```
- Aura：
```
cp -R <retrieve-dir>/experiences force-app/main/default/
```
  同时复制同级的
```
<siteName>.site-meta.xml
```
  文件——缺少该文件会导致Aura部署被拒绝。
异步部署并轮询：
bash
```
sf project deploy start --source-dir force-app/main/default \
  --target-org <org-alias> --async
```
每15秒轮询一次，最多轮询10分钟：
bash
```
sf project deploy report --job-id <job-id> --target-org <org-alias>
```
当状态为
```
Succeeded
```
、
```
Failed
```
、
```
SucceededPartial
```
或
```
Canceled
```
时停止轮询。若部署失败，展示部署报告且不继续执行发布步骤。有关完整轮询循环和常见失败模式，请参阅
```
references/deploy_and_publish.md
```
。

Phase 5 — Publish and Verify

阶段5 —— 发布与验证

Resolve the
Network.Name
.

Network.Name

frequently differs from the site

DeveloperName

, so query it by the URL path prefix rather than guessing:

bash

sf data query --query \
  "SELECT Name FROM Network WHERE UrlPathPrefix='<urlPath>' LIMIT 1" \
  --target-org <org-alias>

Publish the community with the resolved name:

bash

sf community publish --name "<resolved-Name>" --target-org <org-alias>

Smoke-test guest access by hitting the public URL:
bash
```
curl -sL -o /dev/null -w "%{http_code}" \
  https://<domainHostname>/<urlPath>
```
Report success only when the response is
```
200
```
.

解析
Network.Name
。

Network.Name

通常与站点

DeveloperName

不同，因此请通过URL路径前缀查询，而非猜测：

bash

sf data query --query \
  "SELECT Name FROM Network WHERE UrlPathPrefix='<urlPath>' LIMIT 1" \
  --target-org <org-alias>

使用解析后的名称发布社区：

bash

sf community publish --name "<resolved-Name>" --target-org <org-alias>

通过访问公共URL测试访客访问权限：

bash

curl -sL -o /dev/null -w "%{http_code}" \
  https://<domainHostname>/<urlPath>

仅当响应为

时报告成功。

Phase 6 — Manual Fallback

阶段6 —— 手动回退

If any automated step fails (bundle undetectable, patch write blocked, deploy fails, publish fails, or guest URL not
```
200
```
), print the Experience Builder deep link and verbatim instructions from
```
references/manual_fallback.md
```
. Do not claim the widget is live until the user confirms.
The deep link is:
text
```
https://<MyDomain>.lightning.force.com/sfsites/picasso/core/config/commeditor.apexp?...networkId=<Network.Id>
```
Resolve
```
<MyDomain>
```
via
```
sf org display --target-org <org-alias>
```
and
```
<Network.Id>
```
via:
bash
```
sf data query --query \
  "SELECT Id FROM Network WHERE UrlPathPrefix='<urlPath>' LIMIT 1" \
  --target-org <org-alias>
```
Do not hardcode either value. Instruct the user to open Experience Builder, drag the Embedded Messaging component onto the target page, pick the deployment from the property panel, and click Publish.

若任何自动化步骤失败（包无法检测、修补写入被阻止、部署失败、发布失败或访客URL未返回
```
200
```
），打印Experience Builder深度链接及
```
references/manual_fallback.md
```
中的完整说明。除非用户确认，否则请勿声称组件已上线。
深度链接格式如下：
text
```
https://<MyDomain>.lightning.force.com/sfsites/picasso/core/config/commeditor.apexp?...networkId=<Network.Id>
```
通过
```
sf org display --target-org <org-alias>
```
解析
```
<MyDomain>
```
，通过以下命令解析
```
<Network.Id>
```
：
bash
```
sf data query --query \
  "SELECT Id FROM Network WHERE UrlPathPrefix='<urlPath>' LIMIT 1" \
  --target-org <org-alias>
```
请勿硬编码任何值。指导用户打开Experience Builder，将Embedded Messaging组件拖到目标页面，在属性面板中选择部署，然后点击发布。

Rules / Constraints

规则/约束

Constraint	Rationale
Detect bundle type from retrieval output, do not assume	LWR and Aura sites need different files patched with different key names
Preserve the existing component `id` when updating in place	Ensures idempotency; the Experience runtime keys off `id`
Every new `id` must be a fresh UUID	Duplicate IDs corrupt the layout and can fail render
LWR uses `definition` / `attributes` ; Aura uses `componentName` / `componentAttributes`	Wrong key names silently drop the component from render
LWR `community_layout:section` `sectionConfig` is a JSON string, not a nested object	The Experience CMS serializer expects a string
Aura sibling `<siteName>.site-meta.xml` must be copied alongside the bundle	Deploy is rejected without it
Poll the async deploy; do not fire-and-forget	Publish must run only after deploy succeeds
Resolve `Network.Name` from `UrlPathPrefix` , do not reuse site `DeveloperName`	The two are frequently different
Do not claim "live on the site" until the guest URL returns `200` or the user confirms	Publish is asynchronous; premature success reports mislead
Never hardcode `MyDomain` or `Network.Id` in the manual fallback link	Values are org-specific and must be queried
Idempotency: re-running with new ESD coordinates must update in place	Users iterate on `deploymentName` , `scrtUrl` , `siteEndpoint` during setup

约束	理由
从检索输出检测包类型，不做假设	LWR和Aura站点需要修补不同的文件，且使用不同的键名
更新时保留现有组件的 `id`	确保幂等性；Experience运行时依赖 `id`
每个新 `id` 必须是全新的UUID	重复ID会破坏布局并可能导致渲染失败
LWR使用 `definition` / `attributes` ；Aura使用 `componentName` / `componentAttributes`	错误的键名会导致组件被静默排除在渲染之外
LWR的 `community_layout:section` 的 `sectionConfig` 是JSON字符串，而非嵌套对象	Experience CMS序列化程序要求为字符串格式
Aura的同级 `<siteName>.site-meta.xml` 必须与包一同复制	缺少该文件会导致部署被拒绝
轮询异步部署，不采用“触发即遗忘”方式	必须在部署成功后再执行发布步骤
通过 `UrlPathPrefix` 解析 `Network.Name` ，不重复使用站点 `DeveloperName`	两者通常不同
仅当访客URL返回 `200` 或用户确认手动发布后，才可声称“已上线”	发布是异步操作；过早报告成功会产生误导
手动回退链接中切勿硬编码 `MyDomain` 或 `Network.Id`	这些值为组织特定值，必须通过查询获取
幂等性：使用新ESD坐标重新运行必须就地更新	用户在设置过程中会迭代 `deploymentName` 、 `scrtUrl` 、 `siteEndpoint`

Gotchas

常见问题

Issue	Resolution
`too-many-requests` route missing during LWR deploy	Scaffold the missing route+view pair per `references/lwr_route_scaffolding.md`
Aura deploy rejected with missing site metadata	Copy the sibling `<siteName>.site-meta.xml` from the retrieve dir
Component appended but not rendering	Confirm the region wrapper uses the correct `type: "region"` key and that Aura components use `componentName` (not `definition` )
`sf community publish` fails with "community not found"	The `Network.Name` differs from site `DeveloperName` ; resolve via `UrlPathPrefix` query
Guest URL returns `403` or `503` after publish	Publish is async — retry the smoke test after 60s before falling back to manual
Re-run adds a second messaging component	The recursive search matched on the wrong key name; component detection must use `definition` (LWR) or `componentName` (Aura)
Deploy succeeds but widget does not appear	The messaging component is present in a region that is not on the site's home page — patch `home/content.json` (LWR) or `homeGuestLayout.json` (Aura), not another view
`sectionConfig` written as an object	Serialize it as a JSON string; the CMS parser will not accept an object

问题	解决方案
LWR部署期间提示 `too-many-requests` 路由缺失	根据 `references/lwr_route_scaffolding.md` 搭建缺失的路由+视图对
Aura部署因缺少站点元数据被拒绝	从检索目录复制同级的 `<siteName>.site-meta.xml` 文件
组件已附加但未渲染	确认区域包装器使用正确的 `type: "region"` 键，且Aura组件使用 `componentName` （而非 `definition` ）
`sf community publish` 因“未找到社区”失败	`Network.Name` 与站点 `DeveloperName` 不同；通过 `UrlPathPrefix` 查询解析
发布后访客URL返回 `403` 或 `503`	发布是异步操作——回退到手动操作前，等待60秒后重试冒烟测试
重新运行后添加了第二个消息组件	递归搜索匹配了错误的键名；组件检测必须使用 `definition` （LWR）或 `componentName` （Aura）
部署成功但组件未显示	消息组件位于站点主页以外的区域——修补 `home/content.json` （LWR）或 `homeGuestLayout.json` （Aura），而非其他视图
`sectionConfig` 被写入为对象	将其序列化为JSON字符串；CMS解析器不接受对象格式

Verification Checklist

验证清单

Bundle Detection

包检测

Was exactly one of

sfdc_cms__view/home/content.json

(LWR) or

views/homeGuestLayout.json

(Aura) found?

If neither was found, did the workflow route to the manual fallback?

是否仅找到

sfdc_cms__view/home/content.json

（LWR）或

views/homeGuestLayout.json

（Aura）中的一个？

若两者均未找到，工作流是否跳转到手动回退？

Patch Correctness

修补正确性

For LWR, are the messaging component's keys
```
definition
```
and
```
attributes
```
?
For Aura, are the keys
```
componentName
```
and
```
componentAttributes
```
?
When updating in place, was the existing
```
id
```
preserved?
When appending, are all new
```
id
```
values fresh UUIDs?
For LWR, is
```
sectionConfig
```
a JSON string (not a nested object)?
For LWR, do the UUIDs referenced inside
```
sectionConfig
```
match the section
```
id
```
and child region
```
id
```
?

对于LWR，消息组件的键是否为
```
definition
```
和
```
attributes
```
？
对于Aura，键是否为
```
componentName
```
和
```
componentAttributes
```
？
更新时是否保留了现有
```
id
```
？
附加时，所有新
```
id
```
是否为全新的UUID？
对于LWR，
```
sectionConfig
```
是否为JSON字符串（而非嵌套对象）？
对于LWR，
```
sectionConfig
```
中引用的UUID是否与区域
```
id
```
和子区域
```
id
```
匹配？

Deploy

部署

For Aura, was
```
<siteName>.site-meta.xml
```
copied alongside the bundle?
Was the async deploy polled until a terminal status?
Is the terminal status
```
Succeeded
```
or
```
SucceededPartial
```
before proceeding to publish?

对于Aura，是否将
```
<siteName>.site-meta.xml
```
与包一同复制？
是否轮询异步部署直至终端状态？
在执行发布前，终端状态是否为
```
Succeeded
```
或
```
SucceededPartial
```
？

Publish

发布

Was
```
Network.Name
```
resolved via
```
UrlPathPrefix
```
, not reused from site
```
DeveloperName
```
?
Did
```
sf community publish
```
complete without error?

是否通过
```
UrlPathPrefix
```
解析
```
Network.Name
```
，而非重复使用站点
```
DeveloperName
```
？
```
sf community publish
```
是否无错误完成？

Verify

验证

Did the guest URL curl return
```
200
```
?
Did the workflow refrain from claiming success until
```
200
```
was observed or the user confirmed manual publish?

访客URL的curl请求是否返回
```
200
```
？
工作流是否在观察到
```
200
```
或用户确认手动发布后才声称成功？

Output Expectations

输出预期

Deliverables:

Modified home-page JSON in the retrieval directory and in
```
force-app/main/default/...
```
(LWR only, if needed) new
```
sfdc_cms__route/<RouteApiName>/
```
+
```
sfdc_cms__view/<viewId>/
```
pair for any scaffolded missing route
Deploy
```
job-id
```
and the final deploy report
Publish confirmation
Guest URL smoke-test HTTP status
On failure: the Experience Builder deep link and manual instructions

Do not produce the

EmbeddedServiceConfig

or the

MessagingChannel

metadata — those are the responsibilities of the deployment and channel skills below.

交付成果：

检索目录和
```
force-app/main/default/...
```
中已修改的主页JSON
（仅LWR，若需要）为任何搭建的缺失路由新增的
```
sfdc_cms__route/<RouteApiName>/
```
+
```
sfdc_cms__view/<viewId>/
```
对
部署
```
job-id
```
和最终部署报告
发布确认
访客URL冒烟测试的HTTP状态
失败时：Experience Builder深度链接和手动操作说明

请勿生成

EmbeddedServiceConfig

或

MessagingChannel

元数据——这些属于下方部署和渠道技能的职责。

Cross-Skill Integration

跨技能集成

Need	Delegate to
Create or update the Embedded Service Deployment	`service-digital-engagement-deployment-configure`
Create the underlying MIAW messaging channel	`service-digital-engagement-channel-configure`
Create the Experience Cloud LWR site itself	`experience-lwr-site-generate`
Scaffold a missing LWR route + view pair (e.g. `too-many-requests` )	`experience-lwr-site-generate` (route/view creation, ID handling)

需求	委托给
创建或更新嵌入式服务部署	`service-digital-engagement-deployment-configure`
创建底层MIAW消息渠道	`service-digital-engagement-channel-configure`
创建Experience Cloud LWR站点本身	`experience-lwr-site-generate`
搭建缺失的LWR路由+视图对（如 `too-many-requests` ）	`experience-lwr-site-generate` （路由/视图创建、ID处理）

Reference File Index

参考文件索引

File	When to read
`references/bundle_detection.md`	Phase 1 — LWR vs Aura retrieval and disambiguation
`references/lwr_route_scaffolding.md`	Phase 2 — delegation pointer for scaffolding missing LWR template routes (owned by `experience-lwr-site-generate` )
`references/lwr_patch.md`	Phase 2 — what `patch_lwr_bundle.sh` does and how to verify its output
`references/aura_patch.md`	Phase 3 — what `patch_aura_bundle.sh` does and how to verify its output
`references/deploy_and_publish.md`	Phases 4–5 — staging into `force-app` , async deploy polling, publish, and guest-URL smoke test
`references/manual_fallback.md`	Phase 6 — Experience Builder deep link and manual drag-drop-publish instructions
`scripts/detect_bundle_type.sh`	Phase 1 — deterministic LWR/Aura/UNKNOWN detection over a retrieved bundle
`scripts/patch_lwr_bundle.sh`	Phase 2 — idempotent LWR `content.json` patch (insert or update in place)
`scripts/patch_aura_bundle.sh`	Phase 3 — idempotent Aura `homeGuestLayout.json` patch (insert or update in place)

文件	阅读时机
`references/bundle_detection.md`	阶段1 —— LWR与Aura的检索和区分
`references/lwr_route_scaffolding.md`	阶段2 —— 搭建缺失LWR模板路由的委托指引（由 `experience-lwr-site-generate` 负责）
`references/lwr_patch.md`	阶段2 —— `patch_lwr_bundle.sh` 的功能及输出验证方法
`references/aura_patch.md`	阶段3 —— `patch_aura_bundle.sh` 的功能及输出验证方法
`references/deploy_and_publish.md`	阶段4-5 —— 暂存到 `force-app` 、异步部署轮询、发布及访客URL冒烟测试
`references/manual_fallback.md`	阶段6 —— Experience Builder深度链接及手动拖放发布说明
`scripts/detect_bundle_type.sh`	阶段1 —— 对检索到的包进行确定性LWR/Aura/UNKNOWN检测
`scripts/patch_lwr_bundle.sh`	阶段2 —— 幂等性修补LWR `content.json` （插入或就地更新）
`scripts/patch_aura_bundle.sh`	阶段3 —— 幂等性修补Aura `homeGuestLayout.json` （插入或就地更新）