@thinkingai/ae-cli 6.0.56 → 6.0.57

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,10 +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
 
-For each new topic include `semantic_basis` with Agent-authored `business_question`, `grouping_reason`, and nonempty `evidence_item_ids` from the same topic. See [independent Agent preflight](agent_review_preflight.md) for mandatory topic interpretation review. This optional transport extension preserves legacy packet compatibility; accepted structure never establishes semantic quality.
+### 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.

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

@@ -117,8 +117,11 @@ This is the exhaustive command and flag inventory for the analysis skill. Read t
 | `ae-cli analysis report-version rollback` | analysis.report_version.rollback | write | `--project-id` (number; required) — Numeric project ID.<br>`--report-id` (number; required) — Report ID.<br>`--target-version` (number; required) — History version to rollback to. | [report_version_rollback.md](report_version_rollback.md) |
 | `ae-cli analysis run inspect` | gateway lifecycle | read | `--run-id` (string; required) — Async run ID returned by an export capability. | [run_inspect.md](run_inspect.md) |
 | `ae-cli analysis run wait` | gateway lifecycle | read | `--run-id` (string; required) — Async run ID returned by an export capability.<br>`--wait-timeout-seconds` (number; optional, min=1, max=21600) — Maximum time this CLI process waits. Default: 600 seconds; expiry never cancels the remote run.<br>`--output` (string; optional) — After success, stream the artifact to this local file.<br>`--force` (boolean; optional) — Allow --output to atomically replace an existing file. | [run_wait.md](run_wait.md) |
-| `ae-cli analysis scenario append` | analysis.scenario.append | write | `--question-id` (string; optional) — Stable original scenario turn ID. Collect defaults to current turn; append must reuse the original ID.<br>`--answer-id` (string; optional) — Actual answer identifier; defaults to answer:<current-turn-id>. Revisions need a new ID.<br>`--query-path` (json; optional) — 1..64 ordered references: [{capability_id,invocation_id?,client_request_id?,purpose?}]. Prefer only returned meta.invocation_id; fallback to returned gateway meta.client_request_id, never business request_id. One analysis data-query step required. Inputs/status/timing come from existing call telemetry. Never include query results.<br>`--project-id` (number; optional) — Source analysis project. Collection is skipped if omitted or the project has not explicitly enabled scenario samples.<br>`--entry-type` (string; required) — user_feedback or answer_revision.<br>`--target-answer-id` (string; required) — Existing answer being questioned or revised. Never overwrite it.<br>`--text` (string; required) — Verbatim user feedback (up to 4096) or exact revised answer (up to 16384); no judgment of whether feedback is right.<br>`--entry-id` (string; optional) — Stable append ID; defaults to current-turn-id:entry-type. Preserve on retries, independent of text edits.<br>`--user-message` (string; optional) — For answer_revision only: exact triggering follow-up request, up to 4096 characters, when not already captured as user_feedback. Preserve scope changes without inventing negative feedback. | [scenario_append.md](scenario_append.md) |
-| `ae-cli analysis scenario collect` | analysis.scenario.collect | write | `--question-id` (string; optional) — Stable original scenario turn ID. Collect defaults to current turn; append must reuse the original ID.<br>`--answer-id` (string; optional) — Actual answer identifier; defaults to answer:<current-turn-id>. Revisions need a new ID.<br>`--query-path` (json; optional) — 1..64 ordered references: [{capability_id,invocation_id?,client_request_id?,purpose?}]. Prefer only returned meta.invocation_id; fallback to returned gateway meta.client_request_id, never business request_id. One analysis data-query step required. Inputs/status/timing come from existing call telemetry. Never include query results.<br>`--project-id` (number; optional) — Source analysis project. Collection is skipped if omitted or the project has not explicitly enabled scenario samples.<br>`--question` (string; required) — Original user scenario question and confirmed clarifications; up to 8192 characters.<br>`--answer` (string; required) — Exact answer text to deliver, not a summary. Up to 16384 characters. Deliver the same text after collection. | [scenario_collect.md](scenario_collect.md) |
+| `ae-cli analysis scenario append` | analysis.scenario.append | write | `--start-time` (string; optional) — Exact start_time returned by scenario begin for this answer. CLI computes one question-to-answer duration; omit if not captured.<br>`--question-id` (string; optional) — Stable original scenario turn ID. Collect defaults to current turn; append must reuse the original ID.<br>`--answer-id` (string; optional) — Actual answer identifier; defaults to answer:<current-turn-id>. Revisions need a new ID.<br>`--query-path` (json; optional) — 1..64 ordered references: [{capability_id,invocation_id?,client_request_id?,purpose?}]. Prefer only returned meta.invocation_id; fallback to returned gateway meta.client_request_id, never business request_id. One analysis data-query step required. Inputs/status/timing come from existing call telemetry. Never include query results.<br>`--project-id` (number; optional) — Source analysis project. Collection is skipped if omitted or the project has not explicitly enabled scenario samples.<br>`--entry-type` (string; required) — user_feedback or answer_revision.<br>`--target-answer-id` (string; required) — Existing answer being questioned or revised. Never overwrite it.<br>`--text` (string; required) — Verbatim user feedback (up to 4096) or exact revised answer (up to 16384); no judgment of whether feedback is right.<br>`--entry-id` (string; optional) — Stable append ID; defaults to current-turn-id:entry-type. Preserve on retries, independent of text edits.<br>`--user-message` (string; optional) — For answer_revision only: exact triggering follow-up request, up to 4096 characters, when not already captured as user_feedback. Preserve scope changes without inventing negative feedback. | [scenario_append.md](scenario_append.md) |
+| `ae-cli analysis scenario begin` | local utility | read | None | [scenario_begin.md](scenario_begin.md) |
+| `ae-cli analysis scenario collect` | analysis.scenario.collect | write | `--start-time` (string; optional) — Exact start_time returned by scenario begin for this answer. CLI computes one question-to-answer duration; omit if not captured.<br>`--question-id` (string; optional) — Stable original scenario turn ID. Collect defaults to current turn; append must reuse the original ID.<br>`--answer-id` (string; optional) — Actual answer identifier; defaults to answer:<current-turn-id>. Revisions need a new ID.<br>`--query-path` (json; optional) — 1..64 ordered references: [{capability_id,invocation_id?,client_request_id?,purpose?}]. Prefer only returned meta.invocation_id; fallback to returned gateway meta.client_request_id, never business request_id. One analysis data-query step required. Inputs/status/timing come from existing call telemetry. Never include query results.<br>`--project-id` (number; optional) — Source analysis project. Collection is skipped if omitted or the project has not explicitly enabled scenario samples.<br>`--question` (string; required) — Original user scenario question and confirmed clarifications; up to 8192 characters.<br>`--answer` (string; required) — Exact answer text to deliver, not a summary. Up to 16384 characters. Deliver the same text after collection. | [scenario_collect.md](scenario_collect.md) |
+| `ae-cli analysis scenario get` | analysis.scenario.get | read | `--project-id` (number; required) — Project to review. Requires project configuration permission to read collected content.<br>`--days` (number; optional) — Recent calendar days including today in the deployment timezone. Default 7; range 1..90.<br>`--end-time` (string; optional) — Exclusive ISO-8601 snapshot boundary. Reuse the first response meta.end_time and the same days on every subsequent page.<br>`--open-id` (string; required) — Exact initial.open_id from scenario list. Project configuration permission is still required.<br>`--agent-session-id` (string; required) — Exact initial.agent_session_id from scenario list.<br>`--question-id` (string; required) — Exact initial.question_id from scenario list. | [scenario_get.md](scenario_get.md) |
+| `ae-cli analysis scenario list` | analysis.scenario.list | read | `--project-id` (number; required) — Project to review. Requires project configuration permission to read collected content.<br>`--days` (number; optional) — Recent calendar days including today in the deployment timezone. Default 7; range 1..90.<br>`--limit` (number; optional) — Complete scenarios per page. Default 20; range 1..50.<br>`--offset` (number; optional) — Scenario offset. Default 0; follow meta.next_offset until meta.has_more is false.<br>`--end-time` (string; optional) — Exclusive ISO-8601 snapshot boundary. Reuse the first response meta.end_time and the same days on every subsequent page. | [scenario_list.md](scenario_list.md) |
 | `ae-cli analysis sql-table columns` | analysis.sql_table.columns | read | `--project-id` (number; required) — Numeric project ID.<br>`--table-ref` (string; required) — Exact table_ref or quoted sql_reference returned by analysis sql-table list; a unique table-only reference is also accepted.<br>`--usage` (string; optional) — Authorized table set: analysis (default), tag_cluster for SQL tags/clusters, or sql_datatable for SQL-built data tables. Use the same usage for list and columns. | [sql_table_columns.md](sql_table_columns.md) |
 | `ae-cli analysis sql-table list` | analysis.sql_table.list | read | `--project-id` (number; required) — Numeric project ID.<br>`--queries` (json; optional) — Optional JSON array of 1 to 20 keyword filters. Results match any keyword.<br>`--limit` (number; optional, min=1, max=200) — Directory page size. Default: 50, max: 200. Values outside 1..200 are rejected.<br>`--offset` (number; optional, min=0) — Zero-based directory page offset. Default: 0. Negative values are rejected.<br>`--usage` (string; optional) — Authorized table set: analysis (default), tag_cluster for SQL tags/clusters, or sql_datatable for SQL-built data tables. Use the same usage for list and columns. | [sql_table_list.md](sql_table_list.md) |
 | `ae-cli analysis user-cluster create` | analysis.user_cluster.create | write | `--project-id` (number; required) — Numeric project ID.<br>`--cluster-name` (string; required, minLength=1, maxLength=80, pattern=^[a-zA-Z][a-zA-Z0-9_]*$) — New cluster_name. Must start with a letter, contain only letters, digits, and underscores, and be at most 80 characters.<br>`--display-name` (string; required, minLength=1, maxLength=80) — Human-readable display name. Maximum: 80 characters.<br>`--definition-request` (json; required) — Semantic snake_case cluster definition. Read skills/ae-analysis/references/user_cluster_models.md; shared primitives are in audience_models.md.<br>`--authenticated-only` (boolean; optional) — Return only resources whose metadata can be resolved under the current identity.<br>`--zone-offset` (number; optional) — Optional timezone offset. UTC+8 is 8; UTC-5 is -5.<br>`--entity-id` (number; optional) — Optional entity ID. Required by ID-file create commands. | [user_cluster_create.md](user_cluster_create.md) |
