@thinkingai/ae-cli 6.1.28 → 6.1.30

package/dist/{te-system-IE7NCKC3.js → te-system-CYWSK3UN.js}

@@ -1,8 +1,8 @@
 import { createRequire as __createRequire } from 'node:module'; const require = __createRequire(import.meta.url);
 import {
   require_archiver
-} from "./chunk-QSAR3GHY.js";
-import "./chunk-T44M3PLZ.js";
+} from "./chunk-OAWPT7VP.js";
+import "./chunk-JEUXDY3B.js";
 import {
   TeAgentApiError,
   deleteFromMainApp,
@@ -12,19 +12,19 @@ import {
   postToMainApp,
   putToMainApp,
   uploadToMainApp
-} from "./chunk-2UWS5CUP.js";
+} from "./chunk-JSBLCLFE.js";
 import "./chunk-Y74WTIKJ.js";
-import "./chunk-P7KL7IOH.js";
+import "./chunk-SOSFRU3O.js";
 import {
   isAeSandboxRuntime,
   readSandboxCliTokenEntry,
   safeJsonParse
-} from "./chunk-LMCYSVVA.js";
+} from "./chunk-4PSTYEG5.js";
 import {
   CliValidationError,
   PermissionError,
   __toESM
-} from "./chunk-ZW4VMY5H.js";
+} from "./chunk-Z3Q2AEIN.js";
 
 // src/commands/te-system/shared.ts
 import { readFileSync } from "fs";

package/dist/{te-team-MGQ5CNRW.js → te-team-ISN52YNG.js}

@@ -2,19 +2,20 @@ import { createRequire as __createRequire } from 'node:module'; const require =
 import {
   getAuthHeaders,
   kbApi
-} from "./chunk-GTPWDLTE.js";
-import "./chunk-QW3R6O7L.js";
+} from "./chunk-TFORY6WY.js";
 import {
   printError,
   printOutput
-} from "./chunk-ELCR235M.js";
+} from "./chunk-YULUBP3R.js";
+import "./chunk-HRUOV6EQ.js";
 import "./chunk-Y74WTIKJ.js";
-import "./chunk-P7KL7IOH.js";
-import "./chunk-LMCYSVVA.js";
+import "./chunk-CG773QXN.js";
+import "./chunk-SOSFRU3O.js";
+import "./chunk-4PSTYEG5.js";
 import {
   externalCliTokenRequestOptions,
   redactExternalCliToken
-} from "./chunk-ZW4VMY5H.js";
+} from "./chunk-Z3Q2AEIN.js";
 
 // src/commands/te-team/shared.ts
 var API_PREFIX = process.env.AE_API_PREFIX ?? "/agent";

package/dist/{things-4JIBCA55.js → things-DDQ52Z3Q.js}

@@ -1,20 +1,20 @@
 import { createRequire as __createRequire } from 'node:module'; const require = __createRequire(import.meta.url);
 import {
   resolveMemoryApiBaseUrl
-} from "./chunk-GI5BMEZO.js";
-import "./chunk-JJJIP2XQ.js";
-import "./chunk-2UWS5CUP.js";
+} from "./chunk-AWVZTN2B.js";
+import "./chunk-VDICGXCY.js";
+import "./chunk-JSBLCLFE.js";
 import {
   CapabilityGatewayError,
   buildCapabilityGatewayUrl,
   callCapabilityApi
-} from "./chunk-QW3R6O7L.js";
+} from "./chunk-HRUOV6EQ.js";
 import "./chunk-Y74WTIKJ.js";
-import "./chunk-P7KL7IOH.js";
-import "./chunk-LMCYSVVA.js";
+import "./chunk-SOSFRU3O.js";
+import "./chunk-4PSTYEG5.js";
 import {
   PermissionError
-} from "./chunk-ZW4VMY5H.js";
+} from "./chunk-Z3Q2AEIN.js";
 
 // src/commands/things/parity-actions.ts
 import { readFileSync } from "fs";

package/dist/{update-AX66IFMJ.js → update-CTLNTX35.js}

@@ -2,6 +2,10 @@ import { createRequire as __createRequire } from 'node:module'; const require =
 import {
   missingAeHostHint
 } from "./chunk-6ZIQV5GW.js";
+import {
+  printError,
+  printOutput
+} from "./chunk-YULUBP3R.js";
 import {
   buildVersionInstallPlan,
   exactVersion,
@@ -11,17 +15,16 @@ import {
   getLocalCliPackageInfo,
   installHost,
   installVersion,
-  printError,
-  printOutput,
-  recordVersionSyncResult
-} from "./chunk-ELCR235M.js";
+  recordVersionSyncResult,
+  rememberBusinessConfig
+} from "./chunk-CG773QXN.js";
 import {
   peekCliToken
-} from "./chunk-P7KL7IOH.js";
+} from "./chunk-SOSFRU3O.js";
 import {
   getActiveHost
-} from "./chunk-LMCYSVVA.js";
-import "./chunk-ZW4VMY5H.js";
+} from "./chunk-4PSTYEG5.js";
+import "./chunk-Z3Q2AEIN.js";
 
 // src/commands/update.ts
 var HOST_OPTION_DESC = "Override active AE host URL (e.g., https://ta.thinkingdata.cn)";
