uipath-governance

UiPath 治理

用于编写 UiPath 治理策略的综合技能。由两个 CLI 接口提供支持：

接口	管理对象	CLI
AOps 产品策略	产品功能行为——Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder 在设计时 / 运行时可以执行的操作	uip gov aops-policy
访问策略（ToolUsePolicy）	资源 / 工具使用边界——Actor Process 调用子级 Resource（Agent / Maestro / Flow / RPA / API / Case Management）时，是否允许该调用？	uip gov access-policy

两个接口都支持相同的动词（block、restrict、deny、allow、require、enforce）。同一句英文描述通常可能对应任一层，因此此技能会先分类，再使用相应机制处理。

何时使用此技能

遇到任何治理 / 策略 / 规则相关意图时启用——即使用户没有提及底层 CLI：

• policy / rule / guardrail / govern / gate / control 请求
• block / restrict / deny / disable / disallow 某个操作、模型、应用、URL、Agent、Flow 或 Process
• require / enforce / mandate 某种行为或规则
• allow only / permit only / limit to / restrict to X
• who can / which … can / on behalf of——与执行主体或身份相关的治理
• 基于策略的 compliance / posture / audit 表述
• .uipolicy 文件路径、compliance standard、apply standard
• 标准名称：ISO 42001、ISO 27001、GDPR、HIPAA、SOC 2、EU AI Act。仅凭名称即可确定路由——哪些标准实际可用取决于环境，并会在运行时从 catalog list 读取，此处不会预先假定。
• check compliance、compliance posture、posture against、drift check
• is my tenant compliant、am I compliant with
• organization-wide、all tenants、entire org、across all tenants——组织范围内的完整应用

故障排除

• 调查治理策略未生效的原因
• 调试部署优先级（用户 > 组 > 租户覆盖）
• 根据测试场景评估访问策略规则（access-policy evaluate）
• 排查被阻止的工具 / 工作流调用
• 审计已部署的策略及其适用对象
• 找出导致静默无操作的许可证类型 / 产品不匹配问题

同级技能跳转：

• 平台运维（身份验证、Orchestrator 资源、打包、部署）→ uipath-platform
• 编写 Agent / 工作流 / RPA 本身 → uipath-agents / uipath-rpa / uipath-maestro-flow

关键规则

1. 开始编写前先分类。 处理任何治理请求时，首先要将意图归类到分支 A（AOps）或分支 B（Access）。使用 references/disambiguation-guide.md 中的先验判断。分类尚未确定前，绝不要开始执行 create / update / delete——无论是根据用户的措辞还是通过消歧问题确定分类。
2. 在最上层完成分类。 机制库默认分支已经选定。不要让这些流程询问“你指的是另一个分支吗？”——这个问题应在此处提出。
3. 每次变更只走一个分支。 单个用户请求只能在一个分支上生成策略。如果用户两者都想要，就依次执行两个流程，并设置两个确认关卡。
4. 每套机制都有自己的关键规则。 路由到相应分支后，遵循该分支的规则——不要从此顶层放宽规则。
5. 未经用户确认，绝不应用、还原或移除合规设置。 对于应用操作：先运行合规状态分析，再展示计划（摘要 + 详情）。无论哪种情况：都要先询问，然后结束回复——绝不要在提出确认问题的同一条回复中运行变更命令。只有在用户的下一条消息中明确回复 y 后才可继续。用户最初的请求表示意图，并非同意。唯一例外：用户事先明确表示无需确认（例如“不要请求确认”）——将此豁免视为 y。
6. 每次应用后都要提供回执。 呈现应用后的报告（已配置的设置、所需的手动步骤、应用者 / 日期），以便用户留存记录。无需写入本地文件——CLI 和 UiPath 平台是事实来源。
7. Compliance Standards 是预览功能——所有合规包流程都必须经过准入检查。 面向用户的合规标准回复中都要附上预览免责声明；如果任何 uip gov compliance-packs … 调用返回 HTTP 403 / Forbidden，立即停止（不要重试，也不要运行其他合规命令），并告知用户该功能需要注册预览计划。免责声明的准确措辞和位置见 references/compliance-pack/preview-gate.md。403 表示未启用预览；401 是常规登录失败——两者绝不可混淆。
8. 运行任何 uip gov … 命令前，始终先运行 uip login。 evaluate（Access）还要求使用租户范围的登录——参见 access-policy-overview-guide.md § Critical Rules。
9. 标准尚未确定前，绝不运行范围限定为合规包的命令。 state coverage、state get、state enable、state disable、state restore 和 catalog get 都需要 packId，且有多个可用标准——因此，未指定标准的请求（“检查我的合规状态”“我是否合规”）并未确定合规包。运行 catalog list，列出可用标准，询问用户要选哪个，然后结束回复。绝不要因为某个标准排在列表首位、最常见或是你之前见过的唯一标准，就擅自选择：即使命令全部成功，根据用户未指定的标准报告合规状态也是错误的。处理规则见 references/compliance-pack/catalog/impl.md § Pack ID lookup。
10. 绝不捏造 UUID。 根据相应分支的查询结果，解析每个已指定的用户 / 组 / 流程 / Agent / 流 / 机器人 / 租户。

