需要通过 ae-cli 执行 AE 分析查询…

适用于用 ae-cli 路由并执行 AE 分析侧数据查询、资产操作、资产治理及 Agent 审查提交流程。

适用场景

解决思路

1. 数据查询时，先取当前项目和请求的指标、窗口、分组、过滤；复用已知资产和定义；对未知业务度量按 references/metadata_resolution.md 发现，再选择需要的 saved-report 或 ad-hoc 命令/模型引用。
2. 对新的业务映射只确认一次，填写必要参数，并执行适用的 saved report 或补全 ad-hoc 定义；在依赖查询中复用已确认含义；如果确认工具不能获得回复，用文本呈现相同选择并等待回复。
3. 在编译器报告的路径修正编译错误；新证据或用户纠正会改变已完成选择；保留其他已验证输入。
4. 直接使用返回结果；只有用户要求文件或必要本地处理需要时才保存原始 JSON；遵循 result handling；保持 stderr 和 CLI exit status 可见。
5. 只计算请求缺少的值，并在一次本地调用中一起计算；复用已完成结果，当请求数据可用时回答，或解释具体错误或缺失输入。
6. 在打开任何参考前，先把请求映射到命令族。
7. 对 CLI Agent 资产认证和指标推荐审查，包括推荐项目资产用于认证、审查资产认证候选、审查项目资产治理建议或审查推荐指标，打开 references/governance_recommendation_export.md 并路由到 analysis-meta governance-recommendation export|submit|decisions；对审查页提交，打开 references/agent_review_submit_to_page.md 并使用 analysis-meta agent-review submit-to-page|list|detail|records|review|retry；不要把 project semantics、project KB 或个人语义偏好作为 preflight。
8. 对项目语义知识库构建、更新、刷新或同步，打开 references/project_semantic_knowledge_wiki.md，路由到 project-semantic asset-package export、本地语义规划和本地 Wiki 渲染；默认用 CLI 语义预编译成 Markdown sources、source ZIP upload 和 KB schema/compile；刷新时更新变更源文件并运行增量 KB compilation；绝不用只读快照导入替代；公司权限拒绝时停止。
9. 对已知命令族，只打开其专用参考；例如 retention 请求直接使用 references/adhoc_run.md、公共 references/ai_models.md 和 references/ai_models/retention.md。
10. 对未知命令族，用 rg 或等价文本搜索工具搜索 references/command_index.md，只保留匹配行；command_index.md 仅作搜索回退，绝不用整文件读取或打印整个文件。
11. 组合前读取所选命令的专用参考：event list 读 references/event_list.md，analysis dashboard list 读 references/dashboard_list.md，personal-semantic-preference list 读 references/personal_semantic_preference_list.md。
12. 资产中心跨源配置（资产中心 / 跨源资产配置 / Excel 配置表导入）用 L3 discovery：capability search cross_source_config --domain metadata --project-id <id>；读 references/cross_source_config.md 了解 workbook upload 和 validation；没有专用业务命令。
13. Gateway 文件名中的连字符替换为下划线。
14. 对 AI-facing definition，读取短的公共 references/ai_models.md 和每个选中模型的 references/ai_models/<model_type>.md；批量读取；直接模型路径代替标题搜索和行号计算。
15. 对 cluster/tag 的 --definition-request，还要读取匹配的 references/user_cluster_models.md 或 references/user_tag_models.md；共享原语在 references/audience_models.md。
16. 对 tag 周期刷新，读取 references/user_tag_create.md 或 references/user_tag_update.md；它们覆盖 enable switch、frequency/time schedule、cron alternative 和 timezone behavior。
17. 查询数据时，将短的 references/analysis_data_retrieval.md 与所选命令和模型文件一起读取；仅当需要导出和后续操作时才链接到 export 和 follow-up 细节。
18. 对未知 AI-facing metadata，或当编译失败包含 slot_kind、allowed_resource_types、search_targets、next_action 时，读取并遵循 references/metadata_resolution.md。
19. 对不熟悉的 aggregation、cohort 或 attribution 规则，查阅 references/analysis_interpretation.md 的匹配章节。
20. 路由完成的标志是选定一个命令族及其专用参考；生成的命令索引是详尽索引，除匹配搜索行外必须留在模型上下文之外；此文件只含路由和工作流规则，不要复制手工维护的命令清单。
21. 将本技能用于这些 CLI 服务：analysis 用于 reports、dashboards、BI panels、ad-hoc analysis、drilldown、detail data、alerts、clusters、tags、async runs/artifacts。
22. analysis-meta 用于 gateway metadata assets、events、properties、virtual metadata、metrics、data tables、exchange rules、super metadata；跨源资产配置使用 metadata L3 catalog。
23. analysis-governance 用于 gateway 资产治理操作，包括 governed asset lists/exports、lineage、dependency、impact、query history、rule schema/list/create/update/delete、batch asset actions、operation records；用于资产治理工作流，不用于 metadata event/property/metric CRUD。
24. tracking 用于 gateway tracking plan、checking、ingest、live-data、event blacklist 操作。
25. personal-semantic-preference 用于当前用户项目范围个人语义偏好；在解决模糊业务措辞、资产选择或反复用户偏好前作为 agent context。
26. project-semantic 和 kb 仅在明确的项目语义知识库命令参考工作流内使用；它们不是资产认证和指标推荐审查的先决条件。
27. 对生成索引之外的 metadata gateway detail，使用 metadata skill；对 Engage、DataOps 或 Community 工作，使用对应 skill。
28. 将 ae-cli 作为本技能唯一执行路径；如果命令缺失、不支持、未实现或确认能力差距，报告该差距，不要切换到直接 MCP 执行。
29. 验证错误或 need_clarification 要求对其具体输入进行纠正。
30. 传输失败如 fetch failed 表示结果不可用：报告错误和已获得结果并停止依赖请求；环境恢复后继续；不要启动 route probes、sleep 或后台网络轮询；传输失败不证明能力缺失或数据为空。
31. 对 tags 和 audience clusters，使用原生 analysis user-tag ... 和 analysis user-cluster ... gateway 命令。
32. 对 CLI Agent 资产认证和指标推荐审查，路由到 analysis-meta governance-recommendation export|submit|decisions；Common 返回确定性证据包；Agent 负责 references/governance_recommendation_export.md 中固定人工审批显示，包括业务域分组、纯文本状态标签、风险/冲突解释。
33. 不要用 project-semantic、project-KB 或 personal-semantic-preference 命令作为该审查工作流的先决上下文。
34. 不要用管理命令如 asset-authentication list|export|update 或 metric CRUD 命令来合成建议。
35. 不要绕过 curated 命令，用 ae-cli capability inspect|validate|dry-run|run 处理 governance.asset_authentication.dashboard_package、metadata.metric.recommended_scan 或 metadata.metric.recommended_create。
36. 展示建议后，可询问是否提交到审查页；用户选择提交只授权 analysis-meta agent-review submit-to-page，不授权 approval 或 certification。
37. 如果用户拒绝提交，不要写入或反复建议提交；已有明确提交授权仍有效且无需再次提示。
38. 预授权无人值守任务只可提交审查提案；绝不自动调用 agent-review review|retry、legacy governance-recommendation submit 或直接 certification/metric mutations。
39. 用 agent-review list|detail|records 和任务持久化的 proposal fingerprint 复用先前批次。
40. 不要对未变更提案、待审、已完成或先前拒绝建议重复提交或重复通知；新 run ID 不是新证据。
41. 报告返回的 review_url 一次，并保持安静直到有有意义变化或需要用户操作；参见 references/agent_review_submit_to_page.md 的稳定请求键和 packet 规则。
42. 报告审查详情必须解释计算逻辑和统计度量，不只业务目的。
43. 遵循 resolve/export -> material-package completeness check -> gap-only analysis-meta agent-review evidence 或 analysis report get -> chunked AI explanation -> independent preflight -> authorized submit-to-page -> detail readback 流程。
44. LOCAL_ONLY 停在本地 preflight 结果。
45. governance-recommendation export 预期包含 report 的 evidence_snapshot.analysis 和 target_revision 在 review_material_package.candidate_assets；这些字段存在时，不要要求客户为每个报告运行 analysis report get。
46. 仅在报告项缺少当前分析、验证生成草稿或材料包明确标记定义缺口时，获取 agent-review evidence。
47. 读取 references/agent_review_evidence.md 了解稳定分析字段及其限制。
48. 用 evidence-backed measures、dimensions、calculations、filters、time_scope、query_columns 填充 item.ai_summary.analysis_explanation（如适用）；分别解释每个支持的 SQL projection column。
49. 仅引用实际支持事实的响应路径，根在 evidence_snapshot.analysis；source_path 是来源，不是自动 evidence_refs 替代。
50. 将服务器事实与 AI 解释分开保存，并明确识别 null、missing、dynamic 或 unparsed evidence。
51. 对 DYNAMIC SQL，将支持的 sql.raw/normalized_definition.params 讨论标记为 original-text interpretation，绝不捏造 select_columns 或 runtime substitutions。
52. Common create 存储提交的 packet；它不为 Agent 填写缺失的计算解释。
53. 调用 submit-to-page 前，检查必需的 evidence_snapshot.analysis 和可解析引用位于 analysis_explanation.calculations / analysis_explanation.measures；缺少必需结构仍是错误。
54. 审查者可读性和解释缺陷遵循 bounded quality correction/warning procedure。
55. 提交后详细验证存储快照和引用。
56. 绝不猜测 SQL、别名、列、公式、时间范围、时区或成功执行；定义检查、证据读取、验证和提交不是查询结果、批准或认证的证明。
57. item.ai_summary.summary 是简洁的项推荐原因，包含证据基础和主要风险，显示在主列表；batch.ai_summary.summary 是批次概览，不能替代项原因。
58. 详细事实解释只放在 item.ai_summary.analysis_explanation；不要把原因或详细分析重复到 presentation fields；保持 presentation_snapshot.analysisByItem 为 {}。
59. 不要从未知值发明原因；明确说明缺失证据或不确定风险，而不是当作零或不存在。
60. 脚本可以构建传输文件、保留 ID、复制证据、规范化链接、运行确定性完整性检查。
61. 脚本不得通过填充可复用句子模板来编写页面可见的 ai_summary.summary、analysis_explanation.*.statement、limitations、open questions 或 approval rationale；这些字段必须是 Agent 根据当前资产/报告证据书写的解释。
62. 如果许多提交项在仅资产名或数字变化后共享相同叙述形状，标记质量失败并遵循 references/agent_review_preflight.md 中 bounded correction/warning procedure。
63. 页面可见审查文本面向人类资产审查者，不是实现者；在 item.ai_summary.summary、可见语句和开放问题中写 plain business Chinese：资产用途、如何计算、哪些 filters/date windows 重要、审查者应确认什么。
64. 当有助于审查者验证计算定义时，使用当前资产定义中的 event 和 property 名称。
65. 不要暴露 internal evidence、parser terms、临时 SQL 别名、runtime parameter names 如 SAVED_REPORT_ONLY、DYNAMIC、REPORT、T1、a0、a1、Variable2、selector3、PartDate date1、source_path、evidence_snapshot、raw JSON、raw SQL、hash/revision details、dashboard override warnings、timezone-not-saved notes 或查询执行声明，除非用户明确要求 debug evidence。
66. 显示前转换内部值，例如 T1/day 变为 按天，dynamic SQL caveats 变为业务确认项如“确认参数含义、默认日期范围和是否包含测试数据”。
67. 真实审查页提交从 analysis-meta governance-recommendation export --limit 20 开始；这是初始候选池，不是必需提交数。
68. 遵循 references/governance_recommendation_export.md 中 rejection filtering 和 bounded expansion procedure：隐藏每个同定义被拒绝 dashboard 的整个显示分支，仅在其他保留 dashboard 下保留共享资产，过滤已 completed/authenticated、deferred 或 in-flight 资产作为 pending work，并从 20 扩展到 50 到 100 后停止。
69. 扩展用于业务域覆盖，不是无限工作量：对重复每日批次，目标约 20-50 待审资产，硬上限约 80，平衡约 3-6 可见域及每域配额后再添加上下文。
70. 使用最新成功 export 作为草拟证据，并报告实际审查范围和溢出留给后续批次。
71. 不要将合格覆盖压缩成几个代表主题或只提交第一个工作单元，除非用户要求样本或诊断批次。
72. 业务主题组织保留的 dashboard 集；不替代其覆盖。
73. 对重复推荐任务，只提交仍包含 pending review assets 的业务域；authenticated assets 是这些可见域下的支持上下文，不是独立工作。
74. 不要为隐藏域或纯 authenticated 上下文写长 Agent summaries。
75. 对 dashboard 推荐，保留来自 Common 的可选 location facts：当 dashboard candidate 或 source dashboard 包含 space_id 或 space_name，将这些字段复制到提交 dashboard item 的 evidence_snapshot.definition.config，以便审查页显示 所属空间。
76. 不是每个 dashboard 都属于空间；缺失空间字段有效，不得发明、要求或用于过滤掉其他合格 dashboard。
77. presentation_snapshot.topics 必须是业务域，不是 dashboard 容器；业务域不是 dashboards。
78. 绝不只因 export 返回 20 work units 就为每个热门 dashboard 创建一个 topic。
79. 首先用 dashboard 名称、子 report 名称、report 定义、引用 events/properties、metrics、folder context、authored notes 聚类选中的 dashboards 按业务流程。
80. 如果多个 dashboards 描述同一业务区域，放入一个 topic，并将每个 dashboard 保留为该 topic 下根项。
81. 仅当业务流程或审查决定有实质不同才拆分 topics。
82. 期望层级是 业务域 -> 看板 -> 报表 -> 元数据；topic 数量可小于选中 dashboards 数量；topic_count == selected_dashboard_count 必须由真正不同业务含义证明，不是源数组顺序。
83. 页面审查时保留 presentation_snapshot.relations 中的 prototype hierarchy：source dashboard items 是其 child report items 的 parents，type 为 contains；report items 是它们实际引用的 metadata items 的 parents，type 为 uses，如 events、event properties、user properties、metric assets。
84. Topic items 可列出相同稳定 client_item_ids，但页面必须能从 relations 渲染 看板 -> 报表 -> 元数据。
85. flat relations: [] packet 仅在选中资产确实没有已知父子证据时有效。
86. 完整 evidence_hash 包含收集时间，可能在预览间无业务变化却改变；用 target_revision 做保存定义版本检查，并单独比较材料事实。
87. 不要用完整 snapshot hashes 触发跨扫描重新提交。
88. Create 存储提交快照而不恢复省略字段；详细验证引用和重要事实与最终派发材料。
89. 如果 retired split recommendation command 或 capability 被意外探测并返回错误，视为路由纠正。
90. 不要使用 split recommendation commands 或 capabilities 的数据作为推荐答案的业务来源；通过 analysis-meta governance-recommendation export 重跑当前工作流。
91. 审查页草拟、材料检查或本地演练时，读取 references/agent_review_preflight.md 和 references/agent_review_priorities_comparisons.md。
92. 在 item 解释后生成 evidence-backed review priorities，并比较相关定义跨 authoring chunks/topics；在 item AI summaries 中存储 recommendation、classified comparisons 和 comparison_review。
93. 审查优先级不是认证决定，相似性不是冲突。
94. 使用独立 fresh-context reviewer 比较所有证据（包括 signals）与保存来源，并审查 item-specific meaning、priorities 和 paired definitions。
95. 作者最多为整个 packet 修正具体发现 3 次，并进行独立 re-review。
96. 如果质量仍失败，已授权提交继续并附明确 unresolved-quality warnings；绝不声称 PASS 或重置修正预算。
97. 披露不可用审查或不完整覆盖。
98. Local-only intent 始终禁止提交。
99. 质量评估属于 Agent，不属于 Common；结构验证、授权和传输错误仍强制执行。
100. 命令形式使用 ae-cli analysis <resource> <action> [options]、ae-cli analysis-meta <resource> <action> [options]、ae-cli analysis-governance <resource> <action> [options]、ae-cli tracking <resource> <action> [options]、ae-cli capability search|inspect|validate|dry-run|run [options]。
101. Gateway commands 使用 kebab-case flags 如 --project-id；CLI 发送 snake_case JSON。
102. JSON values 必须是 JSON string literals。
103. Global flags 包括 --host、--format json|table、--jq、--validate、--dry-run、--yes；仅用 --validate 解决具体复杂输入问题；用 --dry-run 对高风险写入或明确请求预览；这些模式互斥。
104. 直接执行完全指定的 read 或普通 write；不要例行堆叠 inspect、validate、dry-run、run。
105. 当具体 schema mismatch 需要时，inspect 选中的 model contract 一次，并在未更改的对话范围内复用该 inspected contract；这是本地证据复用，不是声称 CLI 缓存 contracts。
106. JSON 是默认机器可读输出；失败时保留结构化错误和非零 exit。
107. 绝不发明命令名、flags、payload fields、projects、resource IDs、asset names、canonical event/property identifiers、metric formulas 或 dates；用户提供的业务措辞是有效未解析编译器输入，不是已知 canonical binding。
108. 中文时间表达按固定语义映射：最近7天/近7天 -> mode=recent -> QP recentDay=0-7，含今天；过去7天/前7天 -> mode=previous -> QP recentDay=1-7，不含今天；用户明确说明是否包含今天时，以该说明为准；完整映射见 references/ai_models.md。
109. CAPABILITY_NOT_FOUND 意味着当前 host 未暴露该 gateway capability；改参数不会修复；权限错误停止任何依赖链；inspect async run 时 404 是 route/deployment failure；不要永远轮询同一 ID。
110. 按状态解释 gateway envelopes：ok: true 且空数据是成功，表示无匹配数据；绝不要把空 report/dashboard 结果重标为查询失败。
111. ok: true 且 meta.partial: true 是部分成功；使用成功数据并明确报告 meta.failures；不要整批失败或隐藏失败项。
112. ok: false 是失败；保留 error.code、error.message、meta.request_id、meta.invocation_id、meta.stage、meta.failures（如存在）。
113. OUTPUT_PROJECTION_FAILED 是命令完成后本地输出失败：stdout 保留原始业务 payload 在 data 和原始 meta，exit status 仍非零；从返回 envelope 修复 projection，不重新提交远程命令。
114. 不要重试未变更的失败命令或猜测替代 payload 形状；仅在应用具体 validation/clarification guidance 或纠正验证的瞬态条件后重试。
115. 进程 exit code 为 0 不是业务成功，当 envelope 说 ok: false；优先直接 CLI 调用；如果必须 shell pipeline，用 set -o pipefail 保留 CLI exit status 并保留完整错误 envelope，不截断。
116. TE_TOOL_POLICY_DENIED 标识 runtime authorization stage；报告确切原因；它不证明后端 schema 检查通过或用户需要重新登录；不要绕过 policy 或通过改变业务范围重试。
117. INVALID_ANALYSIS_DEFINITION / INVALID_CAPABILITY_INPUT 标识输入失败；在允许重试预算内一起纠正所有相关字段；仅在相同 host 上相同完整定义显式成功验证响应后说 validation passed。
118. QUERY_FAILED 确立查询失败，不确立数据库或引擎根因；保留返回错误和 correlation IDs，保持不可用值未知（不是零），当用户要求不重试时停止；区分观察到错误与未验证假设。
119. 对每个暴露 --request-id 的 gateway 命令，ae-cli 在 caller 省略时生成 request_id 并在 dispatch 前打印到 stderr；保留该 ID 与最终 envelope 和 diagnostics；仅当需要 caller-owned correlation ID 时传显式 --request-id cli_<32 lowercase hex>。
120. 第一页恰好探测一次；开始分页循环前验证 ok、文档化 data shape 和有效 limit。
121. 对分页目录结果，仅当 has_more true 时用返回的 next_offset 继续；绝不计算推测 offset、重复当前页或声明列表完整，直到 has_more false。
122. 跟踪每个 invocation 的 normalized command、input 和 announced request_id；绝不在仍在进行时重新提交相同 invocation；等待当前进程，或当异步时检查返回 run_id。
123. 当 host、identity、project、definition、effective scope、completeness 匹配时，复用已完成数据、已验证 metadata、选中资产和已下载文件；仅查询识别的缺失依赖；批量兼容 metrics，不添加无关分析。
124. 仅重试 meta.failures 中命名的项，且仅当其 retryable 值和 next_action 允许；绝不重试同批次成功或空项。
125. 中文产品术语 看板 指 analysis board backed by saved reports；路由到 ae-cli analysis dashboard ... 和 capability IDs under analysis.dashboard.*。
126. 中文产品术语 仪表盘 和 BI 仪表盘 指 BI dashboard with worksheets、charts、pages；路由到 ae-cli analysis bi-panel ... 和 capability IDs under analysis.bi_panel.*。
127. 这些资产不是别名；绝不用 analysis board 替代 BI dashboard，或反之。
128. 单独英文词 dashboard 在此产品中歧义；写前询问用户是 analysis board（看板）还是 BI dashboard（仪表盘），除非上下文已明确产品资产。
129. 如果请求的 BI-panel capability 不可用或未授权，报告该约束；不要回退创建 analysis board。
130. 使用 Agent host 提供的当前 turn 的 project ID；未提供时用 project info list 解析用户 ID 或名称；仅当返回候选留下真实歧义时询问；新用户选择替换后续命令的先前项目。
131. 不要调用 project-semantic catalog、entry、candidate、release、publish 命令作为普通分析或资产治理请求的先决上下文；已退役 governed-project-semantic lifecycle 不是此 CLI Agent 流的一部分。
132. 当用户明确要求构建、更新、刷新、重建或同步项目语义知识库时，打开 references/project_semantic_knowledge_wiki.md；该命令参考工作流从 ae-cli project-semantic asset-package export 开始，然后上传/编译 KB sources；不要为此工作流加载 standalone project semantic Skill。
133. 当请求涉及个人业务措辞、资产偏好或明确个性化时，调用 ae-cli personal-semantic-preference list --project-id <project_id> 一次每 host、authenticated user、project、conversation；在该范围复用结果；使用 Agent host 提供的当前项目。
134. 如果采纳个人语义条目，读取 references/personal_semantic_preference_list.md 并用 --mark-used 获取该条目；记录持久用户偏好前读同一参考；一次性分析确认是任务上下文。
135. 个人语义偏好规则不适用于通过 analysis-meta governance-recommendation export|submit|decisions 的 CLI Agent 资产认证和指标推荐审查；该工作流不得加载 personal semantic preferences 作为先决上下文。
136. 直接复用已知定义和 canonical metadata；对未知业务度量，遵循 references/metadata_resolution.md：搜索相关 saved metrics/reports，读定义，仅发现缺失 events 或 properties；allowed_resource_types 对 compiler error 权威；确认选中业务映射一次，即使只有一个合适候选；复用任务已确认映射。
137. 如果精确资产或定义来自 knowledge-base page，先读取并遵循 ../ae-kb/references/analysis-workflow.md；尝试匹配资产再用下方普通回退；如果无法产生可用结果，保留证据，然后遵循工作流明确回退和披露规则。
138. 使用合适 saved report 并支持请求的 overrides；对自定义组合，在 ad-hoc model 中复用适用定义；读 references/analysis_gateway_assets.md 获取 saved filters、dashboard context 和 asset selection；构造 ad-hoc 定义时加载模型参考。
139. 最终查询前解析请求的 metrics、filters、groups、comparison windows、timezone、cohort eligibility；将用户纠正带入实际定义，包括每个依赖查询；在推理中注意到旧日期或指标不匹配不会纠正提交输入；按 metadata workflow 带入实际确认回复到这些选择。
140. 当 caller 提供现有 definition snapshot 时，使用选中命令的可选 --intent-snapshot contract 检查本地 JSON 一致性。
141. 指标值、趋势、比较或异常，根据上述决策选择 saved report/dashboard 或 ad-hoc。
142. 指标定义搜索/创建/更新使用 metadata commands。
143. 事件/实体行使用 event-detail run|export 或 entity-detail run|export。
144. 来自查询结果的事件/实体，传原始 --project-id，遵循返回的同步 query_context_id 和 compact source action summary，然后调用 analysis query-context get 获取完整坐标选项；绝不要重建原始 QP 或使用导出行作为坐标。
145. 集群/标签定义使用匹配 gateway cluster/tag commands 和匹配模型参考。
146. 标签/集群候选值，包括措辞为 latest version 或 latest result 的请求，解析确切资产，然后用 analysis filter-value list 并设置 cluster_date_policy=LATEST；这意味着最新计算数据快照，绝非定义或配置发布；不要发明 version lists、version IDs、draft states 或 publish states。
147. 告警/配置/追踪计划请求，从索引读取专用 gateway 命令参考。
148. 对有限内联结果用 run，对完整或超限结果用 export --output <file>；导出或恢复中断导出时读 references/analysis_data_export.md。
149. 当请求需要返回查询上下文通告的后续操作时，读 references/analysis_drilldown_contract.md。
150. 仅在明确用户意图下写；需要时用 --validate 纠正具体复杂输入问题；对高风险写入或明确请求预览用 --dry-run；不要堆叠这些模式；执行 read 和普通 write 命令不用 --yes；对 high-risk-write，先 dry-run，总结目标和影响，等待明确用户确认，然后才用 --yes 执行未变命令。
151. Project-space 和 folder create/delete/share 是 L3 capabilities 而非 curated analysis commands；读匹配命令参考，然后用 ae-cli capability inspect|dry-run|run；通过 capability search|inspect|run 和 references/analysis_gateway_assets.md 发现 *.members；对 risk=high-risk-write，先 dry-run，总结影响，仅在稍后明确确认后用 --yes 执行。
152. 成功 create/update 后，如果 resource ID 和受支持 resource type 可用，调用 analysis-meta asset url-get 并返回链接；明确声明何时因无 resource ID 跳过链接生成或失败。
153. 返回请求结果及其 metric、window、dimension/filter scope 和 units。
154. 复用已返回或计算的值；仅在请求需要时计算额外值。
155. 对 saved dashboard 答案，使用非空 location.folder_name、dashboard_name、remark、notes[].note_title/description 建立业务范围；将文件夹名和注释标记为 authored context，与观察到的查询证据分开。
156. 声明任何返回的 partial-data、permission 或 capability limitation 影响请求。
157. CLI Agent 资产认证和指标推荐审查的最终答案必须使用 references/governance_recommendation_export.md 固定审批显示。
158. 顶层分组是 业务主题域；不要使用分开的顶层章节如 资产认证建议 和 推荐指标。
159. 保持 source dashboard 为核心证据包；从 dashboard semantics 及其 child report names、event/property/metric semantics、shared business process 派生 业务主题域；不要使用 raw source titles、test labels、priority labels、asset-type tags 或 backend topic_seed strings 作为最终组名，当它们只是工作流标签。
160. work_units 是证据容器，不是展示组；单个 dashboard/work unit 可拆成多个业务域，当其 child reports 覆盖不同业务流程；一个业务域可合并多个 dashboards/work units 的证据，当业务含义匹配。
161. 保持每个 report-centered evidence chain 一起：report row、metadata rows 和由该 report 引入的 metric candidates 跟随同一 业务主题域；不要将 report metadata 分离到单独通用 metadata group，也不要仅因共享一个 source dashboard 就合并无关 child-report 域。
162. 当一个 source dashboard 包含不同业务问题的 child reports，为每个 child-report 业务问题创建一个 业务主题域；不要仅因共享同一 dashboard 就将不同 report 域合并成宽泛的 A 与 B 运营、综合运营 或 核心语义 组；dashboard 可作为共享链接源证据出现在每个相关域。
163. source dashboards 和 reports 是证据容器和可能资产行，不是独立顶层业务域；不要创建通用组如 看板上下文、综合验收看板上下文、推荐上下文 或 待审批资产 仅为了放置 source dashboards；将每个 source dashboard 附到其 child reports、events、properties、metrics、definitions 暗示的业务域；如果一个 dashboard 支持多个域，在每个相关域作为链接源证据重用，不用 dashboard 标题作为域。
164. 每个 业务主题域 必须包含 asset-authentication rows 和 metric-candidate rows 在同一审查表。
165. 在域详情表，类型 列是对象类（资产 或 指标）；将审查标签如 [已认证]、[未认证]、[认证资产候选]、[推荐指标候选] 放在 状态 或 审批关注点 列，不作为 类型 值。
166. 默认推荐 export 包含 completed/authenticated context；在每个 业务主题域 内，将返回的 [已认证] 和 [未认证] asset rows 一起放在同一审查表，当两者都存在；如果只出现一种状态，说明这反映当前返回证据范围，不是 Agent 侧 pending-only 过滤或全项目认证覆盖证明。
167. 在主审查表，当 markdown_link 或 raw_url 可用时，将 asset names 显示为可点击 Markdown links；不要将 raw asset IDs 作为主要对象文本；保留 item identities 和 hashes 在上下文中用于 submit 或 debug。
168. 在 来源证据 列，首先使用每个 asset row 的 source_evidence[].markdown_link/raw_url；对 metric rows，使用 source_report.markdown_link/raw_url；仅当行没有直接 source_evidence 时回退到 work unit 的 source_dashboard 或 source_reports links；当 JSON 提供 links 时不要剥离；不要用无链接通用文本如 相关报表、热门看板、来源看板、同名看板、同名报表、<业务>相关报表 或裸 report names 替换链接源；如果 asset row 本身是 source dashboard 或 source report，重用该 row 自己的 link 作为来源证据；如果多个链接源支持一行，显示最直接源链接或紧凑逗号分隔列表。
169. 显示可用决策信号来自数据，尤其 heat、user count、impact degree；不要发明缺失值。
170. 仅使用纯文本审查标签： [已认证]、[未认证]、[已有指标资产]、[推荐指标候选]、[认证资产候选]、[风险/冲突]；不要用 HTML、font tags、color names 或依赖颜色的措辞在 Agent 答案中。
171. 当 conflict_risks、previous_decision、action_state、actionable、authentication_status 表明语义冲突、身份冲突、先前拒绝/跳过、不可操作状态或 approval blocker 时，风险/冲突文本必需。
172. 不要将 raw JSON 作为最终答案。

适用边界 · 注意事项

• 没有 ae-cli 或没有 AE 分析、元数据、治理、tracking 等网关访问权限时不适用。
• 非 AE 分析侧任务，例如 Engage、DataOps、Community，或生成索引之外的 metadata gateway detail 时，应改用对应 skill。
• 需要绕过 curated 命令、直接 MCP 执行或违反授权/权限策略时不适用。