@@ -90,6 +93,7 @@ async function resolveTargetVersion(program, opts) {
   const token = peekCliToken(host);
   if (token) {
     const remote = await fetchCliConfig(host, token);
+    if (remote) rememberBusinessConfig(host, token, remote.businesses);
     if (remote?.aeCliVersion) {
       return validateTarget(remote.aeCliVersion);
     }

package/dist/{workspace-Q5NMEKEN.js → workspace-2CKQX2XL.js}

@@ -13,18 +13,18 @@ import {
   workspaceResourcePath,
   workspaceTargetFlags,
   workspaceTargetPath
-} from "./chunk-UUD5RB36.js";
+} from "./chunk-E25OSZLJ.js";
 import "./chunk-RK6GLDGI.js";
 import {
   getAgentBuffer
-} from "./chunk-JJJIP2XQ.js";
-import "./chunk-2UWS5CUP.js";
+} from "./chunk-VDICGXCY.js";
+import "./chunk-JSBLCLFE.js";
 import "./chunk-Y74WTIKJ.js";
-import "./chunk-P7KL7IOH.js";
-import "./chunk-LMCYSVVA.js";
+import "./chunk-SOSFRU3O.js";
+import "./chunk-4PSTYEG5.js";
 import {
   CliValidationError
-} from "./chunk-ZW4VMY5H.js";
+} from "./chunk-Z3Q2AEIN.js";
 
 // src/commands/workspace/shared.ts
 var WORKSPACE_SERVICE = "workspace";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@thinkingai/ae-cli",