工作流

1. 在内部判断意图，绝不要向用户说明路由情况。 内部流程标签（AOps / Access / Compliance standard）是实现细节；用户只会看到结果。阅读 references/disambiguation-guide.md——其中列出了各流程的强信号、需要消歧的短语模式，以及规范的完整示例。如果匹配到强信号，就静默路由。如果措辞含糊（同时匹配 AOps 或 Access），请提出消歧问题，并等待用户回复数字。如果用户回复的不是 1 或 2，则将其视为对意图的重新表述，并重新判断。在分类确定之前，不要运行任何 CLI 命令——提出消歧问题本身不需要 uip，无关请求（平台运维、Agent 编写）则必须在此处进行任何设置之前，重定向到同级技能。如果请求包含标准名称（ISO 42001、ISO 27001、GDPR、HIPAA、SOC 2、EU AI Act）、apply standard、compliance posture、drift check、am I compliant、is my tenant compliant、what packs are available、what packs are configured、which standards are enabled、organization-wide、disable standard 或 reset / restore / undo drift on a standard，则静默路由到相应的合规标准插件，并先确定具体标准（references/compliance-pack/catalog/impl.md § Pack ID lookup）——有多个可用标准，因此不提及标准的请求（例如“check my compliance posture”）需要先确定标准，再运行任何针对特定 pack 的命令。对于范围受限的请求，阅读 partial-apply/planning.md；对于合规状况检查，阅读 coverage/impl.md；对于发现可用项，阅读 catalog/impl.md；对于信息查询，阅读 query/impl.md；确认合规状况计划后，阅读 full-apply/impl.md；对于移除操作，阅读 disable/impl.md；对于将已配置的标准重置为建议设置，阅读 restore/impl.md；对于列出当前已配置的 pack，阅读 catalog/impl.md + state list。
2. 验证 uip 并登录 （仅在分类后路由到治理流程时执行）。

   which uip && uip --version
   uip login status --output json
   

   如果尚未安装，请运行官方安装程序（macOS/Linux 上运行 curl -fsSL https://download.uipath.com/uipath-cli/install.sh | bash；Windows PowerShell 中运行 irm https://download.uipath.com/uipath-cli/install.ps1 | iex）。如果尚未登录：运行 uip login（非生产环境使用 --authority <URL>）。对于 Access evaluate，必须以租户级范围登录。 如果已登录到同一组织中的错误租户，请使用快速方式：先运行 uip login tenant list --output json，然后运行 uip login tenant set <NAME>。只有在切换到不同组织或 authority 时才需要完整重新登录。参见 references/auth-context.md § 切换租户。
3. 路由到选定的机制，并从头到尾遵循对应流程。
   • AOps 产品策略 → references/aops-policy/aops-policy-overview-guide.md
   • Access ToolUsePolicy → references/access-policy/access-policy-overview-guide.md
   • 合规标准 → 使用上方第 1 步中的插件路由（catalog / coverage / full-apply / partial-apply / disable / restore / query）

消歧问题

当用户意图同时符合两个分支时，请原样呈现以下编号列表（不要使用 AskUserQuestion，也不要使用表格），并等待用户回复数字：

### Which layer should this rule govern?

1. **Govern the product** — control what Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder *can do* (e.g. block ChatGPT inside Studio, enforce Workflow Analyzer, disable a Marketplace widget). Backed by `uip gov aops-policy`.
2. **Govern resource/tool use** — control which Actor Processes / identities can *invoke* which child Resource as a tool (e.g. block agents tagged `Sandbox` from being called, only let the finance group trigger this Flow). Backed by `uip gov access-policy`.

Reply with the number.

规范的含糊提示是 “Block ChatGPT for my finance team using Studio.” 有关两种解读为何都会产生可用但不同的产物，请参阅 references/disambiguation-guide.md 中的完整推理示例。

参考导航

