ae-project-semantic

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ae-project-semantic

Project semantics are governed L2 project-wide business concepts, rules, calculation conventions, and default asset-selection methods. They sit above dashboards and reports. Dashboards, reports, events, properties, and metrics are L1 evidence and execution assets; they are not project semantics by themselves.

Use

ae-cli

only. Do not write the database directly for recommendations, approvals, or releases.

项目语义是受管控的L2级全项目业务概念、规则、计算约定以及默认资产选择方法，位于仪表板和报表之上。仪表板、报表、事件、属性和指标属于L1级证据与执行资产，它们本身并非项目语义。

仅使用

ae-cli

操作。请勿直接写入数据库来进行推荐、审批或发布操作。

Boundary

边界

Use this skill to generate or evaluate project semantic recommendations.
Use
```
ae-analysis
```
to consume already published project semantics during analysis tasks.
Frontend can review, edit, approve, reject, and publish candidates; it must not generate recommendations.
Start with governed authenticated dashboards/reports. Broader project assets may be inspected only after explicit user consent and must retain their lower authority in evidence and confidence. Events, properties, metrics, background documents, and notes can provide supporting evidence only, never the primary L2 candidate subject.

使用本技能生成或评估项目语义推荐。
在分析任务中使用
```
ae-analysis
```
来调用已发布的项目语义。
前端可对候选语义进行审核、编辑、批准、拒绝和发布，但不得生成推荐。
从受管控的已认证仪表板/报表开始。只有在获得用户明确授权后，才可检查更广泛的项目资产，且这些资产在证据和可信度方面需保持较低的权威性。事件、属性、指标、背景文档和注释仅可提供支持性证据，绝不能作为主要的L2级候选对象。

Required Workflow

必备工作流程

Resolve the project and host.
Read both recommendation references before inspecting candidates:
- ```
references/recommendation-quality.md
```
  for the governed L2 quality bar;
- ```
references/query-routing-v5.md
```
  for the current query-routing, recall-shortcut, and analysis-playbook discovery protocol.
Check existing published project semantics:

bash

ae-cli project-semantic list --project-id <project_id>

Export governed authenticated project assets and semantic snapshot context by default:

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope governed --output <tmp>/project-semantic-assets --force

When

--host

points directly to a locally started Common service instead of the deployed analysis gateway, scope the empty gateway domain to that command so the request uses Common's native

/api/cli/v1

route. Do not export this override globally:

bash

AE_CLI_CAPABILITY_GATEWAY_DOMAIN= ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope governed --output <tmp>/project-semantic-assets --force --host http://127.0.0.1:8992

Inspect
```
asset_scope
```
,
```
exported_asset_count
```
,
```
authenticated_asset_count
```
,
```
unauthenticated_asset_count
```
,
```
truncated
```
, work-unit count, and definition-family count before scanning. If
```
truncated=true
```
, warn that the package hit a compatibility limit. If the governed package is too sparse to support useful problem frames, report the actual counts and ask whether to re-export active collaborative assets. Do not broaden automatically:

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope collaborative --output <tmp>/project-semantic-assets --force

If that package is still too sparse, report its counts and ask separately whether to export all valid project dashboards/reports and their referenced metadata:

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope all_visible --output <tmp>/project-semantic-assets --force

governed

is authenticated + collaborative + active in the recent 90-day window.

collaborative

removes only the authentication requirement.

all_visible

removes authentication, collaboration, and recency filters while still excluding deleted, frozen, hidden, offline, or otherwise invalid assets. Export is project-administrator-only; no per-user visibility filtering is required inside

all_visible

. Asset authentication is a separate governance write and must never be changed implicitly by scanning.

Read the package in this order:
- ```
manifest.json
```
  ,
```
.asset-package.json
```
  ,
```
catalog/published.jsonl
```
  ,
```
catalog/disabled.jsonl
```
  when present,
```
catalog/active-candidates.jsonl
```
  , and
```
catalog/rejected-candidates.jsonl
```
  to build the exclusion and revision context;
- ```
indexes/work-units.jsonl
```
  as the dashboard-first investigation queue, preserving its usage-priority order while rotating across distinct business themes;
- ```
indexes/definition-families.jsonl
```
  and compact dashboard/report records to compare reusable definition variants;