@@ -204,7 +207,8 @@ This is the exhaustive command and flag inventory for the analysis skill. Read t
 | `ae-cli analysis-meta exchange rule-validate` | metadata.exchange_rule.validate | read | `--project-id` (number; required) — Numeric project ID.<br>`--payload` (json; required) — Required snake_case capability payload. Read the dedicated command reference for its semantic shape; an empty object is not a generic valid payload. | [exchange_rule_validate.md](exchange_rule_validate.md) |
 | `ae-cli analysis-meta governance-recommendation auto-review` | metadata.governance_recommendation.auto_review | write | `--project-id` (number; required) — Numeric project ID.<br>`--window-days` (number; optional, min=1, max=365) — Usage window in days for the recommendation batch. Default: 90.<br>`--limit` (number; optional, min=1, max=100) — Maximum hot dashboard evidence packages selected before automatic asset review. Omit for CLI bounded expansion over top-20/top-50/top-100; pass explicitly for a fixed diagnostic scope. | [governance_recommendation_auto_review.md](governance_recommendation_auto_review.md) |
 | `ae-cli analysis-meta governance-recommendation decisions` | metadata.governance_recommendation.decisions | read | `--project-id` (number; required) — Numeric project ID.<br>`--run-id` (string; optional) — Optional run_id filter.<br>`--limit` (number; optional, min=1, max=500) — Maximum rows returned. Default: 100. | [governance_recommendation_decisions.md](governance_recommendation_decisions.md) |