我需要……	阅读
判断请求属于哪个分支（先验信息、短语表、示例）	references/disambiguation-guide.md
编写 AOps 产品策略	references/aops-policy/aops-policy-overview-guide.md
将 AOps 策略部署到用户 / 组 / 租户	references/aops-policy/aops-policy-deploy-guide.md
查询已部署的 AOps 策略 / 生效规则	references/aops-policy/aops-policy-deployed-guide.md
编写 Access ToolUsePolicy	references/access-policy/access-policy-overview-guide.md
查询 CLI 标志 / 输出格式（AOps）	references/aops-policy/aops-policy-commands.md
查询 CLI 标志 / 输出格式（Access）	references/access-policy/access-policy-commands.md
将名称解析为 Access 的 UUID	references/access-policy/resource-lookup-guide.md
诊断治理故障（能力索引）	references/diagnose/CAPABILITY.md
识别已知的治理故障模式	references/diagnose/failure-modes.md
按优先级逐步排查问题	references/diagnose/troubleshooting-guide.md
发现可用的合规标准 / 将标准名称解析为 packId	references/compliance-pack/catalog/impl.md
列出当前配置的合规标准	references/compliance-pack/catalog/impl.md — 使用 state list tenant <id>
态势分析——哪些设置已配置，哪些是建议设置	references/compliance-pack/coverage/impl.md
应用完整的合规包	先运行 coverage，然后阅读 references/compliance-pack/full-apply/impl.md
应用特定控制项 / 条款	references/compliance-pack/partial-apply/planning.md
移除合规标准设置	references/compliance-pack/disable/impl.md
将标准重置 / 还原为建议设置（撤销偏离）	references/compliance-pack/restore/impl.md
查询——某条款 / 控制项建议什么？	uip gov compliance-packs catalog get <packId> --output json（从 catalog list 解析 <packId>——切勿硬编码），然后阅读 references/compliance-pack/query/impl.md
预览免责声明 + 403 自愿启用门槛（所有合规流程）	references/compliance-pack/preview-gate.md

反模式

• 如果措辞同时符合两个分支，切勿跳过消歧问题。机制库假定已选定分支，不会发现路由到了错误分支。
• 切勿先移交给机制，再问“你指的是另一个分支吗？”。必须在此顶层提出这个问题。
• 切勿将 AOps 和 Access 意图合并到同一策略中。它们使用不同的制品、不同的 CLI 和不同的架构。
• 切勿为平台运维激活此技能。应路由到 uipath-platform。
• 如果意图与任一分支都不匹配，切勿建议编辑技能。请用户澄清。
• 切勿使用 deployed-policy list 检测差距——它会按优先级返回所有规则，而不是合并后的有效值。请使用 deployed-policy get <licenseType> <productName> <tenantId> 获取单个有效的合并策略。
• 即使 apply 部分失败，也切勿跳过应用后的报告——说明哪些操作成功，以及哪些需要人工处理。
• 对于合规包状态分析，请使用 uip gov compliance-packs state coverage——切勿使用 aops-policy deployed-policy 命令；这些命令用于 AOps 策略调试（分支 A），不适用于合规包流程。
• 对于完整的包配置，请使用 state enable——切勿手动为每个产品调用 aops-policy create；该路径仅适用于部分或限定范围的配置。
• 对于部分或限定范围的配置（仅针对特定条款、产品或领域），请使用 synthesize-formdata.mjs + aops-policy create——切勿调用 state enable；state enable 会应用完整标准，无法限定到特定条款或产品。
• 对于组织范围的应用，切勿调用 state enable organization——后端不支持启用组织范围。应改为：使用 uip login tenant list 列出租户，然后对每个租户分别调用 state enable tenant <id>。请参阅 references/compliance-pack/full-apply/impl.md § 组织范围部署。
• 绝不可声称某个租户符合某项标准——只能说明已配置建议的设置。合规状态由客户的审计员判定。
• 切勿将策略名称、产品标识符（AITrustLayer、Robot、Development）或条款 ID（A.6.2.8）作为主要回复内容——应以通俗易懂的控制项名称和条款说明为主。策略是内部实现细节。条款 ID 只能作为括号中的次要参考信息。
• 面向用户的输出中切勿使用“控制项”一词——请使用“设置”。UiPath UI 将标准建议配置的内容称为“设置”。
• 切勿向用户描述内部步骤。绝不要说“我运行了……”“CLI 返回了……”“正在调用治理 CLI……”，或“API 响应了……”。静默运行命令，并仅使用参考文档中的输出模板呈现解读后的结果。绝不向用户显示原始 JSON、UUID、错误堆栈或 CLI 输出——应使用通俗易懂的语言概述错误。
• 切勿倾倒原始命令输出。解析每条 CLI 响应，并将其呈现为格式化表格或通俗易懂的摘要。用户只需看到结果，不应看到实现过程。