- ```
indexes/asset-directory.jsonl
```
  and
```
indexes/governance-coverage.jsonl
```
  for supporting evidence;
- ```
details/normalized/**
```
  only for candidate-bearing or conflicting families, and
```
details/raw/**
```
  only when the normalized definition is insufficient.
The service owns deterministic parsing, key-field normalization, definition signatures, usage ordering, and catalog assembly. The Agent owns business topic discovery, evidence interpretation, counterexample review, and candidate wording. Display names, descriptions, and notes remain evidence for interpretation, but they never make two otherwise identical definitions distinct. Do not load every detail file into context up front or delegate business judgment to a project-specific keyword table or deterministic template generator.
Compare the proposed behavior against published, disabled, active-candidate, and rejected catalogs. Disabled semantics are suppression context: do not consume, recreate, or update them through recommendation generation. A project administrator can explicitly enable them later. Produce
```
CREATE
```
only for a genuinely new semantic,
```
UPDATE
```
when an active semantic needs a material revision, and no candidate when the package is already covered. Zero new candidates is a valid successful recommendation result.
Validate the Agent-authored file against the exact exported package. This command checks only deterministic contract rules such as required fields, supported enums, catalog conflicts, duplicate fingerprints, and resolvable evidence references.
```
passed=true
```
is not a semantic-quality approval:

bash

ae-cli project-semantic candidate validate --asset-package <tmp>/project-semantic-assets --submit-file <tmp>/project-semantic-candidates.json

Perform a separate Agent quality-review pass over the unchanged candidate file and the evidence it cites. Apply the Hard Quality Bar and
```
references/recommendation-quality.md
```
; do not rely on the generation pass to approve its own wording. For every candidate, record
```
PASS
```
,
```
REVISE
```
, or
```
INSUFFICIENT_EVIDENCE
```
with concrete findings and evidence references. Revise and repeat both deterministic validation and Agent review until every submitted candidate is
```
PASS
```
. A successful empty recommendation is preferable to weak filler.
Submit the unchanged validated and Agent-reviewed file. Use
```
.asset-package.json.snapshot_hash
```
, or the
```
snapshot_hash
```
returned by
```
candidate validate
```
:

bash

ae-cli project-semantic candidate submit --project-id <project_id> --submit-file <tmp>/project-semantic-candidates.json --snapshot-hash <snapshot_hash>

Review and enable through CLI when validating the full closed loop:

bash

ae-cli project-semantic candidate list --project-id <project_id>
ae-cli project-semantic candidate get --project-id <project_id> --candidate-id <candidate_id>
ae-cli project-semantic candidate enable --project-id <project_id> --candidate-ids '["candidate_1"]'
ae-cli project-semantic get --project-id <project_id> --id <semantic_id> --mark-used

Lifecycle management is deliberately separate from recommendation review:

bash

ae-cli project-semantic disable --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>
ae-cli project-semantic list --project-id <project_id> --status disabled
ae-cli project-semantic delete-impact --project-id <project_id> --semantic-id <semantic_id>
ae-cli project-semantic delete --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>
ae-cli project-semantic enable --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>

Disable means “do not consume and do not recommend again.” From disabled state, either enable the same semantic or inspect impact and physically delete it. Physical deletion means the semantic is absent and may be rediscovered by a future scan. Never delete merely to regenerate recommendations.

解析项目和主机信息。
在检查候选语义前，先阅读两份推荐参考文档：
- ```
references/recommendation-quality.md
```
  ：受管控的L2级质量标准；
- ```
references/query-routing-v5.md
```
  ：当前的查询路由、召回快捷方式以及分析手册发现协议。
检查已发布的项目语义：

bash

ae-cli project-semantic list --project-id <project_id>

默认导出受管控的已认证项目资产和语义快照上下文：

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope governed --output <tmp>/project-semantic-assets --force

当

--host

指向本地启动的Common服务而非部署的分析网关时，需将空网关域作用于该命令，以便请求使用Common原生的

/api/cli/v1

路由。请勿全局导出此覆盖配置：

bash

AE_CLI_CAPABILITY_GATEWAY_DOMAIN= ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope governed --output <tmp>/project-semantic-assets --force --host http://127.0.0.1:8992