-  "version": "6.1.28",
+  "version": "6.1.30",
   "description": "CLI tool for ThinkingAI (AE) analytics platform",
   "type": "module",
   "bin": {
@@ -55,7 +55,7 @@
     "verify:resource-package": "node --import tsx tests/resource-package-command.test.ts && node --import tsx tests/resource-package-cli.test.ts && node --import tsx tests/resource-package-transfer.test.ts && node --import tsx tests/resource-package-skill.test.ts",
     "verify:agent-context": "tsx tests/agent-context-command.test.ts",
     "verify:cli-agent-model-context": "tsx --test tests/cli-agent-model-context.test.ts",
-    "verify:analysis-scenario": "tsx --test tests/analysis-scenario-command.test.ts",
+    "verify:analysis-scenario": "tsx --test tests/analysis-scenario-command.test.ts tests/analysis-scenario-list-command.test.ts",
     "verify:analysis-feedback": "tsx --test tests/analysis-feedback-command.test.ts",
     "verify:agent-distribution": "tsx tests/agent-distribution-command.test.ts && tsx tests/agent-distribution-skill.test.ts",
     "verify:approval": "tsx tests/approval-command.test.ts && tsx tests/approval-cli-client.test.ts && tsx tests/approval-skill.test.ts",
@@ -72,10 +72,10 @@
     "verify:page-context": "node --test test/page-context-skill.test.mjs test/page-context-references.test.mjs test/internal-skill-distribution.test.mjs",
     "verify:skill-migration": "node --test test/ae-migrate-tracking-code/migration-regression.test.mjs test/ae-migrate-tracking-code/ir-golden-consistency.test.mjs test/ae-migrate-tracking-code/migrated-signatures.test.mjs",
     "verify:skill-migration-e2e": "node test/ae-migrate-tracking-code/e2e/diff.mjs",
-    "verify:tracking-tools": "tsx test/tracking-client.test.mjs && tsx test/tracking-skill-flow.test.mjs && node test/tracking-commands.test.mjs && tsx tests/tracking-display-name-sync.test.ts && tsx tests/local-data-inspect-convert.test.ts && tsx tests/local-data-upload-client.test.ts && tsx tests/local-data-upload-command.test.ts && tsx tests/local-data-encoding-sniff.test.ts && tsx tests/local-data-time-formats.test.ts && tsx tests/local-data-xlsx-dates.test.ts && tsx tests/local-data-xlsx-hidden-sheets.test.ts && tsx tests/local-data-xlsx-formulas.test.ts && tsx tests/local-data-title-rows.test.ts && tsx tests/local-data-xlsx-merged-cells.test.ts && tsx tests/local-data-xlsx-shared-strings.test.ts && tsx tests/local-data-xlsx-namespace-prefix.test.ts && tsx tests/local-data-value-distribution.test.ts && tsx tests/local-data-summary-rows.test.ts && tsx tests/local-data-duplicate-keys.test.ts && tsx tests/local-data-row-balance.test.ts && tsx tests/local-data-eight-types.test.ts && tsx tests/local-data-mapping-extras.test.ts && tsx tests/local-data-plan.test.ts && tsx tests/local-data-handoff.test.ts && tsx tests/local-data-reuse.test.ts && tsx tests/local-data-conflicts-resolutions.test.ts && tsx tests/runner-variadic-flags.test.ts && node test/local-data-skill.test.mjs",
+    "verify:tracking-tools": "tsx test/tracking-client.test.mjs && tsx test/tracking-skill-flow.test.mjs && node test/tracking-commands.test.mjs && tsx tests/tracking-display-name-sync.test.ts && tsx tests/local-data-inspect-convert.test.ts && tsx tests/local-data-upload-client.test.ts && tsx tests/local-data-upload-command.test.ts && tsx tests/local-data-encoding-sniff.test.ts && tsx tests/local-data-time-formats.test.ts && tsx tests/local-data-xlsx-dates.test.ts && tsx tests/local-data-xlsx-hidden-sheets.test.ts && tsx tests/local-data-xlsx-formulas.test.ts && tsx tests/local-data-title-rows.test.ts && tsx tests/local-data-xlsx-merged-cells.test.ts && tsx tests/local-data-xlsx-shared-strings.test.ts && tsx tests/local-data-xlsx-namespace-prefix.test.ts && tsx tests/local-data-value-distribution.test.ts && tsx tests/local-data-summary-rows.test.ts && tsx tests/local-data-duplicate-keys.test.ts && tsx tests/local-data-row-balance.test.ts && tsx tests/local-data-eight-types.test.ts && tsx tests/local-data-mapping-extras.test.ts && tsx tests/local-data-plan.test.ts && tsx tests/local-data-handoff.test.ts && tsx tests/local-data-reuse.test.ts && tsx tests/local-data-conflicts-resolutions.test.ts && tsx tests/local-data-parquet.test.ts && tsx tests/runner-variadic-flags.test.ts && node test/local-data-skill.test.mjs",
     "verify:self-check-overlay": "node test/self-check-overlay.test.mjs",
-    "verify:update-check": "tsx tests/compat-check.test.ts && tsx test/update-check.test.mjs",
-    "verify:version-sync": "npx tsx tests/version-sync.test.ts && node --import tsx --test tests/compat-check-autosync.test.ts",
+    "verify:update-check": "tsx tests/compat-check.test.ts && tsx test/update-check.test.mjs && node --import tsx --test tests/cli-config-transport.test.ts",
+    "verify:version-sync": "npx tsx tests/version-sync.test.ts && node --import tsx --test tests/compat-check-autosync.test.ts tests/resume-command.test.ts",
     "verify:auth-credentials": "npx tsx tests/secure-store.test.ts && npx tsx tests/secure-store-environment.test.ts && npx tsx tests/cli-token-validation.test.ts && npx tsx tests/auth-multi-account.test.ts && npx tsx tests/mcp-no-disk.test.ts && npx tsx tests/external-cli-token.test.ts && node --import tsx --test tests/secure-store-windows-lock.test.ts",
     "verify:readme": "node --test test/readme-command-surface.test.mjs",
     "verify:dependency-hygiene": "node --test test/dependency-hygiene.test.mjs",
@@ -91,9 +91,16 @@
     "verify:kb-versions": "tsx test/kb-version-management-command.test.mjs",
     "verify:automation": "tsx tests/automation-command.test.ts",
     "verify:project-kb-schema": "tsx --test test/kb-schema-import-command.test.mjs && node --test test/project-semantic-compile-schema.test.mjs test/project-semantic-empty-skeleton.test.mjs test/project-semantic-execution-contract.test.mjs test/project-semantic-fidelity.test.mjs && node test/project-semantic-knowledge-wiki-reference.test.mjs",
-    "verify:install": "tsx --test tests/installation.test.ts && node --test test/install-entrypoint.test.mjs",
+    "verify:install": "tsx --test tests/installation.test.ts && node --test test/install-entrypoint.test.mjs test/runtime-capabilities-entrypoint.test.mjs",
+    "verify:optional-agent": "tsx --test tests/login-device-flow.test.ts tests/auth-device-command.test.ts tests/agent-business-transport.test.ts",
+    "verify:business-skills": "node --import tsx --test tests/business-skill-sync.test.ts",
+    "verify:skill-businesses": "node --test test/release-gate-skill-businesses.test.mjs",
     "verify:notifications": "tsx tests/notification-command.test.ts",
-    "verify:optional-agent": "tsx --test tests/login-device-flow.test.ts tests/auth-device-command.test.ts tests/agent-business-transport.test.ts"
+    "verify:mcp-int64-request": "npx tsx tests/mcp-int64-request.test.ts",
+    "verify:capability-api": "npx tsx tests/capability-api.test.ts",
+    "verify:community-ux": "npm run build && npx tsx tests/community-ux.test.ts",
+    "verify:community-evidence": "node --import tsx tests/community-evidence.test.ts",
+    "verify:businesses": "node --import tsx --test tests/business-config.test.ts tests/business-command-filter.test.ts tests/business-cli.test.ts tests/environment-refresh.test.ts tests/business-sandbox-boundary.test.ts"
   },
   "repository": {
     "type": "git",
@@ -111,6 +118,7 @@
   },
   "dependencies": {
     "@types/json-bigint": "^1.0.4",
+    "apache-arrow": "^21.2.0",
     "cli-table3": "^0.6.5",
     "commander": "^12.1.0",
     "cross-spawn": "7.0.6",
@@ -119,7 +127,9 @@
     "jq-wasm": "^3.0.0-jq-1.8.2",
     "jschardet": "^3.1.4",
     "json-bigint": "^1.0.0",
+    "parquet-wasm": "^0.9.0",
     "saxes": "^6.0.0",
+    "skills": "1.5.12",
     "stream-json": "3.6.0",
     "turndown": "^7.2.4",
     "undici": "6.28.1",

package/skills/ae-agent/references/resource-package.md

@@ -51,3 +51,7 @@ Current transport: CLI-token REST `/api/resource-packages/**`
 Gateway target: TBD
 Review after: 2027-01-16
 Exit condition: equivalent stable Gateway capabilities cover task control and the upload/download workflow; retain CLI orchestration and compatibility for published commands.
+
+## Knowledge base export view
+
+`resource-package export` accepts `--view working|published` (default `working`). Working exports include editable sources and schema without stale generated wiki. Published exports require a verifiable formal snapshot and use its matching source metadata; retries retain the same frozen version and dependency closure. A missing formal version fails explicitly. Editable imported KBs have pending sources and no formal version until compilation/publication completes. See [KB publication](../../ae-kb/references/publication.md).

package/skills/ae-analysis/SKILL.md

@@ -1,12 +1,16 @@
 ---
 name: ae-analysis
-version: 4.2.42
-description: "Use ae-cli for AE analysis-side data questions, asset operations, and asset governance: reports, analysis boards, BI dashboards, ad-hoc models, drilldown, detail data, alerts, clusters, tags, metrics, metadata discovery, project configuration, tracking plans, local input-file upload, governance asset lists/rules/lineage/impact/dependency, batch asset operations, projects, and resource links. Use when the user asks to query data, explain a change, export evidence, inspect/create/update/govern analysis assets, recommend project assets for certification/authentication, review asset-certification recommendations, review metric recommendations, or build/update/refresh/sync a project semantic knowledge base from a governed asset package."
+version: 4.2.52
+description: "Use ae-cli for AE analysis-side data questions, asset operations, and asset governance: reports, analysis boards, BI dashboards, ad-hoc models, drilldown, detail data, alerts, clusters, tags, metrics, metadata discovery, project configuration, tracking plans, local input-file upload, governance asset lists/rules/lineage/impact/dependency, batch asset operations, projects, and resource links. Use when the user asks to review collected analysis questions or badcases, query data, explain a change, export evidence, inspect/create/update/govern analysis assets, recommend project assets for certification/authentication, review asset-certification recommendations, review metric recommendations, or build/update/refresh/sync a project semantic knowledge base from a governed asset package."
 ---
 
 # ae-analysis
 
-This is the single entry skill for analysis intent and command execution.
+This is the single entry skill for analysis intent and command execution, including review and semantic deduplication of collected analysis questions and evidence-based badcase assessment.
+
+At the beginning of a new analysis question, capture `ae-cli analysis scenario begin` locally and retain its exact `data.start_time` for that answer. Pass it as `--start-time` only when the project permits collection. Do not invent a start time or reuse it for a later revised answer; capture a fresh start for that follow-up. This records one question-to-answer elapsed duration, not separate timing phases. Historical archive review does not start or collect a scenario.
+
+For historical analysis-question inventory or badcase review, route directly to [scenario list and review](references/scenario_list.md), and for quality assessment read [independent scenario evaluation](references/scenario_evaluation.md). This is a separate archive-review task: skip business-query semantic/KB/personal-preference preflight and do not collect the review itself as another analysis scenario. The CLI retrieves evidence; the calling Agent judges and deduplicates it. No server-side rating or evaluation writeback is required.
 
 ## Capability contract
 
@@ -39,9 +43,9 @@ For data queries:
 3. Correct compiler errors at their reported paths. New evidence or a user correction changes a completed choice; preserve the other verified inputs.
 4. Use the returned result directly. Save original JSON only when the user requests a file or necessary local processing requires one; follow [result handling](references/analysis_data_retrieval.md#preserve-and-interpret-results). Keep stderr and the CLI exit status visible.
 5. Compute only missing values needed by the request, together in one local call. Reuse completed results and answer when the requested data is available, or explain the specific error or missing input.
-6. Scenario collection is project opt-in. Before preparing or uploading a scenario sample, read `ae-cli project info get --project-id <source_project_id>` for the current host, authenticated account, and source analysis project. Only `data.analysis_scenario_collection_enabled === true` permits collection. Recheck for each new scenario and before appending feedback or a revision; do not reuse a previous grant or the company configuration's 24-hour cache. A missing field (including older services), false, unreadable configuration, or unknown project means skip collection and answer normally. Never enable the project switch, choose a different project, or invent a project ID to make collection succeed. The curated collect/append commands also check immediately before submission, and the service is authoritative if the switch changes. This controls only scenario samples; existing invocation and intent logs stay unchanged. `accepted=false, skipped=true` is a normal skip, not a failed analysis or successful upload. Do not retry, backfill, or fall back to `analysis feedback submit` to bypass this switch.
+6. Scenario collection is project opt-in. Before preparing or uploading a scenario sample, read `ae-cli project info get --project-id <source_project_id>` for the current host, authenticated account, and source analysis project. Only `data.analysis_scenario_collection_enabled === true` permits collection. Recheck for each new scenario and before appending feedback or a revision; do not reuse a previous grant or the company configuration's 24-hour cache. A missing field (including older services), false, unreadable configuration, or unknown project means skip collection and answer normally. Never enable the project switch, choose a different project, or invent a project ID to make collection succeed. The curated collect/append commands also check immediately before submission, and the service is authoritative if the switch changes. This controls scenario samples and the related Common gateway HDFS call archive; existing invocation and intent event reporting stays unchanged. `accepted=false, skipped=true` is a normal skip, not a failed analysis or successful upload. Do not retry, backfill, or fall back to `analysis feedback submit` to bypass this switch.
 
-   Collect one sample for the whole user scenario, not one per CLI call. After forming the final answer, use `ae-cli analysis scenario collect` as specified in [scenario collection](references/scenario_collect.md), then deliver that exact answer text. Capture the original question/confirmed clarifications, actual final answer and the ordered query path (existing capability/call IDs and optional short purpose; prefer only meta.invocation_id, never confuse a business request_id with gateway client_request_id), never query result rows or error payloads; do not score correctness or generate a separate self-evaluation. The question_id is the original scenario's first user turn ID, stable across clarification, retries, multiple queries and corrections. Store/reuse the IDs returned by collection in conversation context. On later user objections, scope corrections or reported omissions targeting that answer, append the user's original text with `ae-cli analysis scenario append --entry-type user_feedback` and the original question_id/target_answer_id; do not decide whether the user is right. An ambiguous request for an explanation may be preserved as user text when clearly linked; do not invent a link. A normal follow-up or changed requirement is not automatically negative feedback. After a substantive follow-up answer to the same scenario (recheck, explanation, correction or scope clarification), append answer_revision with that exact answer/query path and a new answer_id, even when the conclusion stays the same; keep earlier answers. If the triggering user request was not already captured as user_feedback, include its exact text using --user-message on answer_revision so later scope changes are not lost. Do not duplicate feedback text in user_message. Acknowledgments such as thanks alone need no entry. A genuinely separate question gets a new question_id. Do not create another initial sample for an existing scenario. A separate evaluation task reads these samples later and can join existing call telemetry for parameters/status/timing. Path-only evidence cannot prove numeric answer correctness; unresolved correctness stays unknown. Only attempted analysis data queries qualify; metadata, discovery, help and asset writes alone do not. No routine satisfaction question. Collection failure must not block the answer or subsequent business work, trigger login or automatic retries, or be claimed as successful ingestion. For external Agents this is a Skill collection step, not a guaranteed post-answer hook; it has one collection tool call but no additional evaluation task on the answering path.
+   Collect one sample for the whole user scenario, not one per CLI call. After forming the final answer, use `ae-cli analysis scenario collect` as specified in [scenario collection](references/scenario_collect.md), then deliver that exact answer text. Capture the original question/confirmed clarifications, actual final answer and the ordered query path (existing capability/call IDs and optional short purpose; prefer only meta.invocation_id, never confuse a business request_id with gateway client_request_id), never query result rows or error payloads; do not score correctness or generate a separate self-evaluation. The question_id is the original scenario's first user turn ID, stable across clarification, retries, multiple queries and corrections. Store/reuse the IDs returned by collection in conversation context. On later user objections, scope corrections or reported omissions targeting that answer, append the user's original text with `ae-cli analysis scenario append --entry-type user_feedback` and the original question_id/target_answer_id; do not decide whether the user is right. An ambiguous request for an explanation may be preserved as user text when clearly linked; do not invent a link. A normal follow-up or changed requirement is not automatically negative feedback. After a substantive follow-up answer to the same scenario (recheck, explanation, correction or scope clarification), append answer_revision with that exact answer/query path and a new answer_id, even when the conclusion stays the same; keep earlier answers. If the triggering user request was not already captured as user_feedback, include its exact text using --user-message on answer_revision so later scope changes are not lost. Do not duplicate feedback text in user_message. Acknowledgments such as thanks alone need no entry. A genuinely separate question gets a new question_id. Do not create another initial sample for an existing scenario. A separate evaluation task reads these samples later and can join existing call telemetry for parameters/status/timing. Path-only evidence cannot prove numeric answer correctness; unresolved correctness stays unknown. Only attempted analysis data queries qualify; metadata, discovery, help and asset writes alone do not. No routine satisfaction question. Collection failure must not block the answer or subsequent business work, trigger login or automatic retries, or be claimed as successful ingestion. For external Agents this is a Skill collection step, not a guaranteed post-answer hook; it has a local clock capture plus the collection tool call, with no additional evaluation task on the answering path.
 
 User feedback is evidence, not a correctness label. Preserve exact user words and their target answer even if you disagree. Do not routinely ask for a satisfaction rating. The existing `analysis feedback submit` contract remains available for explicit standalone user ratings without a collected scenario; when a scenario exists, use its append command instead of submitting duplicate feedback. No explicit feedback means no submission or new feedback event for `cli_analysis_feedback`. Do not upload the analysis answer through that legacy feedback command. All collection excludes credentials, full transcripts and private reasoning.
 
@@ -50,7 +54,7 @@ User feedback is evidence, not a correctness label. Preserve exact user words an
 ## Route before reading
 
 1. Map the request to a command family before opening any reference.
-   - CLI Agent asset-authentication and metric-recommendation review: this includes requests to recommend project assets for certification/authentication, review asset-certification candidates, review project asset-governance recommendations, review recommended metrics, or explicitly auto-review/auto-certify recommended assets. Open `references/governance_recommendation_export.md` and route to `analysis-meta governance-recommendation export|submit|auto-review|decisions`. For review-page submission, open `references/agent_review_submit_to_page.md` and use `analysis-meta agent-review submit-to-page|list|detail|records|review|retry`. Do not load project semantics, project KB, or personal semantic preferences as a preflight.
+   - CLI Agent asset-authentication and metric-recommendation review: this includes requests to recommend project assets for certification/authentication, review asset-certification candidates, review project asset-governance recommendations, review recommended metrics, or explicitly auto-review/auto-certify recommended assets. Open `references/governance_recommendation_export.md` and route to `analysis-meta governance-recommendation export|submit|auto-review|decisions`. For review-page submission, open `references/agent_review_submit_to_page.md` and use `analysis-meta agent-review submit-to-page|list|detail|records|review|retry`. Apply its Business Topics and Subtopics contract: both levels require business interpretation and independent review; a source dashboard is an evidence container, not a default second-level group. Do not load project semantics, project KB, or personal semantic preferences as a preflight.
    - Project semantic knowledge-base build/update/refresh/sync: open `references/project_semantic_knowledge_wiki.md` and route to `project-semantic asset-package export`, local semantic planning, and local Wiki rendering. Default to CLI semantic precompilation into Markdown sources, source ZIP upload, formal preset initialization/reuse, and KB compilation. Do not regenerate Schema or AI-validate unchanged presets during normal refresh. Update changed source files and use incremental compilation on ordinary refresh; a navigation taxonomy version change requires the full migration rebuild reported by the source-tree packager. Never substitute read-only snapshot import. Stop on company permission denial. This is a command-reference workflow inside `ae-analysis`, not a standalone project semantic Skill.
    - Known family: open only its dedicated reference. For example, a retention request goes directly to `references/adhoc_run.md`, the common `references/ai_models.md`, and `references/ai_models/retention.md`.
    - Unknown family: search [`references/command_index.md`](references/command_index.md) with `rg` or an equivalent text-search tool and keep only the matching rows. `command_index.md` is a search-only fallback; never open it with a whole-file read or print the entire file.
@@ -98,9 +102,9 @@ For CLI Agent asset-authentication and metric-recommendation review, route to `a
 
 Start a recommendation with `governance-recommendation export` before lengthy Agent analysis so Common can atomically mark the project as running. Later exports in the same Agent turn may expand the candidate pool. If Common returns `RECOMMENDATION_RUNNING`, stop this attempt and report that a recommendation is already in progress; do not retry with another Agent context or bypass the marker. Successful page submission and automatic review release the marker; recommendation-only or failed Agent runs rely on the fixed expiry. No separate start or finish CLI command is required.
 
-After presenting recommendations, the Agent may ask whether to submit them to the review page. A user choice to submit authorizes `analysis-meta agent-review submit-to-page` only; it does not authorize approval, certification, config checking, or `governance-recommendation auto-review`. If the user declines, do not write or repeatedly suggest submission. Existing explicit submission authorization remains valid and does not need another prompt. A preauthorized unattended task may submit review proposals only; it must never call `agent-review review|retry`, legacy `governance-recommendation submit`, `governance-recommendation auto-review`, or direct certification/metric mutations automatically. Use `agent-review list|detail|records` and the task's persisted proposal fingerprint to reuse prior batches. Do not resubmit or send repeated notifications for unchanged proposals, pending reviews, completed items, or previously declined suggestions. A new run ID alone is not new evidence. Report the returned `review_url` once and remain quiet until there is a meaningful change or required user action. See `references/agent_review_submit_to_page.md` for stable request keys and packet rules.
+After presenting recommendations, the Agent may ask whether to submit them to the review page. A user choice to submit authorizes `analysis-meta agent-review submit-to-page` only; it does not authorize approval, certification, config checking, or `governance-recommendation auto-review`. If the user declines, do not write or repeatedly suggest submission. Existing explicit submission authorization remains valid and does not need another prompt. A preauthorized unattended task may submit review proposals only; it must never call `agent-review review|retry`, legacy `governance-recommendation submit`, `governance-recommendation auto-review`, or direct certification/metric mutations automatically. Do not query review history to select candidates. Select currently uncertified assets by business value and evidence, regardless of earlier recommendations or review decisions. Keep stable request keys only for network replay of the same submission; a new authorized recommendation may include previously recommended assets. Read the returned batch detail to verify submission. See `references/agent_review_submit_to_page.md` for request keys and packet rules.
 
-Report review details must explain calculation logic and statistical measures, not only business purpose. Follow resolve/export -> material-package completeness check -> gap-only `analysis-meta agent-review evidence` or `analysis report get` -> chunked AI explanation -> independent preflight -> authorized submit-to-page -> detail readback. LOCAL_ONLY stops at the local preflight result. `governance-recommendation export` is expected to include report `evidence_snapshot.analysis` and `target_revision` in `review_material_package.candidate_assets`; do not ask the customer to run `analysis report get` for every report when those fields are present. Fetch `agent-review evidence` only when a report item lacks current analysis, when validating a generated draft, or when the material package explicitly marks a definition gap. Read `references/agent_review_evidence.md` for stable analysis fields and their limits. Populate `item.ai_summary.analysis_explanation` with evidence-backed measures, dimensions, calculations, filters, time_scope, and query_columns as applicable; interpret each supported SQL projection column separately. Reference only actual fact-supporting response paths rooted at `evidence_snapshot.analysis`; `source_path` is provenance, not an automatic evidence_refs substitution. Preserve server facts separately from AI interpretation and explicitly identify null, missing, dynamic or unparsed evidence. For DYNAMIC SQL, label supported sql.raw/normalized_definition.params discussion as original-text interpretation, never fabricate select_columns or runtime substitutions. Common create stores the submitted packet; it does not fill missing calculation explanations for the Agent. Before calling `submit-to-page`, check required `evidence_snapshot.analysis` and resolvable references in `analysis_explanation.calculations` / `analysis_explanation.measures`; missing required structure remains an error. Reviewer-readability and interpretation defects follow the bounded quality correction/warning procedure. Verify the stored snapshot and references in detail after submission. Never guess SQL, aliases, columns, formulas, time ranges, timezones, or successful execution. Definition inspection, evidence reads, validation, and submission are not proof of query results, approval, or certification.
+Ordinary recommendations prepare concise material for human review, not a full certification audit. Follow resolve/export -> select -> business-domain/subtopic grouping and concise reasons -> one local structure/evidence check plus focused preflight -> authorized submit-to-page -> one detail readback. LOCAL_ONLY stops at local artifacts. For each report, explain at least one core statistical measure or calculation with fact-supporting references rooted at `evidence_snapshot.analysis`; purpose alone is insufficient. Preserve current packaged analysis and `target_revision`, and add relevant population/filter/time boundaries when they affect that core meaning. Do not require every dimension, SQL output column or calculation step unless the user requests a full audit or a concrete risk needs that detail. Fetch `agent-review evidence` only for a missing/stale definition or a specific unresolved claim, not once per report or as routine spot validation. Preserve server facts separately from AI interpretation; never guess formulas, aliases, time ranges or successful execution. See `references/agent_review_submit_to_page.md` for the ordinary workflow and optional full-audit detail. Existing report-analysis, evidence-link and reference validation remains enforced.
 
 `item.ai_summary.summary` is the concise item recommendation reason, including its evidence basis and main risks, displayed in the main list. `batch.ai_summary.summary` is the batch overview and cannot replace item reasons. Detailed factual explanations belong only in `item.ai_summary.analysis_explanation`. Do not duplicate reasons or detailed analysis into presentation fields; keep `presentation_snapshot.analysisByItem` as `{}`. Do not invent a reason from unknown values; state missing evidence or uncertain risks explicitly rather than treating them as zero or absent.
 
@@ -108,7 +112,7 @@ Scripts may build the transport file, preserve IDs, copy evidence, normalize lin
 
 Page-visible review text is for human asset reviewers, not implementers. In `item.ai_summary.summary`, visible statements, and open questions, write plain business Chinese: what the asset is for, how it is calculated, which filters/date windows matter, and what the reviewer should confirm. Use event and property names from the current asset definition when they help the reviewer verify the calculation definition. Do not expose internal evidence, parser terms, temporary SQL aliases, or runtime parameter names such as `SAVED_REPORT_ONLY`, `DYNAMIC`, `REPORT`, `T1`, `a0`, `a1`, `Variable2`, `selector3`, `PartDate date1`, `source_path`, `evidence_snapshot`, raw JSON, raw SQL, hash/revision details, dashboard override warnings, timezone-not-saved notes, or claims about query execution unless the user explicitly asks for debug evidence. Convert internal values before display, for example `T1`/`day` becomes `按天`, and dynamic SQL caveats become business confirmation items such as “确认参数含义、默认日期范围和是否包含测试数据”.
 
-For real review-page submission, start with `analysis-meta governance-recommendation export --limit 20`. This is the initial candidate pool, not a required submission count. Follow the rejection filtering and bounded expansion procedure in `references/governance_recommendation_export.md`: hide each same-definition rejected dashboard's entire display branch, retain shared assets only under other retained dashboards, filter out already completed/authenticated, deferred, or in-flight assets as pending work, and expand an insufficient pool from 20 to 50 to 100, then stop. Expansion is for business-domain coverage, not unlimited workload: for recurring daily batches, target about 20-50 pending review assets, hard cap around 80, and balance roughly 3-6 visible domains with per-domain quotas before adding context. Use the latest successful export as the drafting evidence and report the actual reviewed scope plus overflow left for later batches. Do not compress eligible coverage into a few representative themes or submit only the first work unit unless the user requests a sample or diagnostic batch. Business themes organize the retained dashboard set; they do not replace its coverage. For recurring recommendation jobs, submit only business domains that still contain pending review assets; authenticated assets are supporting context under those visible domains, not standalone work. Do not write long Agent summaries for hidden domains or pure authenticated context.
+For real review-page submission, start with `analysis-meta governance-recommendation export --limit 20`. This is the initial candidate pool, not a required submission count. Follow current-state selection and bounded expansion in `references/governance_recommendation_export.md`: select currently uncertified assets by business value and evidence, keep authenticated assets only as necessary context, and expand an insufficient pool from 20 to 50 to 100, then stop. Earlier recommendations and review decisions do not remove an otherwise eligible asset. Expansion is for business-domain coverage, not unlimited workload: for recurring daily batches, target about 20-50 pending review assets, hard cap around 80, and balance roughly 3-6 visible domains with per-domain quotas before adding context. Use the latest successful export as the drafting evidence and report the actual reviewed scope plus overflow left for later batches. Do not compress eligible coverage into a few representative themes or submit only the first work unit unless the user requests a sample or diagnostic batch. Business themes organize the retained dashboard set; they do not replace its coverage. For recurring recommendation jobs, submit only business domains that still contain pending review assets; authenticated assets are supporting context under those visible domains, not standalone work. Do not write long Agent summaries for hidden domains or pure authenticated context.
 
 For dashboard recommendations, preserve optional location facts from Common: when a dashboard candidate or source dashboard includes `space_id` or `space_name`, copy those fields into the submitted dashboard item's `evidence_snapshot.definition.config` so the review page can show `所属空间`. Not every dashboard belongs to a space; missing space fields are valid and must not be invented, required, or used to filter out an otherwise eligible dashboard.
 
@@ -120,7 +124,7 @@ The full `evidence_hash` includes collection time and may change between preview
 
 If a retired split recommendation command or capability is accidentally probed and returns an error, treat that as a routing correction only. Do not use data from split recommendation commands or capabilities as the business source for a recommendation answer; rerun the current workflow through `analysis-meta governance-recommendation export`.
 
-For review-page drafting, material inspection, or local-only rehearsals, read `references/agent_review_preflight.md` and `references/agent_review_priorities_comparisons.md`. After item explanations, generate evidence-backed review priorities and compare related definitions across authoring chunks/topics; store `recommendation`, classified `comparisons` and `comparison_review` in item AI summaries. Review priority is not a certification decision, and similarity alone is not conflict. Use an independent fresh-context reviewer to compare all evidence (including `signals`) with saved sources and review item-specific meaning, priorities and paired definitions. The author corrects concrete findings at most 3 times for the whole packet, with independent re-review. If quality still fails, an already authorized submission continues with explicit unresolved-quality warnings; never claim PASS or reset the correction budget. Disclose unavailable review or incomplete coverage. Local-only intent always forbids submission. Quality assessment belongs to the Agent, not Common; structural validation, authorization and transport errors remain enforced.
+For ordinary review-page drafting, material inspection, or local-only rehearsals, use the focused scope in `references/agent_review_preflight.md`: programmatic evidence/identity/reference checks cover the entire exact packet; one independent semantic review covers every business domain/subtopic, its supporting member definitions and identified risk items. Do not require the reviewer to re-interpret every report, grade every metadata dependency or generate per-item comparison coverage. Load `references/agent_review_priorities_comparisons.md` only for requested prioritization, actual comparison/conflict clues or an explicit full audit. Optional priorities rank human review urgency, never certification outcome. Missing comparisons do not prove no conflict. Deepen checks only for the affected claims/peers; apply full definition-audit requirements when explicitly requested. Correct factual errors and unsupported membership, not ordinary copy preferences through routine rounds; the existing maximum 3 corrections is a ceiling for material findings. Record actual review scope, disclose unchecked/full-audit scope and unresolved findings, and preserve LOCAL_ONLY and submission authorization boundaries. These rules do not change approval, automatic certification, permissions or Common admission.
 
 ## Global AE CLI Rules
 

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

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

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

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