中风险
Provider 边界可能向过多后代组件授予草稿读取和提交能力
原文依据：3 处发现了什么
指南明确把 Provider 边界作为访问控制范围：边界内的组件可读取消息和附件，也可调用 submit，即使不在 Composer.Frame 内。如果应用把 Provider 包在较大的组件树或包含不完全可信的第三方组件，这些后代会获得超出界面外观所暗示的能力。
为什么需要注意
受影响的后代组件可能读取尚未发送的内容、修改共享状态，或触发转发/提交动作。证据没有显示数据会被发送到外部，也没有显示这些动作会自动执行；风险取决于使用该模式时的 Provider 范围和后代组件。
该风险在架构层面成立，但不是已经发生的数据泄露。指南主动建议以 Provider 范围共享状态，并示例说明 Frame 外的后代可调用 submit、读取消息及附件。若应用把同一 Provider 扩展到不需要这些能力或不完全可信的组件，它们可能获得草稿读取或提交能力。这里是文档中的示例代码，不会由 Skill 自行执行。用户可要求作者明确 Provider 不是安全边界，并将其限制在最小可信组件树中。
The provider boundary is what matters—not the visual nesting. Components thatneed shared state don't have to be inside the `Composer.Frame`. They just needto be within the provider.查看另外 2 个位置
// This button lives OUTSIDE Composer.Frame but can still submit based on its context!function ForwardButton() { const { actions: { submit }, } = use(ComposerContext) return <Button onPress={submit}>Forward</Button>}// This preview lives OUTSIDE Composer.Frame but can read composer's state!function MessagePreview() { const { state } = use(ComposerContext) return <Preview message={state.input} attachments={state.attachments} />}The ForwardButton lives outside the Composer.Frame but still has access to thesubmit action because it's within the provider. Even though it's a one-offcomponent, it can still access the composer's state and actions from outside theUI itself.**Key insight:** Components that need shared state don't have to be visuallynested inside each other—they just need to be within the same provider.