在扫描前检查
```
asset_scope
```
、
```
exported_asset_count
```
、
```
authenticated_asset_count
```
、
```
unauthenticated_asset_count
```
、
```
truncated
```
、工作单元数以及定义族数量。若
```
truncated=true
```
，需警告该资产包已达到兼容性限制。若受管控资产包过于稀疏，无法支撑有效的问题框架，则报告实际数量并询问是否重新导出活跃的协作资产。请勿自动扩大范围：

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope collaborative --output <tmp>/project-semantic-assets --force

若该资产包仍过于稀疏，则报告其数量并单独询问是否导出所有有效的项目仪表板/报表及其关联元数据：

bash

ae-cli project-semantic asset-package export --project-id <project_id> --asset-scope all_visible --output <tmp>/project-semantic-assets --force

governed

指最近90天内已认证且协作活跃的资产。

collaborative

仅移除认证要求。

all_visible

移除认证、协作和时效性筛选，但仍排除已删除、冻结、隐藏、离线或其他无效资产。导出操作仅限项目管理员执行；

all_visible

范围内无需进行按用户可见性的筛选。资产认证是独立的管控写入操作，绝不能通过扫描隐式修改。

按以下顺序读取资产包：
- 读取
```
manifest.json
```
  、
```
.asset-package.json
```
  、
```
catalog/published.jsonl
```
  （若存在则读取
```
catalog/disabled.jsonl
```
  ）、
```
catalog/active-candidates.jsonl
```
  和
```
catalog/rejected-candidates.jsonl
```
  ，以构建排除和修订上下文；
- 将
```
indexes/work-units.jsonl
```
  作为以仪表板优先的调查队列，在保留其使用优先级顺序的同时，跨不同业务主题轮换处理；
- 读取
```
indexes/definition-families.jsonl
```
  和压缩的仪表板/报表记录，以比较可复用的定义变体；
- 读取
```
indexes/asset-directory.jsonl
```
  和
```
indexes/governance-coverage.jsonl
```
  作为支持性证据；
- 仅针对包含候选语义或存在冲突的族读取
```
details/normalized/**
```
  ，仅当标准化定义不足时读取
```
details/raw/**
```
  。

服务负责确定性解析、关键字段标准化、定义签名、使用排序和目录组装。Agent负责业务主题发现、证据解读、反例审核和候选语义措辞。显示名称、描述和注释作为解读的证据，但不会使其他方面完全相同的定义产生差异。请勿预先加载所有详细文件到上下文，也不要将业务判断委托给项目特定的关键词表或确定性模板生成器。

将拟议行为与已发布、已禁用、活跃候选和已拒绝的目录进行比较。已禁用的语义是抑制上下文：在生成推荐时，请勿使用、重新创建或更新它们。项目管理员可在之后显式启用它们。仅为真正全新的语义生成
```
CREATE
```
操作；当活跃语义需要实质性修订时生成
```
UPDATE
```
操作；若资产包已覆盖相关内容，则不生成候选语义。零新候选语义是有效的推荐结果。
根据导出的资产包精确验证Agent编写的文件。此命令仅检查确定性合约规则，如必填字段、支持的枚举、目录冲突、重复指纹以及可解析的证据引用。
```
passed=true
```
并不代表语义质量获得批准：

bash

ae-cli project-semantic candidate validate --asset-package <tmp>/project-semantic-assets --submit-file <tmp>/project-semantic-candidates.json

对未修改的候选文件及其引用的证据进行独立的Agent质量审核。应用严格质量标准和
```
references/recommendation-quality.md
```
；不要依赖生成环节来批准其自身措辞。对每个候选语义记录
```
PASS
```
、
```
REVISE
```
或
```
INSUFFICIENT_EVIDENCE
```
，并附上具体结论和证据引用。修订并重复确定性验证和Agent审核，直到所有提交的候选语义均为
```
PASS
```
。成功的空推荐优于薄弱的填充内容。
提交经过验证和Agent审核且未修改的文件。使用
```
.asset-package.json.snapshot_hash
```
，或
```
candidate validate
```
返回的
```
snapshot_hash
```
：

bash

ae-cli project-semantic candidate submit --project-id <project_id> --submit-file <tmp>/project-semantic-candidates.json --snapshot-hash <snapshot_hash>

在验证完整闭环时，通过CLI进行审核和启用：

bash

