@thinkingai/ae-cli 6.0.55 → 6.0.57

package/skills/ae-analysis/SKILL.md

@@ -1,12 +1,16 @@
 ---
 name: ae-analysis
-version: 4.2.31
-description: "Use ae-cli for AE analysis-side data questions, asset operations, and asset governance: reports, analysis boards, BI dashboards, ad-hoc models, drilldown, detail data, alerts, clusters, tags, metrics, metadata discovery, project configuration, tracking plans, local input-file upload, governance asset lists/rules/lineage/impact/dependency, batch asset operations, projects, and resource links. Use when the user asks to query data, explain a change, export evidence, inspect/create/update/govern analysis assets, recommend project assets for certification/authentication, review asset-certification recommendations, review metric recommendations, or build/update/refresh/sync a project semantic knowledge base from a governed asset package."
+version: 4.2.52
+description: "Use ae-cli for AE analysis-side data questions, asset operations, and asset governance: reports, analysis boards, BI dashboards, ad-hoc models, drilldown, detail data, alerts, clusters, tags, metrics, metadata discovery, project configuration, tracking plans, local input-file upload, governance asset lists/rules/lineage/impact/dependency, batch asset operations, projects, and resource links. Use when the user asks to review collected analysis questions or badcases, query data, explain a change, export evidence, inspect/create/update/govern analysis assets, recommend project assets for certification/authentication, review asset-certification recommendations, review metric recommendations, or build/update/refresh/sync a project semantic knowledge base from a governed asset package."
 ---
 
 # ae-analysis
 
-This is the single entry skill for analysis intent and command execution.
+This is the single entry skill for analysis intent and command execution, including review and semantic deduplication of collected analysis questions and evidence-based badcase assessment.
+
+At the beginning of a new analysis question, capture `ae-cli analysis scenario begin` locally and retain its exact `data.start_time` for that answer. Pass it as `--start-time` only when the project permits collection. Do not invent a start time or reuse it for a later revised answer; capture a fresh start for that follow-up. This records one question-to-answer elapsed duration, not separate timing phases. Historical archive review does not start or collect a scenario.
+
+For historical analysis-question inventory or badcase review, route directly to [scenario list and review](references/scenario_list.md), and for quality assessment read [independent scenario evaluation](references/scenario_evaluation.md). This is a separate archive-review task: skip business-query semantic/KB/personal-preference preflight and do not collect the review itself as another analysis scenario. The CLI retrieves evidence; the calling Agent judges and deduplicates it. No server-side rating or evaluation writeback is required.
 
 ## Capability contract
 