-| `ae-cli analysis-meta governance-recommendation export` | metadata.governance_recommendation.export | read | `--project-id` (number; required) — Numeric project ID.<br>`--window-days` (number; optional, min=1, max=365) — Usage window in days. Default: 90.<br>`--limit` (number; optional, min=1, max=100) — Maximum hot dashboard evidence packages selected before report and metadata expansion. Default: 20; this is not the business-topic count.<br>`--include-completed` (boolean; optional) — Whether to include completed/authenticated context in the same business topic. Default: true; set false only for pending-only review. | [governance_recommendation_export.md](governance_recommendation_export.md) |
+| `ae-cli analysis-meta governance-recommendation export` | metadata.governance_recommendation.export | read | `--project-id` (number; required) — Numeric project ID.<br>`--window-days` (number; optional, min=1, max=365) — Usage window in days. Default: 90.<br>`--limit` (number; optional, min=1, max=100) — Maximum hot dashboard evidence packages selected before report and metadata expansion. Default: 20; this is not the business-topic count.<br>`--include-completed` (boolean; optional) — Whether to include completed/authenticated context in the same business topic. Default: true; set false only for pending-only review.<br>`--track-run` (boolean; optional) — Track the complete recommendation workflow through page submission or explicit run-update. Default: false for compatibility.<br>`--run-id` (string; optional) — Continue the same tracked workflow when expanding evidence. Requires --track-run true. | [governance_recommendation_export.md](governance_recommendation_export.md) |
+| `ae-cli analysis-meta governance-recommendation run-update` | metadata.governance_recommendation.run_update | write | `--project-id` (number; required) — Numeric project ID.<br>`--run-id` (string; required) — Exact run_id returned by the tracked export.<br>`--status` (string; required) — HEARTBEAT, SUCCEEDED, FAILED or CANCELLED. Finish only after the actual workflow has ended.<br>`--reason` (string; optional) — Short non-sensitive result or failure reason; never include credentials or raw logs. | [governance_recommendation_run_update.md](governance_recommendation_run_update.md) |
 | `ae-cli analysis-meta governance-recommendation submit` | metadata.governance_recommendation.submit | write | `--project-id` (number; required) — Numeric project ID.<br>`--run-id` (string; required) — run_id returned by governance-recommendation export.<br>`--snapshot-hash` (string; optional) — Authentication snapshot hash returned by governance-recommendation export.<br>`--topic-id` (string; optional) — Optional CLI Agent business-domain ID. Dashboard-seeded evidence may submit only topic-name.<br>`--topic-name` (string; required) — CLI Agent business-domain display name.<br>`--window-days` (number; optional, min=1, max=365) — Usage window in days for server-side metric candidate re-scan. Default: 90.<br>`--limit` (number; optional, min=1, max=100) — Dashboard limit for server-side metric candidate re-scan. Default: 20.<br>`--decisions` (json; required) — Approval decisions JSON array for one CLI Agent topic. Each item uses item_type asset or metric_candidate and decision APPROVE, REJECT, or SKIP. | [governance_recommendation_submit.md](governance_recommendation_submit.md) |
 | `ae-cli analysis-meta metric create` | metadata.metric.create | write | `--project-id` (number; required) — Numeric project ID.<br>`--metric-name` (string; required) — Metric technical name, for example pay_count.<br>`--metric-desc` (string; required) — Metric display name.<br>`--metric-remark` (string; optional) — Metric remark.<br>`--model-type` (string; required) — Semantic metric model type: event or retention.<br>`--metric-events` (json; required) — One semantic event-analysis definition, or a native snake_case QP array for compatibility.<br>`--metric-params` (json; optional) — Metric params JSON object. Defaults to {} in common when omitted. | [metric_create.md](metric_create.md) |
 | `ae-cli analysis-meta metric delete` | metadata.metric.delete | high-risk-write | `--project-id` (number; required) — Numeric project ID.<br>`--metric-id` (number; required) — Metric ID. | [metric_delete.md](metric_delete.md) |

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

@@ -33,38 +33,52 @@ Input sends `project_id`, optional `window_days`, optional `limit`, and optional
 
 Output includes `schema_version`, `run_id`, `project_id`, `snapshot_hash`, `work_units`, `coverage`, `stat_scopes`, and `agent_presentation_contract`.
 
+## Tracked page-recommendation lifecycle
+
+For page-review recommendations, including sidebar, scheduled and external Agent runs, start with `export --project-id <id> --limit 20 --track-run true`. This requires the matching Common service release. A tracked export starts the project run only when the server accepts actual work; filling a prompt never starts it. Legacy exports without this optional flag retain their original behavior.
+
+- Preserve `run_id`. Expansion to top-50/top-100 must pass `--track-run true --run-id <same_run_id>`; do not start another run. The server rejects competing project runs.
+- During Agent interpretation, call `analysis-meta governance-recommendation run-update --project-id <id> --run-id <id> --status HEARTBEAT` at least every five minutes. A fifteen-minute lost lease becomes `TIMED_OUT`; do not resume an expired run.
+- Submit the final packet with `source_run_id` equal to the tracked `run_id`. Successful page submission finishes the run with its exact `batch_id` automatically.
+- An export with `run_status: SUCCEEDED` has no actionable candidates and is already complete; do not heartbeat or submit it. If later Agent filtering leaves no new recommendation, finish with `--status SUCCEEDED` and report the empty result. If interpretation fails, finish with `--status FAILED --reason <short_non_sensitive_reason>`; use `CANCELLED` only once actual execution has stopped. This command records a terminal state; it does not cancel an executing Agent.
+- Terminal states release project occupancy. Never claim success merely because export finished, and never include credentials or raw tool logs in a reason.
+- `RECOMMENDATION_RUNNING` means another run owns this project. Do not bypass it with an untracked export. Query `metadata.governance_recommendation.run_status` through capability discovery if diagnosis is needed.
+
 ## Customer/Agent Material Package Contract
 