ae-cli project-semantic candidate list --project-id <project_id>
ae-cli project-semantic candidate get --project-id <project_id> --candidate-id <candidate_id>
ae-cli project-semantic candidate enable --project-id <project_id> --candidate-ids '["candidate_1"]'
ae-cli project-semantic get --project-id <project_id> --id <semantic_id> --mark-used

生命周期管理与推荐审核故意分离：

bash

ae-cli project-semantic disable --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>
ae-cli project-semantic list --project-id <project_id> --status disabled
ae-cli project-semantic delete-impact --project-id <project_id> --semantic-id <semantic_id>
ae-cli project-semantic delete --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>
ae-cli project-semantic enable --project-id <project_id> --semantic-id <semantic_id> --expected-version <version> --reason <reason>

禁用意味着“不使用且不再推荐”。从禁用状态，可启用相同语义或检查影响后进行物理删除。物理删除表示该语义已不存在，未来扫描可能会重新发现。请勿仅为重新生成推荐而删除语义。

Hard Quality Bar

严格质量标准

A candidate file is not acceptable unless all of these are true:

It starts from governed evidence, or records the explicitly approved broader scope and lowers confidence for claims that depend on unauthenticated assets.
It groups by L2 business topic domain before generating candidates.

Every topic group includes the submit-contract fields

topic_domain_key

topic_domain_title

topic_group_key

, and

topic_group_title

It does not create one candidate per asset.
It does not promote an event/property/metric name into a project semantic title.
Each candidate binds
```
resource_refs
```
with real asset names/types/ids or names from the package.
Each candidate explains what it means, where it applies, how to use it, and what it excludes.
Each candidate body covers business definition, applicable questions, decision or calculation rules, Agent usage, and boundaries or exceptions in the project's natural language. Exact headings are not a machine contract.
The concrete business judgment belongs in the decision or calculation content; asset names and counts belong in
```
resource_refs
```
,
```
evidence
```
, and
```
recommendation_reason
```
, not in the semantic body.
A batch fails review when candidates reuse the same body with only asset names or counts changed.
Each candidate includes evidence excerpts or source titles that show why it was recommended.
Each candidate changes how the Agent interprets a business question, selects default assets, or applies a project-wide rule.
Each candidate declares one of the evidence-backed recommendation kinds in
```
query-routing-v5.md
```
:
```
QUERY_ROUTING
```
,
```
RECALL_SHORTCUT
```
, or
```
ANALYSIS_PLAYBOOK
```
.
A formula, threshold, state, event, property, report, or asset name is supporting L1 evidence, never a standalone candidate.
A route must contain a meaningful asset-choice branch; a shortcut must contain a minimal bundle plus stop and fallback; a playbook must be note-backed or explicitly labeled as a structure-inferred recommended path.
Existing published and disabled semantics are checked before submission; disabled semantics suppress recreation.
An unauthenticated asset may support a route, shortcut, or playbook only when definitions, work-unit structure, usage, or notes provide corroboration. Never present it as a certified project rule solely because it was exported.
Sparse evidence is either skipped or marked lower confidence; do not inflate weak recommendations.

候选文件必须满足以下所有条件才被接受：

基于受管控证据生成，或记录明确批准的扩大范围，并降低依赖未认证资产的声明的可信度。
在生成候选语义前，按L2级业务主题域进行分组。

每个主题组包含提交合约字段

topic_domain_key

、

topic_domain_title

、

topic_group_key

和

topic_group_title

。