@@ -39,20 +43,27 @@ For data queries:
 3. Correct compiler errors at their reported paths. New evidence or a user correction changes a completed choice; preserve the other verified inputs.
 4. Use the returned result directly. Save original JSON only when the user requests a file or necessary local processing requires one; follow [result handling](references/analysis_data_retrieval.md#preserve-and-interpret-results). Keep stderr and the CLI exit status visible.
 5. Compute only missing values needed by the request, together in one local call. Reuse completed results and answer when the requested data is available, or explain the specific error or missing input.
-6. Only after a completed analysis data query and the final business analysis answer, ask once in the user's language whether the analysis met expectations: satisfied, partially satisfied, dissatisfied, or unable to judge. Do not ask after individual CLI calls, intermediate steps, discovery, metadata inspection, asset governance/writes, configuration, help, unrelated questions, query submission, running exports or failed queries. No explicit feedback means no submission or new feedback event. On a clear evaluation of the completed analysis, use [analysis query feedback](references/feedback_submit.md); preserve the evaluated session and turn IDs, the user's original feedback and a short verifiable route summary. Do not upload the analysis answer or infer a rating from silence, a follow-up question or a new requirement. Feedback collection must not block subsequent business work.
+6. Scenario collection is project opt-in. Before preparing or uploading a scenario sample, read `ae-cli project info get --project-id <source_project_id>` for the current host, authenticated account, and source analysis project. Only `data.analysis_scenario_collection_enabled === true` permits collection. Recheck for each new scenario and before appending feedback or a revision; do not reuse a previous grant or the company configuration's 24-hour cache. A missing field (including older services), false, unreadable configuration, or unknown project means skip collection and answer normally. Never enable the project switch, choose a different project, or invent a project ID to make collection succeed. The curated collect/append commands also check immediately before submission, and the service is authoritative if the switch changes. This controls scenario samples and the related Common gateway HDFS call archive; existing invocation and intent event reporting stays unchanged. `accepted=false, skipped=true` is a normal skip, not a failed analysis or successful upload. Do not retry, backfill, or fall back to `analysis feedback submit` to bypass this switch.
+
+   Collect one sample for the whole user scenario, not one per CLI call. After forming the final answer, use `ae-cli analysis scenario collect` as specified in [scenario collection](references/scenario_collect.md), then deliver that exact answer text. Capture the original question/confirmed clarifications, actual final answer and the ordered query path (existing capability/call IDs and optional short purpose; prefer only meta.invocation_id, never confuse a business request_id with gateway client_request_id), never query result rows or error payloads; do not score correctness or generate a separate self-evaluation. The question_id is the original scenario's first user turn ID, stable across clarification, retries, multiple queries and corrections. Store/reuse the IDs returned by collection in conversation context. On later user objections, scope corrections or reported omissions targeting that answer, append the user's original text with `ae-cli analysis scenario append --entry-type user_feedback` and the original question_id/target_answer_id; do not decide whether the user is right. An ambiguous request for an explanation may be preserved as user text when clearly linked; do not invent a link. A normal follow-up or changed requirement is not automatically negative feedback. After a substantive follow-up answer to the same scenario (recheck, explanation, correction or scope clarification), append answer_revision with that exact answer/query path and a new answer_id, even when the conclusion stays the same; keep earlier answers. If the triggering user request was not already captured as user_feedback, include its exact text using --user-message on answer_revision so later scope changes are not lost. Do not duplicate feedback text in user_message. Acknowledgments such as thanks alone need no entry. A genuinely separate question gets a new question_id. Do not create another initial sample for an existing scenario. A separate evaluation task reads these samples later and can join existing call telemetry for parameters/status/timing. Path-only evidence cannot prove numeric answer correctness; unresolved correctness stays unknown. Only attempted analysis data queries qualify; metadata, discovery, help and asset writes alone do not. No routine satisfaction question. Collection failure must not block the answer or subsequent business work, trigger login or automatic retries, or be claimed as successful ingestion. For external Agents this is a Skill collection step, not a guaranteed post-answer hook; it has a local clock capture plus the collection tool call, with no additional evaluation task on the answering path.
+
+User feedback is evidence, not a correctness label. Preserve exact user words and their target answer even if you disagree. Do not routinely ask for a satisfaction rating. The existing `analysis feedback submit` contract remains available for explicit standalone user ratings without a collected scenario; when a scenario exists, use its append command instead of submitting duplicate feedback. No explicit feedback means no submission or new feedback event for `cli_analysis_feedback`. Do not upload the analysis answer through that legacy feedback command. All collection excludes credentials, full transcripts and private reasoning.
+
+
 
 ## Route before reading
 
 1. Map the request to a command family before opening any reference.
-   - CLI Agent asset-authentication and metric-recommendation review: this includes requests to recommend project assets for certification/authentication, review asset-certification candidates, review project asset-governance recommendations, review recommended metrics, or explicitly auto-review/auto-certify recommended assets. Open `references/governance_recommendation_export.md` and route to `analysis-meta governance-recommendation export|submit|auto-review|decisions`. For review-page submission, open `references/agent_review_submit_to_page.md` and use `analysis-meta agent-review submit-to-page|list|detail|records|review|retry`. Do not load project semantics, project KB, or personal semantic preferences as a preflight.
+   - CLI Agent asset-authentication and metric-recommendation review: this includes requests to recommend project assets for certification/authentication, review asset-certification candidates, review project asset-governance recommendations, review recommended metrics, or explicitly auto-review/auto-certify recommended assets. Open `references/governance_recommendation_export.md` and route to `analysis-meta governance-recommendation export|submit|auto-review|decisions`. For review-page submission, open `references/agent_review_submit_to_page.md` and use `analysis-meta agent-review submit-to-page|list|detail|records|review|retry`. Apply its Business Topics and Subtopics contract: both levels require business interpretation and independent review; a source dashboard is an evidence container, not a default second-level group. Do not load project semantics, project KB, or personal semantic preferences as a preflight.
    - Project semantic knowledge-base build/update/refresh/sync: open `references/project_semantic_knowledge_wiki.md` and route to `project-semantic asset-package export`, local semantic planning, and local Wiki rendering. Default to CLI semantic precompilation into Markdown sources, source ZIP upload, formal preset initialization/reuse, and KB compilation. Do not regenerate Schema or AI-validate unchanged presets during normal refresh. Update changed source files and use incremental compilation on ordinary refresh; a navigation taxonomy version change requires the full migration rebuild reported by the source-tree packager. Never substitute read-only snapshot import. Stop on company permission denial. This is a command-reference workflow inside `ae-analysis`, not a standalone project semantic Skill.
    - Known family: open only its dedicated reference. For example, a retention request goes directly to `references/adhoc_run.md`, the common `references/ai_models.md`, and `references/ai_models/retention.md`.
    - Unknown family: search [`references/command_index.md`](references/command_index.md) with `rg` or an equivalent text-search tool and keep only the matching rows. `command_index.md` is a search-only fallback; never open it with a whole-file read or print the entire file.
 2. Read the selected command's dedicated reference before composing it:
    - `event list` -> `references/event_list.md`
+   - Project member groups (Project management → Member management → Member groups): use `project member-group list|members|create|rename|delete|add-members|remove-members` and the matching `references/project_member_group_<action>.md` (replace action hyphens with underscores). This manages project member groups, distinct from AgentSpace/system membership and analysis user-cluster/user-tag audiences.
    - Readable saved report/dashboard discovery -> `analysis asset search` and `references/asset_search.md`; this includes shared read-only assets.
    - `analysis dashboard list` -> `references/dashboard_list.md`
-   - Saved event-report chart/result-table layout -> `references/report_get.md` and the matching `report_create.md` or `report_update.md`. A table card on a specific analysis board -> `dashboard-report get/update` and `references/dashboard_report_get.md` / `references/dashboard_report_update.md`; the card display is separate from its source report definition.
+   - Saved event-report chart/result-table layout -> `references/report_get.md` and the matching `report_create.md` or `report_update.md`. A table card, card frame size, or grid position on a specific analysis board -> `dashboard-report get/update` and `references/dashboard_report_get.md` / `references/dashboard_report_update.md`; the card display is separate from its source report definition. Geometry writes need the fresh dashboard layout version; event chart/table settings remain event-only.
    - Event combination chart or per-metric bar/line and primary/secondary axes -> also read `references/event_report_presentation.md`. Series is source-report scoped and can affect its other trend cards; card display updates cannot create a local series override.
    - `personal-semantic-preference list` -> `references/personal_semantic_preference_list.md`
    - Asset center cross-source configuration (资产中心 / 跨源资产配置 / Excel 配置表导入): L3 discovery via `capability search "cross_source_config" --domain metadata --project-id <id>`; read [`references/cross_source_config.md`](references/cross_source_config.md) for workbook upload and validation. No dedicated business commands.
@@ -91,9 +102,9 @@ For CLI Agent asset-authentication and metric-recommendation review, route to `a
 
 Start a recommendation with `governance-recommendation export` before lengthy Agent analysis so Common can atomically mark the project as running. Later exports in the same Agent turn may expand the candidate pool. If Common returns `RECOMMENDATION_RUNNING`, stop this attempt and report that a recommendation is already in progress; do not retry with another Agent context or bypass the marker. Successful page submission and automatic review release the marker; recommendation-only or failed Agent runs rely on the fixed expiry. No separate start or finish CLI command is required.
 
-After presenting recommendations, the Agent may ask whether to submit them to the review page. A user choice to submit authorizes `analysis-meta agent-review submit-to-page` only; it does not authorize approval, certification, config checking, or `governance-recommendation auto-review`. If the user declines, do not write or repeatedly suggest submission. Existing explicit submission authorization remains valid and does not need another prompt. A preauthorized unattended task may submit review proposals only; it must never call `agent-review review|retry`, legacy `governance-recommendation submit`, `governance-recommendation auto-review`, or direct certification/metric mutations automatically. Use `agent-review list|detail|records` and the task's persisted proposal fingerprint to reuse prior batches. Do not resubmit or send repeated notifications for unchanged proposals, pending reviews, completed items, or previously declined suggestions. A new run ID alone is not new evidence. Report the returned `review_url` once and remain quiet until there is a meaningful change or required user action. See `references/agent_review_submit_to_page.md` for stable request keys and packet rules.
+After presenting recommendations, the Agent may ask whether to submit them to the review page. A user choice to submit authorizes `analysis-meta agent-review submit-to-page` only; it does not authorize approval, certification, config checking, or `governance-recommendation auto-review`. If the user declines, do not write or repeatedly suggest submission. Existing explicit submission authorization remains valid and does not need another prompt. A preauthorized unattended task may submit review proposals only; it must never call `agent-review review|retry`, legacy `governance-recommendation submit`, `governance-recommendation auto-review`, or direct certification/metric mutations automatically. Do not query review history to select candidates. Select currently uncertified assets by business value and evidence, regardless of earlier recommendations or review decisions. Keep stable request keys only for network replay of the same submission; a new authorized recommendation may include previously recommended assets. Read the returned batch detail to verify submission. See `references/agent_review_submit_to_page.md` for request keys and packet rules.
 
-Report review details must explain calculation logic and statistical measures, not only business purpose. Follow resolve/export -> material-package completeness check -> gap-only `analysis-meta agent-review evidence` or `analysis report get` -> chunked AI explanation -> independent preflight -> authorized submit-to-page -> detail readback. LOCAL_ONLY stops at the local preflight result. `governance-recommendation export` is expected to include report `evidence_snapshot.analysis` and `target_revision` in `review_material_package.candidate_assets`; do not ask the customer to run `analysis report get` for every report when those fields are present. Fetch `agent-review evidence` only when a report item lacks current analysis, when validating a generated draft, or when the material package explicitly marks a definition gap. Read `references/agent_review_evidence.md` for stable analysis fields and their limits. Populate `item.ai_summary.analysis_explanation` with evidence-backed measures, dimensions, calculations, filters, time_scope, and query_columns as applicable; interpret each supported SQL projection column separately. Reference only actual fact-supporting response paths rooted at `evidence_snapshot.analysis`; `source_path` is provenance, not an automatic evidence_refs substitution. Preserve server facts separately from AI interpretation and explicitly identify null, missing, dynamic or unparsed evidence. For DYNAMIC SQL, label supported sql.raw/normalized_definition.params discussion as original-text interpretation, never fabricate select_columns or runtime substitutions. Common create stores the submitted packet; it does not fill missing calculation explanations for the Agent. Before calling `submit-to-page`, check required `evidence_snapshot.analysis` and resolvable references in `analysis_explanation.calculations` / `analysis_explanation.measures`; missing required structure remains an error. Reviewer-readability and interpretation defects follow the bounded quality correction/warning procedure. Verify the stored snapshot and references in detail after submission. Never guess SQL, aliases, columns, formulas, time ranges, timezones, or successful execution. Definition inspection, evidence reads, validation, and submission are not proof of query results, approval, or certification.
+Ordinary recommendations prepare concise material for human review, not a full certification audit. Follow resolve/export -> select -> business-domain/subtopic grouping and concise reasons -> one local structure/evidence check plus focused preflight -> authorized submit-to-page -> one detail readback. LOCAL_ONLY stops at local artifacts. For each report, explain at least one core statistical measure or calculation with fact-supporting references rooted at `evidence_snapshot.analysis`; purpose alone is insufficient. Preserve current packaged analysis and `target_revision`, and add relevant population/filter/time boundaries when they affect that core meaning. Do not require every dimension, SQL output column or calculation step unless the user requests a full audit or a concrete risk needs that detail. Fetch `agent-review evidence` only for a missing/stale definition or a specific unresolved claim, not once per report or as routine spot validation. Preserve server facts separately from AI interpretation; never guess formulas, aliases, time ranges or successful execution. See `references/agent_review_submit_to_page.md` for the ordinary workflow and optional full-audit detail. Existing report-analysis, evidence-link and reference validation remains enforced.
 
 `item.ai_summary.summary` is the concise item recommendation reason, including its evidence basis and main risks, displayed in the main list. `batch.ai_summary.summary` is the batch overview and cannot replace item reasons. Detailed factual explanations belong only in `item.ai_summary.analysis_explanation`. Do not duplicate reasons or detailed analysis into presentation fields; keep `presentation_snapshot.analysisByItem` as `{}`. Do not invent a reason from unknown values; state missing evidence or uncertain risks explicitly rather than treating them as zero or absent.
 
@@ -101,7 +112,7 @@ Scripts may build the transport file, preserve IDs, copy evidence, normalize lin
 
 Page-visible review text is for human asset reviewers, not implementers. In `item.ai_summary.summary`, visible statements, and open questions, write plain business Chinese: what the asset is for, how it is calculated, which filters/date windows matter, and what the reviewer should confirm. Use event and property names from the current asset definition when they help the reviewer verify the calculation definition. Do not expose internal evidence, parser terms, temporary SQL aliases, or runtime parameter names such as `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, or claims about query execution unless the user explicitly asks for debug evidence. Convert internal values before display, for example `T1`/`day` becomes `按天`, and dynamic SQL caveats become business confirmation items such as “确认参数含义、默认日期范围和是否包含测试数据”.
 
-For real review-page submission, start with `analysis-meta governance-recommendation export --limit 20`. This is the initial candidate pool, not a required submission count. Follow the rejection filtering and bounded expansion procedure in `references/governance_recommendation_export.md`: hide each same-definition rejected dashboard's entire display branch, retain shared assets only under other retained dashboards, filter out already completed/authenticated, deferred, or in-flight assets as pending work, and expand an insufficient pool from 20 to 50 to 100, then stop. Expansion is for business-domain coverage, not unlimited workload: for recurring daily batches, target about 20-50 pending review assets, hard cap around 80, and balance roughly 3-6 visible domains with per-domain quotas before adding context. Use the latest successful export as the drafting evidence and report the actual reviewed scope plus overflow left for later batches. Do not compress eligible coverage into a few representative themes or submit only the first work unit unless the user requests a sample or diagnostic batch. Business themes organize the retained dashboard set; they do not replace its coverage. For recurring recommendation jobs, submit only business domains that still contain pending review assets; authenticated assets are supporting context under those visible domains, not standalone work. Do not write long Agent summaries for hidden domains or pure authenticated context.
+For real review-page submission, start with `analysis-meta governance-recommendation export --limit 20`. This is the initial candidate pool, not a required submission count. Follow current-state selection and bounded expansion in `references/governance_recommendation_export.md`: select currently uncertified assets by business value and evidence, keep authenticated assets only as necessary context, and expand an insufficient pool from 20 to 50 to 100, then stop. Earlier recommendations and review decisions do not remove an otherwise eligible asset. Expansion is for business-domain coverage, not unlimited workload: for recurring daily batches, target about 20-50 pending review assets, hard cap around 80, and balance roughly 3-6 visible domains with per-domain quotas before adding context. Use the latest successful export as the drafting evidence and report the actual reviewed scope plus overflow left for later batches. Do not compress eligible coverage into a few representative themes or submit only the first work unit unless the user requests a sample or diagnostic batch. Business themes organize the retained dashboard set; they do not replace its coverage. For recurring recommendation jobs, submit only business domains that still contain pending review assets; authenticated assets are supporting context under those visible domains, not standalone work. Do not write long Agent summaries for hidden domains or pure authenticated context.
 
 For dashboard recommendations, preserve optional location facts from Common: when a dashboard candidate or source dashboard includes `space_id` or `space_name`, copy those fields into the submitted dashboard item's `evidence_snapshot.definition.config` so the review page can show `所属空间`. Not every dashboard belongs to a space; missing space fields are valid and must not be invented, required, or used to filter out an otherwise eligible dashboard.
 
@@ -113,7 +124,7 @@ The full `evidence_hash` includes collection time and may change between preview
 
 If a retired split recommendation command or capability is accidentally probed and returns an error, treat that as a routing correction only. Do not use data from split recommendation commands or capabilities as the business source for a recommendation answer; rerun the current workflow through `analysis-meta governance-recommendation export`.
 
-For review-page drafting, material inspection, or local-only rehearsals, read `references/agent_review_preflight.md` and `references/agent_review_priorities_comparisons.md`. After item explanations, generate evidence-backed review priorities and compare related definitions across authoring chunks/topics; store `recommendation`, classified `comparisons` and `comparison_review` in item AI summaries. Review priority is not a certification decision, and similarity alone is not conflict. Use an independent fresh-context reviewer to compare all evidence (including `signals`) with saved sources and review item-specific meaning, priorities and paired definitions. The author corrects concrete findings at most 3 times for the whole packet, with independent re-review. If quality still fails, an already authorized submission continues with explicit unresolved-quality warnings; never claim PASS or reset the correction budget. Disclose unavailable review or incomplete coverage. Local-only intent always forbids submission. Quality assessment belongs to the Agent, not Common; structural validation, authorization and transport errors remain enforced.
+For ordinary review-page drafting, material inspection, or local-only rehearsals, use the focused scope in `references/agent_review_preflight.md`: programmatic evidence/identity/reference checks cover the entire exact packet; one independent semantic review covers every business domain/subtopic, its supporting member definitions and identified risk items. Do not require the reviewer to re-interpret every report, grade every metadata dependency or generate per-item comparison coverage. Load `references/agent_review_priorities_comparisons.md` only for requested prioritization, actual comparison/conflict clues or an explicit full audit. Optional priorities rank human review urgency, never certification outcome. Missing comparisons do not prove no conflict. Deepen checks only for the affected claims/peers; apply full definition-audit requirements when explicitly requested. Correct factual errors and unsupported membership, not ordinary copy preferences through routine rounds; the existing maximum 3 corrections is a ceiling for material findings. Record actual review scope, disclose unchecked/full-audit scope and unresolved findings, and preserve LOCAL_ONLY and submission authorization boundaries. These rules do not change approval, automatic certification, permissions or Common admission.
 
 ## Global AE CLI Rules
 
@@ -134,6 +145,8 @@ ae-cli capability search|inspect|validate|dry-run|run [options]
 - Execute a fully specified read or ordinary write directly. Do not routinely stack inspect, validate, dry-run, and run. Inspect the selected model contract once when a concrete schema mismatch requires it; reuse that inspected contract within the unchanged conversation scope. This is local evidence reuse, not a claim that the CLI caches contracts.
 - JSON is the default machine-readable output. On failure, preserve the structured error and non-zero exit.
 - `CREDENTIAL_STORE_UNREADABLE` (`error.type: config`) is a local credential read/decryption failure. Preserve the files and retry in the original OS user/runtime with machine-identifier access; do not automatically log in, replace tokens, or log out. It does not establish server-side token expiration.
+- Inject credentials into the current CLI invocation through environment variables or a specified file without changing stored machine accounts; automation scripts, CI/CD, and shared Agents are example use cases. Use `AE_CLI_TOKEN` plus required `AE_CLI_TOKEN_HOST`, `AE_CLI_TOKEN_FILE`, or global `--cli-token-file <path>` using `{"url":"https://host.example.com","token":"cli_..."}`. Precedence is explicit file > environment token > environment file > existing credentials. The bound host is the default; an explicit `--host` must match. Invalid selected sources return `EXTERNAL_CLI_TOKEN_INVALID` without identity fallback. Do not print or persist supplied tokens, or manage machine accounts while external mode is active (`EXTERNAL_CLI_TOKEN_ACTIVE`). Use `auth status` to inspect the selected source and identity.
+- The member's natural-day quota counts each Gateway capability `execute` call eligible for usage statistics (an identifiable user and statistics enabled), regardless of its database or business purpose. Report reads/saves, metadata reads, asset exports, data queries, cache hits, repeated calls, and failures within `execute` count, including schema errors, permission denials, and unknown capability IDs. Reusing an existing run does not exempt a new `execute` call. Gateway capability discovery (list/inspect), validate/dry-run, and separate run-status/artifact-download HTTP endpoints do not count; pagination and cancellation through capability execution, such as `analysis.query.cancel`, do count. `QUERY_DAILY_LIMIT_EXCEEDED` (HTTP 429) requires waiting until reset or contacting an administrator; `QUERY_QUOTA_UNAVAILABLE` fails explicitly. Do not change identities to bypass enforcement. See [quota and export policy](references/analysis_data_export.md) for blocked-call auditing, retry rules, async server defaults, and separate typed-CLI/local-wait limits.
 - Never invent command names, flags, payload fields, projects, resource IDs, asset names, canonical event/property identifiers, metric formulas, or dates. User-provided business wording is valid unresolved compiler input; it is not a claim that a canonical binding is known.
 - 中文时间表达必须按固定语义映射：最近7天/近7天 -> `mode=recent` -> QP `recentDay=0-7`，含今天；过去7天/前7天 -> `mode=previous` -> QP `recentDay=1-7`，不含今天。用户明确说明是否包含今天时，以该说明为准。完整映射见 [`references/ai_models.md`](references/ai_models.md)。
 

package/skills/ae-analysis/references/adhoc_export.md

@@ -50,7 +50,7 @@ Rules:
 - `--resolutions`: only after user confirmation, pass deterministic bindings keyed by compiler error path while keeping each bound field's path and original wording. Fill the other confirmed model parameters in `--definition`. Follow [`metadata_resolution.md`](metadata_resolution.md).
 - `--artifact-format`: `jsonl` or `csv`.
 
-Async export has no inline row limit. Runtime defaults to and is capped at 21600 seconds (6 hours); cancel earlier with `analysis query cancel --run-id <run_id>`. Shared lifecycle handling is in [analysis_data_export.md](analysis_data_export.md).
+Async export has no inline row limit. Omit `--timeout-seconds` to use the deployment's server default (normally 21600 seconds / 6 hours). The typed CLI accepts explicit `1..21600`; inspect this capability for the server default/max and use `capability run` for larger explicit values only when allowed. Read the run descriptor for the effective deadline; cancel earlier with `analysis query cancel --run-id <run_id>`. Shared lifecycle handling is in [analysis_data_export.md](analysis_data_export.md).
 
 Do not use raw QP, `events`, `event_view`, `visual_view`, removed ad-hoc QP builder outputs, or schema helper outputs as `--definition`.
 

package/skills/ae-analysis/references/agent_review_preflight.md

@@ -1,6 +1,6 @@
 # Agent Review Preflight
 
-Use for preparing or checking review-page materials, including a local-only rehearsal. This is an Agent workflow, not a Common admission rule. Read alongside [submit-to-page](agent_review_submit_to_page.md). A CLI validation success is not a quality approval.
+Use for preparing or checking review-page materials, including a local-only rehearsal. Ordinary recommendation defaults to FOCUSED_RECOMMENDATION; FULL_AUDIT applies only when the user explicitly requests a comprehensive definition/material audit. These are local review-scope labels, not CLI flags or Common fields. Read alongside [submit-to-page](agent_review_submit_to_page.md). A CLI validation success is not a quality approval; a focused review is not a full certification audit.
 
 ## Authorization and Isolation
 
@@ -10,18 +10,30 @@ Use a fresh-context reviewer subagent that did not author the material. Give it
 
 For an explicit audit-only request, the independent reviewer may run these checks directly without spawning another reviewer. Its findings are the audit result, not self-approval of authored text.
 
+## Focused Recommendation Review (Default)
+
+Apply one whole-packet programmatic check and one independent semantic pass over the following focused scope:
+
+- Check every business domain and subtopic, including the narrower question, membership, supporting definitions from each represented dashboard, missed cross-dashboard merges and unjustified source-container splits. Use actual core measures/populations/time boundaries; exhaustive SQL projection analysis is unnecessary unless it affects that judgment.
+- Check the recommendation basis and explanation for identified material risks: uncertain counting entity or formula, a meaningful name/definition mismatch, conflicting peers, or missing evidence behind a claim. Inspect only the affected fields and relevant peers. Dynamic SQL or a generic extractor's empty fields alone is not a requirement for a full audit.
+- Other items retain concise author-written purposes/reasons and a core evidence-backed measure/calculation for every report. The independent reviewer does not need to reread every remaining definition, individually grade metadata dependencies, or author exhaustive pair comparisons. Omitted priority/comparison fields are allowed; never interpret them as a no-conflict result.
+- Record checked semantic item IDs and identified risk IDs separately from whole-packet machine coverage. PASS means the declared focused scope passed; explicitly state that full item-definition auditing was not performed. No focused PASS with unchecked topics/subtopics or unchecked identified risks. A few sampled items do not constitute a full audit.
+- Correct factual or materially unsupported grouping/recommendation claims, then recheck affected semantic fields and rerun the machine check. Do not spend rounds on stylistic preferences, exhaustive coverage records or optional prose. The existing maximum of 3 material corrections remains a ceiling, never a routine three-round workflow.
+
+Preserve the exact source/draft hashes and actual coverage. A newly discovered risk expands only the affected inspection scope; it does not silently turn ordinary recommendation into a full-batch audit. Authorization, missing required evidence and structural errors remain separate checks.
+
 ## Prepare Once, Interpret in Batches
 
-1. Resolve the host/project, export the candidate pool, and apply the existing rejection/20 -> 50 -> 100 procedure. Preserve the original export file. Record CLI/source revision, loaded Skill path and file hashes so an installed old Skill cannot silently stand in for the tested one.
-2. Build a scope ledger accounting for every candidate: retained, existing certified context, same-definition rejection, or an explicit evidence gap. Account separately for metric-creation candidates, which are not CERTIFY proposals. A missing explanation is unfinished work, not a reason to silently remove an asset. Preserve shared asset identity and retained relations.
-3. Split retained assets into manageable business-domain chunks, with a per-item checklist. Read actual definitions before writing each chunk. Authoring subagents may work on disjoint chunks, but none may approve its own work. Complete and merge every chunk before calling a batch complete; do not stop at representative examples or fill remaining entries with templates.
+1. Resolve the host/project, export the candidate pool, and apply current-state selection and the bounded 20 -> 50 -> 100 procedure; do not query review history to exclude candidates. Preserve the original export file. Record CLI/source revision, loaded Skill path and file hashes so an installed old Skill cannot silently stand in for the tested one.
+2. Build a scope ledger accounting for every candidate: selected current uncertified work, existing certified context, overflow, or an explicit evidence gap. Account separately for metric-creation candidates, which are not CERTIFY proposals. A missing explanation is unfinished work, not a reason to silently remove an asset. Preserve shared asset identity and retained relations.
+3. Interpret selected assets' core definitions and author both grouping levels under [Business Topics and Subtopics](agent_review_submit_to_page.md#business-topics-and-subtopics). Compare grouping across source dashboard boundaries before transport assembly. Keep concise per-item reasons and material risk notes; use chunks only when needed for the size. Full audits also require the per-item comprehensive interpretation below. Do not drop selected assets merely to avoid writing their core meaning or fill entries with templates.
 4. Keep narrative entries separately keyed by `client_item_id`. Scripts may join these entries to the packet, never compose their sentences. Deep-copy each original `evidence_snapshot`, including `asset`, `signals`, `definition`, `analysis`, revisions and source provenance when present. Copy candidate source/evidence links too. The abbreviated transport example is not a field allowlist.
 5. For a gap-only evidence read, preserve the entire original response and record its asset identity and file in the source ledger. The reviewer must verify any replacement/addition against that response. Never replace an existing value merely to agree with prose or recompute server hashes. Common stores the submitted packet; it does not fill omitted statistics or author explanations.
-6. Complete [per-asset priorities and cross-asset comparisons](agent_review_priorities_comparisons.md) after merging chunks. Supply evidence-backed `recommendation`, classified `comparisons` and explicit `comparison_review` coverage; missing fields are not a default priority or proof of no conflict.
+6. Run [priorities and cross-asset comparisons](agent_review_priorities_comparisons.md) only when requested, when concrete peer/conflict evidence needs inspection, or for a full audit. Ordinary items need not carry grades or comparison coverage. For comparisons actually made, keep evidence and classifications; missing fields are not a default priority or proof of no conflict.
 
 ## Required Independent Checks
 
-The reviewer performs both passes on the complete retained scope. It may use scripts for deterministic comparisons, but must itself interpret the definitions for the semantic pass.
+The machine pass covers the entire exact packet in either scope. The independent reviewer interprets definitions for every topic/subtopic and identified risk in focused scope; a FULL_AUDIT additionally covers every retained item's detailed meaning. Use scripts for deterministic comparisons rather than repeating those checks in prose.
 
 ### A. Evidence and Coverage
 
@@ -31,7 +43,16 @@ The reviewer performs both passes on the complete retained scope. It may use scr
 - Resolve every factual `evidence_refs` path and check the value, not just path existence. Verify revisions, source links, hierarchy and documented exclusions. Save machine-check results with checked item IDs and uncovered IDs.
 - Cross-check counted entities, filter/group fields and formula dependencies in actual definitions against the exported dependency graph. All relation IDs resolving does not prove all dependencies were exported. Record missing dependencies as source gaps; never invent asset IDs or evidence-backed edges. Use the relevant read-only CLI lookup only when it can resolve that gap, and preserve its response before adding a verified relation.
 
-### B. Meaning, Not Filled Fields
+### B. Business Grouping (Both Scopes)
+
+- Business topics: review every topic's Agent-authored `semantic_basis.business_question`, `grouping_reason`, and `evidence_item_ids` against definitions of items displayed in that topic. Missing basis is a semantic quality finding even though legacy transport accepts its absence. Copying a dashboard/report title or `topic_seed` is not a business interpretation. Explain why reports answer the same business question, identify justified cross-dashboard merges and within-dashboard splits, and use `待确认业务主题` with the specific uncertainty when evidence is insufficient. A legitimate business name can equal a source name: never reject it by keyword or equality alone.
+- Business subtopics: independently check every `topics[].groups[]` and its own `semantic_basis` against member report definitions, not just the parent topic's meaning. Verify its narrower question, boundaries from siblings, evidence for every represented dashboard, and whether related selected dashboards were wrongly separated. One-dashboard-per-group output requires definition-based scrutiny for missed merges; changing group names without reconsidering membership does not resolve it. Accept a single-dashboard subtopic when its specific question and selected-scope limits justify it. Do not force unrelated dashboards together or use name equality/count thresholds as the verdict. Missing basis, copied source containers and unsupported membership are semantic quality findings, not new CLI/Common admission rules.
+- Record `checked_topic_ids`, `unreviewed_topic_ids`, and scoped `checked_subtopic_refs` / `unreviewed_subtopic_refs` (`{topic_id, group_id}`), with topic/subtopic-specific findings alongside item coverage. For every subtopic record its dashboard item IDs, definition evidence inspected, cross-dashboard merge/split assessment and any single-dashboard justification in `subtopic_checks`. A top-level topic review or item-only PASS cannot stand in for these checks. No whole-packet PASS with unchecked topics or subtopics. Reuse the existing bounded correction budget and warning continuation policy; grouping checks do not authorize certification or submission.
+
+
+### C. Full Audit Only
+
+The following comprehensive item, priority and paired-definition checks apply to FULL_AUDIT. For focused recommendations use them only on fields needed by a grouping judgment or an identified risk; do not expand to every item.
 
 - Review every retained item's recommendation, and every retained dashboard/report's definition-based explanation. Track checked IDs; sampling cannot establish a whole-batch PASS. If the scope is too large, split the review across fresh reviewers with disjoint ID lists and combine their coverage and findings.
 - Dashboard: explain the business question jointly answered by its actual child reports and why this particular combination merits review. A title plus heat and "stabilize downstream definitions" is insufficient.
@@ -49,6 +70,7 @@ Write a local `preflight-review.json` with:
 ```json
 {
   "mode": "LOCAL_ONLY",
+  "review_scope": "FOCUSED_RECOMMENDATION",
   "decision": "NEEDS_REVISION",
   "repair_attempt": 0,
   "max_repair_attempts": 3,
@@ -58,10 +80,31 @@ Write a local `preflight-review.json` with:
   "expected_item_ids": [],
   "checked_evidence_ids": [],
   "checked_semantic_ids": [],
+  "expected_semantic_ids": [],
+  "identified_risk_ids": [],
+  "unchecked_risk_ids": [],
+  "not_audited_item_ids": [],
   "unreviewed_ids": [],
+  "checked_topic_ids": [],
+  "unreviewed_topic_ids": [],
+  "checked_subtopic_refs": [],
+  "unreviewed_subtopic_refs": [],
+  "subtopic_checks": [
+    {
+      "topic_id": "<business-domain-id>",
+      "group_id": "<business-subtopic-id>",
+      "dashboard_item_ids": ["<dashboard item id>"],
+      "definition_evidence_refs": ["<raw file and report-definition path>"],
+      "merge_split_assessment": "<why these members belong together and differ from siblings>",
+      "single_dashboard_justification": "<reason if one dashboard; null otherwise>",
+      "result": "<PASS|NEEDS_REVISION>"
+    }
+  ],
   "findings": [
     {
-      "item_id": "<asset ID>",
+      "topic_id": "<domain ID for a grouping finding; omit for item-only findings>",
+      "group_id": "<subtopic ID for a subtopic finding; omit otherwise>",
+      "item_id": "<asset ID for an item finding; omit for grouping-only findings>",
       "field": "<draft field>",
       "code": "<EVIDENCE_LOSS|UNSUPPORTED_CLAIM|BOILERPLATE|INCOMPLETE|SCOPE_GAP>",
       "source_ref": "<raw file and supporting path>",
@@ -72,9 +115,11 @@ Write a local `preflight-review.json` with:
 }
 ```
 
-The reviewer, not the author or transport script, sets `PASS` only when both passes cover the entire expected scope and no blocking finding remains. Source limitations may remain when honestly explained and the core interpretation is supported; unresolved core meaning cannot PASS. Do not put this local artifact into the Common packet or treat it as authoritative server evidence.
+The reviewer, not the author or transport script, sets `PASS` only for the explicitly recorded `review_scope`. For FOCUSED_RECOMMENDATION, machine checks cover all expected item IDs, semantic checks cover all topic/subtopic supporting evidence and identified risk IDs, and remaining items appear in `not_audited_item_ids`; their absence from detailed semantic review is not automatically a finding. For FULL_AUDIT, `expected_semantic_ids` includes every retained item and none may remain unaudited. Reports without an explicit scope are legacy full-audit records, not evidence of a newly completed focused review.
+
+Enumerate expected `{topic_id, group_id}` pairs from the exact draft and reconcile them with checked/unreviewed coverage; counts or a few examples are insufficient. Unknown source facts may remain when honestly explained; unresolved meaning within the declared checked scope cannot PASS. Do not put this local artifact into the Common packet or treat it as authoritative server evidence. Always disclose focused versus full coverage without creating identical per-item audit boilerplate.
 
-On `NEEDS_REVISION`, the author reopens cited definitions, restores evidence or rewrites the actual interpretation. Adding asset names, IDs, numeric details, synonyms or prefixes merely to defeat repeated-text checks is prohibited. Re-review changed narratives independently and rerun full evidence/coverage checks.
+On `NEEDS_REVISION`, reopen cited definitions, restore evidence or correct the actual interpretation. Adding synonyms or prefixes merely to defeat repeated-text checks is prohibited. Independently re-review affected material findings in the declared scope and rerun whole-packet programmatic evidence checks; do not restart every unchanged report explanation for a grouping or copy edit.
 
 Allow at most **three correction attempts per logical material packet**. Initial drafting/review is attempt 0 and does not consume a correction. Each subsequent author revision plus independent re-review consumes one attempt (1, 2, 3); stop correcting immediately on PASS. Persist the counter and link each finding to the changed fields and the reviewer's resolved/unresolved result. After review of attempt 3 still returns NEEDS_REVISION, do not start attempt 4: retain the failed quality verdict and continue with warnings under the policy below. Replacing subagents, renaming files, regenerating drafts, changing source run IDs, or resuming the same task must not reset this counter. Do not quietly reduce the batch, skip the reviewer or label unfinished work complete. A new retry budget requires explicit user authorization. This is a ceiling, not a quota: stop correcting earlier when no meaningful repair is possible with available evidence and scope; record why, and do not spend attempts on unchanged retries.
 

package/skills/ae-analysis/references/agent_review_priorities_comparisons.md

@@ -1,6 +1,8 @@
 # Review Priority and Definition Comparisons
 
-Read after interpreting individual assets and before [independent preflight](agent_review_preflight.md). These are Agent assessments inside each item's `ai_summary`, not new Common admission rules, certification decisions or server evidence. Generate them in LOCAL_ONLY rehearsals too, without submitting anything.
+Read only when the user requests prioritization/comparison or a full audit, or when concrete evidence suggests related/conflicting definitions. Ordinary recommendation does not require this pass for every item. These are Agent assessments inside `ai_summary`, not Common admission rules, certification decisions or server evidence. LOCAL_ONLY keeps any requested assessments local.
+
+The exhaustive per-item requirements below apply to an explicit full audit. For ordinary recommendations, priority is optional and comparisons cover only actually examined peers. Do not fill empty comparison/coverage records or grades merely for completeness. Missing comparison fields mean no documented assessment, never verified absence of conflicts. If supplied, preserve the evidence, classification and reciprocity rules below.
 
 ## Per-Asset Review Priority
 
@@ -55,7 +57,7 @@ In the current page contract, actionable peer links require both assets in the r
 
 ## Explicit Coverage, Not Empty-by-Default
 
-Every item also carries `comparison_review`:
+For a full audit, every item also carries `comparison_review`. For an ordinary recommendation, add it only when an actual comparison was performed; unexamined items may omit it or explicitly use NOT_REVIEWED, never COMPLETE:
 
 ```json
 {
@@ -71,6 +73,6 @@ Every item also carries `comparison_review`:
 
 ## Preflight and Bounded Repair
 
-The independent reviewer checks per-item priority coverage and evidence, cross-chunk candidate selection, both definitions for each pair, classifications, reciprocal conflict edges, identity/refs and whether the wording claims more coverage than was checked. It must challenge both false conflict badges and likely missed conflicts. Record counts by priority (including unassessed), comparison outcome, unique unordered conflict pairs, affected items, and incomplete comparisons. Count pair A-B once, not twice because of reciprocal entries.
+Within the requested or triggered comparison scope, the independent reviewer checks priority coverage and evidence, cross-chunk candidate selection, both definitions for each pair, classifications, reciprocal conflict edges, identity/refs and whether the wording claims more coverage than was checked. It must challenge both false conflict badges and likely missed conflicts. Record counts by priority (including unassessed), comparison outcome, unique unordered conflict pairs, affected items, and incomplete comparisons. Count pair A-B once, not twice because of reciprocal entries.
 
 Use the same logical-packet correction budget in preflight: at most 3 corrections total, not 3 for each priority, pair or reviewer. On exhausted quality corrections, preserve the findings and follow authorized warning continuation. LOCAL_ONLY always ends with local files. Missing priority, incomplete comparison, and poor rationale are Agent quality findings, not new CLI/Common rejection rules.

package/skills/ae-analysis/references/agent_review_submit_to_page.md

@@ -14,12 +14,12 @@ ae-cli analysis-meta agent-review submit-to-page \
   --source-run-id rec_source --source-task-id task_review \
   --client-request-id review_task_proposal_001 \
   --ai-summary '{"summary":"Evidence-backed retention assets"}' \
-  --presentation-snapshot '{"project":{"name":"Example"},"evidenceDate":"2026-09-08","topics":[{"id":"retention","name":"Retention","groups":[{"id":"retention_core","name":"核心留存看板","items":[{"id":"dashboard_1"},{"id":"report_1"},{"id":"event_login"}]}]}],"relations":[{"parent":"dashboard_1","child":"report_1","type":"contains"},{"parent":"report_1","child":"event_login","type":"uses"}],"analysisByItem":{}}' \
+  --presentation-snapshot '{"project":{"name":"Example"},"evidenceDate":"2026-09-08","topics":[{"id":"retention","name":"Retention","groups":[{"id":"retention_core","name":"新用户回访","items":[{"id":"dashboard_1"},{"id":"report_1"},{"id":"event_login"}]}]}],"relations":[{"parent":"dashboard_1","child":"report_1","type":"contains"},{"parent":"report_1","child":"event_login","type":"uses"}],"analysisByItem":{}}' \
   --items '[{"client_item_id":"dashboard_1","target_ref":{"type":"dashboard","key":"1"},"action_type":"CERTIFY","proposal_payload":{"authentication_status":1},"ai_summary":{"summary":"<verified dashboard recommendation basis; main risks or explicit evidence gaps>"},"evidence_snapshot":{"source_run_id":"rec_source"}},{"client_item_id":"report_1","target_ref":{"type":"report","key":"1"},"action_type":"CERTIFY","proposal_payload":{"authentication_status":1},"ai_summary":{"summary":"<verified report recommendation basis; main risks or explicit evidence gaps>"},"evidence_snapshot":{"source_run_id":"rec_source"}},{"client_item_id":"event_login","target_ref":{"type":"event","key":"login"},"action_type":"CERTIFY","proposal_payload":{"authentication_status":1},"ai_summary":{"summary":"<verified metadata recommendation basis; main risks or explicit evidence gaps>"},"evidence_snapshot":{"source_run_id":"rec_source"}}]' \
   --dry-run
 ```
 
-Large real drafts should be submitted as a local file instead of shell-escaped JSON:
+Real drafts should be submitted as a local file instead of shell-escaped JSON. With submission authorization and local checks complete, execute directly; remote `--validate` or `--dry-run` is optional for uncertain input or a new contract, not a routine prerequisite:
 
 ```bash
 ae-cli analysis-meta governance-recommendation export \
@@ -30,11 +30,10 @@ ae-cli analysis-meta governance-recommendation export \
 ae-cli analysis-meta agent-review submit-to-page \
   --project-id 1 \
   --client-request-id review_task_proposal_001 \
-  --input-file submit-to-page-draft.json \
-  --dry-run
+  --input-file submit-to-page-draft.json
 ```
 
-`submit-to-page-draft.json` must follow this customer/Agent contract. `--project-id` and `--client-request-id` are still supplied as CLI flags so a replay keeps the same project and stable operation key:
+`submit-to-page-draft.json` follows this customer/Agent contract. The example includes optional detailed explanation sections; ordinary recommendations need only a concise core measure or calculation plus material boundaries/risks. `--project-id` and `--client-request-id` are still supplied as CLI flags so a replay keeps the same project and stable operation key:
 
 ```json
 {
@@ -59,9 +58,16 @@ ae-cli analysis-meta agent-review submit-to-page \
         "groups": [
           {
             "id": "<second-level-group-id>",
-            "name": "<second-level group or source dashboard>",
+            "name": "<business-subtopic-name>",
+            "semantic_basis": {
+              "business_question": "<specific business question>",
+              "grouping_reason": "<shared meaning and boundary from sibling subtopics>",
+              "evidence_item_ids": ["<supporting item id in this group>"]
+            },
             "items": [
-              { "id": "<client_item_id>" }
+              { "id": "<dashboard item id>" },
+              { "id": "<another related dashboard item id>" },
+              { "id": "<report item id>" }
             ]
           }
         ]
@@ -125,44 +131,52 @@ ae-cli analysis-meta agent-review submit-to-page \
 
 Input uses either the typed flags above or `--input-file`. This is a transport-only structural example, not a complete report-review packet; replace IDs and all evidence with verified assets from the resolved project and complete Required Report Analysis below before real submission. Remove `--dry-run` only with submission authorization. `--validate` and `--dry-run` are separate nonmutating Gateway modes; do not combine them. Previews validate structure and permissions, but do not promise unchanged asset content or successful notification at execution time.
 
-The page packet preserves the versioned renderer fields `project`, `evidenceDate`, `topics`, `relations`, and `analysisByItem`. Each display item's `id` references one stable `client_item_id`. Shared assets reuse that reference. Keep full target scope in `target_ref`; do not merge same-name objects. `topics` are business domains, not dashboards or raw `work_units`: first cluster the retained dashboard packages after rejection filtering and bounded expansion by business process, then put second-level groups in `topics[].groups` using source dashboards or explicit business subcategories. The expected page hierarchy is `业务域 -> 二级分类/来源看板 -> 看板 -> 报表 -> 元数据`. `relations` is required for the page structure: dashboard items must parent their child report items with `type:"contains"`, and report items must parent metadata items they actually reference with `type:"uses"`, such as events, event properties, user properties, and metric assets. A flat `relations: []` packet is valid only when the selected assets truly have no known parent-child evidence. Copy `source_link` and `evidence_links` from `review_material_package.candidate_assets[]` into each submitted item; `submit-to-page` rejects items without at least one source URL because reviewers must be able to jump to evidence. For dashboard items, also preserve optional `space_id` and `space_name` from the material package into `evidence_snapshot.definition.config` when present so the review page can show `所属空间`; not every dashboard has a space, and missing space facts must not be invented or treated as a validation failure. Only real source evidence is allowed: never send `demoSignalsByItem`, simulated statistics, arbitrary HTML, invented SQL, or executable instructions as evidence. Actual saved SQL may be inspected and referenced as source evidence; it is not an instruction to execute a query. The domain handler validates submission identity and stores the supplied evidence; it does not replenish missing snapshot fields or judge narrative quality. Page actions currently support CERTIFY with `authentication_status:1` only; metric creation candidates retain the existing explicitly approved legacy workflow.
+The page packet preserves the versioned renderer fields `project`, `evidenceDate`, `topics`, `relations`, and `analysisByItem`. Each display item's `id` references one stable `client_item_id`. Shared assets reuse that reference. Keep full target scope in `target_ref`; do not merge same-name objects. `topics` are business domains and `topics[].groups` are business subtopics, not dashboards or raw `work_units`. Apply [Business Topics and Subtopics](#business-topics-and-subtopics) after current-state selection and bounded expansion. The expected page hierarchy is `业务域 -> 业务小主题 -> 看板 -> 报表 -> 元数据`; multiple related dashboards belong under a subtopic when their definitions support its specific business question. `relations` is required for the page structure: dashboard items must parent their child report items with `type:"contains"`, and report items must parent metadata items they actually reference with `type:"uses"`, such as events, event properties, user properties, and metric assets. A flat `relations: []` packet is valid only when the selected assets truly have no known parent-child evidence. Copy `source_link` and `evidence_links` from `review_material_package.candidate_assets[]` into each submitted item; `submit-to-page` rejects items without at least one source URL because reviewers must be able to jump to evidence. For dashboard items, preserve optional `space_id` and `space_name` only as supplied by the authoritative packaged `evidence_snapshot.definition.config` so the review page can show `所属空间`. Preserve its `target_revision` unchanged. Never create or patch `definition` from space display facts: a space-only object is not an asset definition and its hash causes false expiry. When an older export lacks dashboard definition/revision, fetch `analysis-meta agent-review evidence` for that dashboard before submitting; not every dashboard has a space, and missing space facts must not be invented or treated as a validation failure. Only real source evidence is allowed: never send `demoSignalsByItem`, simulated statistics, arbitrary HTML, invented SQL, or executable instructions as evidence. Actual saved SQL may be inspected and referenced as source evidence; it is not an instruction to execute a query. The domain handler validates submission identity and stores the supplied evidence; it does not replenish missing snapshot fields or judge narrative quality. Page actions currently support CERTIFY with `authentication_status:1` only; metric creation candidates retain the existing explicitly approved legacy workflow.
 
 Scripts may build the transport file, preserve IDs, copy evidence, normalize links, group display items, and run deterministic completeness checks. Scripts must not author page-visible `ai_summary.summary`, `analysis_explanation.*.statement`, limitations, open questions, or approval rationale by filling reusable sentence templates. Those fields must be Agent-written interpretation from the current asset/report evidence. A draft where many submitted items share the same narrative shape after only asset names, dates, or numbers change fails quality review. Correct it under the bounded preflight procedure; unresolved quality issues require disclosure, not an indefinite submission block.
 
 `item.ai_summary.summary` is the concise item recommendation reason, including its evidence basis and main risks, displayed in the main list. Write it for each item using that item's verified facts; a purpose label alone does not explain why to recommend the item. `batch.ai_summary.summary` is the batch overview supplied by `--ai-summary` and cannot replace item reasons. Detailed factual explanations belong only in `item.ai_summary.analysis_explanation`. Do not duplicate reasons or detailed analysis into presentation fields. Keep `presentation_snapshot.analysisByItem` as the compatibility placeholder `{}`. The server-generated analysis remains in `item.evidence_snapshot.analysis`. Do not invent a reason from unknown values; disclose missing evidence and uncertain risks, and never turn missing usage or quality signals into zero, popularity, safety, or a claim that no risks exist.
 
-For dashboard, report, and SQL report drafts, write the page-visible explanation with the same intent as the project-KB source file's single `Agent 使用摘要`: business purpose, calculation caliber, input/date/filter meaning, output fields or measures, applicable questions, non-applicable questions, and concrete reviewer confirmations. The review page does not need a second SQL-specific section or a source-code reading note. If the packaged evidence includes SQL, use the SQL only as source material for business interpretation; keep raw SQL, parser output, and unresolved parameter tokens in `evidence_snapshot.analysis`. If a fact is not supported, write the business-facing unknown or confirmation question, for example "确认日期参数默认范围和是否包含测试数据", instead of copying `${PartDate:...}`, `selector3`, `parse_status`, or `DYNAMIC`.
+For ordinary dashboard, report and SQL-report drafts, explain purpose, recommendation basis, core calculation meaning and any known material boundary in concise business language. Do not create every explanation section just because it appears in the example. Complete field-by-field interpretation is reserved for explicit full audit or affected risk investigation. Use actual event/property names only where they help verify the core meaning; convert unresolved parameters into concrete reviewer questions rather than exposing parser tokens or raw SQL.
 
 Write all page-visible review text for a business reviewer. `item.ai_summary.summary`, `business_purpose`, `calculations`, `filters`, `time_scope`, `limitations`, `open_questions`, and presentation labels must use plain Chinese that explains purpose, calculation 口径, date/filter choices, and reviewer action. Use event and property names from the current asset definition when they help the reviewer verify the calculation definition. While drafting, avoid template copy such as “保存定义摘要”, “审核时需确认口径”, “本草稿不改写 SQL”, “其下报表和依赖元数据已随同提交审核”, or a sentence that only repeats asset name + heat + 未认证. Such copy is a quality finding handled by the bounded correction/warning procedure, not an unconditional dispatch ban. The item reason must answer why this exact asset is worth reviewing now, which saved definition facts support it, and what concrete risk remains. Keep implementation vocabulary out of visible text: do not show `SAVED_REPORT_ONLY`, `DYNAMIC`, `REPORT`, `T1`, temporary SQL aliases such as `a0`/`a1`, runtime parameter names such as `Variable2`/`selector3`/`PartDate date1`, `source_path`, `evidence_snapshot`, raw JSON, raw SQL, projection/select-column jargon, hash/revision values, dashboard-override limitations, timezone-not-saved notes, or “query not proven/executed/returned rows” caveats. Convert them to reviewer decisions only when material: for example `T1`/`day` means `按天`, and dynamic SQL parameter uncertainty becomes “确认参数含义、默认日期范围和是否包含测试数据”.
 
 ## Normal Submission Workflow
 
-Every item needs an Agent assessment of review urgency and related-definition comparisons, not just a narrative summary. Follow [Priority and Definition Comparisons](agent_review_priorities_comparisons.md): use `ai_summary.recommendation.priority` / `priority_reason` / `evidence_refs`, classified `ai_summary.comparisons[]`, and `ai_summary.comparison_review` coverage. These are stored inside the existing AI summary object; they are not top-level packet fields or new Common admission checks. Unknown priority stays unassessed; LOW is lower review urgency, not a defer decision. Only POSSIBLE_CONFLICT comparisons should create conflict badges, with reciprocal links between both in-packet assets. Empty comparisons without recorded coverage do not mean no conflict. Older page versions may label all comparisons as conflicts: verify renderer support before authorized dispatch and disclose compatibility gaps rather than silently mislabeling non-conflicts.
+Ordinary recommendation and page submission use the focused scope below, including on the first run. A request to recommend assets or hand proposals to a human is not an instruction to perform a complete definition audit. Full audit is available on explicit request; risk-specific inspection stays limited to affected claims and peers. No new CLI mode flag or project switch is required.
 
-For both normal submission preparation and no-submit material checks, [Independent Agent Preflight](agent_review_preflight.md) is mandatory before step 5. A fresh-context reviewer checks the raw sources and exact draft; author self-checks or CLI dry-run success do not replace that review. In `LOCAL_ONLY` mode, stop after local review and do not execute steps 5-7. Preserve every original snapshot field, especially `signals`, even when absent from the abbreviated JSON example above. Common does not restore omitted evidence.
+1. Resolve the project and export current candidates. Follow [Current Candidates and Bounded Expansion](governance_recommendation_export.md#rejection-filtering-and-bounded-expansion): filter to pending review work and expand only when pending assets or visible business domains are insufficient. Preserve source-run identity and full snapshots.
+2. Apply the daily review capacity before drafting: about 20-50 pending assets, never more than about 80, balanced across roughly 3-6 business domains. Keep overflow counts/domains, and only necessary authenticated context; zero-pending domains must not be submitted as standalone page sections.
+3. Read the selected assets' core definitions and author both grouping levels under [Business Topics and Subtopics](#business-topics-and-subtopics). Write a concise per-item purpose/recommendation basis, core report meaning and known material risks. Metadata dependencies need their role and any specific risk, not standalone long analyses. Preserve copied evidence, signals, links, optional location facts and known relations. Do not execute report data to prepare recommendations.
+4. Escalate only concrete uncertainties that affect a recommendation: unclear counted entity/formula, materially inconsistent names versus definitions, a relevant conflicting peer, or missing evidence for a claimed grouping. Inspect affected definitions or missing evidence once. Dynamic SQL or an empty generic extractor alone does not require exhaustive SQL/column analysis. Use [priorities/comparisons](agent_review_priorities_comparisons.md) only when requested or triggered; do not populate comparison records for every ordinary item. Omission is not a no-conflict conclusion.
+5. Run one programmatic structure/evidence pass over the exact whole packet and one [focused independent review](agent_review_preflight.md#focused-recommendation-review-default) of every domain/subtopic and identified risks. Correct factual or material grouping errors and recheck affected fields; do not rewrite sound copy through routine rounds. Preserve actual checked scope and warnings. LOCAL_ONLY stops here without remote writes.
+6. With current submission authorization, submit the final material once using `submit-to-page --input-file <draft.json>` and a stable `client_request_id`. Do not add a routine remote validation/dry-run; use one only for an uncertain input or new contract. After submission, read detail and compare the stored packet, evidence links/references and hierarchy once. Return the public review-page URL. A network replay uses the same key, exact payload and original source run; authorization, structural/API errors and source evidence checks remain enforced.
 
-1. Resolve the project and exact asset identities, then obtain the current recommendation export. Keep target keys, `run_id`, `snapshot_hash`, and `review_material_package` intact; do not bind same-name assets by guesswork. Apply [Rejection Filtering and Bounded Expansion](governance_recommendation_export.md#rejection-filtering-and-bounded-expansion) before drafting: start at 20, filter to pending review work, expand to 50 then 100 only if pending assets or visible business domains are insufficient, and use the latest successful packet.
-2. Apply the daily review capacity before drafting. Unless the user requests otherwise, select about 20-50 pending review assets, never more than about 80, and balance roughly 3-6 visible business domains with per-domain quotas. Rank pending candidates by impact, heat, user count, dependency breadth, and under-covered business domains. Keep overflow counts/domains for the batch summary and later batches.
-3. Generate the review draft from `review_material_package`: candidate items, heat evidence, copied `source_link` / `evidence_links`, relations, report/AI-model definition summaries, versions/hash, batch `ai_summary`, item reasons, and Agent-generated `presentation_snapshot.topics[].groups`. Only create visible topics for business domains that contain selected pending review assets. Authenticated/completed assets may be included as direct context under those topics, but zero-pending domains must not be submitted as standalone page sections.
-4. Fetch `analysis-meta agent-review evidence` only for targets whose material package marks a definition or analysis gap, or when validating a generated draft. Read [the stable analysis field reference](agent_review_evidence.md), inspect the returned `evidence_snapshot.analysis`, parse status, limitations, hash and revision. Do not ask customers to manually run `analysis report get` for every report.
-5. Draft AI explanations and per-item priorities from packaged definitions and current Common evidence, then run cross-asset comparisons over merged chunks before independent preflight. Select real, fact-supporting paths before submission; keep original facts separate from AI interpretation and disclose missing, null or dynamic evidence. The same maximum 3 correction attempts covers explanations, priorities and comparisons together.
-6. With current submission authorization, submit after independent preflight PASS or the bounded warning-continuation outcome in [preflight](agent_review_preflight.md#continue-with-disclosed-quality-issues). At most 3 corrections are allowed; remaining quality failures must be disclosed in the batch overview and affected-item notes, without relabeling the quality verdict PASS. Submit the final hash-recorded material with `submit-to-page --input-file <draft.json>` and a stable `client_request_id`. Preserve the original source-run identity on network replay. Evidence fetching, preflight PASS and retry exhaustion never supply submission or approval authorization. Ordinary structural/API failures cannot be bypassed.
-7. Read detail and compare the stored snapshot with the final dispatched material and source facts. Track the last reviewed draft separately from warning-only additions so those disclosed additions are not mistaken for storage changes. After submission, read detail and check that those paths resolve, still support the claims, and that `presentation_snapshot.relations` can render 看板 -> 报表 -> 元数据 for the submitted assets. `evidence_hash` includes collection time and can differ across reads; `target_revision` corresponds to the saved definition, not all sampled signals. Do not treat a changed full snapshot hash as a cross-scan business change or require it to equal the preview hash. If important facts changed or hierarchy is missing, report the mismatch; do not silently rewrite explanations, approve, or resubmit. Inspect records only for actual review/execution outcomes.
-8. Return the `review_page_url` field from `submit-to-page` when it is present. If only `review_url` is returned, treat it as a relative product-page path and prepend the public AE web host, not a local Common/API host. Never tell a reviewer to open `http://127.0.0.1:8992/#/...` or another backend capability host as the review page.
+The preflight's existing bounded warning policy applies to unresolved quality issues, not invalid required fields or missing authorization. A focused review is not a full certification audit and must not be labeled as one. This workflow creates human review proposals only; approval, retry, automatic certification and metric creation retain their existing explicit intents and checks.
 
 ## Required Report Analysis
 
-Before real page submission, verify the filtering and scope rules in [Rejection Filtering and Bounded Expansion](governance_recommendation_export.md#rejection-filtering-and-bounded-expansion). No same-definition rejected dashboard or its removed display branch may remain in submitted items, groups, topics, or relations; shared assets may remain under other retained dashboards. Active deferrals and items already in unfinished review batches must be excluded from pending work when that state is available. Verify that all displayed references resolve and that counts reflect the retained graph. Include eligible pending assets across the retained branches rather than a few representative themes. The initial top 20 is a candidate pool, not a submission quota; expand to 50 then 100 when pending review assets or visible business domains are insufficient, and stop at 100 or earlier when sufficient or exhausted. The final page batch is still capped for human review capacity: default target about 20-50 pending assets, hard cap about 80, roughly 3-6 visible domains, with per-domain quotas before adding extra assets from one domain. Explain the final scope, overflow and shortfall, and do not submit an empty batch. Business themes organize this retained coverage; merge dashboards describing the same business process instead of copying source order into one topic per dashboard. Do not submit a business topic whose displayed assets are all authenticated/completed context.
+### Minimum for Ordinary Recommendations
+
+Read only enough of each selected report definition to explain its purpose, one core measure/calculation and material population/filter/time boundaries. Every report still requires packaged analysis, its revision, and a real supporting reference. Short authored text never permits dropping source snapshot fields. Evidence fetching is gap-only; do not request per-report re-fetches or execute data merely to prepare a review.
+
+The detailed interpretation table below is for explicit full audits or the affected part of a concrete risk investigation. Ordinary recommendation does not require filling every section or enumerating every SQL projection.
+
+Before real page submission, verify the current-state selection and scope rules in [Current Candidates and Bounded Expansion](governance_recommendation_export.md#rejection-filtering-and-bounded-expansion). Do not query review history to select candidates. Earlier recommendations and review decisions do not exclude currently uncertified assets from this manual review workflow. Verify that all displayed references resolve and that counts reflect the retained graph. Include eligible pending assets across the retained branches rather than a few representative themes. The initial top 20 is a candidate pool, not a submission quota; expand to 50 then 100 when pending review assets or visible business domains are insufficient, and stop at 100 or earlier when sufficient or exhausted. The final page batch is still capped for human review capacity: default target about 20-50 pending assets, hard cap about 80, roughly 3-6 visible domains, with per-domain quotas before adding extra assets from one domain. Explain the final scope, overflow and shortfall, and do not submit an empty batch. Business themes organize this retained coverage; merge dashboards describing the same business process instead of copying source order into one topic per dashboard. Do not submit a business topic whose displayed assets are all authenticated/completed context.
 
 Generate Agent-written narrative only for material that the reviewer will actually see as work: the batch overview, visible business domains, and pending review assets. Hidden domains and pure authenticated context rows should keep copied evidence, signals, links, snapshots and relations, but should not receive long new `ai_summary.summary` or `analysis_explanation` prose unless needed to explain a visible pending item.
 
-Before drafting every report proposal, use the definition and analysis embedded in `review_material_package` first. Current Common export should place report `evidence_snapshot.analysis` and `target_revision` under `review_material_package.candidate_assets`; this is the normal path and should not require an extra report-definition command per report. Call `analysis-meta agent-review evidence` only for report items whose package analysis is missing, stale, or explicitly marked as a gap. Inspect the returned `model_type`, normalized definition, saved SQL, parameters, output columns, filters, grouping, and hashes for SQL reports. A report name, purpose, screenshot, or prior AI summary does not replace the definition. Do not execute report data merely to inspect calculation logic. If a required definition is absent from the package and evidence endpoint, report a material gap instead of submitting a purpose-only explanation.
+Before drafting every report proposal, use the definition and analysis embedded in `review_material_package` first. Current Common export should place report `evidence_snapshot.analysis` and `target_revision`, plus dashboard authoritative `evidence_snapshot.definition` and `target_revision`, under `review_material_package.candidate_assets`. Call `analysis-meta agent-review evidence` only for missing/stale analysis or a specific evidence gap. Do not ask customers to manually run `analysis report get` for every report. A report title or prior AI summary cannot replace the definition; missing required core evidence is a material gap, not a reason to invent an explanation.
 
-After reading each report from the material package, draft its interpretation from the packaged analysis. Fetch `agent-review evidence` only for the gap cases above or for spot validation of the generated draft. Store AI interpretation in `item.ai_summary.analysis_explanation`, not in the authoritative `evidence_snapshot.analysis`. Common create stores the submitted packet for page review; it does not repair a missing Agent calculation explanation during create. Agent-supplied snapshots, SQL text, columns, hashes, or a `verified` flag cannot manufacture server evidence. The renderer consumes the stored explanation, not a new AI answer on page load.
+After reading each report from the material package, draft its concise core interpretation from packaged analysis. Store AI interpretation in `item.ai_summary.analysis_explanation`, not the authoritative `evidence_snapshot.analysis`. Common create stores the submitted packet for page review; it does not repair a missing Agent calculation explanation during create. Agent-supplied SQL, hashes or a `verified` flag cannot manufacture server evidence.
 
 Before a real `submit-to-page` call, run a local completeness check over the exact payload: every report item must contain current `evidence_snapshot.analysis`, and must contain reviewer-readable `item.ai_summary.analysis_explanation.calculations` or `item.ai_summary.analysis_explanation.measures`. A purpose-only report summary is incomplete; missing required analysis or resolvable evidence references still fails structural validation. Do not invent either to force submission. Dashboard items may summarize the child reports, but their own missing calculation analysis is not a blocker because the actual calculation belongs to the reports below the dashboard.
 
-The independent Agent review must include narrative-quality checks before dispatch: flag generic summaries, repeated sentence templates, and repeated limitation/open-question text that does not name the specific unresolved evidence. The author must repair concrete findings, with at most 3 correction/re-review attempts. After the limit, continue an already authorized submission with unresolved findings disclosed; LOCAL_ONLY remains local. These are Agent quality findings, not CLI or Common narrative admission checks. Passing structural checks does not prove that explanations were model-generated or business-correct.
+The focused independent Agent review must include narrative-quality checks before dispatch for the selected grouping evidence and risk items: identify unsupported claims and repeated limitation/open-question text that hides a specific evidence gap. Do not expand it into an exhaustive per-item prose audit or require cosmetic repairs. Full audits check every retained explanation. At most 3 correction/re-review attempts remain available for material findings; this is a ceiling, not a required sequence. Follow preflight's warning continuation and LOCAL_ONLY boundaries, without relabeling incomplete/full-audit scope as passed.
+
+### Full Audit Detail (On Explicit Request or Affected Risk Only)
+
+For a full audit, read actual model/SQL definitions and apply the following field-level requirements. In an ordinary recommendation, inspect only fields needed for the core explanation, grouping or identified risk.
 
 Use arrays of `{ "statement": "...", "evidence_refs": ["..."], "inferred": false }` for the following explanation sections. The statements are AI interpretations; factual clauses require exact, Common-verifiable paths rooted at `evidence_snapshot.analysis`. Use only paths present in the current evidence response that support the retrieved source facts; do not invent field names, array indexes, aliases, or references. `source_path` identifies provenance and is not automatically an AI evidence reference. After submission, read detail and check that those paths resolve in the server-returned snapshot. An unresolved path is missing evidence, not a verified fact. For `DYNAMIC` SQL, follow the original-text-only rules in [agent_review_evidence.md](agent_review_evidence.md); do not manufacture parsed projections or runtime values.
 
@@ -181,6 +195,28 @@ Never guess or rewrite saved SQL, projected columns, or formulas to make a recom
 
 Before writing, consult the user's current intent. Submission can be offered once; declining produces no write. Prior explicit submission authorization does not require repeated permission. A preauthorized unattended task only submits proposals and never approves, retries certification, invokes legacy submit, or creates metrics.
 
-Persist the exact payload, `client_request_id`, proposal fingerprint and returned batch ID in task state. Network replay uses the same key and exact payload, including the original `source_run_id`. Same key with different content is a conflict, not a reason to generate a new key. On subsequent runs, compare material proposal/evidence changes against stored state and `agent-review list|detail|records`; ignore incidental new run IDs and timestamps. Do not repeatedly submit, suggest, or notify on unchanged, pending, completed, rejected, or deferred evidence. Create a new batch only for new material evidence or explicit resubmission intent. Notification deduplication is owned by Common; the Agent does not send another notification separately.
+Persist the exact payload, `client_request_id` and returned batch ID in task state. Network replay uses the same key and exact payload, including the original `source_run_id`. Same key with different content is a conflict, not a reason to generate a new key. A deliberate new authorized recommendation uses a new request key and may contain assets recommended previously; do not require evidence changes or inspect old batches before recommending them again. Historical review records remain available for audit only. Notification delivery is owned by Common; the Agent does not send another notification separately.
 
 Output is the review detail, including string `id`, `review_url`, `review_page_url`, `status`, `notification_state`, versioned `items`, and `reused`. `review_page_url` is the user-facing page URL. `review_url` is kept for server compatibility and may be relative. An exact request replay returns its original batch. A new request can retain a new batch identity while reusing prior proposals: item-level `reused_batch_id` and `reused_item_id` identify the originals without dropping any requested items. Preserve both as decimal strings. `reused:true` alone does not prove the returned batch ID is an older batch. A fully reused batch can report `status:REUSED` and `notification_state:NOT_REQUIRED`; do not send another notification. Creation success is not proof of approval or certification. Return the link once for a newly actionable batch, distinguish notification failure, and read `detail` / `records` after a meaningful change.
+
+## Topic Semantic Evidence
+
+### Business Topics and Subtopics
+
+The intended page hierarchy is `业务域 -> 业务小主题 -> 看板 -> 报表 -> 元数据`: the left navigation is a broad business domain, and the right group heading is a narrower business question that can collect multiple related dashboards. Dashboard names belong on asset rows. A two-level layout whose second level simply repeats the source dashboard list has not completed business classification.
+
+Before assembling transport JSON, the Agent must interpret the selected reports' actual definitions and propose both grouping levels. Record each subtopic's business question, member evidence chains, and why it differs from sibling subtopics. Compare reports across source dashboards within the selected scope: merge complementary views of the same question, and identify materially different questions within a source dashboard instead of inheriting its container boundary. Keep report/metadata dependencies, source links and scoped asset identities intact; never fabricate relations or duplicate certification items to force a taxonomy. If shared placement cannot be represented faithfully, record that presentation gap for review.
+
+For each new topic and each `topics[].groups[]` subtopic include Agent-authored `semantic_basis`:
+
+- `business_question`: the broad domain question or, for a subtopic, the specific question its members jointly answer.
+- `grouping_reason`: definition-based reasons for the included members and the boundary from sibling groups. For a subtopic covering multiple dashboards, explain their complementary roles. For a single-dashboard subtopic, explain why other selected dashboards do not answer the same question; lack of other supported candidates is a valid scope limitation.
+- `evidence_item_ids`: nonempty references to displayed items in that same topic or group respectively. Use representative core report definitions and supporting metadata to justify the business meaning, including evidence for every represented dashboard; a dashboard title alone is insufficient. Select the few definitions needed to support the question and boundaries, rather than listing every child report to imitate full-audit coverage.
+
+Scripts may assemble an Agent-authored membership plan and validate references. They must not derive subtopics by looping over dashboards, copying dashboard names/IDs or `work_units`, adding a business-sounding prefix, or mechanically merging adjacent dashboards. Renaming a one-dashboard group does not repair its membership. Do not force unrelated dashboards together to meet a minimum count, or reject a legitimate business name merely because it equals an asset title.
+
+For example, within a customer-adoption domain, a subtopic about sustained use could combine a daily/weekly activity dashboard and a cohort-retention dashboard when their definitions support that question, while feature breadth belongs to a different subtopic. This illustrates semantic membership, not a fixed taxonomy or required number of dashboards. When meaning is unsupported, use `待确认业务主题` with the concrete missing evidence rather than inventing a category.
+
+[Independent Agent preflight](agent_review_preflight.md) must cover every domain and subtopic, explicitly assessing missed cross-dashboard merges and unsupported splits. All or most groups matching dashboards one-to-one is a review signal, not an automatic name/count rejection. A PASS for either focused or full scope requires evidence-backed grouping and recorded coverage at both levels; focused scope does not claim exhaustive item-definition review. These assessments share the existing correction budget and warning-continuation policy.
+
+The `semantic_basis` fields remain optional in transport for legacy compatibility. When supplied, CLI validation checks nonempty explanation fields and same-topic/same-group evidence references; it does not judge meaning, require two dashboards per group, or reject source-name equality. Existing Common stores the nested presentation object and the page already renders multiple dashboard roots in a group, so this contract requires no server schema or frontend change. Updating this Skill does not reorganize an already stored batch.