@thinkingai/ae-cli 6.0.53 → 6.0.54

package/skills/ae-analysis/scripts/project-semantic-knowledge-wiki/company-kb.mjs

@@ -1,13 +1,29 @@
 #!/usr/bin/env node
 import fs from 'node:fs';
+import path from 'node:path';
 import { spawnSync } from 'node:child_process';
 import { pathToFileURL } from 'node:url';
 
-const scoped = new Set(['+new', '+add', '+list-sources', '+schema', '+compile', '+status', '+import']);
+const scoped = new Set(['+new', '+add', '+list-sources', '+schema', '+compile', '+status', '+import', '+schema-download', '+schema-import', '+schema-import-list']);
 const requestScoped = new Set(['+import-status']);
 const directory = new Set(['+source-ls', '+source-read', '+source-put', '+source-rm']);
 const value = (args, key) => args[args.indexOf(key) + 1];
 
+export function invokeCompanyKbCli(flags, { spawn = spawnSync, localCli = path.resolve(import.meta.dirname, '../../../../bin/ae-cli.js') } = {}) {
+  // Packaged/project scripts use their matching CLI; standalone installed Skills retain PATH lookup.
+  const bundled = fs.existsSync(localCli);
+  const child = spawn(bundled ? process.execPath : 'ae-cli', bundled ? [localCli, ...flags] : flags,
+    { encoding: 'utf8', stdio: ['inherit', 'pipe', 'pipe'] });
+  if (child.stderr) process.stderr.write(child.stderr);
+  if (child.error) throw child.error;
+  if (child.status === 0) return JSON.parse(child.stdout);
+  // CLI failures are JSON on stderr, possibly surrounded by compatibility/progress messages.
+  const start = child.stderr.indexOf('{\n  "ok": false,');
+  const end = start < 0 ? -1 : child.stderr.indexOf('\n}', start);
+  if (end >= 0) return JSON.parse(child.stderr.slice(start, end + 2));
+  throw new Error(child.stderr || child.stdout || 'CLI process failed.');
+}
+
 // Project semantic KB operations must never fall back to a personal KB.
 export async function runCompanyKb(command, args, invoke) {
   if (args.some((arg) => arg === '--custom-instructions' || arg.startsWith('--custom-instructions='))) {
@@ -24,7 +40,9 @@ export async function runCompanyKb(command, args, invoke) {
   const call = async (cmd, flags) => {
     const result = await invoke(['kb', cmd, ...flags]);
     if (!result || result.ok !== true) {
-      throw new Error(`Company KB operation failed; stop without personal fallback: ${JSON.stringify(result?.error ?? result)}`);
+      const error = new Error(`Company KB operation failed; stop without personal fallback: ${JSON.stringify(result?.error ?? result)}`);
+      error.code = result?.error?.code;
+      throw error;
     }
     return result;
   };
@@ -98,12 +116,7 @@ function expandCustomInstructionsFile(args) {
 if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) {
   try {
     const [command, ...args] = process.argv.slice(2);
-    const result = await runCompanyKb(command, args, (flags) => {
-      const child = spawnSync('ae-cli', flags, { encoding: 'utf8', stdio: ['inherit', 'pipe', 'pipe'] });
-      if (child.stderr) process.stderr.write(child.stderr);
-      if (child.error || child.status !== 0) throw new Error(child.error?.message || child.stderr || child.stdout || 'CLI failed.');
-      return JSON.parse(child.stdout);
-    });
+    const result = await runCompanyKb(command, args, invokeCompanyKbCli);
     console.log(JSON.stringify(result, null, 2));
   } catch (error) {
     console.error(error.message);

package/skills/ae-analysis/scripts/project-semantic-knowledge-wiki/default-compile-rules.md

@@ -2,18 +2,29 @@
 
 These rules guide Schema generation for project semantic knowledge bases built from source tree ZIP uploads.
 
-- Generate durable compile rules only. Do not copy platform working directory names, absolute filesystem paths, temporary extraction paths, source IDs, run IDs, or local machine paths into the generated rules.
-- Refer to the uploaded material as "the ZIP source tree" or "files under the source tree root". Use stable source-tree paths such as `sources/assets/reports/...` only when a rule must mention a category.
-- Treat `sources/README.md` and category `README.md` files as filing guides. They define where future material belongs; they are not business evidence.
-- CLI-managed asset facts live under `sources/assets/**`. Human project background, business rules, meetings, decisions, corrections, and references live outside `sources/assets/**`; asset refresh must not delete or override those human inputs.
-- Organize generated Wiki pages for knowledge consumption, not by mirroring every source file. Use project overview, business domains, reusable semantics, assets, decisions, and review pages.
+- Generate durable rules. Never copy working directories, absolute or temporary paths, source IDs, run IDs, or machine paths. Refer to "the ZIP source tree" and use stable `sources/...` paths only when needed. README files are filing guides, not business evidence.
+- `sources/project/pskb-p*-refresh-state.md` and its numbered `-part-*.md` files are CLI machine state. Do not read, decode, cite, or compile them as business evidence; use the authored project and asset sources instead.
+- CLI-managed asset facts live under `sources/assets/**`. Adopted personal semantics exported by the asset package live under `sources/personal-semantics/**` and are also CLI-managed generated source. Human project background, business rules, meetings, decisions, corrections, and references live outside those generated directories; asset refresh must not delete or override those human inputs.
+- Organize generated Wiki pages by scope and business use, not by mirroring every source file. The primary navigation has five ordered entries: project overview, project-wide shared knowledge, business domains, event and asset catalog, and governance with provenance. Within each domain, explain the business question, judgment path, relevant events, metrics, assets, and boundaries. Keep asset-type pages as secondary evidence and lookup indexes.
+- Begin the root page with question-intent routing. Route business-state and current-value questions through the matching domain and recall card; route named assets and field/definition/dependency questions through the asset catalog and governance; route shared product background through project-wide knowledge. If no card matches, enter the relevant domain and filter assets by business object, answer grain, filters and time. If no suitable evidence remains, state the gap. Stop searching once the smallest authoritative evidence set matches object, grain, scope and time.
+- Each recall card must identify its triggering questions, business object and answer grain, required parameters, conditional branches with direct asset targets, excluded or non-interchangeable assets, a stop condition, and a fallback for unavailable, conflicting or unmatched evidence. Preserve these as instructions in the compiled card; a fixed preferred-then-fallback sequence is insufficient when branches use different definitions.
+- Public event groups are a project event lookup taxonomy. A group such as a product module is not automatically a business domain or an event definition. Only include events present in the exported asset scope, preserve their event-name identity, and link to the canonical event page. Never infer business meaning, certification, or domain membership from a group label alone. Personal event catalogs must not enter a shared project Wiki.
+- The project overview must start with the project-level business model: business positioning, audience roles, business objects, object relationships, decision chains, asset roles in those chains, and non-goals. Asset counts, snapshot hashes, source package metadata and build logs belong after that model. Do not reduce the overview to a directory, asset inventory, or build summary.
 - Do not infer business meaning from titles alone. Preserve unknowns, conflicts, source scope, certification state, and provenance when evidence is incomplete.
+- Distinguish query counts, distinct report counts, company counts and people counts; never substitute one grain for another from similarly named fields. A scoped personal-semantic method for customer report usage belongs only on its verified scenario card and must link the actual search event, company field, report-name field, report asset and adoption record. Mark unverified field equivalence or name uniqueness as unknown.
+- If the governed package contains neither certified entry assets nor adopted personal semantics, compile the uploaded empty skeleton as an explicit unknown-state Wiki with the normal five navigation layers. Do not invent business domains, decisions, metrics, or asset definitions. When later evidence replaces the skeleton, remove obsolete empty-state claims from the published Wiki.
 - Corrections and decisions override other material only when they state target, content, date, status, and applicable scope.
 
 
 ## Navigation and page naming
 
-The generated top-level `index.md` must be a decision-oriented navigation page. It may contain only module navigation, common-entry guidance, and a compact category/count overview. Do not append a complete page list, sitemap, individual asset files, metadata property pages, numeric report IDs, numeric dashboard IDs, source container IDs, or raw source filenames to the top-level page. Top-level navigation should link to project overview, business domains, recall cards, asset category indexes, decisions, and review pages. List individual assets only inside the matching asset index page, domain page, dashboard page, source-container page, or search result context. If the compiler wants to expose a full sitemap, put it under `wiki/index.md` or category index pages, never in root `index.md`.
+The top-level `index.md` is decision-oriented. Keep its five primary entries; do not add a sitemap, individual assets or properties, numeric IDs, containers, or raw filenames. Put recall cards under domains, event groups under the event map, asset indexes under the catalog, and individual assets in category/domain/container pages. A full sitemap belongs in `wiki/index.md` or category indexes, never the root.
+
+Both indexes use these primary targets: `wiki/project-overview.md`, `wiki/common/index.md`, `wiki/domains/index.md`, `wiki/asset-index/index.md`, `wiki/governance/index.md`. Put `wiki/event-map/index.md` below the catalog; keep asset, card, and adoption pages reachable below the five entries.
+
+Adopted personal semantics are source provenance, not a top-level knowledge category. Integrate each accepted conclusion into its declared project, domain, recall-card, or asset target with its applicable boundary; retain a knowledge-adoption record under governance. A personal preference remains scoped and must not be turned into a project-wide rule merely because it was adopted. Use the label "project supplementary knowledge" for the integrated content and "knowledge adoption record" for its provenance.
+
+Navigation taxonomy version 2.1 adds root intent routing and conditional recall-card execution. On a refresh from an older version, perform a full Wiki rebuild from current sources and regenerate the root index and cards; do not reuse obsolete published pages or retain an old top-level personal-semantic page. Preserve human source files and current canonical asset facts. After publication, verify routing, no-card fallback, card branches, stop conditions and all five navigation entries. A valid file count alone does not prove answer quality.
 
 When linking to an individual asset, use its business title as the visible link text and keep the numeric ID only as supporting identity beside the title, for example `示例报表（report 1001）`. Do not render bare numeric links such as `1001` as navigation items.
 
@@ -21,10 +32,17 @@ When linking to an individual asset, use its business title as the visible link
 
 CLI Agent has already performed the main semantic compilation for ALL assets: business meanings, SQL interpretation, calculation definitions, relationships, domains, recall boundaries, and conflict findings. These are editable source documents, not an imported final Wiki snapshot. Reuse their complete prose and calculation facts. Do not repeat project-wide extraction, SQL parsing, semantic planning, or per-field rewriting.
 
-Business-domain pages include an `Agent 使用摘要` for first-hop routing. Preserve it as the concise answer source for "what does this domain solve", "which events/metrics are mainly used", and "which dimensions should the agent drill down by". Do not replace it with a raw report list or regenerate it from every report page unless newer scoped evidence explicitly changes the summary.
+Consume adopted personal semantics by type: `background` informs context, `preference` informs routing and style, `experience` supplies proven cautions, and `asset_context` annotates an existing referenced asset. Retain person name, source/update time, source IDs, and scope; never expose `open_id`. Fuse similar conclusions without widening scope. They cannot override governed definitions, SQL facts, corrections, decisions, or live results.
+
+Business-domain pages need a judgment model and `Agent 使用摘要` for first-hop routing: business state, objects, signals, decision path, primary/supporting/drilldown/excluded assets, events, metrics, and dimensions. Do not replace this with a report list or regenerate it without newer scoped evidence.
+
+Reject or repair any generated Wiki shape where the root, overview, or business-domain pages only list questions, events, metrics, dimensions, reports, dashboards or counts without explaining the business judgment chain that makes those assets useful. Examples in source instructions are illustrative only; never hardcode project-specific business domains, assets, metrics, event names or decision chains into the compiled Wiki.
+
+Compile and publish the Wiki with prepared asset sections, linked references, concise titled navigation, and scoped human context. Batch independent writes and link checks; reuse unchanged pages.
 
-KB must compile and publish the final Wiki: preserve prepared asset sections, map source references to Wiki links, build concise titled navigation, and integrate project background, meetings, decisions and corrections. Batch independent page writes and link checks. Do not read each source repeatedly or regenerate unchanged pages.
+For SQL assets, keep Agent-authored purpose, parameters, output fields, grain, filters, limits, applicable/non-applicable questions, and evidence locator in one `Agent 使用摘要`. Raw SQL/index JSON stays local; do not infer missing details. Keep unknowns, certification, dependency-only status, conflicts, and blocked recall; do not dismiss safety states as stale placeholders. Never expose `CLI Agent`, `摘要来源`, `semantic_plan`, parser fallback, or builder/debug terms in Wiki prose.
+- `dependency_only` is an answer-authority limit, not a blanket ban on retrieval. Known metadata may support definition, dependency or conflict explanations. It cannot independently prove business state or live numeric results. If platform permissions block direct metadata retrieval, follow its authorized referencing asset and say what remains unverified.
 
-For SQL assets, preserve the complete Agent-authored purpose, parameters, output fields, grain, filters, limits, applicable/non-applicable questions and evidence locator in the report page's single `Agent 使用摘要`. Raw SQL/index JSON stays in the local evidence package; do not attempt to fetch it or infer omitted details. Missing facts remain unknown. Preserve certification, dependency-only status, conflicts and blocked recall; do not dismiss safety states as stale placeholders.
+For non-SQL reports, keep `Agent 使用摘要` useful for business routing, not a mechanical parser echo. Purpose and applicable questions must differ. Preserve evidenced metrics, dimensions, and filters; where unavailable, direct the reader to confirm in the source report instead of using broad `未识别/未发现` placeholders.
 
-During incremental compilation, inspect changed sources and their existing dependent pages. Update affected asset pages, indexes and cross-source conclusions; retain unrelated pages. Remove obsolete current assertions when a source changes or is removed. Integrate human evidence according to explicit scope, status and authority, never recency alone. Scope differences belong separately from same-scope contradictions. Preserve provenance to the actual uploaded source.
+During incremental compilation, update changed sources and dependent pages, indexes, and cross-source conclusions; reuse unrelated pages and remove obsolete assertions. Adopted personal semantics share generated sources' paths, hashes, and add/replace/remove lifecycle. Integrate human evidence by scope, status, and authority rather than recency; distinguish scope differences from contradictions and preserve uploaded-source provenance.

package/skills/ae-analysis/scripts/project-semantic-knowledge-wiki/default-compile-schema.md

@@ -0,0 +1,66 @@
+# 项目语义知识库编译准则
+
+预置版本：1.1。导航分类版本：2.1。
+
+## 总体要求
+
+将项目语义源文件编译为有证据支撑的 Wiki，供分析 Agent 和知识维护者使用。保留项目层面的业务模型、资产定义、判断路径、问题路由、有明确适用范围的补充知识及其来源。当前数值、实体列表和趋势必须通过实时执行获取。项目名称、业务对象、事件名称、指标、资产身份和结论均以当前源文件为准，不得从本预置准则中推定。
+
+本文件是可持续复用的编译指令，不是要求再次生成编译准则的提示词。首次构建与增量编译使用同一套准则；全量重建也无需重新生成准则。只有经过明确审查的准则变更，才可升级预置版本。
+
+## 源文件职责与读取方式
+
+- `raw/` 存放已上传的源文件，只允许读取；仅当前平台插件明确授权的 URL 更新除外。`wiki/` 存放编译后的页面。根目录 `index.md` 用于导航。
+- 一个 ZIP 对应一个父源文件。使用本次执行提供的固定目录树，完整读取其中有效的业务文件，不得扫描目录树以外的内容。保留真实的父级 `sourceId` 和实际吸收的原始子文件精确路径；子文件不是独立源文件。URL 源文件同样保留平台提供的 `sourceId` 和实际吸收的子文件精确路径。不得编造身份标识或来源路径。
+- README 是归档说明，不是业务证据。清单文件、刷新状态索引及其编号分片、哈希、日志和机器状态均不是业务证据，不得解码后编译为 Wiki 事实。应使用已编写的项目与资产源文档。
+- CLI 管理的资产事实位于 `sources/assets/`；已采纳的个人语义位于 `sources/personal-semantics/`。人工补充的项目背景、会议、决策、纠正和参考资料属于独立证据。刷新时必须保留人工文件和未预期的手工修改。
+- Markdown、文本、CSV、SVG 等文本格式优先使用 Read；长文本须分页读至末尾。获得完整、可用的语义后停止解析。读取失败时处理编码或格式问题，不得运行无关解析器。其他格式遵循当前插件的源文件解析约定，包括首选工具、有界回退、完整覆盖工作表或页面，以及失败退出方式。图片也优先使用 Read，只有语义提取失败或结果不可用时，才允许使用插件支持的回退方式。不得依据模型名称决定解析顺序，也不得在编译过程中安装解析器。
+- 记录真实的失败情况，包括源文件身份、精确原始路径和失败原因。不得用笼统断言补齐缺失事实，也不得将解析失败表述为成功。
+
+## 上游已编写语义的复用约定
+
+上游 Agent 已编写业务含义、SQL 解释、计算事实、关系、业务域、召回边界和冲突说明；这些内容是可编辑的源文档。应复用其完整表述和证据，不得重复开展全项目提取、SQL 解析、语义规划或逐字段改写。只有发现具体矛盾或更新且适用范围明确的证据时，才重新审视已有解释；冲突无法解决时保留不确定性。
+
+项目概览首先呈现项目层面的业务模型：项目定位、受众角色、业务对象及其关系、业务判断链、资产作用和不覆盖的目标。源文件清单与数量是辅助信息。业务域应解释需要判断的状态、对象、信号、决策路径、主要资产、辅助资产、下钻资产、排除资产和适用边界，不得用报表列表代替。缺失的业务证据应明确标为未知；空的源文件骨架不得被扩写成虚构的业务模型。
+
+每项资产保留一份由 Agent 编写的业务摘要。SQL 报表摘要包含用途、参数、输出字段、统计粒度、筛选条件、限制、适用与不适用的问题，以及证据定位。非 SQL 报表应区分用途与可回答的问题，保留有证据的指标、维度、筛选条件和限制，不得机械复述解析器输出。定义细节缺失时，要求回到源报表确认。原始 SQL 和原始索引 JSON 保留在本地证据包中。
+
+不得将安全状态当作过时占位信息而忽略。保留认证状态、定义有效性、冲突、运行时策略和召回限制。已认证的资产仍可能存在定义未知的情况。仅作为依赖的资产可以解释定义、依赖关系和冲突，但不能独立证明业务状态或当前结果。遵守平台访问权限；权限不足时，不得改用其他项目或扩大范围来替代。
+
+## 权威性与补充知识
+
+- 资产定义、治理事实和实时结果保留各自的权威性。决策或纠正仅在明确的目标、内容、日期、状态和适用范围内覆盖其他材料；时间较新本身不足以构成覆盖依据。
+- 已采纳的背景知识用于补充上下文；偏好用于问题路由和呈现；经验用于提供注意事项；资产上下文用于注释已引用的既有资产。保留来源人员的显示名、来源或更新时间、采纳来源和适用范围，不得暴露后端私有用户标识。
+- 将结论整合到其对应的项目、业务域、问答卡片或资产页面。采纳个人语义不意味着将个人偏好提升为全项目通用规则，也不意味着替换资产定义。在治理目录中保留知识采纳记录。目标已删除或失效时，必须明确按历史信息处理。
+- 保留未知项和冲突。不得仅凭标题或分组标签推断业务含义、字段等价关系、唯一身份、事件定义或认证状态。合并事实前须核对业务对象、统计粒度、筛选条件、范围和时间。
+- 公共事件分组是检索分类，不自动构成业务域或事件定义。仅纳入导出范围内有证据的事件，并保留实际名称。个人事件目录不得转为项目共享知识。
+
+## 导航与页面命名
+
+一级导航按以下五项顺序组织，让业务问题有入口，让资产目录提供进一步的证据：
+
+1. 项目概览：`wiki/project-overview.md`。
+2. 项目公共知识：`wiki/common/index.md`。
+3. 业务域：`wiki/domains/index.md`。
+4. 事件与资产目录：`wiki/asset-index/index.md`。
+5. 治理与来源追溯：`wiki/governance/index.md`。
+
+事件分组保留在 `wiki/event-map/index.md` 下，通过资产目录访问。问答卡片归入对应业务域；单项资产页面放入匹配的报表、看板、指标或元数据分类。新增页面应进入适当的既有分类。已采纳个人语义属于来源信息，不单独设为顶层知识分类。页面名使用基于标题的稳定短横线命名（kebab-case），ID 仅作为辅助身份信息。
+
+根目录 `index.md` 与存在时的 `wiki/index.md` 通过相同的五个一级入口导航。根目录 `index.md` 不含 YAML 元数据头、来源详情、格式化器（Formatter）内容、构建日志或页面元数据。一级模块最多八个，直接 Wiki 链接最多十二个。不得平铺单项资产，也不得使用裸数字作为链接文本。同类详情页面达到三个时使用分类索引；完整站点地图放在下级索引中。每个已发布页面都必须能从根目录沿链接逐级访问。
+
+## 问题路由与召回卡片
+
+根导航首先按问题意图提供入口。业务状态和当前数值问题进入匹配的业务域与卡片；指定资产、字段、定义和依赖问题进入资产目录与治理；共享产品背景进入公共知识。没有匹配卡片时，在相关业务域内按对象、回答粒度、筛选条件和时间筛选资产；证据不足时明确说明缺口。
+
+保留每张卡片的触发问题、适用范围、对象与回答粒度、必需参数、直接指向资产的条件分支、排除或不可互换的资产、停止条件，以及资产不可用、证据冲突或无匹配时的回退方式。不得将条件分支替换为统一的“首选资产、失败后备用资产”列表。缺失的路由或参数必须明确保留为缺口，不得编造。找到与对象、粒度、范围和时间匹配的最小权威证据集合后，停止扩展检索。当前数值、实体列表、趋势和明细结果必须通过已获授权的实时报表或查询执行获取。
+
+## 页面元数据与来源追溯
+
+每个 `wiki/**/*.md` 页面均以 YAML 元数据头开始，包含 `title`、`type`、`depth`、`related` 和 `source`；使用 ZIP 或 URL 证据时还须包含 `sourceId`。`type` 取值为 `overview`、`concept`、`guide`、`reference`、`synthesis` 或 `faq`；`depth` 取值为 `overview`、`detail` 或 `howto`；`summary` 为可选字段。使用真实的原始文件相对路径和真实父源文件身份，不得因存在来源字段就编造路径。正文中的来源引用使用纯文本路径，不使用指向原始文件的 Markdown 链接。Wiki 正文不得暴露凭据、宿主机路径或内部构建与调试标记。
+
+## 刷新与发布前检查
+
+增量编译应更新变化的源文件、依赖页面、索引和跨源结论，复用无关页面。源文件发生变化或消失时，移除过时的当前结论。已采纳个人语义同样遵循新增、替换、删除的生命周期。保留人工证据、手工内容和未变化的事实。导航迁移可以要求全量重建 Wiki，但不因此重新生成或替换正式准则。
+
+发布前检查元数据头、真实来源、链接、根目录可达性、全部五个一级入口、卡片分支和停止条件、权威性限制、冲突以及过时结论。相关链接与索引应一并修复。源文件和页面数量完整不等于回答质量合格。发布必须成功结束，且抽查召回页面应保留源文件定义、人工补充内容的适用边界和导航。发布失败时，不得将源文件已上传或编译已排队表述为已发布知识得到更新。