不为每个资产创建一个候选语义。
不将事件/属性/指标名称提升为项目语义标题。
每个候选语义绑定
```
resource_refs
```
，其中包含真实资产名称/类型/ID或资产包中的名称。
每个候选语义解释其含义、适用场景、使用方法以及排除范围。
每个候选语义正文以项目的自然语言涵盖业务定义、适用问题、决策或计算规则、Agent使用方式以及边界或例外情况。确切标题并非机器合约要求。
具体业务判断应放在决策或计算内容中；资产名称和数量应放在
```
resource_refs
```
、
```
evidence
```
和
```
recommendation_reason
```
中，而非语义正文。
若候选语义仅更改资产名称或数量就复用相同正文，则整批候选无法通过审核。
每个候选语义包含证据摘录或来源标题，说明推荐理由。
每个候选语义会改变Agent对业务问题的解读、默认资产选择或全项目规则的应用方式。
每个候选语义声明
```
query-routing-v5.md
```
中基于证据的推荐类型之一：
```
QUERY_ROUTING
```
、
```
RECALL_SHORTCUT
```
或
```
ANALYSIS_PLAYBOOK
```
。
公式、阈值、状态、事件、属性、报表或资产名称是支持性L1级证据，绝不能作为独立候选语义。
路由必须包含有意义的资产选择分支；快捷方式必须包含最小包以及停止和回退机制；手册必须有注释支持或明确标记为基于结构推断的推荐路径。
提交前需检查已发布和已禁用的语义；已禁用语义会阻止重新创建。
未认证资产仅在定义、工作单元结构、使用情况或注释提供佐证时，才可支持路由、快捷方式或手册。绝不能仅因已导出就将其作为认证项目规则呈现。
稀疏证据要么跳过，要么标记为低可信度；不得夸大薄弱的推荐。

Generic Extraction Protocol

通用提取协议

The protocol must work unchanged for games, retail, finance, SaaS, operations, and unknown project domains.

Inventory evidence without deciding themes. Separate authenticated and unauthenticated dashboards/reports, record the export scope and selection reason, and keep existing governed semantics and supporting L1 metadata distinct.
Discover semantic families only from evidence that was actually read. Use these cross-domain dimensions as questions, not as prefilled answers:
- business object, state, and alias;
- analysis subject and deduplication grain;
- measure, aggregation, numerator, denominator, and transformation;
- inclusion, exclusion, and filter scope;
- query range, cohort window, observation window, and freshness;
- unit, currency, normalization, and attribution;
- default asset selection and relationships between assets;
- applicability, exception, and conflict boundaries.
Compare definition variants inside each family. A candidate may state a default only when evidence shows one authoritative variant. Conflicting variants require a disambiguation rule or a warning, not an invented standard.
Form a topic domain after the semantic families are understood. The domain title must come from the project's natural business language and explain why its candidates are reviewed together.
Generate a candidate only when removing it would make a future Agent more likely to choose the wrong business object, asset, grain, formula, scope, unit, window, or exception.
For every claim in the body, identify direct supporting evidence. Keep asset names and excerpts in
```
resource_refs
```
,
```
evidence
```
, and
```
recommendation_reason
```
; keep reusable business knowledge in
```
content
```
.
Compare candidates by resulting Agent behavior. Merge candidates that lead to the same interpretation and execution; split candidates that answer independently searchable questions.
Run a counterexample pass: inspect minority definitions and assets that may violate the proposed rule. Narrow or drop unsupported conclusions.
Before wording candidates, form evidence-backed problem frames and assign asset roles. Use
```
query-routing-v5.md
```
; do not optimize for candidate count or one-candidate-per-asset coverage.
Keep a decision ledger for discovered problem frames, including routed, shortcut, playbook, definition-only, and evidence-insufficient dispositions.

该协议必须无需修改即可适用于游戏、零售、金融、SaaS、运营以及未知项目领域。

在未确定主题的情况下盘点证据。区分已认证和未认证的仪表板/报表，记录导出范围和选择理由，并将现有受管控语义与支持性L1级元数据分开。
仅从实际读取的证据中发现语义族。将以下跨领域维度作为问题，而非预先填充的答案：
- 业务对象、状态和别名；
- 分析主体和去重粒度；
- 度量、聚合、分子、分母和转换；
- 包含、排除和筛选范围；
- 查询范围、群组窗口、观察窗口和新鲜度；
- 单位、货币、标准化和归因；
- 默认资产选择以及资产间的关系；
- 适用性、例外和冲突边界。
比较每个语义族内的定义变体。只有当证据显示存在一个权威变体时，候选语义才可声明默认值。冲突变体需要消歧规则或警告，而非凭空创造标准。
在理解语义族后形成主题域。域标题必须来自项目的自然业务语言，并解释为何其候选语义需一起审核。
仅当移除候选语义会导致未来Agent更可能选择错误的业务对象、资产、粒度、公式、范围、单位、窗口或例外时，才生成该候选语义。
为正文中的每个声明确定直接支持证据。将资产名称和摘录放在
```
resource_refs
```
、
```
evidence
```
和
```
recommendation_reason
```
中；将可复用的业务知识放在
```
content
```
中。
根据Agent的行为结果比较候选语义。合并导致相同解读和执行的候选语义；拆分可独立回答可搜索问题的候选语义。
进行反例检查：检查可能违反拟议规则的少数定义和资产。缩小范围或放弃无支持的结论。
在措辞候选语义前，形成基于证据的问题框架并分配资产角色。使用
```
query-routing-v5.md
```
；不要为了候选数量或每个资产一个候选的覆盖范围而优化。
为发现的问题框架保留决策台账，包括路由、快捷方式、手册、仅定义和证据不足的处置情况。