-For page-review material preparation or inspection, continue with [independent Agent preflight](agent_review_preflight.md), including when the user requests no submission. Preserve full snapshots, not just the fields shown in a transport example; the preflight checks evidence integrity and interpretation separately.
-Generate [review priorities and classified definition comparisons](agent_review_priorities_comparisons.md) from that evidence. Export ranking and `conflict_risks` are inputs, not replacements for Agent interpretation of individual urgency and both sides of a comparison. A related asset is not automatically a conflicting definition.
+Ordinary recommendations use concise purpose, recommendation basis, core report meaning and known material risks. Page preparation or a local rehearsal uses [focused preflight](agent_review_preflight.md#focused-recommendation-review-default); recommendation-only display does not require a separate full audit. Preserve full source snapshots even when the authored explanation is short. Interpret only selected assets and their necessary grouping/dependency evidence; scripts can account for overflow without an Agent narrative for each unselected candidate.
+
+Read [priorities and definition comparisons](agent_review_priorities_comparisons.md) only for requested ranking, concrete comparison/conflict clues or an explicit full audit. Ordinary items do not need priority grades or comparison-coverage records. Export ranking and `conflict_risks` are inputs; a related asset is not automatically a conflicting definition. Unknown or unexamined conflict scope must never be reported as fully checked.
 
 - This command requires a numeric `--project-id`. If the user provides only a project name, resolve the project on the same host with `ae-cli project info list` before export.
 - `run_id`, `snapshot_hash`, and `review_material_package` are the handoff package for Agent review drafting.
 - `review_material_package` should contain candidate assets, heat evidence, source links, evidence links, dashboard/report/metadata relations, report definitions, AI-model definitions, `target_revision`, and hashes needed to draft a page review.
 - The Agent must generate the downstream `agent-review submit-to-page` draft from this package: batch `ai_summary`, `presentation_snapshot`, per-item `ai_summary` / recommendation reasons, copied `evidence_snapshot`, copied source links, and relations.
-- `work_units` are deterministic Common evidence containers. They are not the final page grouping. The Agent clusters selected assets into one or more business-domain topics and second-level groups for review.
+- `work_units` are deterministic Common evidence containers. They are not the final page grouping. The Agent clusters selected assets into business domains and business subtopics for review. Apply [Business Topics and Subtopics](agent_review_submit_to_page.md#business-topics-and-subtopics) to both levels; a source dashboard is not a default subtopic.
 - For report and SQL-report items, use `review_material_package.candidate_assets[].evidence_snapshot.analysis` first. Call `analysis-meta agent-review evidence` only when the package marks a definition/analysis gap or when validating a generated draft.
 
-## Rejection Filtering and Bounded Expansion
+<a id="rejection-filtering-and-bounded-expansion"></a>
+
+## Current Candidates and Bounded Expansion
 
-Common selects ranked shared dashboards before attaching decision state; it does not automatically replace rejected dashboards with lower-ranked ones. The Agent must apply this procedure before drafting a review:
+Manual recommendation selects assets that currently need certification, by business value and current evidence. Do not query review history to select candidates. Earlier recommendations, pending reviews, rejection or deferral do not exclude an otherwise eligible uncertified asset. Historical fields returned in the packet remain audit context; they do not define manual recommendation eligibility. Automatic certification retains its separate explicit intent and safety rules.
 
-1. Start with `--limit 20`, unless the user explicitly specifies a different scope or a diagnostic sample. Keep the same host, project, time window, and completed-context setting throughout expansion.
-2. Match each source dashboard to its asset candidate by resource identity. If its current `action_state` is `PREVIOUSLY_REJECTED`, omit the dashboard and its entire display branch: its groups, report/metadata/metric placements, and relations. Do not display that rejected dashboard as completed context or submit it again. A historical `REJECT` alone is not enough to exclude a changed definition; use Common's current same-evidence decision state. Do not treat every `actionable=false` asset as rejected: authenticated context remains useful.
-3. Rebuild the presentation from retained dashboard branches. Keep a shared report, metadata asset, or metric candidate when independently referenced by another retained dashboard, and show it only under retained branches. Deduplicate by scoped asset identity, not name. Remove orphan items, empty groups/topics, and relations to omitted items from `presentation_snapshot`; omit items supported only by removed branches from the submission. This is presentation filtering, not a cascading rejection or a certification-state change. Preserve copied source evidence unchanged.
-4. Separate pending review work from context before judging the batch. Pending review work is a returned item that still needs a reviewer decision, for example `action_state:"PENDING"` or unauthenticated `authentication_status:0`, after excluding same-evidence rejects, active deferrals, and items already in an unfinished review batch when that state is available. `AUTHENTICATED` / completed assets are context only unless the evidence shows a material definition change that requires a new decision.
-5. Assess whether the remaining pending review assets and visible business domains meet the user's requested breadth and have sufficient evidence for a useful review. If no count was requested, treat the pool as insufficient when there are fewer than about 10 pending review assets, fewer than 3 pending business domains, or the retained material is mostly authenticated context with little work for the reviewer. If insufficient and coverage indicates more dashboards exist, re-export with `--limit 50`; repeat filtering and assessment, then use `--limit 100` if still insufficient. These limits are cumulative top-N pools, not disjoint pages. Replace the previous drafting packet with the latest successful export; do not concatenate runs or mix their `run_id`, `snapshot_hash`, revisions, or evidence hashes.
-6. Apply the daily review capacity after expansion. Expansion increases business-domain coverage; it does not authorize submitting every pending asset found. Unless the user requests a different batch size, target about 20-50 pending review assets, use a hard cap around 80, and keep roughly 3-6 visible business domains. When the expanded pool is larger than the cap, rank pending assets by impact_degree, heat_count90d, user_count90d, dependency/relation breadth, and whether their business domain is under-covered. Use per-domain quotas before taking many assets from one domain.
-7. Stop when the pending review assets and business-domain breadth are sufficient, the available dashboard pool is exhausted, or the top 100 have been inspected. Do not automatically expand beyond 100. At the cap, submit only the ranked slice of genuinely eligible, evidence-supported candidates within the user's submission authorization; never revive rejected, deferred, already in-flight, or weak candidates to fill a quota. Record overflow counts and domains for later batches. If none remain, explain the result without submitting an empty batch. A failed export is an execution failure, not evidence of candidate scarcity; do not expand in response to an error or silently fall back to stale material.
-8. Build page topics only for business domains that contain at least one selected pending review asset. Retain authenticated/completed assets only as direct context needed by those selected pending items, for example source dashboards, source reports, and referenced metadata along the relation path. Do not display or submit a zero-pending business domain as standalone work, even if it has many hot authenticated assets.
+1. Start with `--limit 20`, unless the user explicitly requests another scope. Keep the same host, project, time window and completed-context setting throughout expansion.
+2. Treat current `authentication_status:0` assets as pending review work. Use current certification facts in the asset or `evidence_snapshot.asset`; do not use historical `action_state`, `actionable`, or `previous_decision` as a substitute for current certification. Unknown certification or missing definition evidence is an evidence gap, not proof of eligibility. Authenticated assets are context only.
+3. Deduplicate shared assets by full scoped identity within this packet and preserve source evidence, links and known relations. Do not remove dashboard branches because they appeared in an earlier recommendation.
+4. Assess current candidates and business breadth. If there are fewer than about 10 pending review assets or fewer than 3 pending business domains and more dashboards exist, re-export with `--limit 50`, then use `--limit 100` if still insufficient. The pools are cumulative, not pages. Replace the earlier drafting packet with the latest successful export; never mix run IDs, hashes, revisions or snapshots.
+5. Apply the daily review capacity after expansion: target about 20-50 pending review assets, hard cap around 80, across roughly 3-6 visible business domains. Rank by impact_degree, heat_count90d, user_count90d and dependency breadth. Use per-domain quotas before adding many assets from one domain.
+6. Stop when candidates and domain coverage are sufficient, the pool is exhausted, or the top 100 have been inspected. Record overflow counts and domains for later batches. Do not fill a quota with weak or unsupported candidates. An export failure is an execution failure, not evidence of scarcity; do not expand because of an error or use stale material.
+7. Build visible domains only when they contain selected pending work. Retain authenticated assets only as direct supporting context. Do not display or submit a zero-pending business domain as standalone work.
+8. Submit the current material once when authorized. A new recommendation may include previously recommended assets. Reuse the same client request key and exact payload only when replaying the same submission after a network failure; a deliberate new submission uses a new key. Read back the returned batch rather than searching old batches to change the candidate set.
 
-Report the final requested limit, actual dashboards returned, same-definition rejected dashboards excluded, active deferrals or in-flight items excluded when known, retained dashboard count, visible pending-domain count, selected pending review asset count, context asset count, overflow pending count/domain summary, and stopping reason. Explain why expansion was needed or why candidates remain insufficient. Do not describe an expanded or filtered batch as covering all of the top 20/50/100 dashboards. Keep this scope summary separate from the hidden rejected branches, zero-pending context domains, and overflow left for later batches.
+Report the final requested limit, actual dashboards returned, dashboards represented in the selected packet, visible pending-domain count, selected pending asset count, context count, overflow summary and stopping reason. Do not describe a selected slice as covering all top-N dashboards. Historical recommendation counts are not part of eligibility or the required scope report.
 
 ## Decision Rules
 
 - Use this command before presenting recommendations for certification or metrics.
 - After export, always build the business-domain review display before answering. The command output is evidence, not the response format.
-- For real review-page submission, apply Rejection Filtering and Bounded Expansion before grouping. Include eligible assets across the retained dashboard branches; do not compress them into a few representative themes or submit only the first hot dashboard or first `work_unit`. A smaller batch is valid when the evidence supports fewer eligible candidates or the user explicitly requests a sample or diagnostic batch. Explain the actual scope and omissions.
+- For real review-page submission, apply Current Candidates and Bounded Expansion before grouping. Include eligible assets across the retained dashboard branches; do not compress them into a few representative themes or submit only the first hot dashboard or first `work_unit`. A smaller batch is valid when the evidence supports fewer eligible candidates or the user explicitly requests a sample or diagnostic batch. Explain the actual scope and omissions.
 - For recurring recommendation jobs, the default reviewer workspace is pending-first: only business domains with pending review assets are visible. Authenticated/completed assets remain available as relation/context rows under those domains, but they must not create a visible topic by themselves.
 - Treat `业务主题域` as a semantic cluster over the selected dashboards, not a copy of the dashboard list. Do not create one topic per hot dashboard just because `--limit 20` returned 20 work units. Merge dashboards into the same topic when their child reports, referenced metadata, metrics, folder context, or authored notes describe the same business process. Split only when the business meaning or review decision is materially different. A result where `topic_count == selected_dashboard_count` requires explicit evidence that every selected dashboard has a distinct business domain.
 - Do not call project-semantic, project-KB, or personal-semantic-preference commands as prerequisite context for this workflow.
@@ -89,8 +103,8 @@ Each newly authored topic includes optional transport field `semantic_basis: {bu
 This is an Agent presentation contract, not a CLI flag and not a Common renderer. Use the basic fields returned by Common to produce exactly one review shape:
 
 - The top-level grouping must be `业务主题域`. Do not split the final answer into separate top-level sections such as `资产认证建议` and `推荐指标`.
-- Aggregate by `业务主题域` with each source dashboard as the core evidence package for coverage, not as the business-domain name. Infer each domain from the dashboard semantics plus the business meaning of `topic_seed`, `source_reports`, asset names, metric names, and semantic definitions. The final group name should describe the business area or process, such as payment/revenue, login/channel, retention, item economy, or lifecycle, not the backend work-unit label. This grouping is for review comprehension only; it must not reduce the retained dashboard set after rejection filtering and bounded expansion.
-- The expected page hierarchy is `业务域 -> 看板 -> 报表 -> 元数据`. Put multiple source dashboards under one topic when they belong to the same business domain. The topic is not the dashboard node; the dashboard remains a root asset row inside the topic.
+- Aggregate by `业务主题域` with each source dashboard as the core evidence package for coverage, not as the business-domain name. Infer each domain from the dashboard semantics plus the business meaning of `topic_seed`, `source_reports`, asset names, metric names, and semantic definitions. The final group name should describe the business area or process, such as payment/revenue, login/channel, retention, item economy, or lifecycle, not the backend work-unit label. This grouping is for review comprehension only; it must not reduce the retained dashboard set after current-state selection and bounded expansion.
+- The expected page hierarchy is `业务域 -> 业务小主题 -> 看板 -> 报表 -> 元数据`. Put source dashboards answering the same specific business question under one subtopic within their broader domain. Neither grouping level is the dashboard node; the dashboard remains an asset row inside a subtopic. Review one-group-per-dashboard layouts for missed business merges rather than accepting renamed dashboard containers.
 - Treat `work_units` as evidence containers, not presentation groups. One dashboard/work unit can split into multiple business domains when its child reports cover different business processes; one business domain can merge rows from multiple dashboards/work units when the evidence describes the same business process.
 - Keep each report-centered evidence chain together: the report row, metadata rows, and metric candidates introduced by that report follow the same `业务主题域`. Do not detach report metadata into a separate generic metadata group, and do not merge unrelated child-report domains only because they share one source dashboard.
 - When one source dashboard contains child reports for different business questions, create one `业务主题域` per child-report business question. Do not combine distinct report domains into a broad `A 与 B 运营`, `综合运营`, or `核心语义` group only because they share the same dashboard. The dashboard can appear as shared linked source evidence in each relevant domain.

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

@@ -0,0 +1,13 @@
+# analysis-meta governance-recommendation run-update
+
+Renew or finish the tracked recommendation started by [export](governance_recommendation_export.md#tracked-page-recommendation-lifecycle).
+
+```bash
+ae-cli analysis-meta governance-recommendation run-update --project-id <project_id> --run-id <run_id> --status HEARTBEAT
+```
+
+Capability: `metadata.governance_recommendation.run_update`. Input required flags: `--project-id`, `--run-id`, `--status`. Optional: `--reason` with a short non-sensitive reason.
+
+Use HEARTBEAT at least every five minutes during actual interpretation. SUCCEEDED without page submission means an empty successful result. Page submission automatically records the exact batch ID. FAILED and CANCELLED release occupancy; record CANCELLED only after execution has stopped. Updating state does not cancel Agent execution. The server requires the same project, actor and active run ID; a fifteen-minute lost lease ends as TIMED_OUT and cannot be revived.
+
+Do not use this command to start recommendations or bypass another run. Output returns the current project status, exact run ID and successful batch ID when present; terminal states release occupancy.

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

@@ -25,7 +25,15 @@ CLI Agent performs the main semantic precompilation: understand definitions and
 
 Use the `company-kb.mjs` wrapper below for project KB operations. It fixes scope to company, filters discovery to company results, verifies ZIP ownership before directory operations, and exits on any failed command. A company permission denial is terminal: report the server error and stop. Never create a personal KB, reuse a same-name personal KB, retry without scope, or continue to upload/schema/compile after failed creation.
 
-Resolve host and project first. Search company KBs across `compiled`, `idle`, `pending`, `compiling`, and `failed` build states with `+list --build-status <state>`. Deduplicate by identity. Prefer an exact project binding, otherwise the deterministic name `<project_name> 项目语义知识库`. If several company KBs match, ask for the exact target. Personal KBs are never candidates. If no company target exists, create one with the project binding. Do not ask the user to choose between "existing" and "new" when the target is unambiguous. Once target resolution succeeds, do not stop after local generation.
+Resolve host and project first. Use the authoritative server resolver, not the current user's visible KB list:
+
+```bash
+node <skill_dir>/scripts/project-semantic-knowledge-wiki/company-kb.mjs +resolve --project-id <project_id> --host <host>
+```
+
+The resolver considers all undeleted company KBs bound to the project across all build states, including disabled or inaccessible targets. One bound KB is reused for legacy compatibility. For several candidates, exactly one fixed `项目语义` business tag selects the target; zero tags returns `multiple/untagged`, several tags returns `multiple/tag_conflict`. With no project binding, only the exact authoritative project name `<project_name> 项目语义知识库` without another project binding is a legacy candidate, using the same tag rule. Never select by list order, modification time, or accessible subset. `restricted`, `disabled`, and `multiple` stop the workflow and require permission, activation, or tag correction; do not create or select a replacement. Query/auth/unsupported-endpoint errors are terminal; do not fall back to visible-list inference on older servers. Only `missing` permits creation. `available` supplies the exact `item.dbId` and `item.id` (slug); reuse that identity. An explicitly selected existing target or an automation's stored target ID must not be silently switched by tag changes.
+
+The wrapper's `+new` always sends `--purpose project-semantic` with a project binding. The server validates the project, rechecks the target under the KB write lock, and presets the fixed `项目语义` tag even if omitted by the caller. It preserves additional tags up to the existing total limit of two; overflow is an error, never truncation. Ordinary company KB creation outside this semantic workflow retains its current behavior. The tag is purpose classification, not an access grant; labels and names are not authority for project ownership. Once target resolution succeeds, do not stop after local generation.
 
 The KB description is part of Agent auto-loading and source selection, not a casual note. Always write a normal business-facing description that states the project, asset scope, and intended Agent use. Do not mention temporary implementation details such as ZIP, test version numbers, source-tree packaging, or local build names in the description. Use this template:
 

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

@@ -1,5 +1,7 @@
 # analysis scenario append
 
+Pass original text to `--text`; never pre-encode it. The CLI automatically sends `text` as UTF-8 Base64 with `content_encoding=base64`, for both user feedback and answer revisions and for execute, validate and dry-run. Common collects the exact decoded text. Other fields, including `--user-message`, retain their existing representation. Encoding is reversible and is not encryption. Deploy Common support first; old unmarked requests remain accepted by new Common. An older Common rejects the new marker; do not retry or fall back to plain text.
+
 Command: `ae-cli analysis scenario append`. Capability: `analysis.scenario.append`. Risk: `write`.
 
 ## Project opt-in
@@ -23,3 +25,7 @@ ae-cli analysis scenario append --question-id '<original-question-id>' \
 cli_analysis_scenario_entry links by authenticated user + agent_session_id + question_id, and target_answer_id links the actual answer. Entry deduplication uses the same scope plus entry_id. A separate evaluator determines whether the feedback is supported and whether a later revision resolves the original problem. Preserve both versions even if the latest is correct. Collection does not validate historical ID existence; unresolved links must be marked unknown by evaluation, not treated as verified associations.
 
 Output contains accepted, question_id, event_name and delivery. On unavailable capability, permission/auth failure or transport failure, continue normal answering; do not login, automatically retry or claim recording. accepted=true with delivery=best_effort is not ingestion proof. An older explicit standalone satisfaction command remains available but do not double-report the same collected-scenario feedback through it.
+
+## Answer duration
+
+For a substantive follow-up, capture a fresh local `ae-cli analysis scenario begin` when processing that follow-up starts. Pass its exact `data.start_time` as `--start-time` on answer_revision. Keep the original question_id but use the new answer_id. This measures only that answer; do not include time spent waiting for the user or add earlier answer durations. User feedback accepts no start-time or duration_ms. Omit timing when no start marker was captured.

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

@@ -0,0 +1,11 @@
+# analysis scenario begin
+
+Command: `ae-cli analysis scenario begin`. Risk: `read`. Local clock utility; no Gateway capability or network request.
+
+## Input
+
+No command-specific flags. Run once when starting this question, before analysis calls. Retain the exact returned `data.start_time` and pass it as `--start-time` to [collect](scenario_collect.md) when the answer is ready, or [append](scenario_append.md) for a new revised answer. No local file or question content is written. Do not call this for historical review or regenerate a missing earlier timestamp.
+
+## Output
+
+`data.start_time` is a timezone-qualified ISO-8601 timestamp. The collection command computes one duration_ms. It measures this marker to the prepared-answer collection, not unobserved time before the marker or confirmed UI delivery. Missing timing stays unknown. Start a fresh clock for each follow-up answer so user waiting time is excluded.

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

@@ -4,12 +4,14 @@ Command: `ae-cli analysis scenario collect`. Capability: `analysis.scenario.coll
 
 ## Project opt-in
 
-The source analysis project's `agent_analysis_scenario_collection_enabled` configuration defaults to `off`. Only explicit `on` permits scenario samples. Read its live value through `ae-cli project info get --project-id <id>` (`data.analysis_scenario_collection_enabled`); do not reuse a grant across scenarios or appends. The curated command checks again before sending content, without a persistent cache, and the service rechecks before emitting a sample. Ordinary invocation/intent logs remain unchanged.
+The source analysis project's `agent_analysis_scenario_collection_enabled` configuration defaults to `off`. Only explicit `on` permits scenario samples. Read its live value through `ae-cli project info get --project-id <id>` (`data.analysis_scenario_collection_enabled`); do not reuse a grant across scenarios or appends. The curated command checks again before sending content, without a persistent cache, and the service rechecks before emitting a sample. Ordinary invocation/intent event reporting remains unchanged; the same switch also gates the Common HDFS call archive.
 
 The optional `--project-id` flag remains accepted for compatibility, but omission skips collection (`PROJECT_REQUIRED`). Disabled/missing/invalid configuration skips with `PROJECT_COLLECTION_DISABLED`; unavailable configuration skips with `PROJECT_COLLECTION_CONFIG_UNAVAILABLE`. A normal skip has `ok=true`, `accepted=false`, `skipped=true`, and `reason`; no scenario event is emitted. A returned `event_name` identifies the sample type, not proof of emission. Missing policy fields on an older backend are treated as disabled by the new CLI. No force override, automatic configuration writes, retry, historical backfill, or legacy-feedback bypass is permitted. `--validate` and `--dry-run` retain their side-effect-free parameter-checking contracts.
 
 Read [append](scenario_append.md) for later user feedback and answer revisions. Both commands support `--validate` and `--dry-run`, which do not emit collection events.
 
+Pass the original text to `--answer`; never pre-encode it. The CLI automatically sends `answer` as UTF-8 Base64 with `content_encoding=base64` for execute, validate and dry-run. Common decodes a copy for validation and collection; encoded requests and validation responses retain the wire representation. This is reversible encoding, not encryption. Only `answer` is encoded by collect; other fields retain their existing representation. Deploy Common support before upgrading the CLI. New Common accepts legacy unmarked plain-text requests; older Common rejects the encoding marker, and the CLI never retries with plain text. On rejection, follow the existing collection-failure behavior and answer normally.
+
 ## Collection only
 
 Once a complete scenario answer is ready, collect one sample and deliver the exact captured answer. Keep the original request plus confirmed scope clarifications together in question; do not replace the original goal with the last short user message. Do not self-rate or ask for a rating. Multiple CLI data queries are one sample. Metadata/discovery/help or asset writes alone are not scenarios. An attempted failed query still qualifies when its existing call ID is available. Do not conduct extra queries just for collection.
@@ -28,8 +30,14 @@ ae-cli analysis scenario collect --question-id '<original-user-turn-id>' \
   --project-id 196
 ```
 
-The cli_analysis_scenario event has collection_source=external_agent and query_path_json containing the ordered references. Resolve them against existing cli_gateway_call events using authenticated user/session plus invocation_id or client_request_id; verify capability_id matches and report missing, ambiguous or truncated records. No new call telemetry is introduced. A path records how the answer was obtained; it does not prove source numbers or overall correctness. A separate task follows [the evaluation guide](scenario_evaluation.md).
+The cli_analysis_scenario event has collection_source=external_agent and query_path_json containing the ordered references. Use scenario get to resolve them against archived cli_gateway_call events using authenticated user/session plus invocation_id or client_request_id; verify capability_id matches and report missing, ambiguous or truncated records. The archive reuses existing gateway telemetry. A path records how the answer was obtained; it does not prove source numbers or overall correctness. A separate task follows [the evaluation guide](scenario_evaluation.md).
 
 Existing SDK trackFirst uses authenticated user/session/question as its stable key, independent of answer wording. This is downstream deduplication, not a transactional guarantee. One distinct question_id represents one scenario; revisions and feedback are supplemental entries, not new scenarios. No collection-time good/bad label exists.
 
 accepted=true, delivery=best_effort means endpoint acceptance, not confirmed ingestion. Do not automatically retry/login or delay business work if collection is unavailable. Do not claim it was saved on failure. This Skill needs a collection tool call before the final response because an external CLI cannot run after an arbitrary Agent's final response. It does not promise zero latency or token overhead.
+
+## One question-to-answer duration
+
+At the start of analysis run `ae-cli analysis scenario begin`. It only returns the local clock as `data.start_time`: no server call, file, or question content is written. Retain this exact value and pass `--start-time <value>` to collect when the answer is ready. The CLI computes `duration_ms`; never estimate it with the model or sum command costs. The boundary is the start marker to collection of the prepared answer, not confirmed UI delivery. Earlier time before the marker is not measured. Missing markers must stay missing, including old data; do not substitute zero or backfill timestamps. The timestamp must be valid, not future, and at most 90 days old.
+
+New Common accepts legacy collect/append without duration_ms. Deploy the new Common (with the new gateway dependency) before distributing the timing Skill. An older server rejects the new field; do not retry with a modified payload. Answer normally and report collection failure only when needed.

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

@@ -8,23 +8,11 @@ Evaluate the original question, confirmed clarifications, final answer and query
 
 Check whether the path addresses the requested subquestions and whether the answer covers them. A visible scope mismatch, a contradiction within the answer, or an arithmetic error using the answer's own stated operands can demonstrate a specific defect; arithmetic consistency does not prove those operands are true. A failed call does not establish that all other calls failed. A user's objection is a separate signal: preserve and assess it, never automatically treat it as proof of error or dismiss it because the path appears reasonable. When the only way to confirm or refute feedback is missing result data, its support is unknown.
 
-Use verdicts correct, partial, incorrect, unknown. incorrect requires a demonstrable defect relevant to the scenario. partial means a demonstrable substantive omission or unresolved subquestion, even when honestly acknowledged. correct requires adequate support for the actual requested outcome; a plausible path alone cannot establish a numeric analysis answer as correct. unknown means the available path/answer/feedback cannot establish correctness. Do not turn path compliance into an overall success label. A later revision never erases an earlier defect or the original goal. Label each answer independently, then give the latest verdict.
-
-For each question return:
-
-```json
-{
-  "question_id": "<source id>",
-  "answers": [{
-    "answer_id": "<source answer id>",
-    "verdict": "correct|partial|incorrect|unknown",
-    "reason": "Short source-supported explanation",
-    "limitations": ["What cannot be verified from available path and call records"],
-    "evidence_refs": ["<answer/path-step/call-record/entry IDs or precise source paths>"],
-    "user_feedback": [{"entry_id":"<source entry id>","support":"supported|unsupported|unknown","reason":"Source-supported explanation"}]
-  }],
-  "latest_verdict": "correct|partial|incorrect|unknown"
-}
-```
+Assess answers as correct, incomplete, wrong, or unverifiable internally. A wrong answer requires a demonstrable defect relevant to the scenario. An incomplete answer has a demonstrable substantive omission or unresolved subquestion, even when honestly acknowledged. A correct answer requires adequate support for the actual requested outcome; a plausible path alone cannot establish a numeric analysis answer as correct. Unverifiable means the available path/answer/feedback cannot establish correctness. Do not turn path compliance into an overall success label. A later revision never erases an earlier defect or the original goal. Judge each answer against the confirmed requirements at that point; a newly added requirement is not retroactively an omission.
+
+For project archive review, follow [scenario list](scenario_list.md) for pagination, semantic deduplication and compact output. Include wrong and substantively incomplete answers as badcases. For Chinese output, label them "回答有误" and "回答不完整". Every badcase needs a concrete reason integrating the necessary source evidence, such as the contradictory numbers or the requested-but-missing subquestion. Keep answer/entry IDs and feedback-support checks internally for traceability, rather than dumping them into the final answer. Do not output internal verdict codes, a separate evidence list, raw JSON, or the latest/fixed status. Group repeated questions/defects with distinct-scenario occurrence counts. Briefly count unverifiable scenarios separately; never treat them as confirmed badcases or proven correct answers.
 
 These are independent model judgments, not certified ground truth. Keep evaluations separate from immutable collection; human review can calibrate them. When samples are supplied as local files, read only those files, supplied call records and this guide, never hidden fixtures, test expectations or the collector's private reasoning.
+
+
+Use [scenario list and detail](scenario_list.md#answer-duration-and-cli-execution-detail) when inspecting execution evidence. Add the measured question-to-answer duration to the concise review when available; otherwise state it was not collected. Use call evidence to explain a relevant execution error, but do not infer numeric answer correctness from a successful call or treat every transient failed attempt as a badcase. Preserve each occurrence's timing and invocation provenance when grouping.

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

@@ -0,0 +1,15 @@
+# analysis scenario get
+
+Command: `ae-cli analysis scenario get`. Capability: `analysis.scenario.get`. Risk: `read`.
+
+## Input
+
+Required `--project-id`, `--open-id`, `--agent-session-id`, `--question-id`: copy the exact identity from a scenario list initial record. Requires project configuration permission, even when open-id names another user. Optional `--days` defaults to 7 (1..90); `--end-time` is the exclusive snapshot boundary. Reuse the list's days, exact end_time and explicit `--host`.
+
+## Output
+
+Returns `initial`, `entries`, `conflicting_records`, and `call_archive`. Answers include optional duration_ms plus calls and call_summary. See [execution evidence and presentation rules](scenario_list.md#answer-duration-and-cli-execution-detail). Missing or ambiguous references do not mean success. Async submission status and final execution_status are different. Parameters are sanitized and may be truncated; full result rows are not archived.
+
+## Errors
+
+Missing identity is rejected. SCENARIO_NOT_FOUND means no matching archived scenario in the chosen window, not no activity. Permission, I/O and scan-limit errors must be surfaced. Never switch company/project or use an unrestricted path to bypass a failure. validate/dry-run check input and access without scanning HDFS. This command requires the upgraded Common service; older services may report capability unavailable.