---
name: openxiangda-support
description: 在 OpenXiangda 应用开发中接入内部平台支持协作，咨询平台契约、诊断异常、评审产品与架构，并持续跟进已授权的支持案例。普通应用实现继续使用项目对应代际技能。
---

# OpenXiangda 支持协作

## 接入与恢复

统一入口的 `support status --json` 返回实际接入状态、精确 DWS profile 和当前通道。新应用创建及技能刷新会执行 bootstrap；离线或待授权不会阻塞应用。缺失时执行 `support bootstrap`，由它安装/复用官方稳定 DWS 和全套 multi 技能。旧 V1 项目通过统一入口使用支持命令，业务仍走项目 V1 引擎；不升级项目代际来取得支持。

`support login` 引导用户完成 OAuth；SSH 使用 `--device`。多账号时使用用户指定的 `--profile <corpId:userId>` 或目标组织明确的默认账号，后续复用保存的 profile。不得切换全局默认组织或根据姓名选账号。`support join` 原样打开外置配置的邀请链接，用户在钉钉完成加入；不能打开时展示返回的同一地址。随后运行 `support status` 检查群访问。链接已打开、命令退出成功或群可读不等于独立验证了成员身份或组织限制，以返回的各项状态为准。

DWS 命令、参数和实际访问由官方 `dingtalk-chat`、`dingtalk-event` 及其 references 负责；账号问题读取 `dingtalk-misc/references/profile.md`。始终带同一 `--profile` 和 `--format json`，按叶子 Schema/Help 补齐未知参数。授权、加入或服务暂不可用时记录待办，继续独立的应用工作。

## 何时讨论

遇到平台契约不明确、文档与实测冲突、需要平台源码/部署/日志证据、复杂权限与数据处理、通用能力取舍或新需求评审时，先读项目当前资料及证据，再在用户已经授权的协作范围内发问。此技能不会单独授予发送消息、操作服务器、修改数据或发布权限。

提问包含目标、现象、已尝试方法、关键证据、需平台判断的问题；从项目 context 补平台、应用、环境及实际版本。未创建应用的能力咨询标记为平台咨询，不伪造 appCode。内部协作可以讨论相关业务逻辑、源码、日志和完整方案；凭据自动遮蔽，不把维护者 localhost 地址作为其他成员的审阅入口。

需要读取应用源码时，提供平台地址及平台内置仓库 URL。支持侧使用正式 `source resolve <仓库URL> --base-url <平台> --json`，再 `source clone <仓库URL> <新目录> --base-url <平台> --json`；记录实际分支与 commit，首次检出不安装或运行项目脚本。使用平台现有身份和 `PLATFORM_ADMIN` 权限事实，不按某个账号名字开例外。旧项目使用 `source setup --import` 保留原仓库，正常解决 Git 冲突；详细契约以当前版本 getting-started 资料为准。

## 评审与持续协作

产品/架构咨询明确真实问题、已有能力、应用或平台归属、跨项目价值、成本与兼容性、失败恢复和验收方法。可以得出现有能力可满足、应用层实现、证据不足、重复需求、平台候选、已安排实施或拒绝/延期；每项结论附证据及下一步责任方。只有关联真实工程任务及容量才称为已安排实施，不口头承诺发布日期，不把客户业务实体当作平台定义。

首问使用官方群消息入口；后续按真实消息 ID 引用回复，沿同一案例追加证据与验证，不重复创建问题。读取回复后补实现/复现结果，明确解决、暂行规避、候选需求或尚有争议；已回答不等于已解决。复杂或高影响操作先给具体对象、差异、影响、恢复方式，在已有授权范围内推进，超出部分才请求决定。

活跃任务可通过官方事件技能等待增量，恢复任务时读取未完成案例。消息 ID、游标、未决项和下一步责任方保留在项目现有交接记录中，不含凭据。技能不会唤醒结束的 AI 会话；后台继续需要宿主真实监听或定时任务，不宣称所有宿主均已接入。

两个 AI 使用不同真实身份。发送请求成功不是消息投递成功；检查真实投递结果，结果不明先回读，不盲目重发。确认、感谢和重复消息不启动新轮；初始上限 6 轮有效往返，连续 2 轮无新证据时暂停并列未决项。结论引用来源和适用版本交给既有案例/知识流程，不另建一套权威路线图。