Anti-Overfitting Rule

防过拟合规则

Never encode a customer, project name, project ID, asset ID, expected topic title, expected candidate title, or expected candidate count in this skill or CLI generation code.
Never start from a fixed industry taxonomy or keyword dictionary. Keywords may locate evidence only after a semantic family is discovered; they must not determine the result.
A test package is an evaluation sample, not a source of reusable rules. Tune the protocol only when the change is defensible across unrelated domains.
Quality is measured by evidence support and changed Agent behavior, not by matching a previously approved list of topics.

切勿在本技能或CLI生成代码中编码客户名称、项目名称、项目ID、资产ID、预期主题标题、预期候选标题或预期候选数量。
切勿从固定行业分类或关键词词典开始。关键词仅可在发现语义族后定位证据；不得决定结果。
测试资产包是评估样本，而非可复用规则的来源。仅当变更可在不相关领域中得到辩护时，才可调整协议。
质量由证据支持和Agent行为变化衡量，而非与先前批准的主题列表匹配程度。

User-Facing Recommendation Display

用户侧推荐展示

When showing CLI recommendation results to a user, never flatten candidates into a single numbered list. The user-facing answer must use the same hierarchy as the candidate JSON and frontend review UI:

text

Project semantic recommendation scan completed

Summary:
- Topic domains: <N>
- Candidate semantics: <N>
- Validation: passed | failed

Topic domain: <topic_domain_title> (<candidate_count> semantics)
- [<semantic_type>] <candidate title>
  <one-sentence summary>
  Evidence: <asset title 1>, <asset title 2>, ...

Rules:

Show topic domains first, then candidates under each domain.
Include each domain's semantic count.
Include each candidate's semantic type, title, short summary, and primary evidence asset titles.
If the CLI command returns
```
topic_groups
```
, use that field directly for the display order and counts.
Keep the full JSON path or submit command separate from the human summary.
Do not present a flat list like
```
1. semantic A 2. semantic B ...
```
unless the user explicitly asks for raw candidate order.

向用户展示CLI推荐结果时，切勿将候选语义扁平化为单一编号列表。面向用户的回答必须使用与候选JSON和前端审核UI相同的层级结构：

text

项目语义推荐扫描完成

摘要：
- 主题域：<N>
- 候选语义：<N>
- 验证结果：通过 | 失败

主题域：<topic_domain_title>（<candidate_count>个语义）
- [<semantic_type>] <候选标题>
  <一句话摘要>
  证据：<资产标题1>、<资产标题2>...

规则：

先展示主题域，再展示每个域下的候选语义。
包含每个域的语义数量。
包含每个候选语义的类型、标题、简短摘要和主要证据资产标题。
若CLI命令返回
```
topic_groups
```
，则直接使用该字段确定展示顺序和数量。
将完整JSON路径或提交命令与人工摘要分开。
除非用户明确要求原始候选顺序，否则不要呈现类似
```
1. 语义A 2. 语义B...
```
的扁平列表。

Output Discipline

输出规范

When reporting recommendation results, include:

commands run;
asset scope, exported/authenticated/unauthenticated asset counts, and snapshot hash;
topic domains, semantic counts per domain, and candidate titles grouped under each domain;
evidence assets per candidate;
quality warnings, if any;
problem-frame coverage and rejected shallow-opportunity warnings;
submit/review/release IDs after writes.

报告推荐结果时，需包含：

执行的命令；
资产范围、导出/已认证/未认证资产数量以及快照哈希；
主题域、每个域的语义数量以及按域分组的候选标题；
每个候选语义的证据资产；
质量警告（若有）；
问题框架覆盖情况和浅层机会被拒绝的警告；
写入操作后的提交/审核/发布ID。